Yesterday’s story about the point-of-sale malware used in the Target attack has prompted a flood of analysis and reporting from antivirus and security vendors about related malware. Buried within those reports are some interesting details that speak to possible actors involved and to the timing and discovery of this breach.
As is the case with many data breaches, the attackers in this attack used a virtual toolbox of crimeware to get the job done. As I noted in a Tweet shortly after filing my story Wednesday, at least one of those malware samples includes the text string “Rescator.” Loyal readers of this blog will probably find this name familiar. That’s because Rescator was the subject of a blog post that I published on Dec. 24, 2013, titled “Who is Selling Cards from Target?“.
In that post, I examined a network of underground cybercrime shops that were selling almost exclusively credit and debit card accounts stolen from Target stores. I showed how those underground stores all traced back to a miscreant who uses the nickname Rescator, and how clues about Rescator’s real-life identity suggested he might be a particular young man in Odessa, Ukraine.
This afternoon, McAfee published a blog post confirming many of the findings in my story yesterday, including that two malware uploaders used in connection with the Target attack contained the Rescator string:
“z:\Projects\Rescator\uploader\Debug\scheck.pdb”.
![A private message on cpro[dot]su between Rescator and a member interested in his card shop. Notice the ad for Rescator's email flood service at the bottom.](https://krebsonsecurity.com/wp-content/uploads/2013/12/rescator-pm-cpro.png)
A private message on cpro[dot]su between Rescator and a member interested in his card shop. Notice the ad for Rescator’s email flood service at the bottom.
“First, the malware that infected Target’s checkout counters (PoS) extracted credit numbers and sensitive personal details. Then, after staying undetected for 6 days, the malware started transmitting the stolen data to an external FTP server, using another infected machine within the Target network.”
Seculert continues: “Further analysis of the attack has revealed the following: On December 2, the malware began transmitting payloads of stolen data to a FTP server of what appears to be a hijacked website. These transmissions occurred several times a day over a 2 week period. Also on December 2, the cyber criminals behind the attack used a virtual private server (VPS) located in Russia to download the stolen data from the FTP. They continued to download the data over 2 weeks for a total of 11 GBs of stolen sensitive customer information. While none of this data remains on the FTP server today, analysis of publicly available access logs indicates that Target was the only retailer affected. So far there is no indication of any relationship to the Neiman Marcus attack.”
Target has taken quite a few lumps from critics who say the company waited too long to disclose the breach, and new details about when it may have known something was wrong are likely to fan those flames. As I wrote yesterday, the point-of-sale malware used in Target referenced a domain within Target’s infrastructure called “ttcopscli3acs”. Several sources, including Seculert’s Aviv Raff and Dmitri Alperovitch at CrowdStrike, searched for other files with that unique string within the corpus of malware uploaded to Virustotal.com, a service that employs more than 40 commercial antivirus tools to produce reports about suspicious files submitted by users.
That search turned up numerous related files — including the aforementioned malware uploaders with Rescator’s nickname inside — all dated Dec. 11, 2013. Since this malware is widely thought to have been custom-made specifically for the Target intrusion, it stands to reason that someone within Target (or a security contractor working at the company’s behest) first detected the malware used in the breach on that date, and then submitted it to Virustotal.
Yesterday’s story cited sources saying the malware used in the Target breach was carefully crafted to avoid detection by all antivirus tools on the market. These two virustotal scan results from Jan. 16 (today) show that even to this day not a single antivirus product on the market detects these two malicious files used in the Target attack. Granted, the antivirus tools used at virustotal.com do not include behavioral detection (testing mostly for known threat signatures). I point it out mainly because nobody else has so far.
Incidentally, in malware-writer parlance, the practice of obfuscating malware so that it is no longer detected by commercial antivirus tools is known as making the malware “Fully Un-Detectable,” or “FUD” as most denizens of cybercrime forums call it. This is a somewhat amusing acronym to describe the state of a thing that is often used by security industry marketing people to generate a great deal of real-world FUD, a.k.a. Fear Uncertainty and Doubt.
“the attack consistent of two stages.”
I believe you mean the attack “consisted”.
Regards,
dtb
Man I hope Target has changed the user name and password for that (what seems to be) backup account, as it’s hard coded in the malware and is now easily found in VT.
Another note the twain_32a.dll (is similar to a printer/scanner driver), Tool Without An Interesting Name.
? if I bought a Target gift card at Rite-Aid during the time of the attack is my charge card in jeopardy?
The malware was on Target’s POS terminals, not Rite Aid’s. Unless Rite Aid sent your credit card number on to the third party that tells Target to activate the GC (extremely unlikely), there’s zero chance of Target having your credit card info. (Of course the perps could have drained your GC, but even that’s relatively unlikely; it looks more and more as if they were mainly interested in Visa, MC, etc. numbers to sell on the black market.)
Thanks. Whew!!
Security firm IDs malware used in Target attack
hxxp://www.computerworld.com/s/article/9245491/Security_firm_IDs_malware_used_in_Target_attack?source=CTWNLE_nlt_pm_2014-01-16
Perhaps you could tell me:
1. Can a POS terminal write to the mag strip?
2. If it can – how do we know more mischief isn’t stored on cards out there that haven’t been shredded yet.
I’m not familiar enough with the electronic architecture of any POS device to know these answers, but when I posed questions in the past of whether one could be compromised – the inevitable answer was – OH NO that is impossible as you cannot program a POS terminal, they are READ ONLY, there is no way for malware to find a vector – etc, etc, – Well now that has been proven to work, I’m ready to believe almost anything, including the probably false assumption that the malcode could have entered the POS from the magstripe swipe of a card. So maybe someone can shoot this down, and pose a better theory. I’ve long suspected this Target scenario was possible despite my detractors, and now my original suspicions are founded. Surely my new suspicions are wrong?
>1. Can a POS terminal write to the mag strip?
Not the everyday model, no. Some ATMs and the like can (card readers that take gas cards for fleets are another example). ATMs do it to record failed PINs, so a found card doesn’t mean you can go from ATM to ATM trying PINs trivially: after some number of failures, it’ll eat the card.
But there’s some confusion involved in this whole discussion around the term “POS”: in the Target case, it means the cash register, not the MSR (magnetic strip reader). In a smaller store, the POS and MSR might be the same device. So it’s an all-too-understandable confusion!
If the MSR had encrypted the data, a POS breach would have been useless to the attackers.
Argh, sendus prematurus.
The MSR is R/O, so the answer you got before was correct FSVO correct. And this is why encryption in the MSR (which is of course also a computer, but one that’s programmed before it gets to the store and is then R/O) would have worked.
This is correct. A MSR is read-only, however the PIN entry device (PED) is supposed to have “encrypted” (I quote that because there is a more complicated process, but that is another lesson) the PIN before it ever left the device. Since MSR are R/O, you could cause also cause a buffer overflow. However, this article still backs up my claim that this attack worked because the criminals were able to make changes that captured the data from the MSR (POS) level and the (never should have happened) PED level. Even though Target will get the majority of the blame, I would also be looking at the devices they were using to take the transactions, especially the PEDs. Once they nail down how somebody was able to circumvent the OS of those devices, then all merchants will have a better chance at this. Do some digging on EMV Buffer Overflow Exploitation. I have a feeling this was done to get the MSRs to do what the attackers wanted in the first place.
So much misinformation.
The readers (terminals) were not compromised. The readers are attached to cash registers that run Windows. The cash registers were compromised. The reader passes card data read off the mag stripe to the cash register. PIN data, used in a debit transaction is always encrypted. The rest of the track data is not encrypted unless they are using a P2PE solution. This is true even if the card is an EMV card. EMV does not encrypt the card number.
You are correct.
While the MSR (card reader) encrypts transcations to the rest of the world when it authenticates a credit card, the information transferred between the MSR and POS (cash register) does not have to be encrypted, and the conversation between the POS and MSR can be very chatty, so the retailer can harvest as much information about you as they can legally acquire.
As a high percentage of POS (cash register) terms are still some variation of WinXP running local admin rights, it doesn’t take a rocket scientist to break down their security.
I await the day when a big retailer has it POS terms hit with CryptoLocker – that would be hilarious.
If someone got cryptolocker on a POS computer they would just reimage the box. It would be nothing other than a minor annoyance.
If you read theories from people who actually know what they are talking about, the fact that Target frequently re-images their windows POS boxes for just this reason may explain how the malware got onto so many boxes. It was in the image.
Thanks everyone for your comments, I now have a closer idea how the process works. Your arguments are very revealing, and can help other IT security personnel, at any level, make better decisions.
Greybeard, thank you for finally making the distinction. As a manufacturer of POS terminals, we are fielding a TON of concerned calls from retailers on this subject and our message is clear. 1: This was not perpetrated against a POS terminal 2: If the data was encrypted from the point of swipe it would not be in the public domain now. We hear the usual objections that the “hackers would just get it before it is encrypted” but that is not a simple task on a PTS secure device and would require physical breach of the unit. Again, thanks for the sound contribution to the thread here.
Thanks for the precise explanation. What I’m also wondering is whether the malware was reading the bus or reading memory from another process. In the former case something like http://www.zemana.com/ probably would have sniffed it out. I’m assuming, though I don’t deal in POS, that the card readers (MSRs) are just USB devices like any other. If they used commodity encryption from the device to the terminal, this would not have happened unless the private key would also be compromised.
One thing to note is that Target’s MSRs are actually very cool as compared to others. It looks like there’s a way to push JPEGs to them. I’m not sure how that works, and it could be yet another vector to get something in. But I think they’re “firewalled” to USB.
I’m sorry Brian but I just had to laugh at you writing “Yesterday’s story cited sources saying the malware used in the Target breach was **carefully crafted** to avoid detection by all antivirus tools on the market.”
When it comes to the current state of virus detection technology wouldn’t “carefully crafted” basically just mean making sure the signature is unique and making the executable a self-unpacking encrypted file?
Seems to me that it really isn’t too hard to escape a detection technology that mostly works ONLY once you’ve identified a sample of one or the creators of the malware didn’t encrypt the executable so its’ logic could actually be traced.
The first condition is solved by just releasing something that’s never been released before and I’m no programmer but from what little I do know making self-unpacking executables has been going on for a long time now.
Or ss there something I’m missing which warrants the estimation of making an undetectable malware “hard” and ‘precision work’?
Doktor, remember once decrypted, the malware executable could be scanned in memory or on disk (wherever it exists in the clear). Thus, the payload must also be obfuscated so that it does not match any known malware signatures. I presume the malware writers have access to their own test bed that is like virus total that they verify their malware against.
That does bring up an interesting question. Are antivirus engines simply scanning signatures against an entire file, or against sections of an executable or dll, perhaps even identifying functions reused in other known malware executables?
Yes that’s a good point, Gabe: the thing has to reveal itself at some point if it is to be able to run in the system. So at that point your heuristics checking could in fact come into play.
Where I work every single new .EXE that tries to come in to our environment via attachments to spam is NEVER detectable by our A/V solution or the vast majority of virustotal engines. I submit it as a sample and they generate a signature but it seems to me like they’re doing more running around cleaning up AFTER the mess than actually having any capability to determine if something is actually malicious or not.
I know it’s really hard to programmatically determine something is malware before a human has identified it as such and this isn’t a berating of the AV industry so much as it is a questioning of if malware developers actually have to be super crafty to avoid the reality of just how hard it is to programmatically detect something new.
This, my dear Doctor, is why AV are not really efficient at stopping malware and should never be considered primary defense mechanism. There is however a very efficient software pest control mechanism, which actually ends up as #1 and #2 of the Top 20 Security Controls list every year: whitelisting. It’s amazingly simple to set up, amazingly cheap to maintain and amazingly effective in protecting from known and unknown threats. Compare the simplicity of identifying all authorized devices and all authorized software within your perimeter and ease of maintenance of the resulting database (do you really add hundreds of new devices to your networks every day? install hundreds of new executables?) and then implementing a very simple rule – whatever is not in the database is not allowed to communicate or execute – to the nightmare of maintaining your IDS signatures, AV signatures and what not, all of the time knowing that these tools are reactive, not proactive, and can’t really protect you from new threats (and even from 1 month old ones, as Brian noted.)
Of course, there are other 18 critical controls there, but these two already mitigate 90%+ of threats known and unknown alike. One should rightfully wonder, like I do, why-oh-why Target is not among the adopters of CSIS Top 20 or at least the two top controls from it?
I was about to say – Windows parental controls set to white-list executables was one of the best protections I’ve tested on my honey pots, but I must admit some AVs do a smashingly good job looking for behaviors that are either bad actors, or messing in file locations they have no business in, then comparing the file doing this to known IDs for any code snippet matches. I’ve had one AV that would pop bad actors and put them in quarantine, until the servers determined what it was and could give it a name definition, and either declare it legitimate or remove it from existence. The false positives were VERY low, and when the malware tried to obfuscate or defend itself, the AV would boot into the PE environment and do some serious @ss kicking to contain the attack. I think some of the companies have done a good job, but they always are playing defense and catching up to a new reality. They probably always will.
Agreed: We use whitelisting in our environment. The simplicity of the setup is remarkable and it stops anything new or old, known or unknown.
The issues with whitelisting happen beyond that point, when users need to install something not whitelisted, and don’t have the rights to (as they shouldn’t 80% of the time).
Being a small business, it’s probably a lot easier for us than -say- a large entity with tens or hundreds of admins/superusers involved, each with their personal take on these things. That’s why the Whitelisting software needs to have an approval process, where users can request an install which will then complete automatically upon remote acceptance from the admin.
Also, the WL has to be able to accept automatic updates for programs already on the whitelist. Regular updates from Microsoft, Adobe, etc come in with new .exe filenames – usually not on the whitelist. So if you don’t have a way to automatically accept these, you’re stuck a ton of update whitelist-requests all the time.
That said, I wouldn’t change my mind on implementing our Whitelisting solution for the world! Add hardware IDS/IPS by your main firewall and you’re suddenly feeling a lot better about these things!
Morgan, What happens when the malware is named C:\Program Files\Microsoft Office\Office14\WINWORD.EXE? At this point, whitelisting is useless.
Nick:
It’s not as simple as just the file name.
The way I understand it, a unique key is created for the particular .exe file, which is compared to when trying to run. It’s machine specific, so even the actual same .exe file copied from another computer wouldn’t be allowed to run automatically.
That said, I’m sure if everyone was using whitelisting, someone would work hard at cracking the encrypted keys and replicating them. Just not worth the effort when there’s much easier Targets out there… (pun intended).
This is correct. They would take an md5 or similar hash and submit suspicious exes to the ‘cloud.’ Ultimately, this is why I think Avast will do well. They have wide distribution. Kaspersky may have smarter coders but all the smartness in the world can’t beat raw numbers.
How about we just declare “virus detection” dead once and for all and start focusing on “application whitelisting” instead?
Maybe bring “air gapping” back into vogue again while we’re at it?
You’re still going to see signatures. I don’t think you’re 100% correct. I think you’re going to see a combination of:
1. Signature detection.
2. Heuristic detection.
3. Companies like Avast that realize better distribution will benefit from #2 more.
4. Digital signing and whitelisting.
5. Elements of Tripwire & similar built in to the OS.
If you make #4 too annoying, though, people will just turn it off. Vista was proof.
Every single one of these is precisely something that should be on a specialised OS running only a specialised application like a POS application, and then some. Part of the problem here is that too often the rules that are seen as ‘inconveniencing to users’ on a ‘normal’ operating system are not relevant for a POS. Heuristics, for instance, tends to be turned off, especially at high levels, by all AVs by default — but on a POS machine, there is no reason at all to not run heuristics — the list of rules should be explicitly and implicitly very small.
Incidentally the same is true for any network traffic on their MS backend servers: the IP rules (and geoip rules as well) should have been limited. In a funny way (to me anyway) I think it is their loyalty and ‘suggestions’ programs that made separating their LAN segments off almost impossible.
But money talks. 🙁
Many AVs can detect some (not all) malware for which there is no existing detection signature via heuristic/behavioral techniques. As most of the reputable online AV scanners caution, their service is not intended to be a test/evaluation of the AVs they use. I will bet my sigmaker that at least a few AVs will detect the Target malware in a real-world setting. Unfortunately, the AVs used at Target did not!
Regards,
I agree – I’ve always thought a good AV would have a rock solid HIPs mated with an analysis executive that could use more than one heuristic method to arrive on the likely hood a file or executable is malicious. I wouldn’t think this would take anything so advanced as artificial intelligence; but maybe we are on the cusp of this as a reality.
Thanks Brian for all the amazing information you share with us. I find it very useful in many ways.
I am hoping that some day I will get answers to some of my other questions:
– how was the malware installed in their environment…..specially down to the POS devices which are behind multiple firewalls
– does Target use Tokenization in their environment
– would usage of advanced malware protection tools protect PCs more then anti-virus
I would love to hear comments from other readers.
Thanks again Brian.
There must be at least one software that can protect against this malware?
With a blended defense, maybe; but not one technology. Unfortunately I’ve never seen to many organization use a true blended defense strategy.
Interesting comment BobbyZ and I agree and follow that (WL) rigorously where I can. But it does not apply that well to this Target situation as it seems they first exploited a public web server. And you cannot white-list public access. Blacklist can help to a certain extent or make the task a bit more difficult for the script kiddies relying on bots/infected machines around the world.
And I agree most AV and AM programs are rubbish, especially the big names (Sym, McAfee). I always have to deal with the after-fact. Malware Bytes has actually been much more effective.
But what could have helped here and somebody already suggested that and I have it implemented on most of my DMZ servers (web/sftp) and some critical internal servers is a File Integrity monitoring solution like TripWire. And loads of custom shell scripts to go along and with remote logging. If any files get changed on any of these systems, I get emailed. Email on logins attempts, Page/Text on any root shell or sudo access. No direct Root access, etc. Yes, it can be a bitch sometimes, but it pays.
I have been trying to understand this myself. How exactly did the ex-filtration happen? Even if they had root (which seems more than likely) and totally excluding the injection/harvesting phase of this little party. Shouldn’t anything on the edge be saying things like- You want to open an sftp connection to anything that doesn’t start with 10.x.x.x.? How about NO. But then I suppose I digress, as the notion of whitelisting has already been discussed.
Ignoring the fact that they probably didn’t have white listing for outbound, it’s trivial to defeat.
It would work the same way that a classic browser exploit does to give you a shell (where the exploit runs the shell locally and maps it’s input and output over http://) :
The internal-ish server would be given the data and some obscure url entry point. A random remote client would make an http:// request to the slightly obscure url and the server would return the data. As far as a white list is concerned, it’s standard external request to :80/:443 followed by a response.
I think in this case it was to old fashioned FTP (:20,21) not SFTP (which is actually ssh :22). But having the server make the data available via :80/:443 using some knock-knock sequence wouldn’t be surprising in the future.
Timeless,
After thinking about how I would try to do it, I came to much the same conclusion. I just kept hearing FTP/sFTP bandied about. You are of course, right. Thanks for your input!
-b
Today spotted some some mentioning of Russian been involved in Target breach, and name of worm called Kaptoxa. Which from Russian translates into “potato”.
I have been wondering HOW the number of compromised accounts could have gone from 40 million, to 70, 90 and lately 110 MILLION for users in this 3 week period. Unlikely I’d say.
I now have a theory. I have shopped at Target, but have ALWAYS paid cash and not within that Nov/Dec 2013 time frame.
So imagine my curiosity when I received the 16 JAN 2014 Target “apology” letter with the credit monitoring offer. I cannot guess HOW DID TARGET GET MY E MAIL ADDRESS? And why would my information be at risk? Then it occurred to me.
I HAVE RETURNED a defective product purchased with cash and was required to show my driver’s license and I THINK my e mail info. This was in about 2010 or so.
So if my personal information was compromised, it had to be from 2010 which is the only time I shared personal information with Target.
And that would explain how 1/3 of the US population did not really shop at Target in that brief 3 week window but still were compromised.
ltjd Tuslog
No, it’s inaccurate to say the compromise itself occurred back in 2010. What happened was that your email was stored, and the data store it was in was what was compromised last month.
If that’s what you meant to say, then my apologies, but the way the post is written it appears as though you’re concluding the data breach happened back in 2010.
EMH:
I did not intend to claim the far more extensive customer data was compromised IN 2010. Only that data from 2010 was maintained, poorly secured and compromised recently.
When I heard those HUGE numbers of 70, 90 & 100 million knocked about, I knew that three week time frame could not have been correct. And since e mail addys and home addresses are not on any mag stripe, I guessed the theft was far deeper than merely recently used credit and debit card info.
The poorly secured maintaining of old marketing data and cross referencing other data mining efforts makes account takeover fraud and ID theft a far greater risk than a few bogus charges on some card. And those risks may be dormant for years before being discovered (pun intended).
Some years ago (>3) I received a bunch of spam from Target and shortly after asked them to stop sending it, which they did immediately.
In the last few days I received an email from them, telling me my personal information had been compromised (no actual details of what it comprised) and offering me a year’s free credit monitoring.
So you don’t even need to be a Target customer to be at risk of something…
That is just exactly why I don’t wan’t to sign up for the ID theft protection; I’m wondering – “Is the data base I’m signing up for any better than the compromised one?” Talk about a conundrum?! I’m not going near that free service – even if it is another site!
I’ll just keep the paid service I was already signed up for.
This was my worst fear, that Target’s customer database had been compromised, not just random POS devices. What I find the most concerning, beyond the breadth of the breach, is that no one is discussing the issue of Target, and presumably other retailers, archiving customer data indefinitely.
Knowing what we now do about the vulnerability of these systems to everyone from common criminals to our own government, I am very hesitant to place any trust in their concern for my security over their own self interest.
Would a sandboxing technology at the network level succeeded in catching this malware? Or something new tech such as RSA ecat?
As of this morning Dr Web is detecting the two samples uploaded to VirusTotal as “Trojan.Starter.2935”. Everyone else passes them as clean except for Symantec’s heuristics, which marks them as “Suspicious.Insight – Risk Level 1 : Very Low” (sic).
One of those VirusTotal reports notes that the executable established a TCP connection to 199.188.204.182:21 – a Namecheap Hosting server in Los Angeles. I’ll let Brian decide if that’s significant or not.
None of this explains how the emails accounts were compromised…
That is true, but I can imagine two possibilities:
1) Most major retail outlets track purchases against a database of frequent shoppers who have signed up for their club card. Perhaps the email address is referenced during a transaction.
2) Having domain access, perhaps other Target systems were compromised as well
The latter is the scarier possibility, in that perhaps we are not to the bottom of the rabbit hole yet.
It’s got to be #2. Remember: Physical addresses were leaked too, and that’s simply not part of the payment card’s mag stripe data. Some customer database somewhere was also accessed. Sure, it might be contained or accessed from the point of sale system, but wiredog is right, the memory scraping does not and cannot explain the email addresses leak.
… it’s highly probable that ALL customer data held by TARGET was stolen.
TARGET is very aggressive in demanding customer ID for routine purchases. My local TARGET demanded to scan/record my driver’s-license… in order to buy a bottle of wine; I offered to let the clerk visually check my birthdate on the license (I’m 41)– but they refused the sale unless I consented to the full scan/record of my license into their cashier’s computer.
TARGET also requires a drivers-license scan for some over-the counter drugs.
The customer data loss is much bigger than revealed so far.
Yeah, no kidding. Take a peek at that F-Secure story I linked down below.
I hope people don’t overreact to it – it’s merely a question the blogger asked whether metadata was available and also compromised. If so, aiyee… but it’s not known, and not guaranteed, so people can’t presume it was.
Still though… just the possibility that any sort of customer analytics and behavior data might have been stolen is worrisome. There’s a big, fat “No Kidding” about the conclusion that such data would be “an identity theft goldmine”. I really hope it was just payment card mag stripe data and customer basic info. Analytics – “metadata” – would be useless by itself, but totally usable in conjunction with the others.
Guess we should be glad that Target isn’t collecting biometric data yet!
Story after story about noteworthy breaches have come down to “island hopping”.
Bad guys get access to one machine, whether it be a webserver or a secretary’s computer, and go from there. Once inside, they have much more “trust” to try other attach vectors.
If the vulnerabilities were such that it allowed an attacker to hop from the Internet all the way through control networks, into individual stores and all the way down to the POS terminals (software update pushes?), it says a lot about the infrastructure as a whole.
Maybe, but that makes presumptions not established – or at least not yet established – in the Target breach. I was talking with a colleague trying to imagine ways an internet-exposed server can be compromised so that it lets someone get beyond the DMZ and into internal resources. He told me I was overcomplicating things, that it’s far, far more likely for a human to be the weak point. As an example, it’s possible for someone to have an administrative credential on an outward-facing server that happens to match one on a protected computer further inside the corporation, and that the credentials gives them rights to do bad things. Get that, and you’re set.
Of course we don’t know if that’s how the Target compromise happened. In fact, we can be way off. But my point is twofold:
1. We don’t know that it’s a machine trustworthiness issue at play here. And it wouldn’t have to be if the compromise exposed an organizational or domain administrative account’s credentials.
2. We can’t forget that even the best security can be undone with sloppy practice. While it’s not impossible for an internal machine’s trust to be one of the issues here, it’s also not impossible that this was just someone taking advantage of careless practice by a human.
It all depends, though. If it turns out this did not involve gaining an exposed organizational/domain admin credential – even if it’s just to grant rights to that intrusion-created “Best1_user” username – then you’re right. There’s commentary there begging to be made regarding Target’s IT setup. But it all depends on specifics. I really wish some more detail was forthcoming on this topic. I hope Brian gets further news soon.
Is it possible the pharmacy records were also compromised? This may explain the e-mail address breach. Target may not want to admit that one.
I would say it’s a possibility, yes. They seem to have more than the magstrips. I’m not sure I’d worry so much about that, though. In ancient languages, the word for “thief” was inflected as a “profession.” These guys want to monetize the data. The cheapest way is to use & sell cards and steal identities to do the same. Your personal data would require some sort of communication with you to monetize. That’s risky, and they’re not going to do that. It’s just business for them. That said, there’s no reason you can’t employ another profession that everyone hates — lawyers — to profit on your end 🙂
@Brian
Are we talking the POS devices (i.e. Windows + POS) or the card reader devices? Target’s cardreader devices are notably cool with color LCD displays that are seasonally updated (push? pull?), so I was slightly suspicious of them. On the flipside, I don’t see how they’d be directly connected to any ‘net (probably ta USB/serial device or similar), so I started to lean toward the POS computers running windoze as I was guessing.
Would anything like Zemana or Keyscrambler have made this more difficult? What I’m confused about is why Target even allowed outgoing connections at all (except to a whitelist) from their POS network, which should have been isolated in such an elaborate scheme.
Zemana, as I understand it, installs a kernel module that stops input (and I believe those cardreaders act like input devices) from being easily intercepted by other processes. Keyscrambler does something similar. Not that there’s no way around that, but it does add a wrinkle to the attack.
It’s interesting that an Israeli security firm warned about this sort of thing last Christmas. I still don’t know why their POS network wasn’t entirely firewalled.
Tripwire could have also stopped this from happening, so long as they had an employee poking around at the files that were being added and modified over time, no? Not saying I’d catch it, but it was catchable.
Target’s CEO confirmed the other day that the scanners were compromised, NOT the card readers. Part of the confusion is the term “POS terminal” seems to mean card readers to some and (more accurately) scanners to others.
You mean bar code scanner?
I don’t know what he meant, but I meant the card reader, which is probably attached via USB or similar to the Windows POS — just like a keyboard. In turn a process could be able to read the numbers as they went across the bus or in memory, etc. See http://www.zemana.com/. Obviously this sort of protection could be overcome, but I’m curious if it was a “keylogging” sort of attack reading USB or if it was actually viewing memory in a process from another process.
Finding the malware thats FUD is one thing.
Paying attention to 16GB of data transfered to an unknown location is a HUGE red light, but the light only works if it is turned on and some one is looking.
>Paying attention to 16GB of data
When spread out over the number of days that the breach spanned, it is an average of only 14Mb per hour.
Thanks for another great article Brian. Target has been remaining vague, claiming “ongoing investigation” as if the details of the break-in would not eventually come out. No doubt some blunder that allowed the breach to occur in the first place.
Anyone else starting to get phone calls from random numbers?
Thanks Target.
Thanks Brian for your amazing reporting. You are the ONLY source I trust on this topic.
I am getting calls from random numbers since my data has been breached. Some of them are international calls from Dominica (small caribbean island) , a country I have no ties to and have never been to. I have turned off international calling on my phone for awhile since I don’t need it right now, and I don’t want to have to change my cell phone number.
I am also getting more spam.
I got that annoying and pathetic Target email two days ago but have been getting the unwanted calls and more spam for several weeks.
I think the English for what you are experiencing is ‘opportunistic’. You are probably not getting all of these spams about Target from the people who breached Target or who ever may have that data — you are probably getting all of those spams from people who know that so many people were affected by this Target breach and are more likely to click. It is certainly more ‘compelling’ if you are a victim to click on something related to something very big in the news than to click on ‘man flying through air catches baby from train’.
Instead of Target or a hired Security Contractor, could the malware creators have uploaded samples to virustotal.com to ensure that their product wouldn’t be tripped up by AV?
No, Joseph, the attackers would know better than that. Virustotal shares all of its results with all of the antivirus vendors, so by submitting their malware to Virustotal, the thieves in this case would essentially be shooting up a flare saying, “Hey look at us!”
Malware writers turn to services like ghostbusters[dot]cc, chk4me[dot]com and the like, which explicitly state that they do *not* allow reporting back to the AV firms.
ah ok, thanks. Sometimes in the physical world, the crims will trip themselves up on something simple.
This article have been written almost 2 years ago:
http://www.nytimes.com/2012/02/19/magazine/shopping-habits.html
It gives you a clue how much data Target holds on their clients and what it does with it. One has to wonder if this somehow related to leak of the emails.
It looks like those virustotal links you put in your article have different information than what you are reporting. They state that Symantec at least is detecting the malware as Infostealer.Reedum.B and has been since 12/19
Great work Brian and great confirmation from http://m.startribune.com/news/?id=240511201&c=y
From F-Secure’s blog: “Was ‘Metadata’ leaked in the Target breach?”
http://www.f-secure.com/weblog/archives/00002660.html
“… one thing I’d like to know is this: if Target knows you’re pregnant… do the hackers now know, too?…
… Target generates lots of metadata and customer analytics.
According to Bloomberg, Target has said the theft of customer data may have affected anyone who provided it basic information over the past several years. Provided?
As in data that was filled out on an application for credit — or does “provided” include data that was learned based on shopping patterns? The breach of 70 million records which included name and home address hints at a back end compromise that is far deeper than point of sale malware.
We’ve all learned the value of metadata in the last half-year.
Forget about the breached credit card numbers. Target’s analytics would be an identity theft goldmine.”
I am going to guess that they may have the potential to obtain that information but that it is very unlikely that they have it. I suspect this is something that is generated repeatedly and maybe “on the fly” as purchases are made. I may very well be wrong, I do not know how their systems work, but my guess is that this would require a lot of country-wide purchasing data which would be a lot larger than any customer database and which would be seen as very risky to try to take away from their internal network by a hacker especially because it would not only be very large but probably have to be repeatedly obtained. The size of data they were said to extract would have been much larger than tens of gigabytes of data to have included purchasing data but the 70 or so gigabyte figure that was given does sound approximately correct for about a hundred of million customers’ personal loyalty information or so.
But these are only guesses.
I am making the assumption that those were not 70 gigabytes of data after compression, here, of course.
This in part is why I am a fan of requiring digital signatures on executables. Any executables to be distributed would be signed during development and/or QA, and things like POS terminals should reject any executables that are not properly signed.
Anyone who wishes to distribute malware in such a network would need to get into the machine(s) on which the signing certificate private key is stored, and ideally this should be a very small number of machines even in an organization as large as Target.
Ah, but such a good idea would require Target and it’s shareholders to forgo %.010 of the annual earnings due to infrastructure upgrades. Besides, Microsoft says we’re safe the way we are. (i’ll bet this conversation, or one very similar actually happened in the Months/Years preceding this horrible mess.) I feel really sorry for the Men and Women of Targets’ NOC . This is the kind of stain that doesn’t wash out of a resume too easily.
@Eric, I am curious about your thoughts about digital signatures vs whitelisting. Is one better than the other? Or is each suited to different (possibly overlapping) needs?
Given the compromise of a few big-name CA’s, not to mention leaked signing keys, I wonder if signing is any better than whitelisting.
In reality using digital signatures on executables is a form of whitelisting, but if you start reading about the subject you will find that there are several other ways of doing whitelisting that are discussed.
At the end of the day, whatever method you choose should be one that is extremely difficult for a miscreant to bypass or defeat, and it should be one which isn’t difficult to administer.
Exclusive: Cybercrime firm uncovered six active attacks on U.S. merchants
http://www.reuters.com/article/2014/01/17/us-target-databreach-idUSBREA0G18P20140117
Hi Brian,
Thanks for making this information available, and keeping the topic at the forefront. I appreciate your having to walk a fine line between quickly publishing facts about this breach while simultaneously respecting the need to independently confirm the facts as well as hold back others for the benefit of security and possibly law enforcement.
That said, as someone concerned about preventing breaches, here are a few lingering questions that I hope will one day be answered:
How did these crooks initially penetrate the Target network? (social engineering, inside job, malware, plain dumb luck)?
How was the malware introduced to the POS systems? Was it centrally distributed from one source, or did each infected Windows workstation proceed to infect others? Did it achieve 100% success in penetrating all the POS systems throughout all Target stores? Why or why not?
And, as others have asked, how did the thieves obtain data that isn’t stored on credit cards (e.g. email addresses)? Was this through the other “infected machine” that FTP’ed the data in batches? Or were other systems within the Target network also breached? Or is Target taking the prudent view that, although they don’t know if other systems were breached, they will assume the worst case and act as if all private data was accessed? This doesn’t seem likely as there is a lot of anecdotal evidence to suggest that even customers who didn’t shop at Target during the period in question have seen fraudulent charges on their cards.
Hoping that all the facts will eventually be revealed so that this event can serve as a case study for all us concerned about security.
About the past week’s round of “Dear valued guest” e-mails from Target and how non-Target customer e-mail addresses may have been obtained, there’s speculation in the comments to the James Lyne column in Forbes that other online retailers including Amazon have “shared marketing agreements” with co’s like Target which could have lead to the addresses being shared.
My own experience was browsing on Amazon for a brand-name product that is carried at Target (it may have been an exclusive-to-Target brand) brought up a link to the exact item on the Target website in the “third party / external vendors” area of the Amazon page. Dear valued guest letter received even though I don’t have a Target acct or shop at Target during the affected period.
http://www.forbes.com/sites/jameslyne/
Two days ago I received an unsolicited email purportedly from the President at Target apologizing for the breach in security.
The mail header indicated that it did not come from Target, so I deleted it.
I suppose this could be the first blast of a phishing attack on Target customers.
I have never shopped at Target, so of course that is what triggered my spidey sense on the email.
The graphics were poorly done, as was the email layout.
Huge article in the NY Times (Business Day section) on the Target fiasco. Article is dated January 17, can be found on nytimes.com.
Brian is prominently mentioned several times !
PIN security has been the centerpiece for consensus standards at X9 (www.x9.org) for decades now. Having limited knowledge of Targets POS or MSR implementations, it’s difficult to understand why Target wouldn’t have demanded ANSI X9.8 and ANSI X9.24 PIN security and key management implementations from all their terminal vendors at accept debit.
Is it correct to assume that the impact on debit card w/PINs would be less significan if this was the case?
From everything I keep repeatedly hearing about, is as long as it was PCI compliant Target could care less. I suspect they took the lowest form of security that could allow them to squeak past, even using that standard.
A good PCI consultant once told me that my organization could never afford to become SAQ D compliant due to complexity and cost. I am beginning to wonder if any organization can truly be SAQ D compliant. The same consultant felt strongly the best answer in many cases is a swipe divorced from the computer and one that encrypts at the head. The cost of such swipes has really come down to a few hundred dollars per unit. I wonder why Target couldn’t take that step.
No, it would not be correct to assume that. Any device that is used to accept debit cards has to implement the appropriate standards for PIN encryption. Target disclosed that encrypted PINs were taken. The card number or other data on the magstripe is not encrypted as part of the standard.