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 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 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.
That 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.
THE ATTACK
Target has yet to honor a single request for comment from this publication, and the company has said nothing publicly about how this breach occurred. But according to sources, the attackers broke in to Target after compromising a company Web server. Somehow, the attackers were able to upload the malicious POS software to store point-of-sale machines, and then set up a control server within Target’s internal network that served as a central repository for data hoovered by all of the infected point-of-sale devices.
“The bad guys were logging in remotely to that [control server], and apparently had persistent access to it,” a source close to the investigation told KrebsOnSecurity. “They basically had to keep going in and manually collecting the dumps.”
It’s not clear what type of software powers the point-of-sale devices running at registers in Target’s U.S. stores, but multiple sources say U.S. stores have traditionally used a home-grown software called Domain Center of Excellence, which is housed on Windows XP Embedded and Windows Embedded for Point of Service (WEPOS). Target’s Canadian stores run POS devices from Retalix, a company recently purchased by payment hardware giant NCR. According to sources, the Retalix POS systems will be rolled out to U.S. Target locations gradually at some point in the future.
WHO IS ANTIKILLER?
Image: Securityaffairs.co
A more full-featured Breadcrumbs-level analysis of this malware author will have to wait for another day, but for now there are some clues already dug up and assembled by Russian security firm Group-IB.
Not long after Antikiller began offering his BlackPOS crimeware for sale, Group-IB published an analysis of it, stating that “customers of major US banks, such as such as Chase (Newark, Delaware), Capital One (Virginia, Richmond), Citibank (South Dakota), Union Bank of California (California, San Diego), Nordstrom FSB Debit (Scottsdale, Arizona), were compromised by this malware.”
In his sales thread on at least one crime forum, Antikiller has posted a video of his product in action. As noted by Group-IB, there is a split second in the video where one can see a URL underneath the window being recorded by the author’s screen capture software which reveals a profile at the Russian social networking site Vkontakte.ru. Group-IB goes on to link that account to a set of young Russian and Ukranian men who appear to be actively engaged in a variety of cybercrime activities, including distributed denial-of-service (DDoS) attacks and protests associated with the hackivist collective known as Anonymous.
One final note: Dozens of readers have asked whether I have more information on other retailers that were allegedly victimized along with Target in this scheme. According to Reuters, “smaller breaches on at least three other well-known U.S. retailers took place and were conducted using similar techniques as the one on Target.” Rest assured that when and if I have information about related breaches I feel confident enough about to publish, you will read about it here first.
As always, great research and hopefully news outlets give you the credit you deserve.
I will be interested on what Target has to say on these details, but I am guessing it will be a big “no comment”.
Do you have the link to the report and analysis on Virustotal?
Back in 2009 a series of warnings came up about RAM scraping:
http://www.theregister.co.uk/2009/12/09/ram_scraper_credit_card_theft/
In hindsight, looking at the known threat obvious risks, Target is largely to blame because of its security policies and choice of POS solution, but so are companies developing POS systems which do not encrypt data before it’s stored in the device’s RAM.
And the only reason why they don’t do it is because it involves improving source code and the hardware of the POS itself, which they would have done already should these companies need to be PCI DSS compliant – which they are not!
And that’s ultimately down to VISA, Mastercard and the whole PCI DSS consortium, which has chosen to ignore the obvious risks of RAM scraping at the POS. The reason for this is unknown, and malware could be scraping cards at a concerning high number of POS systems around the World!
The PCI DSS standard needs revising yet again, and the cardholder is ever increasingly suspicious.
Personally, throw away your credit card: it’s not just the Bank that’s feeding on it….
Richard/Frank,
Hoe do you encrypt data before it hits ram? If the malware has access to the RAM, it would seem that it would likely be able to access the registers . As we have seen in recent webcam attacks, a dedicated encryption circuit could be directly compromised.
It will be interesting to see the analysis, but one has to wonder if the OS is the real culprit. Frankly, it’s hard to believe anyone would run a windows variant (much less an XP variant) on any financial system (not a comment on the security of windows, but on the prevalence of attacks)
Hey Les,
I’d have to do some more digging into PCI DSS to see what they recommend on the encryption method part, but I can tell you on the Windows front that Windows Embedded being used for financial applications is *incredibly* prolific.
Being the curious sort I am, anytime I see someone servicing an ATM or train ticket machine, I always take a gander at the underlying OS (without looking too weird)… and in a large number of ATMs (especially Diebold ATMs), it’s all Windows Embedded. In the case of the NYCT system, I believe all their TVMs are running an even older version of Windows Embedded than XP!
Like “PC Cobbler” said above XP Embedded support does not end in April but do you think we will see the patch Tues. updates from MS for this flavour? Granted it stripped down “a little” but if the patches stop coming the exploits will just grow.
The easy answer to “how do you encrypt data before it hits RAM” is to encrypt it at swipe. Card readers that encrypt data before it is even sent to the PC over USB are available and common (though obviously more expensive). Many retailers are already using these, and while they don’t remove all avenues of attack they reduce the attack surface considerably.
For example:
http://www.magtek.com/V2/products/secure-card-reader-authenticators/magnesafe-mini.asp
Sadly, MOST POS devices at the major brand name retail stores are still running XP. If you are lucky it is SP3. Conversely most of the kiosk type of touch screens I have seen are running a flavor of bare bones Linux.
I can tell you that running WePOS doesn’t help matters, it’s fraught with issues thanks to Microsoft’s legacy of poor design, but it is a workhorse and people will continue to use it
Any encrypted data needs to be briefly decrypted into plain text in RAM for it to be processed and used. It is recommended to be encrypted only for storage and transmission. The hack likely utilized this requirement to parse actual plain-text data either upon swiping or a key-in before encryption or upon decryption.
BTW the best article on the Target hack yet.
–Rahul
Each POS device ideally needs to connect directly to a cloud payment gateway, without the data even touching a local POS system i.e eliminate the risk of a local POS exploit. Thus a the POS device is locked down and is truly a black box or a very thin client with minimal risk footprint and managed over the wire in a very secure way. Make paykent traffic completely separate from the corporate network and reduce cross-contamination.
“In an interview with CNBC on Jan. 12, Target CEO Gregg Steinhafel confirmed …”
His choice of CNBC, the sycophant of Wall Street, as his venue gives the impression that he is more concerned about his shareholders than his customers.
“Target hasn’t officially released details about the POS malware involved, nor has it said exactly how the bad guys broke into their network.”
And that’s the part everyone wants to know. Clearly there were at least two distinct actions inside Target’s IT infrastructure.
The first was the downloading of tainted POS software. I wouldn’t be surprised if the miscreants used Target’s regular update method of downloading POS updates to the registers.
And the second was the access of Target’s internal databases which is where the miscreants obtained names, mailing addresses, phone numbers, and email addresses (POS registers would have names, but not the other data). If they accessed one database, they probably were able to access them all.
It is conceivable that Target’s POS registers communicate with a store server and that server communicates with the mother ship. That server probably also contain the names, mailing addresses, phone numbers, and email addresses as found in Target’s wedding registry. This would explain how all of the above data was accessed, as the miscreants copied the data stream from store server to mother ship.
> the miscreants used Target’s regular update method
> of downloading POS updates to the registers
This is also my theory. They certainly wouldn’t have manually pushed the BlackPOS code to the thousands of terminals in the stores, so they either leveraged the POS system’s native s/w distribution mechanism (i.e. ESD) or there’s worm code that we haven’t heard about that carried the POS malware upstream to each terminal as it connected to the mothership.
It sounds like you have worked with POS software (I’ve done other software work). Do you think all registers connect directly with the mother ship or is there a server in each store serving as a middleman?
Likely the POS all connect to a main store server, as well as a back-up server, which then transports to host at corporate via a server farm. Because of the lane count in Target, as well as the need to do cash management functions in a back office (unlike a small retailer), it’s unlikely their server is a POS on their sales floor. Their stores require heavy bandwidth, so it’s pretty inconceivable that their registers connect directly to the “mothership” for updates to PLU, customer files, promotions, screensavers, etc. Instead, it’s likely a packaged push to a store server (or a pull, though this is a less common methodology), which then replicates to lanes, and then runs a back-up routine on its fail-over server.
PC… I would imagine that the stores follow the typical retail fat-client model in that the store’s registers connect to an in-store server and that server is what’s connected to the data center host. This would allow the store to operate off-line if it ever lost connectivity to the host at Target’s data center
In my experience, it’s pretty normal for ruggedized hardware vendors to be running windows ce/embedded. I’ve seen it in a number of industries. The OS’s are horribly out of date (no aslr, dep, etc) and the devices are way to expensive to update with regularity.
I’m seeing more and more iOS (and to a lesser degree android) for these types of special purpose use cases. With it’s the hardware being more affordable, I hope we will see companies doing a better job of refreshing the devices and the device OS. I also wonder is Square will start to get major retailers looking at their solution.
With mission critical applications, it is almost always a requirement to be able to work offline. So, you typically see thick client architectures. That said, we are talking about credit cards. Don’t these systems have to reach out for purchase approval with the bank? If so, why have any storage on the device at all?
If their update server was compromised…
Are there any POS vendors selling solutions that:
– only use firmware based credit card readers (no writable storage)
– or, that use operating systems and devices that locally verify all software signatures?
“His choice of CNBC, the sycophant of Wall Street, as his venue gives the impression that he is more concerned about his shareholders than his customers.”
I’m hard-pressed to think of a publicly owned company for which that statement isn’t true.
I don’t see anything wrong with a CEO deciding to talk with a business-centric TV channel. It is a highly stressful situation and any CEO would want to be interviewed by people who think mostly like he does and will have the expected questions:
* “what will this do to the stock?”
Where should he have gone?
I’ve reached out to a friend who write POS code at a different company. They are not talking about this – could mean they are just busy, however. In the past, they have commented that PCI standards actually made their system less secure. Usually when I hear that, I think “sure, sure, whatever you say”, but this is an extremely smart person with a wide background in computing, software, engineering, and over a decade of POS design and coding. They know their stuff.
PCI only makes your security weaker if you take it as the standard to be fully protected. It should be looked at as “you’re stupid if you don’t do this” but you better be doing other stuff too. You still need all the normal “defense in depth” security architecture and and you should be applying those standards across all your servers not just the ones in PCI scope.
@Rick “I’m hard-pressed to think of a publicly owned company for which that statement isn’t true.”
Quite right, but CNBC is the worst possible venue given their total lack of objectivity and integrity.
Brian has an automatic block on links in comments, so I will do it the old-fashioned way. Search for “The JP Morgan apologists of CNBC” which will explain why CNBC might as well be the official voice of Wall Street.
Nice article, Brian. It’s obvious you’ve done a lot of work on this.
I’ve read that some people suggest going to the bank cards with the chips in them. I don’t think it would’ve made any difference in this situation.
Well, it likely would have helped – using chip-and-pin cards mean that the attackers would have had to compromise the readers somewhere along the line *before* the card readers encrypt the PIN data and send it along.
PCI DSS requires a card reader to encrypt PIN data at the reader itself before the data is transmitted, and I believe every single reader uses a unique key.
I also believe PCI DSS requires some sort of key tampering alert built into readers.
It’s certainly not impossible, but this malware wouldn’t have been able to scrape anything other than an encrypted PIN (which is apparently all they got beyond the card info).
Tangent: is anyone aware of any attacks out there that have successfully targeted non-American POS infrastructure and exfiltrated unencrypted PIN data?
I keep seeing people post on Brian’s site that chip cards are the answer. I don’t understand why when I see chip cards listed on the underground carder sites along with the mag strip cards. What am I missing?
Richard…I would agree, EMV Chip & PIN acceptance would’ve largely thwarted their efforts to steal open and meaningful data… they may have been successful at intercepting the data but all they would’ve gotten was a bunch of scrambled, encrypted data and it would’ve proven useless to them…. this may be the shake-up needed in the USA to force the issuers to wisen up and move towards EMV adoption… the breach costs tied to this incident will be huge…probably in the billions…
(Sorry, I should have continued this in my other comment)
The reason it would have helped is that in chip-and-pin systems, the card readers are built to only accept a physical card inserted into the device as well as the input of the matching PIN.
If the cards stolen were chip-and-pin, the data is less likely to be useful because the buyers of the data can’t make a purchase without the accompanying PIN, which would have been encrypted.
In some regions, we’re in a transition stage; readers still will accept a swipe if the chip reader is malfunctioning or the chip in the card itself is defective… but there are plenty of retailers out there outside of the US who just won’t accept a swipe of a chip-and-pin card, period.
It’s my belief that the only reason we haven’t seen implementation of it in the US is solely due to the cost required – literally millions of readers would need to be replaced, and the related infrastructure/software updates.
Perhaps this breach will force legislators to follow the steps of other countries and finally make it a requirement.
A big reason that it hasn’t been implemented by retailers is because the bank generally bears the loss for a swiped transaction, rather than the retailer, in the US. They don’t have incentive to make the switch.
My understanding is it depends whether a debit or credit card was used. If a debit card was used, the bank will charge the retailer back.
Absolutely…. EMV card acceptance in this breach would’ve thwarted the hackers in that the data stolen in memory would’ve been largely encrypted already from the PIN pad… therefore, they may have intercepted this data in memory but it would’ve been largely useless to them… another wake-up call to the US issuers to get on-board and move to Chip & PIN
Earl that’s not true. EMV has nothing to do with encyption of the data sent to the POS. All it does is check the PIN was right (which can be circumvented… just read Cambridge University research on this). Once the PIN is valid the PIN pad sends a “success code” to the POS saying the PIN was verified along with all the card info. in clear text.
If the PIN is entered wrong the “invalid attempts” field is updated on the chip and can eventually lock out the chip.
Not sure if this is relevant or not in terms of timelining, but:
https://i.imgur.com/wuftbnQ.jpg
According to my phone, I took that photo on September 30, 2013, at the pharmacy counter of a Target store in the Los Angeles area. At the time, multiple (but not all) POS-attached readers in the store were displaying the same message; only ones of this type were down.
At the time that the photo was taken two things were running through my head: one, LOL; two, that the affected readers at the POSes were all of a type that had recently replaced another older model previously used in that store.
Note that I am not stating or implying that the photo is indicative of malware having been installed on that POS at that time. This could simply have been caused by (for example) an in-store networking or other run-of-the-mill IT issue. However, given the events of a few weeks later, it is at least open to speculation.
Weird, that doesn’t look anything like the Target card reader stations at either of the Targets in Reno, NV. The ones here are newer looking and red. Maybe they are the same on the inside.
What’s interesting about your picture is that Verifone device supports EMV Chip & PIN cards… how ironic…
“U.S. stores have traditionally used a home-grown software called Domain Center of Excellence, which is housed on Windows XP Embedded and Windows Embedded for Point of Service (WEPOS)”
Now that’s interesting. I assumed all flavors of XP died in April. However, “Windows XP Professional for Embedded Systems” and “Windows XP Embedded (Toolkit and Runtime), all versions” (will the real WEPOS please stand up?) have EOL dates of, respectively, December 31, 2016 and January 30, 2017. Someone please put a stake in the heart of this vampire.
http://www.microsoft.com/windowsembedded/en-us/product-lifecycles.aspx
I also think someone is pulling Brian’s leg with respect to “Domain Center of Excellence.” Companies are certainly using Microsoft’s various embedded systems flavors — note that there are 8.1 Pro versions — but “Domain Center of Excellence” appears to be a corporate buzz-phrase used by Wipro and other companies.
http://www.wipro.com/search/results.aspx?k=Domain%20Center%20of%20Excellence
MS obviously wants vendors to use Windows over other OSs, so their embedded variants (XPe, WEPOS, POSReady) all have longer lifecycle timelines than the normal retail variants.
For ATM/POS situations most people won’t use an OS if they know it’ll be out of date in 3 years, so I believe MS defaults to a 10-year support lifecycle on the embedded OSs.
To add to my comment: Brian’s link was a search for “Domain Center of Excellence target jobs” on Target’s careers website, but if you look at the second job, for Technical Architect, the word “center” does not appear anywhere in the job description. Their job search engine appears to be as unreliable as their POS infrastructure.
“In early 2010, Target started with a pilot project, migrating its existing virtual workloads, the POS system, and the asset-protection solution to Hyper-V in 10 high-volume stores.”
http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?CaseStudyID=4000009407
FBI agent pranks a red neck making radio talk to him and wears UFO alien suit. Red Neck shoots him, LOL.
Having worked for a large Acquirer (processes credit card transactions for merchants) I know we routinely “pushed” terminal updates out to our entire merchant population. I would think it would be the same for a large retailer that runs their own POS.
However, as a bank. we furnished the terminals to the merchants. The terminals (card readers) encrypted the transaction at the card swipe. In our case, our bank was the mothership consolidator.
As was commented on previously the conversion from mag strip to chip and pin is not only daunting from a cost perspective but also from a cultural one as well… just one more PIN for every cardholder to remember when going to the grocery store.
Chip and Pin will probably be the standard eventually, unless something better comes along. The impetus to make the change will likely be related to the growing customer pain level and business fraud losses.
Even though it’s expensive to the banking industry, it’s got to be less painful then going though what Target is currently dealing with. I haven’t shopped there since the breach. Target barely admits the intrusion, but my bank just underwent the task of canceling my card and issuing me a new one. And I had to wait for it. For bounced checks, or insufficient funds service charges, the banks should be making more than enough to cover the cost of the chip and pin. In addition, I remember Brian talking about chip and pin during the TJ Maxx intrusion. The cost of the chip and pin is only getting more expensive as the years roll on. Maybe the industry should earn a billion less for a couple of quarters to spare us the heartache.
They have been in full use here in Canada for a few years now right down to the smallest retailers. I cannot remember the last time I saw a swipe only POS. Continued excuses against their adoption is clearly costing US retailers.
Great research and enjoying the dialogue. In reference to Nate’s comment re. “retailer incentives to switch”, the upcoming fraud liability shift for the major card types should start to provide the necessary motivation (http://www.emv-connection.com/emv-migration-driven-by-payment-brand-milestones/). Let’s hope they’re resolute in pushing through the changes needed to protect the consumer.
Useful info – excellent job as always.
Late last year I tried using one of my debit cards at a local retailer (small regional 13-branch chain) and it crashed the POS terminal (for reasons I have yet to determine, but it subsequently happened at two other unrelated retailers nearby – chains, but much bigger – yet worked fine at my bank’s ATM).
When the store manager rebooted the PC attached to the terminal I saw the XP boot screen. Every checkout seemed to have the same system so I’m guessing that’s true of the whole chain.
Whether this installation is the same as the XP Embedded systems mentioned in the article I don’t know, but I’ll be taking a much closer look at the POS terminals next time I’m in the store.
Excellent research Brian!
The fact that these guys compromised a Web server, installed their own control server, then kept coming back in to do their dirty work is troubling to say the least. There are a lot of things wrong here; not with the story, but with Target.
Can’t wait for the next bit of information, and wish I had time to check into this more.
Instead of “30503,” it looks like the full pathname wrapped, so the filename was “20130503 POS malware from FBI,” indicating it could be from May 3, 2013.
The “LEGACY_POSWDS” identifier referenced in the ThreatExpert report also shows up on December 19th in:
http://www.symantec.com/security_response/earthlink_writeup.jsp?docid=2013-121920-1520-99
“They basically had to keep going in and manually collecting the dumps.”
Somebody was asleep at the wheel.
That was a real good article on Group-IB, thanks for posting it.
My only question was this a malware infection by way of spear phishing which then infected the server. Or did the point of sale device get physically compromised by malware by a employee , USB thumb-drive , clone. device or some other type of social engineering . which then spread by way of the VPN network to the server and other P.O.S in other stores?
Thanks for for being the only reliable site providing real background information into this.
Not sure it’s related but there is a software from BMC used for performance monitoring in networks/clients that creates a Best1_user account on Windows domains.
ftp://ftp.bmc.com/pub/perform/resolutions/25752.pdf
Maybe this helped in keeping this attack under the covers while transmitting the stolen data through the intranet.
The virus total for the unarchived .rar file is here
https://www.virustotal.com/en/file/0b04ba91597c28443983a2c5135eeca3b17069531ae4e801d4f6da142c6e083a/analysis/1389842968/
i ran the video in sandboxie and the video crashed after viewing it.
anyone else noticed that?
from what ive learned, apps/broswer crashing might be a virus.
They should have been using change detection and file integrity monitoring on those POS devices. Any insight into how the breach expanded to include other customer information? Their customer service folks swear that online accounts weren’t compromised, but the fact that my account password and email address are no longer recognized and there’s no way to regain control of my account suggests otherwise.
1. Visa issued Data Security Alerts in April and August 2013 warning of precisely this type of attack, including malware signatures. http://usa.visa.com/merchants/risk_management/cisp_alerts.html
2. Chip cards (EMV) don’t stop the card data being collected; they prevent the cards being cloned. PINs are encrypted the same way as for mag stripe. The Target statements refer to encrypted PIN data.
3. A large proportion of ATMs run on XP!
Nice catch. I read the most current report:
http://usa.visa.com/download/merchants/Bulletin__Memory_Parser_Update_082013.pdf
Since January 2013, Visa has seen an increase in network intrusions involving retail merchants. Once inside the merchant’s network, the hacker will install memory parser malware on the Windows based cash register system in each lane or on Back-of-the-House (BOH) servers to extract full magnetic stripe data in random access memory (RAM).
Spreading the malware I think is the easy part. Target moved their IT infrastructure to a “2 servers per store” model over the past few years, heavily relying on virtualization.
The point-of-sale systems are updated via Microsoft System Center, this is how all 170+ devices in a given store including the point of sale systems are updated. I wrote up a blog post on how Target’s IT infrastructure is setup here:
http://www.tripwire.com/state-of-security/vulnerability-management/targets-point-sale-system-compromised/
As always great job Brian on getting the scoop!
With this new information at hand, two things come to mind.
First, how did they make the malware persistent on an embeded system OS? Thin clients using windows embeded operating systems have write protected file systems, so a simple power cycle or. reboot every night clears out any malware that may have been memory resident. If Target’s POS system is the same, either they don’t reboot the registers at night or the central system that can unlock the protected file system and apply updates or reimage systems was compromised which sounds more like an inside job.
Second, I’ve been curious about how they exfiltrated the data. Hearing that the bad guys had to manually sign in and collect the dumps suggests that Target may have at least had proper outbound controls blocking the POS systems from communicating directly to the Internet. The problem lies in the access the compromised web server had. I argue with people all the time about this, a publicly accessible web server in your DMZ should never be allowed to initiate traffic to your internal network. If the server needs access to a database that DB should be in a separate DMZ.
You’re right, with Windows Embed, the file system is locked on the thin client. But to get the malware onto all the POS systems,company-wide, it had to be pushed from the mothership, which probably overrides the protection on the clients.
Looks like the ThreatExpert report is no longer available on Google Cache.
POS experts: if I request my cc# be input manually, not swiped, will I be safer?
The data capture risk is about the same. From what I have seen most POS systems that allow manual entry still capture the same data (excluding some pieces of the track data.) most times it is just the card number and expiration date. Some POS systems require card number, expiration and CVV2 number to be entered. Just depends on the retailer and what they want or need to capture to process the transaction.
Sadly the link to the Google cache is bringing up a 404 page.
THINK
for a heist of this size it is unlikely they had “mules” go around and update the softeware in all the POS terminals. if the POS terminals were compromised it was more likely done by compromising the software maintenance process — so that all the POS terminals could be compromised at once.
THINK
the data had to be EXFILTRATED. the POS terminals had to send the data to a compromised process — if that’s how this was done.
THINK
how did the data get out of the net past the firewalls? only secure private channels should have been used.
and TARGET claims to be a leader in computer security. hmmmmmmm
Retails are supposed to have two separate internal networks. One that supports all of the “Credit / PCI” systems (including store registers) and a separate network that supports everything else (Non-Credit).
Target allowed a physical host running MS Virtualization software to span both it’s “protected” Credit network AND it’s non-Credit network. VERY BAD IDEA. But they were proud of it:
http://news.cnet.com/8301-10805_3-20045503-75.html
Additional detail: Retailers are supposed to place significant restrictions on their internal Credit Network. You know, like “no hosts can connect externally (Internet). Things like that.
The reference to CNET.COM has a hint of situational irony. Start with CNET.COM selling products from Anvisoft. http://www.cnet.com/1770-5_1-0.html?query=Anvisoft&tag=srch .
Then read about Anvisoft:
https://www.mywot.com/en/scorecard/anvisoft.com
Saving the best for last:
http://krebsonsecurity.com/tag/anvisoft/
The question still remains. How do you get malware on every single POS system in a major retailer. Obviously the threats actors knew intimate details about the OS platforms on these systems. To get malware on thousands of POS systems, it is quite possible that some software distribution system (SDS) was involved. Be it their own internal SDS, or a home grown one planted by the threat actor to exploit a vulnerability on the POS systems. After all, they set up their own collection server right there under Targets noses allowing the actors to waltz on it and copy the dumps right out.
Unless they share this detail, we won’t know, of course.
Speaking from my own experience working in large retailers in IT, there have been more than one meeting where I had to explain to one of our POS developers that it was *not* a good idea to have a centralized public share with POS placed on it that a scheduled task can “just run every night” to update their code in production.
I would not be surprised if this method was used. It is “too easy” a solution and it a very common approach used by developers.
@Jody “I had to explain to one of our POS developers that it was *not* a good idea to have a centralized public share with POS placed on it that a scheduled task can ‘just run every night’ to update their code in production”
Wow, retail is more screwed-up than I ever imagined! It is a terrible idea from an network isolation point of view as well as from a systems test point of view.
I guess I am lucky to be out of the software business. I always thought proper procedure was to not release code until it is tested within an inch of its life. What is the rationale of updating production code on a daily basis? Are these eXtreme/Agile/Scrum teams?
@Jody Generally, releasing early and often is better for software quality and security. Working in smaller, more verifiable, chunks and getting those chunks in as close to development as possible. It makes detecting issues and vulnerabilities easier, not harder. Having a public share is bad. However, having a nightly job that pushes code is, in the absence of an infected deployment server, likely to reduce security issues. Sure, it makes an inviting target. However, it is no less a target than any of the developer’s workstations or devices. Now, if you need it secured, then the code that is being pushed should be signed and verified by the runtime device.
>>> As noted by Group-IB, there is a split second in the video where one can see a URL underneath the window being recorded by the author’s screen capture software which reveals a profile at the Russian social networking site Vkontakte.ru. Group-IB goes on to link that account to a set of young Russian and Ukranian men who appear to be actively engaged in a variety of cybercrime activities, including distributed denial-of-service (DDoS) attacks and protests associated with the hackivist collective known as Anonymous.<<<
Small world. This site says Edward Snowden works for Vkontakte.ru.
http://www.orlytaitzesq.com/?p=438857
That was from October and was an unfounded rumour that turned out to be false. 🙂 Don’t believe all you read on the internet.
Many things on the Net are rumors. But the author of that site I posted has been in direct contact with people (attorneys) in Russia RE: Snowden. Not many people can do such things unless they really have contacts.
That site was repeating a rumour from somewhere else. Just like many other professionals, this person may have sources but will occasionally quote unfounded things and theories. He is not at vkontakte. 🙂