Day: October 29, 2015

Executive Summary

The Palo Alto Networks vision for threat information sharing is that cybersecurity vendors should share the intelligence that they all individually collect with each other and with whomever else has the capacity to consume it. In that way, each vendor can build more innovative products with that superset of intelligence and better protect their combined customer bases because of it.

Project Redstone, the results of which we announced today, was a 90-day proof-of-concept designed to test the value and practicality of security vendors collaborating against one cyber adversary campaign in the summer of 2015: the campaign associated with CryptoWall version 3.  The project showed immediate tactical success and demonstrated the value of such a collaborative information sharing arrangement. That said, the project also identified four capability gaps that Palo Alto Networks must solve in order to share intelligence on 5,000 adversary campaigns, every day in real time:

1. How to convert large volumes of Indicators of Compromise into prevention controls;
2. How to measure alliance member contributions with more granularity;
3. What is the common set of success metrics for deployed security controls across Alliance membership; and
4. What is the right sharing architecture that works at scale.

Introduction

Palo Alto Networks has a bold vision about threat Information Sharing. We believe that cyber threat intelligence collected by security vendors should be shared by all. We believe that the intelligence all security vendors collect through their vastly deployed product sets should not be marketed individually to promote product differentiation or rolled out as an additional revenue stream. Instead, we believe that all security vendors should have access to the same threat intelligence so that individually each vendor can build better and more innovative products to protect its customers. Those innovations are how the security vendors will distinguish their products in the market place. More importantly, the result of that cooperation among security vendors will exponentially provide better threat prevention capabilities to the shared global customer base. Palo Alto Networks helped found the Cyber Threat Alliance with that vision in mind.

Officially formed on September 4, 2014, with nothing more formal than a common Non-Disclosure Agreement (NDA), the Cyber Threat Alliance members began working through the issues of how a group of competitive security vendors could share threat intelligence with each other. Two issues became paramount: building trust between all members and establishing an infrastructure that could facilitate the sharing of large volumes of threat intelligence.

While the Cyber Threat Alliance began working those two issues, other security vendors who agreed with the vision came on board: Barracuda, ReversingLabs, Telefonica, and zScaler. At the White House Summit on Cybersecurity and Consumer Protection held at Stanford University in February 2015, President Obama signed an executive order directing the creation of new Information Sharing and Analysis Organizations (ISAOs) and praised the Cyber Threat Allianceas a model for the way forward.

Three organizational principles distinguish the Cyber Threat Alliance from other existing information sharing groups.

• The first is that every participating member must contribute. No members can simply consume the shared intelligence. They must share in equal quantities and the Cyber Threat Alliance measures the volume and quality of intelligence contributions daily to ensure compliance.
• The second is that whatever is shared by individual members is deployed across all other members’ product lines. For example, when Palo Alto Networks shares malware samples with the Cyber Threat Alliance, all other Cyber Threat Alliance members use that intelligence to strengthen their individual product sets and vice versa.
• The third is that Alliance members will update their security controls to their deployed products within their respective customer bases without the customer having to review and install themselves. In the traditional ISAC (Information Sharing and Analysis Center) modelfor example, customers must decide that they want to share intelligence. They have to package it up and send it off to their respective ISAC Security Operations Centers. Once the new intelligence arrives, the ISAC Security Operations Center must process the information, transform it into useful intelligence and distribute it to the other ISAC members. Once the ISAC members receive the new intelligence, they have to read it, understand it, decide if it is pertinent to their organization and if it is, develop security controls for their organization and deploy them in a timely manner. The process provides good intelligence, but it is also slow and cumbersome. The Cyber Threat Alliance system eliminates the customer as a middleman. Alliance members automatically deploy the right security controls to their deployed systems making the process more efficient for their respective customer bases.

In June 2015, the Alliance founding CEOs met to discuss the next steps for the Cyber Threat Alliance. Now that trust had been established and a rudimentary infrastructure had been built, where should they take the organization?

The original charter stated that all members would share 1,000 unique malware samples with each other daily as the price of admission to the Cyber Threat Alliance. But security experts estimate that adversaries create approximately 1 million unique pieces of malware a day. The CEOs understood that 1,000 shared samples a day between Alliance members is not that significant. On one hand, having competitors share and collaborate on threat intelligence is a good thing for the security industry. On the other, if we are going to go through all this effort, shouldn’t it be for some meaningful goal?

The Big Hairy Audacious Goal (BHAG) that emerged was what if the Cyber Threat Alliance members decided to share adversary campaign information with each other? Instead of simply sharing newly discovered malware, what if the Cyber Threat Alliance dedicated itself to sharing the entire playbooks, the Indicators of Compromise throughout the cyber attack lifecycle, for every cyber adversary operation that is known? The implications of that idea could be a game changer.

Experts from the Cyber Threat Alliance estimate that the number of adversary campaigns that exist in the world at any given time could be as many as 5,000. This is not the number of attacks. This is the number of existing playbooks that adversaries use to conduct those attacks on multiple victims. Other experts not in the Cyber Threat Alliance say the number is higher — roughly 25,000 — and others say it is much smaller, roughly 500. Regardless of the actual number, what is interesting is that the number is not 1 million or even 100,000. The number of existing adversary playbooks is in the thousands. Analysts can track a thousand items in a spreadsheet. This is a manageable number, and that means something that can be done if the Cyber Threat Alliance focuses the right resources on the problem.

If the Cyber Threat Alliance was able to share Indicators of Compromise (IOCs) down the cyber attack lifecycle for every adversary campaign that is known, members of the Cyber Threat Alliance could automatically deploy threat prevention controls to their products and to their customer base potentially in real time. If the Cyber Threat Alliance membership grew large enough, the membership roles would reach a tipping point where every organization – commercial, government and anything else – that connects to the Internet would have at least one Cyber Threat Alliance member’s product deployed within their networks helping to defend it against attacks. At that point, every organization on the planet connected to the Internet will have the latest and greatest attack prevention controls within minutes of discovery.

That is a bold and disruptive idea and it could revolutionize the business.

The founding CEOs decided to run a proof a concept. Instead of tackling 5,000 adversary campaigns at once, they tasked the group to focus on one campaign: collaborate on one playbook to see if the intelligence collected and shared amongst members is better than what the individual Alliance members collect on their own. And they gave the team 90 days to do it. The name of the project was called Redstone and the CEOs met on October 1, 2015, to discuss the results.

Project Redstone: “Lucrative Ransomware Attacks: Analysis of the Cryptowall Version 3 Threat

The Cyber Threat Alliance intelligence analysts focused on the adversary campaign associated with the malware called CryptoWall version 3. CryptoWall version 3 is a nefarious piece of ransomware that encrypts the data on victim’s laptops and consequently demands payment in return for the key that can unlock the data. It is one of the most lucrative and broad reaching ransomware campaigns affecting the customers of the Cyber Threat Alliance members today. Project Redstone was the Cyber Threat Alliance’s attempt to work collaboratively to disrupt this ransomware campaign.

The Cyber Threat Alliance founding members handpicked their best intelligence analysts for Project Redstone. The analysts worked independently during the week but collaborated daily through a chat program called Slack. They conducted weekly progress meetings with the Cyber Threat Alliance working committee to receive guidance and resource support. They deployed a CryptoWall version 3 tracker for public consumption and posted it on the Palo Alto Networks website. This will track new instances of CryptoWall version 3 emerging in the future. During the 90 days, they drafted a white paper describing the results of their research.  In the end, they discovered that each founding member knew something about the CryptoWall version 3 campaign that the others did not. In total, after they finished their research, the combined analyst team identified the following:

• $325 million in estimated revenue generated by the adversary campaign
• 406,887 attempted infections across the Cyber Threat Alliance customer base
• 839 Command & Control URLs used by the campaign
• 5 Second Tier IP Addresses used for Command & Control by the campaign
• 49 Campaign Code Identifiers attributed to the campaign

Palo Alto Networks Information Sharing Capability Gaps

In addition to participation in the Cyber Threat Alliance, Palo Alto Networks also shares threat intelligence with other non-vendor organizations and individuals who have the capacity to consume it and whom are willing to share with us. With all of these relationships, the types of sharing generally fall into two buckets.

The first bucket contains large collections of Indicators of Compromise that have no context about specific adversaries at all. They are simply collections of random bad guy activity that somebody, somewhere declared was malicious. This is not helpful. Single Indicators of Compromise by themselves, even if you have a large set of them, are prone to false positives. In order to give them validity, you have to attribute them to the playbook of an adversary. In that way, your Security Operations Center is not looking for a single Indicator of Compromise. Your Security Operations Center is looking for a percentage of Indicators of Compromise about one adversary. If you only see 1/100 in your network, your confidence that a specific adversary is in your network is not high. But if you see 60/100 in your network, your confidence is very high that a specific adversary has compromised your network.

The second bucket usually contains Indicators of Compromise about one adversary. While this is useful as far as it goes, it is not enough. We want to track 5,000 campaigns, every day, in real time.

If the industry is going to make this information sharing concept useful, we need a different bucket. We need a bucket that contains the changes noticed by the information sharers about 5,000 adversary playbooks every day. That is a big ask and we can’t do it today unless we solve some technical issues. From a Palo Alto Networks perspective, there are four research gaps that we must close in order to make this thing work at scale:

1. Convert Large Volumes of Indicators of Compromise into Prevention Controls: The first capability gap that Palo Alto Networks must solve is how to ingest large volumes of newly discovered Indicators of Compromise from outside sources and convert them into brand new prevention controls for our product line. About half way through Project Redstone, Palo Alto Networks realized that the combined Cyber Threat Alliance intelligence team was discovering reams of new Indicators of Compromise, but we did not have the ability to quickly turn them into prevention controls for our customer base. This was a semi-manual process for us and this does not scale.

2. Measure Sharing Contributions with More Granularity: The second capability gap we have to solve is how to measure the value of information shared. Our initial thought was that counting Indicators of Compromise down the cyber attack lifecycle, or Kill Chain, from each sharing partner might be sufficient. But Project Redstone showed us that not all Indicators of Compromise are created equal. On the one hand, a sharing partner might provide 100 Indicators of Compromise that are so common that intelligence analysts from Unit 42, the Palo Alto Networks threat intelligence team, will not be able to distinguish them among multiple adversary campaigns.

In other words, they do not help us identify the specific adversary campaign we are trying to track. On the other hand, another sharing partner might provide one Indicator of Compromise that is the linchpin to attributing the entire campaign. Clearly, counting Indicator of Compromise volume between sharing partners is not the right metric. Further, using the Kill Chain to categorize Indicators of Compromise might not be sufficient either. Distinguishing Indicators of Compromise in the Recon, Delivery and Installation stages of the lifecycle is very difficult. A new approach might be called for or if not, we have to get a lot smarter about how to do it with the cyber attack lifecycle model.

3. Develop Common Success Metrics for Deployed Security Controls: The third capability gap that the security community must develop is a way of collecting success metrics for deployed security controls. When the Alliance analysts finished their research and each individual member company finished deploying their prevention controls to their respective product lines, all Alliance members struggled with capturing meaningful metrics that demonstrated that the deployed prevention controls stopped actual adversary activity. First, since all Alliance members have their own language around how to describe this activity, there was no common language to normalize the information. Second, all security vendors struggled with their respective customer bases about what intelligence is acceptable to share from the customer enterprise to the security vendor intelligence cloud. There are many reasons for this, privacy concerns are the chief among them, but security vendors and their respective customer bases must come to terms with the idea that sharing bad guy information is not sharing company secrets. If the security community wants to establish meaningful metrics around the security controls we all deploy, we have to come to terms with this notion.

4. Identify the Sharing Architecture that works at Scale: Finally, the fourth, and probably most important capability gap, is the sharing infrastructure. In parallel to Project Redstone, the Alliance technical team started to build out the first working STIX/TAXII instance for the Cyber Threat Alliance members. They did not finish their work until after the research for Project Redstone was complete. Project Redstone analysts relied on their chat program and a shared Box folder to exchange information. This is highly inefficient, does not scale and demonstrates the need for an installed information sharing infrastructure. Further, Cyber Threat Alliance analysts are beginning to suspect that STIX/TAXII may not be the sharing standard that we need for this kind of research. For what we are trying to do, the STIX/TAXII framework has some limitations namely in the area of scaling. At Palo Alto Networks, we either need to determine how to use STIX/TAXII more efficiently or adopt a new framework altogether.

Palo Alto Networks Future State for Information Sharing

In order for Palo Alto Networks to pursue the vision articulated by the Cyber Threat Alliance Founding CEOs — that members of the Alliance will innovate their product lines based on a common shared intelligence and exponentially protect their respective customer bases at the same time – a focus on scaling the Palo Alto Networks operation is required.

In order to track the changes in approximately 5,000 adversary campaigns daily, share that intelligence with all of our sharing partners, and convert that intelligence into real prevention controls for the Palo Alto Networks customer base in a timely and efficient manner, the capability gaps identified above must be closed. For the next six months, the Unit 42 technical team will focus their efforts on these issues.

Conclusion

The vision of the Cyber Threat Alliance is a classic BHAG (Big Hairy Audacious Goal). Project Redstone was the Alliance’s proof of concept that the vision is possible. While the result showed some immediate tactical success, Palo Alto Networks realizes that there are four capability gaps that must be solved in order for the effort to scale. These are all hard but solvable problems. I am hopeful. In the mean time, when non-Alliance vendors come to your door to pitch their wares, ask them why they are not member of the Cyber Threat Alliance. We currently have eight members. We want 50 and we need their help.

Rick Howard

[Palo Alto Networks Blog]

In recent years, there have been a number of high-profile stories involving the compromise of point of sale (PoS) devices. My research often involves deep reverse engineering and analysis of various malware families targeting PoS devices. As such, I’m often asked about the overall threats that these machines face. In this article I hope to provide a high-level view of the threat landscape currently affecting PoS devices.

Background

The term PoS refers to a machine used by businesses to conduct a retail transaction. If you have ever used a debit or credit card to make a purchase, you’ve likely seen these machines. They often run customized hardware and software, however, the underlying operating system (OS) is more commonly some version of Microsoft Windows, often Windows XP or Windows 7. This trend has shifted slightly in recent years with the popularity of mobile PoS devices, most of which run either Android or iOS. While these are becoming more common in smaller businesses, Windows-based PoS machines still make up the majority, and by association are the devices most heavily targeted by attackers.

Figure 1. Example PoS machine

Infiltration

While PoS devices can be attacked in many ways, the method of infiltration typically falls into one of the following three categories, listed by least sophisticated to most sophisticated:

1. Spam emails / Exploit kits
2. Scanning the Internet for default or common credentials
3. Compromising trusted third parties

Spam Emails / Exploit Kits

These types of attacks are widespread and are often leveraged by attackers who are looking to infect as many machines as possible. Botnet owners are often seen leveraging these attacks to add further devices to their botnets.

Unfortunately, a number of organizations that own PoS machines use them as they would a personal computer. They browse the web, check email, and conduct day-to-day operations from the same machine that is conducting financial transactions. Attackers discovered that while infecting a large number of machines on the Internet, they were also infecting a small number of PoS devices as well. One such example of how PoS devices can be misused was demonstrated on Reddit, where a user discovers that he/she can access the site on their PoS. While accessing this site alone does not pose any significant security issues, it demonstrates how PoS devices can be misconfigured to allow users to access websites and Internet-based resources that should be blocked. Because of the lack of security controls on these devices, spam emails and exploit kits are able to infect these machines and subsequently steal financial data from them.

Internet Scanning for Default or Common Credentials

While more common in past years, this particular type of threat still represents a portion of attacks against PoS machines. Many PoS vendors configure their devices with remote administration services, such as Microsoft Remote Desktop, VNC, pcAnywhere, or LogMeIn. These services allow vendors to update and configure PoS machines remotely. As PoS machines may be located in geographically diverse regions, this is commonly built-in as a necessity.

Unfortunately, these services are often are configured to communicate and be accessible directly from the Internet, which allows both administrators and attackers alike to connect and attempt authentication. Additionally, these remote management services are frequently configured with default usernames and passwords. Knowing these combinations of usernames and passwords, attackers will continually scan the Internet in the hopes of identifying systems that can be accessed in such a way. A number of free utilities are available online that are designed for such tasks, making it trivial for individuals online to identify and subsequently compromise misconfigured PoS machines described.

At a recent RSA conference, researchers unveiled that a major PoS vendor had included a default username and password for all of their products for roughly 25 years. Misconfigurations such as these by both vendors and those configuring PoS machines allow attackers to obtain unauthorized access.

Figure 2. Example Remote Desktop brute force login tool

Compromising Trusted Third Parties

In one of the most sophisticated techniques seen to date, attackers have begun targeting trusted third party organizations in order to gain access to PoS machines.  This trend has been seen in recent years, with the Target breach being the most well known example. In that particular instance, an intrusion at the organization’s HVAC contractor was used to gain access to Target’s PoS machines.

Additional third party organizations, such as point of sale integrators, have been increasingly targeted in the past two years. PoS integrators are organizations responsible for the installation and maintenance of PoS machines for their clients. These organizations are often the victim of targeted attacks where spear-phishing emails and other ploys are used to compromise their networks. Once compromised, the attackers use stolen credentials, as well as the trust of the integrators networks to pivot and compromise PoS machines on their client’s networks. This tactic has been deployed heavily by the attackers behind the Backoff PoS malware family, impacting over one thousand US-based companies in 2014.

Malware Types

PoS malware is described in four categories:

• Network Sniffer
• File Scraper
• Keylogger
• Memory Scraper

Due to improvements in both PCI regulations as well as general security surrounding PoS machines, network sniffers and file scrapers are rarely, if ever, seen today. Not only did network sniffers provide track data sent across the network unencrypted, but they also had the ability to extract other sensitive information, such as credentials sent across the network. Such information could be used by attackers to gain access to other systems on the network. Alternatively, file scrapers had similar abilities, where both card data and other sensitive data on the victim machine could be identified and subsequently used by attackers. From 2007 to 2009, especially, these types of malware families were prevalent.

Since then, keyloggers and memory scraping malware families have become commonplace in PoS breaches. Keyloggers can work in a number of ways, however, one of the most common ways is to create a message-only window via a call to CreateWindow. The malware will then register a new input device via a call to RegisterRawInputDevices, which is in turn used to capture keyboard input data. Additionally, keyloggers will often also capture screenshots of the desktop to provide the attacker with more information about the victim machine.

Figure 3. Example of malware implementing keylogging functionality

Memory scrapers typically work in a small number of ways. They will begin by obtaining a handle to a process that the malware wishes to target. These processes are typically discovered via calls to either CreateToolhelp32Snapshot or EnumProcesses. At this particular stage, memory scrapers will often employ either a blacklist approach, where common process names are ignored, or a whitelist approach, where only a small subset of known process names are targeted. As an example, the svchost.exe process might be ignored, while the frmweb.exe process might be targeted.

Once a process is identified and a handle is obtained, memory scrapers will iterate through pages of memory using the VirtualQuery function. Further checks are often performed during this particular stage. Namely, a good memory scraper that is targeting track data will typically only look at pages that are set with read/write permissions and has a state of MEM_COMMIT. This allows the malware to ignore free or reserved memory, or memory that contains code, which in turn will improve performance.

After a page of memory is identified, the malware will actually read it via a call to ReadProcessMemory. After the memory has been read into a buffer, it will commonly apply a regular expression against this data, or feed the buffer to a function that is responsible for identifying track1 and track2 data. An example of some regular expressions witnessed in the wild can be seen below:

• \d{15,19}=\d{13,}
• \?
• ((B(([0-9]{13,16})|([0-9]|\\s){13,25})\\^[A-Z\\s0-9]{0,30}\\/[A-Z\\s0-9]{0,30}\\^(0[7-9]|1[0-5])((0[1-9])|(1[0-2]))([0-9]|\\s){3,50})|(((37)|([4-5][0-9])|(60))[0-9]{13,14}(D|=)(0[7-9]|1[0-5])((0[1-9])|(1[0-2]))[0-9]{8,30}))
• ((b|B)(([0-9]{13,16})|([0-9]|\s){13,25})\^[A-Za-z\s0-9]{0,30}\/[A-Za-z\s0-9]{0,30}\^(0[7-9]|1[0-5])((0[1-9])|(1[0-2]))([0-9]|\s){3,50})
• ([0-9]{15,16}(D|=)(0[7-9]|1[0-5])((0[1-9])|(1[0-2]))[0-9]{8,30})

As we can see, the regular expressions used by memory scraper authors vary in complexity and effectiveness. For instance, the initial regular expression listed above is used to identify the primary account number (PAN) for a given user. Alternatively, the second regular expression simply looks for the character ‘?’, which will match on any number of strings. Thus, the ability to gather accurate results will vary based on what particular regular expressions an author chooses.

In addition to some of the other checks performed, a luhn check may be performed in order to validate the data that is identified.

After track data has been identified, it may be written to a dump file, or automatically exfiltrated using a network protocol. HTTP, HTTPS, SMTP, and FTP are the most common protocols witnessed.

Malware Trends

Over the past decade, malware targeting PoS devices has evolved and changed considerably. The following diagram outlines the malware families witnessed during this time.

Figure 4. Timeline of PoS malware families

2007-2008

While attacks against PoS devices took place before 2007, this was the earliest indication of custom malware being written specifically targeting them. During this early period of 2007-2008, custom malware was fairly rare. Many security protections were simply not implemented during this time. PoS devices often didn’t encrypt network traffic, and stored card data was kept on the filesystem, commonly unencrypted. Because many of these lacked security controls, attackers would simply employ tools that were used by security professionals on a daily basis, such as wireshark, tcpdump, find, and grep to name a few. Additionally, the use of file scrapers and network sniffers were very common.

There are some reported incidents where an attacker gained access to a PoS system only to discover a text file on the desktop with years’ worth of transaction records. In such cases, malware is often unnecessary, as the attacker can simply download the file in question and return periodically for any updates.

However, some malware families emerged during this time, such as the infamous RawPOSmalware family. While this particular family gained much notoriety in 2014, it was actually one of the first known memory scrapers used in PoS attacks. The malware families created during this period varied in their techniques but shared many commonalities. For example, these malware families often provided minimal automation in the form of data exfiltration. They would instead write results to a dump file on the victim device’s file system.

It’s also important to note that the media does not often mention attacks hitting PoS devices during this period, and aren’t well known to the public.

2009-2010

Toward the end of the decade, the emergence of memory scrapers and keyloggers continued. As security controls improved, we saw very few instances of file scrapers or network sniffers. During this period, we also saw the appearance of some malware families that were witnessed for many years afterwards — namely, the rdasrv, mmon, and sr/searcher malware families. These families are all memory scrapers that are often incorporated into other malware families in later years. Like the 2007-2008 period, this malware was very specific in its approach, providing no automatic exfiltration or control capabilities. The approach of attacking PoS devices was still considered a very manual endeavor in 2009-2010, as attackers needed to identify processes handling card data, and then target said processes using the malware at their disposal.

2011-2012

The 2011-2012 period for PoS attacks brought several interesting developments. The use of CardRecon, a commercial PCI compliance tool, was discovered in a number of breaches. Attackers used an illegally obtained copy of this program in order to identify card data being stored on the PoS file system. We also saw the first instance of FrameworkPOS, which is one of the more advanced malware families seen to date. FrameworkPOS not only provided automatic exfiltration, but it also heavily obfuscated data stored within the registry, and was highly targeted towards the victim. The group behind this particular malware family would be continually seen in the following years, often compromising very large organizations.

Generally, the use of automatic exfiltration continued to become more common among malware families in 2011-2012. During this time, the use of SMTP and FTP were frequently observed. However, by using these network protocols, the malware authors were forced to include authentication credentials within the malware itself. This of course causes a problem, as a malware analyst has the ability to extract this data from the binaries. In subsequent years, malware authors corrected these mistakes and shift towards other network protocols, such as HTTP and HTTPS.

Toward the end of 2012, we saw some very interesting developments within the PoS malware community. Namely, the release of the Dexter and Alina malware families that caused quite a stir due to their more advanced features. Both Dexter and Alina emerged around the same time, and provided not only automatic exfiltration capabilities, but a command and control (C2) component as well. This allowed attackers to deploy their malware to multiple locations and control the victims from a single C2 administration panel. This had not been witnessed previously, and added an automation to PoS attacks that was not seen prior.

During this period, we also started to see increased media attention on the topic of PoS breaches and malware families. A number of high-profile breaches gained the attention of both the general public and malware authors alike.

2013-2014

The emergence of Dexter and Alina caused quite a stir in the PoS malware community, and many authors took notice. As such, a number of malware families were written with C2 characteristics in 2013-2014, such as vSkimmer, JackPOS and Backoff.

In mid-2013, the source code to the Alina malware family was sold in underground forums for $2,000. This code eventually leaked in the criminal underground shortly afterwards. Roughly two weeks after the announcement of Alina’s source code sale, in an unrelated incident, the source code to the first major variant of Dexter was leaked on the popular underground forum Darkode. The sale/leak of such prominent PoS malware families caused a number of authors to reuse and modify this code. Because of this, a number of new families were subsequently created and used, such as Spark, Eagle, and getmypass. This trend continues to this day.

The high prevalence of malware families using command and control allowed malware authors to essentially create botnets out of infected PoS devices. As such, it wasn’t long before botnet malware authors took notice. Botnets, such as Andromeda, have been used often to distribute PoS malware families, such as Alina and JackPOS. However, other botnet authors began to implement PoS modules directly in their malware, such as Phase.

2015

This trend of adding PoS memory scraping modules to existing botnets continued into 2015. One such example is the Neutrino bot, which features denial of service commands, anti-reversing characteristics, keylogging functionality, and a command shell.

Other than the continued emergence of botnets implementing PoS features, 2015 has had minimal new PoS malware families emerge. It is likely that there simply hasn’t been a need or demand for new malware families, as a number of the more established malware families are continually updated and are successful in their endeavors.

Aftermath

After an attacker has successfully acquired card data from a targeted merchant, they will most likely sell that data on an underground forum. There are many underground forums available today, specializing in both various services and geographic areas.

Many of the larger carders provide shops to sell their dumps, often with clean user interfaces and granular search options. Customer service and ease of use are very important to the owners of these shops, as a shop’s reputation will often be the deciding factor for an interested buyer.

After a number of cards are purchased, carders will clone physical cards with the data they’ve obtained or purchased. Individuals in the same underground forums will often provide services to create plastic cards. Some examples of these cards can be seen below. As we can see, they look quite convincing to an untrained eye.

These cards can then be used to make purchases by carders. In the event a debit card with a PIN has been obtained, cloned cards can be used to withdraw money at various automated teller machines (ATMs). Carders will often purchase high-end items with the intent of reselling them online. In doing so, they are able to essentially use credit cards to obtain actual cash.

Conclusion

Attacks targeting PoS devices have been occurring for many years, and show no sign up stopping in the near future. The universal rollout of “chip and pin” will likely deter traditional attacks facing PoS devices. This has been witnessed in Europe, where EMV technology has been widely adopted for a number of years. In such situations, the attackers typically change tactics. Instead of targeting PoS devices, attackers target e-commerce websites instead, dumping databases from these webservers and acquiring card data.

In general, intrusion techniques targeting PoS devices are often no different from techniques targeting other Internet or network-connected machines. The main difference lies in the payload, which these days are typically a keylogger, or much more commonly, a memory scraper. These payloads, or malware families, have evolved over time to become heavily automated. Such automation allows attackers to infect hundreds or thousands of machines at a time, and make changes at the click of a button.

Proper PoS Security

Those charged with the task of securing PoS devices should take necessary precautions in order to help prevent the theft of card data. Such precautions include, but are not limited to:

• Ensure PoS devices are not directly connected to the Internet. If required, proper controls should be enabled to only allow connections to specific hosts over specified network protocols.
• Web browsing should be disabled completely on PoS devices if possibly. If not possible, controls should be enabled that restrict browsing to specific websites.
• Prevent unauthorized users from installing or running executables on PoS devices using process whitelisting.
• Install security software, such as antivirus, on PoS devices.
• Update all necessary operating system patches.
• Implement network segmentation between PoS devices and other corporate infrastructure.
• Ensure any remote access applications, such as RDP, VNC, LogMeIn, etc. are configured with unique usernames and passwords, are fully up to date on patches, and are configured with 2-factor authentication if possible.
• Properly log host and network-based events.

Josh Grunzweig

[Palo Alto Networks Blog]

In recent years, there have been a number of high-profile stories involving the compromise of point of sale (PoS) devices. My research often involves deep reverse engineering and analysis of various malware families targeting PoS devices. As such, I’m often asked about the overall threats that these machines face. In this article I hope to provide a high-level view of the threat landscape currently affecting PoS devices.

Background

The term PoS refers to a machine used by businesses to conduct a retail transaction. If you have ever used a debit or credit card to make a purchase, you’ve likely seen these machines. They often run customized hardware and software, however, the underlying operating system (OS) is more commonly some version of Microsoft Windows, often Windows XP or Windows 7. This trend has shifted slightly in recent years with the popularity of mobile PoS devices, most of which run either Android or iOS. While these are becoming more common in smaller businesses, Windows-based PoS machines still make up the majority, and by association are the devices most heavily targeted by attackers.

Figure 1. Example PoS machine

Infiltration

While PoS devices can be attacked in many ways, the method of infiltration typically falls into one of the following three categories, listed by least sophisticated to most sophisticated:

1. Spam emails / Exploit kits
2. Scanning the Internet for default or common credentials
3. Compromising trusted third parties

Spam Emails / Exploit Kits

These types of attacks are widespread and are often leveraged by attackers who are looking to infect as many machines as possible. Botnet owners are often seen leveraging these attacks to add further devices to their botnets.

Unfortunately, a number of organizations that own PoS machines use them as they would a personal computer. They browse the web, check email, and conduct day-to-day operations from the same machine that is conducting financial transactions. Attackers discovered that while infecting a large number of machines on the Internet, they were also infecting a small number of PoS devices as well. One such example of how PoS devices can be misused was demonstrated on Reddit, where a user discovers that he/she can access the site on their PoS. While accessing this site alone does not pose any significant security issues, it demonstrates how PoS devices can be misconfigured to allow users to access websites and Internet-based resources that should be blocked. Because of the lack of security controls on these devices, spam emails and exploit kits are able to infect these machines and subsequently steal financial data from them.

Internet Scanning for Default or Common Credentials

While more common in past years, this particular type of threat still represents a portion of attacks against PoS machines. Many PoS vendors configure their devices with remote administration services, such as Microsoft Remote Desktop, VNC, pcAnywhere, or LogMeIn. These services allow vendors to update and configure PoS machines remotely. As PoS machines may be located in geographically diverse regions, this is commonly built-in as a necessity.

Unfortunately, these services are often are configured to communicate and be accessible directly from the Internet, which allows both administrators and attackers alike to connect and attempt authentication. Additionally, these remote management services are frequently configured with default usernames and passwords. Knowing these combinations of usernames and passwords, attackers will continually scan the Internet in the hopes of identifying systems that can be accessed in such a way. A number of free utilities are available online that are designed for such tasks, making it trivial for individuals online to identify and subsequently compromise misconfigured PoS machines described.

At a recent RSA conference, researchers unveiled that a major PoS vendor had included a default username and password for all of their products for roughly 25 years. Misconfigurations such as these by both vendors and those configuring PoS machines allow attackers to obtain unauthorized access.

Figure 2. Example Remote Desktop brute force login tool

Compromising Trusted Third Parties

In one of the most sophisticated techniques seen to date, attackers have begun targeting trusted third party organizations in order to gain access to PoS machines.  This trend has been seen in recent years, with the Target breach being the most well known example. In that particular instance, an intrusion at the organization’s HVAC contractor was used to gain access to Target’s PoS machines.

Additional third party organizations, such as point of sale integrators, have been increasingly targeted in the past two years. PoS integrators are organizations responsible for the installation and maintenance of PoS machines for their clients. These organizations are often the victim of targeted attacks where spear-phishing emails and other ploys are used to compromise their networks. Once compromised, the attackers use stolen credentials, as well as the trust of the integrators networks to pivot and compromise PoS machines on their client’s networks. This tactic has been deployed heavily by the attackers behind the Backoff PoS malware family, impacting over one thousand US-based companies in 2014.

Malware Types

PoS malware is described in four categories:

• Network Sniffer
• File Scraper
• Keylogger
• Memory Scraper

Due to improvements in both PCI regulations as well as general security surrounding PoS machines, network sniffers and file scrapers are rarely, if ever, seen today. Not only did network sniffers provide track data sent across the network unencrypted, but they also had the ability to extract other sensitive information, such as credentials sent across the network. Such information could be used by attackers to gain access to other systems on the network. Alternatively, file scrapers had similar abilities, where both card data and other sensitive data on the victim machine could be identified and subsequently used by attackers. From 2007 to 2009, especially, these types of malware families were prevalent.

Since then, keyloggers and memory scraping malware families have become commonplace in PoS breaches. Keyloggers can work in a number of ways, however, one of the most common ways is to create a message-only window via a call to CreateWindow. The malware will then register a new input device via a call to RegisterRawInputDevices, which is in turn used to capture keyboard input data. Additionally, keyloggers will often also capture screenshots of the desktop to provide the attacker with more information about the victim machine.

Figure 3. Example of malware implementing keylogging functionality

Memory scrapers typically work in a small number of ways. They will begin by obtaining a handle to a process that the malware wishes to target. These processes are typically discovered via calls to either CreateToolhelp32Snapshot or EnumProcesses. At this particular stage, memory scrapers will often employ either a blacklist approach, where common process names are ignored, or a whitelist approach, where only a small subset of known process names are targeted. As an example, the svchost.exe process might be ignored, while the frmweb.exe process might be targeted.

Once a process is identified and a handle is obtained, memory scrapers will iterate through pages of memory using the VirtualQuery function. Further checks are often performed during this particular stage. Namely, a good memory scraper that is targeting track data will typically only look at pages that are set with read/write permissions and has a state of MEM_COMMIT. This allows the malware to ignore free or reserved memory, or memory that contains code, which in turn will improve performance.

After a page of memory is identified, the malware will actually read it via a call to ReadProcessMemory. After the memory has been read into a buffer, it will commonly apply a regular expression against this data, or feed the buffer to a function that is responsible for identifying track1 and track2 data. An example of some regular expressions witnessed in the wild can be seen below:

• \d{15,19}=\d{13,}
• \?
• ((B(([0-9]{13,16})|([0-9]|\\s){13,25})\\^[A-Z\\s0-9]{0,30}\\/[A-Z\\s0-9]{0,30}\\^(0[7-9]|1[0-5])((0[1-9])|(1[0-2]))([0-9]|\\s){3,50})|(((37)|([4-5][0-9])|(60))[0-9]{13,14}(D|=)(0[7-9]|1[0-5])((0[1-9])|(1[0-2]))[0-9]{8,30}))
• ((b|B)(([0-9]{13,16})|([0-9]|\s){13,25})\^[A-Za-z\s0-9]{0,30}\/[A-Za-z\s0-9]{0,30}\^(0[7-9]|1[0-5])((0[1-9])|(1[0-2]))([0-9]|\s){3,50})
• ([0-9]{15,16}(D|=)(0[7-9]|1[0-5])((0[1-9])|(1[0-2]))[0-9]{8,30})

As we can see, the regular expressions used by memory scraper authors vary in complexity and effectiveness. For instance, the initial regular expression listed above is used to identify the primary account number (PAN) for a given user. Alternatively, the second regular expression simply looks for the character ‘?’, which will match on any number of strings. Thus, the ability to gather accurate results will vary based on what particular regular expressions an author chooses.

In addition to some of the other checks performed, a luhn check may be performed in order to validate the data that is identified.

After track data has been identified, it may be written to a dump file, or automatically exfiltrated using a network protocol. HTTP, HTTPS, SMTP, and FTP are the most common protocols witnessed.

Malware Trends

Over the past decade, malware targeting PoS devices has evolved and changed considerably. The following diagram outlines the malware families witnessed during this time.

Figure 4. Timeline of PoS malware families

2007-2008

While attacks against PoS devices took place before 2007, this was the earliest indication of custom malware being written specifically targeting them. During this early period of 2007-2008, custom malware was fairly rare. Many security protections were simply not implemented during this time. PoS devices often didn’t encrypt network traffic, and stored card data was kept on the filesystem, commonly unencrypted. Because many of these lacked security controls, attackers would simply employ tools that were used by security professionals on a daily basis, such as wireshark, tcpdump, find, and grep to name a few. Additionally, the use of file scrapers and network sniffers were very common.

There are some reported incidents where an attacker gained access to a PoS system only to discover a text file on the desktop with years’ worth of transaction records. In such cases, malware is often unnecessary, as the attacker can simply download the file in question and return periodically for any updates.

However, some malware families emerged during this time, such as the infamous RawPOSmalware family. While this particular family gained much notoriety in 2014, it was actually one of the first known memory scrapers used in PoS attacks. The malware families created during this period varied in their techniques but shared many commonalities. For example, these malware families often provided minimal automation in the form of data exfiltration. They would instead write results to a dump file on the victim device’s file system.

It’s also important to note that the media does not often mention attacks hitting PoS devices during this period, and aren’t well known to the public.

2009-2010

Toward the end of the decade, the emergence of memory scrapers and keyloggers continued. As security controls improved, we saw very few instances of file scrapers or network sniffers. During this period, we also saw the appearance of some malware families that were witnessed for many years afterwards — namely, the rdasrv, mmon, and sr/searcher malware families. These families are all memory scrapers that are often incorporated into other malware families in later years. Like the 2007-2008 period, this malware was very specific in its approach, providing no automatic exfiltration or control capabilities. The approach of attacking PoS devices was still considered a very manual endeavor in 2009-2010, as attackers needed to identify processes handling card data, and then target said processes using the malware at their disposal.

2011-2012

The 2011-2012 period for PoS attacks brought several interesting developments. The use of CardRecon, a commercial PCI compliance tool, was discovered in a number of breaches. Attackers used an illegally obtained copy of this program in order to identify card data being stored on the PoS file system. We also saw the first instance of FrameworkPOS, which is one of the more advanced malware families seen to date. FrameworkPOS not only provided automatic exfiltration, but it also heavily obfuscated data stored within the registry, and was highly targeted towards the victim. The group behind this particular malware family would be continually seen in the following years, often compromising very large organizations.

Generally, the use of automatic exfiltration continued to become more common among malware families in 2011-2012. During this time, the use of SMTP and FTP were frequently observed. However, by using these network protocols, the malware authors were forced to include authentication credentials within the malware itself. This of course causes a problem, as a malware analyst has the ability to extract this data from the binaries. In subsequent years, malware authors corrected these mistakes and shift towards other network protocols, such as HTTP and HTTPS.

Toward the end of 2012, we saw some very interesting developments within the PoS malware community. Namely, the release of the Dexter and Alina malware families that caused quite a stir due to their more advanced features. Both Dexter and Alina emerged around the same time, and provided not only automatic exfiltration capabilities, but a command and control (C2) component as well. This allowed attackers to deploy their malware to multiple locations and control the victims from a single C2 administration panel. This had not been witnessed previously, and added an automation to PoS attacks that was not seen prior.

During this period, we also started to see increased media attention on the topic of PoS breaches and malware families. A number of high-profile breaches gained the attention of both the general public and malware authors alike.

2013-2014

The emergence of Dexter and Alina caused quite a stir in the PoS malware community, and many authors took notice. As such, a number of malware families were written with C2 characteristics in 2013-2014, such as vSkimmer, JackPOS and Backoff.

In mid-2013, the source code to the Alina malware family was sold in underground forums for $2,000. This code eventually leaked in the criminal underground shortly afterwards. Roughly two weeks after the announcement of Alina’s source code sale, in an unrelated incident, the source code to the first major variant of Dexter was leaked on the popular underground forum Darkode. The sale/leak of such prominent PoS malware families caused a number of authors to reuse and modify this code. Because of this, a number of new families were subsequently created and used, such as Spark, Eagle, and getmypass. This trend continues to this day.

The high prevalence of malware families using command and control allowed malware authors to essentially create botnets out of infected PoS devices. As such, it wasn’t long before botnet malware authors took notice. Botnets, such as Andromeda, have been used often to distribute PoS malware families, such as Alina and JackPOS. However, other botnet authors began to implement PoS modules directly in their malware, such as Phase.

2015

This trend of adding PoS memory scraping modules to existing botnets continued into 2015. One such example is the Neutrino bot, which features denial of service commands, anti-reversing characteristics, keylogging functionality, and a command shell.

Other than the continued emergence of botnets implementing PoS features, 2015 has had minimal new PoS malware families emerge. It is likely that there simply hasn’t been a need or demand for new malware families, as a number of the more established malware families are continually updated and are successful in their endeavors.

Aftermath

After an attacker has successfully acquired card data from a targeted merchant, they will most likely sell that data on an underground forum. There are many underground forums available today, specializing in both various services and geographic areas.

Many of the larger carders provide shops to sell their dumps, often with clean user interfaces and granular search options. Customer service and ease of use are very important to the owners of these shops, as a shop’s reputation will often be the deciding factor for an interested buyer.

After a number of cards are purchased, carders will clone physical cards with the data they’ve obtained or purchased. Individuals in the same underground forums will often provide services to create plastic cards. Some examples of these cards can be seen below. As we can see, they look quite convincing to an untrained eye.

These cards can then be used to make purchases by carders. In the event a debit card with a PIN has been obtained, cloned cards can be used to withdraw money at various automated teller machines (ATMs). Carders will often purchase high-end items with the intent of reselling them online. In doing so, they are able to essentially use credit cards to obtain actual cash.

Conclusion

Attacks targeting PoS devices have been occurring for many years, and show no sign up stopping in the near future. The universal rollout of “chip and pin” will likely deter traditional attacks facing PoS devices. This has been witnessed in Europe, where EMV technology has been widely adopted for a number of years. In such situations, the attackers typically change tactics. Instead of targeting PoS devices, attackers target e-commerce websites instead, dumping databases from these webservers and acquiring card data.

In general, intrusion techniques targeting PoS devices are often no different from techniques targeting other Internet or network-connected machines. The main difference lies in the payload, which these days are typically a keylogger, or much more commonly, a memory scraper. These payloads, or malware families, have evolved over time to become heavily automated. Such automation allows attackers to infect hundreds or thousands of machines at a time, and make changes at the click of a button.

Proper PoS Security

Those charged with the task of securing PoS devices should take necessary precautions in order to help prevent the theft of card data. Such precautions include, but are not limited to:

• Ensure PoS devices are not directly connected to the Internet. If required, proper controls should be enabled to only allow connections to specific hosts over specified network protocols.
• Web browsing should be disabled completely on PoS devices if possibly. If not possible, controls should be enabled that restrict browsing to specific websites.
• Prevent unauthorized users from installing or running executables on PoS devices using process whitelisting.
• Install security software, such as antivirus, on PoS devices.
• Update all necessary operating system patches.
• Implement network segmentation between PoS devices and other corporate infrastructure.
• Ensure any remote access applications, such as RDP, VNC, LogMeIn, etc. are configured with unique usernames and passwords, are fully up to date on patches, and are configured with 2-factor authentication if possible.
• Properly log host and network-based events.

Josh Grunzweig

[Palo Alto Networks Blog]