Posts Tagged: BlackPOS


4
Feb 14

These Guys Battled BlackPOS at a Retailer

Ever since news broke that thieves stole more than 40 million debit and credit card accounts from Target using a strain of Point-Of-Sale malware known as BlackPOS, much speculation has swirled around unanswered questions, such as how this malware was introduced into the network, and what mechanisms were used to infect thousands of Target’s cash registers.

BLACKPOS copyRecently, I spoke at length with  Tom Arnold and Paul Guthrie, co-founders of PSC, a security firm that consults for businesses on payment security and compliance. In early 2013, these two experts worked directly on a retail data breach that involved a version of BlackPOS. They agreed to talk about their knowledge of this malware, and how the attackers worked to defeat the security of the retail client (not named in this story).

While some of this discussion may be geektacular at times (what I affectionately like to call “Geek Factor 5″), there’s something in here for everyone. Their observations about the methods and approaches used in this attack point to an adversary that is skilled, organized, patient and thorough.

So you first saw BlackPOS at a retailer in early January 2013?

Tom: Yes, it did seem like a game changer at that point because of the way it hooked into the POS system. By that I mean the fact that it hooks into the POS process, and it’s not just a general memory scraper like some people have stated.

Help me understand the distinction between a memory scraper and malware that runs completely in memory?

Tom: Well, it’s very specific. It’s what’s called an inter-process communications hook. If you look at a memory scraper — so if you were to dump the memory on your laptop right now — you would get this big old blob of information and you would have to filter through it to find what you’re looking for. But this [malware] is very specific: It’s very much designed for the POS system it’s running on, because it knows exactly where to hook and where the memory location is going to be when the data it’s looking for is flowing through it. But if you look at what it captures, it captures only the track data [information stored on the magnetic strip on the backs of cards]. So, it’s actually very, very sophisticated and that’s why I think this isn’t just a teenage hacker who put this together in his basement. I think this is a more sophisticated development effort. [HP last week published some interesting, uber-geeky details about the memory behavior of the version of BlackPOS found at Target].

Paul:  It certainly hooks into a specific process, but we did not figure out if it was just good at scraping the memory of that process, or whether it actually altered the process to hook into the code somehow.  That part of the code was obfuscated and not reviewed during the engagement.

What did you think of the iSight paper?

Tom: The iSight paper was good, and what it described was very similar to what we saw in the first variants of BlackPOS. But it didn’t talk about how it appeared on the network or where it came from or how a retailer might defend themselves against it.

In your prior experience with BlackPOS, has it been used against the same POS that Target uses? A source who seemed to have a clue told me that their setup was somewhat homegrown.

Tom: That I don’t know.  I haven’t really looked at what Target uses. With a homegrown system, the problem is if you’re going to build a process hook, you have to have a test environment, you have to know what you’re looking at and what memory addresses to go after, and that’s not exactly something that gets published.

Paul: Target has a homegrown POS.

So you think it’s likely they were using some off-the-shelf equipment and software? Wouldn’t it be enough for the attackers in this case to have obtained a physical point of sale device that was once used at Target?

Tom: If they have one, sure, that would be different. I don’t know if they’re using a commercial product. A lot of the big retailers use commercial products and will customize those with their back end system. But at the front end and what happens at front of the house…a lot of those are just retail off-the-shelf applications. A lot of those retailers, when you have a hard disk that breaks on one of the [checkout] lanes, they’ve got an outsourced service provider of that POS that comes out there with a new hard disk and fixes it.

How do the bad guys break in, and how do they actually get the malware pushed out to the point-of-sale?

Tom:  A lot of the POS systems use whitelisting software of some kind, such as Bit9 or SolidCore. Those two companies are the two you see most out there in the industry.

Paul: It could also come in through the point-of-sale application update process.

By whitelisting, you mean sort of the opposite approach of antivirus, right? As in, if the file or program isn’t approved by the whitelisting software, it simply won’t run on the system?

Tom: The software update processes at a point-of-sale that is running one of those [whitelisting applications] has to come through one of the software update channels and has to be reviewed for the update and approved. And when it’s approved, the whitelisting software says okay this patch is approved to come online.

It’s probably a good idea at this point to make sure we’re defining the terminology in a uniform way. When you think of point-of-sale device, are you talking about the cash register, or the card swipe terminal, or…

Tom: I’m using point-of-sale to mean the payment application that is running on the cash register. The vast majority of those devices, when you check out at the grocery store or large retailer, those are just PCs, and yes they’re mostly running Windows XP or WEPOS as their operating system. But above that, you have what I call the point-of-sale, or the point-of-sale application, and that’s the stuff that the cashier is interfacing with at the time you’re checking out. It’s a software application, running as multiple pieces of software inside the register itself. And whitelisting is put on to protect the register from any sort of unsolicited modification. A lot of the attacks before this [whitelisting became more broadly used] involved where you corrupt a sales clerk to put a USB stick in the cash register and infect the PC with some malware. But by using a whitelisting software, the USB stick will not work and the operations personnel back in the head office will get notified that something isn’t right with that register.

If they get past a whitelisting system, doesn’t that suggest that someone on the inside would have to be involved?

Tom: No, not really. You have to also consider the distribution server that distributes the point-of-sale software.

Paul: Right… three possible ways… it could come through a legitimate update channel, or the retailer was lax in their update procedures, or the attackers hacked the console of the whitelisting software and just whitelisted it themselves.  

Continue reading →


15
Jan 14

A First Look at the Target Intrusion, Malware

Last weekend, Target finally disclosed at least one cause of the massive data breach that exposed personal and financial information on more than 110 million customers: Malicious software that infected point-of-sale systems at Target checkout counters. Today’s post includes new information about the malware apparently used in the attack, according to two sources with knowledge of the matter.

The seller of the point-of-sale "memory dump" malware used in the Target attack.

The seller of the point-of-sale “memory dump” malware allegedly used in the Target attack.

In an interview with CNBC on Jan. 12, Target CEO Gregg Steinhafel confirmed that the attackers stole card data by installing malicious software on point-of-sale (POS) devices in the checkout lines at Target stores. A report published by Reuters that same day stated that the Target breach involved memory-scraping malware.

This type of malicious software uses a technique that parses data stored briefly in the memory banks of specific POS devices; in doing so, the malware captures the data stored on the card’s magnetic stripe in the instant after it has been swiped at the terminal and is still in the system’s memory. Armed with this information, thieves can create cloned copies of the cards and use them to shop in stores for high-priced merchandise. Earlier this month, U.S. Cert issued a detailed analysis of several common memory scraping malware variants.

Target hasn’t officially released details about the POS malware involved, nor has it said exactly how the bad guys broke into their network. Since the breach, however, at least two sources with knowledge of the ongoing investigation have independently shared information about the point-of-sale malware and some of the methods allegedly used in the attack.

‘BLACK POS’

On Dec. 18, three days after Target became aware of the breach and the same day this blog broke the story, someone uploaded a copy of the point-of-sale malware used in the Target breach to ThreatExpert.com, a malware scanning service owned by security firm Symantec. The report generated by that scan was very recently removed, but it remains available via Google cache (Update, Jan. 16, 9:29 a.m.: Sometime after this story ran, Google removed the cached ThreatExpert report; I’ve uploaded a PDF version of it here).

According to sources, "ttcopscli3acs" is the name of the Windows share point used by the POS malware planted at Target stores; the username that the thieves used to log in remotely and download stolen card data was "Best1_user"; the password was "BackupU$r"

According to sources, “ttcopscli3acs” is the name of the Windows computer name/domain used by the POS malware planted at Target stores; the username that the malware used to upload stolen data data was “Best1_user”; the password was “BackupU$r”

According to a source close to the investigation, that threatexpert.com report is related to the malware analyzed at this Symantec writeup (also published Dec. 18) for a point-of-sale malware strain that Symantec calls “Reedum” (note the Windows service name of the malicious process is the same as the ThreatExpert analysis –”POSWDS”). Interestingly, a search in Virustotal.com — a Google-owned malware scanning service — for the term “reedum” suggests that this malware has been used in previous intrusions dating back to at least June 2013; in the screen shot below left, we can see a notation added to that virustotal submission, “30503 POS malware from FBI”.

The source close to the Target investigation said that at the time this POS malware was installed in Target’s environment (sometime prior to Nov. 27, 2013), none of the 40-plus commercial antivirus tools used to scan malware at virustotal.com flagged the POS malware (or any related hacking tools that were used in the intrusion) as malicious. “They were customized to avoid detection and for use in specific environments,” the source said.

pos-fbiThat source and one other involved in the investigation who also asked not to be named said the POS malware appears to be nearly identical to a piece of code sold on cybercrime forums called BlackPOS, a relatively crude but effective crimeware product. BlackPOS is a specialized piece of malware designed to be installed on POS devices and record all data from credit and debit cards swiped through the infected system.

According the author of BlackPOS — an individual who uses a variety of nicknames, including “Antikiller” — the POS malware is roughly 207 kilobytes in size and is designed to bypass firewall software. The barebones “budget version” of the crimeware costs $1,800, while a more feature-rich “full version” — including options for encrypting stolen data, for example — runs $2,300.

Continue reading →