An examination of the malware used in the Target breach suggests that the attackers may have had help from a poorly secured feature built into a widely-used IT management software product that was running on the retailer’s internal network.
As I noted in Jan. 15’s story — A First Look at the Target Intrusion, Malware — the attackers were able to infect Target’s point-of-sale registers with a malware strain that stole credit and debit card data. The intruders also set up a control server within Target’s internal network that served as a central repository for data hoovered up from all of the infected registers.
“ttcopscli3acs” is the name of the Windows share used by the POS malware planted at Target stores; the username that malware used to upload stolen card data was “Best1_user”; the password was “BackupU$r”
That analysis looked at a malware component used in Target breach that was uploaded to Symantec’s ThreatExpert scanning service on Dec. 18 but which was later deleted (a local PDF copy of it is here). The ThreatExpert writeup suggests that the malware was responsible for moving stolen data from the compromised cash registers to that shared central repository, which had the internal address of 10.116.240.31. The “ttcopscli3acs” bit is the Windows domain name used on Target’s network. The user account “Best1_user” and password “BackupU$r” were used to log in to the shared drive (indicated by the “S:” under the “Resource Type” heading in the image above.
That “Best1_user” account name seems an odd one for the attackers to have picked at random, but there is a better explanation: That username is the same one that gets installed with an IT management software suite called Performance Assurance for Microsoft Servers. This product, according to its maker — Houston, Texas base BMC Software — includes administrator-level user account called “Best1_user.”
This knowledge base article (PDF) published by BMC explains the Best1_user account is installed by the software to do routine tasks. That article states that while the Best1_user account is essentially a “system” or “administrator” level account on the host machine, customers shouldn’t concern themselves with this account because “it is not a member of any group (not even the ‘users’ group) and therefore can’t be used to login to the system.”
“The only privilege that the account is granted is the ability to run as a batch job,” the document states, indicating that it could be used to run programs if invoked from a command prompt. Here’s my favorite part:
“Perform Technical Support does not have the password to this account and this password has not be released by Perform Development. Knowing the password to the account should not be important as you cannot log into the machine using this account. The password is known internally and used internally by the Perform agent to assume the identity of the “Best1_user” account.”
I pinged BMC to find out if perhaps the password supplied in the Target malware (BackupU$r) is in fact the secret password for the Best1_user account. The company has so far remained silent on this question.
This was the hunch put forward by the Counter Threat Unit (CTU) of Dell SecureWorks in an analysis that was privately released to some of the company’s clients this week.
Relationships between compromised and attacker-controlled assets. Source: Dell Secureworks.
“Attackers exfiltrate data by creating a mount point for a remote file share and copying the data stored by the memory-scraping component to that share,” the SecureWorks paper notes. “In the previous listing showing the data’s move to an internal server, 10.116.240.31 is the intermediate server selected by attackers, and CTU researchers believe the “ttcopscli3acs” string is the Windows domain name used on Target’s network. The Best1_user account appears to be associated with the Performance Assurance component of BMC Software’s Patrol product. According to BMC’s documentation, this account is normally restricted, but the attackers may have usurped control to facilitate lateral movement within the network.”
According to SecureWorks, one component of the malware installed itself as a service called “BladeLogic,” a service name no doubt designed to mimic another BMC product called BMC BladeLogic Automation Suite. BMC spokeswoman Ann Duhon said that the attackers were simply invoking BMC’s trademark to make the malicious program appear legitimate to the casual observer, but it seems likely that at least some BMC software was running inside of Target’s network, and that the attackers were well aware of it.
Update Jan. 30, 5:48 p.m.: BMC just issued the following statement:
There have been several articles in the press speculating about the Target breach. BMC Software has received no information from Target or the investigators regarding the breach. In some of those articles, BMC products were mentioned in two different ways.
The first was a mention of a “bladelogic.exe” reference in the attack. The executable name “bladelogic.exe” does not exist in any piece of legitimate BMC software. McAfee has issued a security advisory stating that: “The reference to “bladelogic” is a method of obfuscation. The malware does not compromise, or integrate with, any BMC products in any way.
The second reference was to a password that was possibly utilized as part of the attack, with the implication that it was a BMC password. BMC has confirmed that the password mentioned in the press is not a BMC-generated password.
At this point, there is nothing to suggest that BMC BladeLogic or BMC Performance Assurance has a security flaw or was compromised as part of this attack.
Malware is a problem for all IT environments. BMC asks all of our customers to be diligent in ensuring that their environments are secure and protected.
I parse their statement to mean that the “BackupU$r” password referenced in the Target malware is not their software’s secret password. But nothing in the statement seems to rule out the possibility that the attackers leveraged a domain user account installed by BMC software to help exfiltrate card data from Target’s network.
Original story:
According to a trusted source who uses mostly open-source data to keep tabs on the software and hardware used in various retail environments, BMC’s software is in use at many major retail and grocery chains across the country, including Kroger, Safeway, Home Depot, Sam’s Club and The Vons Companies, among many others.
A copy of the SecureWorks report is here (PDF). It contains some fairly detailed analysis of this and other portions of the malware used in the Target intrusion. What it states up front that it does not have — and what we still have not heard from Target — is how the attackers broke in to begin with….
HOW DID IT HAPPEN?
The folks at Malcovery (full disclosure: Malcovery is an advertiser on this blog) have put together a compelling case that the avenue of compromise at Target stemmed from an SQL injection attack. Malcovery notes that techniques that may be similar to the Target breach were used by the Alberto Gonzalez gang, as illustrated in an indictment against Vladimir Drinkman, Aleksandr Kalinin, Roman Kotov, Mikhail Rytikov, Dmitriy Smilianet (see Hacker Ring Stole 160 Million Credit Cards for more information on these guys).
As that report notes, Drinkman and his associates were co-conspirators of Albert Gonzalez (famous for the TJX breach), Damon Toey, and Vladislav Horohorin (BadB). Drinkman and his gang of Russian hackers were active from at least August 2005 through at least July 2012 and were charged with stealing data from NASDAQ, 7-Eleven, Carrefour, JCPenney, Hannaford Brothers, Heartland Payment Systems, Wet Seal, Commidea, Dexia Bank, JetBlue Airways, Dow Jones, an unspecified bank in Abu Dhabi, Euronet, Visa Jordan, Global Payment Systems, Diners Singapore (a regional branch of Diner’s Club), and Ingenicard.
Malcovery’s CTO and co-founder Gary Warner writes:
“In each of these cases, an SQL Injection attack resulted in malware being placed on the network and credit card or personal information being exfiltrated from the network. According to the indictment for the above, Gonzalez and Toey would travel to retail outlets and make observations about which Point of Sale terminal software was being used, afterwards, they would pass the information to the hacker crew who would penetrate the network, customize and load the malware, and exfiltrate the stolen data.”
A copy of the Malcovery report can be downloaded here.
EAGLE CLAW, RESCATOR, AND LAMPEDUZA
An advertisement for “Eagle Claw,” a base of more than 2 million card “dumps” stolen from Target.
Meanwhile, the cybercrook known as Rescator and his merry band of thieves who are selling cards stolen in the Target breach continue to push huge new batches of stolen cards onto the market. In an update on Jan. 21, Rescator’s network of card shops released for sale another batch of two million cards apparently stolen from Target, a collection of cards which these crooks have dubbed “Eagle Claw.”
Working with several banks anxious to know whether this batch of two million cards really was from Target (or else some other recent breach like Neiman Marcus), we were able to determine that all of the cards purchased from Eagle Claw were used at Target between Nov. 27 and Dec. 15. The method behind that research was identical to that used in my previous research on this topic.
Incidentally, anyone who wants to understand the hierarchical pecking order of Rescator’s crew should check out this analysis by security researcher Krypt3ia, which examines the Lampeduza cybercrime forum of which Rescator is a leading member.
Anyone hoping that this retail breach disclosure madness will end sometime soon should stop holding their breath: In a private industry notification dated January 17 (PDF), the FBI warned that the basic code used in the point-of-sale malware has been seen by the FBI in cases dating back to at least 2011, and that these attacks are likely to continue for some time to come.
A frequency analysis of POS malware incidents assembled by Recorded Future.
“The growing popularity of this type of malware, the accessibility of the malware on underground forums, the affordability of the software and the huge potential profits to be made from retail POS systems in the United States make this type of financially-motivated cyber crime attractive to a wide range of actors,” the FBI wrote. “We believe POS malware crime will continue to grow over the near term despite law enforcement and security firms’ actions to mitigate it.”
“Best1_user”; the password was “BackupU$r” seems not good enough for such an operation.
No argument there. No matter whether it’s the default password or one assigned by Target, it’s not close to secure in this day and age.
What’s worse is BMC’s security-by-obscurity attitude towards that account. If it can be leveraged, then it must be open to control and be securable by the sysadmin.
To be honest, though, I wonder if that was really the password, or if the intruders were able to change it to something easier somehow. I don’t know if we’ll ever find out. If that was the default, developer-set password, then BMC has some serious explaining to do.
Ahhh, I should’ve read the linked BMC document. There is indeed a process to delete that “Best1_User” account.
Well, It has Upper, Lower and Special Char..but is missing the number. 🙂
Giving me more reason to adopt a cash-only policy when shopping retail brick-and-mortar stores.
I’m for more regulation as far as the technology these major retailers employ — Especially when an exploit is known. They have to “patch their s” in the words of a popular online broadcast network.
In addition, I think that a company needs to be forced by law to report breaches like this publicly within 24 hours of discovery. Maybe not the full technical details but enough so that:
1. Other retailers can investigate their own systems asap
2. Banks can alert their customers of the breach and begin the (now common) process of cancelling and re-issuing account numbers.
(Or as much as is know as it becomes known – at least to the extent that #1 and #2 above can be properly investigated by the other parties needing this info.)
Doesn’t Canada have a law for reporting breaches similar to this?
Legislating a 24 hour window for reporting to the media about a breach after discovery won’t necessarily provide consumer protection (see next paragraph) and could create significant managerial and consumer confidince issues
If you read the Verizon DBIR reports we see an average of months of time between actual compromise and discovery of it. In a (and we’ve seen this recently) situation where customer information is for sale before the source company is even aware of a breach, which from the Verizon data I imagine is common, the damage is already done regardless of when they report.
At which stage in the investigation would the 24 hour timer start? We could set it at: 1.) when security personnel/service notices anything suspicious (sliding scale – set it too low and the news would have too many to mention and stop caring, along with staff being in constant red-alert), 2.) when security personnel verify a compromise (what assets does this actually include? Think of all the endpoints – customer service etc.) See point 1’s comments), 3.) when security personnel verify exfiltration (seems reasonable but can be hindered by point 5. Also … what type of data is subject?), 4.) when the breach has been contained, or 5.) when the criminal investigation is complete
It’s complicated deciding at which stage to alert, on what data, and what the time window is. There are many, if not the majority, of cases where you could buy your information on the underweb before the sources of the data knows they have a problem. They have finite resources; security doesn’t directly make money for most companies and so the paradigm is to pay into security to the level of (perhaps naive or creatively calculated) acceptable risk. At which point you decide to mark as the notification-worthy event, and how much time they have between discovery and reporting, has very significant implications in the way of demands on the security service or department, and supposedly the talent in the workplace is already spread beyond thin
For this particular string of breaches, it is rumored that up to 6 (maybe more) retailers have determined that they have been victims of the same kind of attack that was reported for Target.
For any of those retailers, the “stage” to go public is way past due at this point if they have confirmed a breach of the same nature.
I would like to know which these other retailers might be. I shopped at more than just Target during that time range and wonder which of my other accounts may have been compromised.
As far as technical details relating to attack vectors, I understand the need for caution when releasing this information. Given enough information, details of this nature could lead to further compromise. This isn’t what I am explicitly asking for here. (I hope that other retailers using some of the same technology have been/are being alerted to possible security flaws as a preventative caution.)
The drive of my comments is this:
If I trusted you (retailer/vendor/service provider/etc.) with any of my personal data and you learn that it was compromised, I want to know that I was a victim as soon as you know. No exceptions.
What’s the start point to notify customers and stockholders of evidence of a data breach?
I’d say between 24 hours of when the EVP/SVP for IT/Security or CTO first calls the CEO to report “Houston, we got a problem”, and the CEO in turn calls law enforcement to report the breach.
The final clearance point for the CEO to release his public breach notice is right after he gets the clearance from law enforcement that there is NO continuing criminal investigation going on inside the CEO’s company.
The customer has a notification need to protect his data and accounts from further damage (Security Freeze).
The stockholder has a notification need to know that the firm’s equity is facing a liability hit, amount soon to be determined.
No CEO wants to be in this post-breach podium position with the kleig lights on. But nothing like breach accountability to get a CEO’s attention at security budget time.
The softness of security described above is not an accident.
Just a minor correction. 🙂 The caption for the first graphic says ‘“ttcopscli3acs” is the name of the Windows share…’. That would actually be the domain name as mentioned in the rest of the article, or it could even the machine name they were connecting to if they were using a local account. c$ is the share.
I would guess that “ttcopscli3acs” is the local host name, not the domain name. Just by the little bits I have read, the “Best1_user” user was a local system account. It looks like the script connected by IP to 10.116.240.31 and then authenticated using the ttcopscli3acs account which had system right to connect to the file share and upload the dumps. Then another server connects to the file share using the same service account to ex-filtrate the data.
The one image shows 4200 cards with CVV2. Unless Target was storing CVV2 values persistently in their database (in violation of PCI standards) then this data would have been scraped from live in-progress transactions. Because this is a small percentage of the total number of cards offered, what does that tell us? Online transactions only?
Worse yet, wouldn’t it been scraped very soon in the transaction? I don’t have practical experience with PCI-DSS, so I’m only going off of what I was taught (by mandate of where I work), but: Don’t the CVV2s/CVC2s get encrypted right on the payment card terminal itself? I thought the breach happened at the POS, which should be a step removed from that level of encryption if I understand things correctly.
**IF**… again, I may be off about a lot of that. Someone correct me if I got any of it wrong. Anyway, aren’t the CVV2/CVC2 numbers encrypted very, very early in the process? And if so, does that illuminate something about how far “downstream” the compromise went?
Cvv2 is not encoded on the mag stripe. It would have to be input manually somewhere. Some retailers do input the CVV2 as a check against counterfeit cards.
Payment terminals do not encrypt anything other than a debit PIN unless they have implemented a P2PE solution.
Oh, whoops! It’s the CVV/CVC stuff that gets on the mag stripe, not the CVV2/CVC2. I got it backwards. That’s my mistake.
Yeah, you all can tell that training stuck real well, can’t you? 😉 But in all seriousness, when you don’t deal with something regularly, training will never stick. Raises the question of why my group’s mandated to have it when we never deal with it, but that’s for our upper management to answer…
Some credit card terminals, in particular, the new MagTek with DynaMag technology don’t transmit credit card track data in the clear.
This is relatively new technology; and from what I understand, requires a handshake or key exchange between the POS terminal software before the MagTek reader kicks out encrypted, tokenized transaction data.
I guess the reader also includes a serialized header, both of the transaction number and also in the hardware itself. A credit card processor like FirstData could in theory track where fraudulent hardware goes after a fraudulent merchant account is shut down.
Overall, it’s likely the best hardware solution; hopefully it becomes a requisite requirement for credit card processing within the next 5 years. The technology protects cardholder data, and also helps to identify fraudulent merchants too.
Okay, but many technologies are out there that prevent replay, much like the over-hyped and expensive Chip-&-Pin, and have 3rd factor authentication, AND are already out there, and don’t need further development. So why spend money doing over what is already proven?
These technologies are cheaper by far, than any solution we’ve discussed on many security forums. But this is not the point AT ALL – what is going on with the subject of the article Brian has graciously presented lately! The problem is likely NOT the authentication tech, but the way it is implemented!! You can have the best thing going since sliced bread, but if the networking and code are vulnerable, then no Supercalifragilistic crap is going to save the system!
Look at what has happened and learn for the future. Expensive-badly conceived-failure, is NOT going to solve the problem, CHEAP-SMART is going to do it, and very economically! We all need to buck up and force our solutions management to a new level. This kind of talk can also end up stupid, I will admit, because we should see all threats on the horizon, and we should be able to pro-actively engage a new threat BEFORE it attacks our systems!
I realize some feel that some kind of predictive preventative measures are a limited part of the picture, but maybe we need to think more like a criminal to beat him at his own game!!?? I like to think better, faster, cheaper as a mantra to modern problems, and why not? I’m not even sure PCI needs a complete overhaul, as I’ve seen good discussion here and elsewhere that maybe simple tweaking can have far reaching improvements!
Mind citing a couple or three suggested tweaks? I’m curious.
My favorite mix would be Magneprint with Passwindow as a third factor authentication scheme. The special characteristics of the reader for Magneprint prevent replay – in fact if it detects ANY identical swipes, it will reject the submission immediately. No prepeated swipe can be the same when done by the human hand.
The above looks familiar … yep, see July 2012 link below. Since then electronic commerce (computer based) and mobile commerce (web enabled smartphone) are growing rapidly (see Forbes link). While the referenced items are beneficial for physical presence transactions, how do they work for e&m commerce? Does everyone have to carry their own devices like an EMV reader? To get widespread adoption any solution should be beneficial in card-present and card-absent situations and impose as few infrastructure modifications as necessary.
Jonathan
July 2012
http://krebsonsecurity.com/2012/07/atm-skimmers-get-wafer-thin/comment-page-1/#comment-92412
October 2013 Forbes Ecommerce Is Growing Nicely While Mcommerce Is On A Tear
http://www.forbes.com/sites/chuckjones/2013/10/02/ecommerce-is-growing-nicely-while-mcommerce-is-on-a-tear/
Most tech postings here are WAY over my head but I still think MY experience with Target is relevant. And I think you’re on the right track, Harry.
I received the Target, “…your information was compromised…” e mail from Target. But I did not use any card during the pre Christmas period.
I figure the ONLY way Target could have or have LOST my personal info (including e mail address) would be from a defective merchandise return two years ago.
So can anyone explain how a compromise of the POS scanners could open a path to their (wrongfully maintained) entire database? And I’ll bet that database included all employee info as well.
ltjd, Thoughtful item in your post about the underpaid, benefit starved staff at all the affected retailers. They use plastic to buy from their respective stores and also get stung just like everyone else. I’m sure the geniuses in suits governing day-to-day store policies and operations are way too busy playing spin the “blame” bottle to consider that staff allegiance will at best diminish or soon tank and become non existent. co mingle massive breaches with employee anger and the walk-in retail environment may cease to exist.
Target suffered email address theft too which was separate from the credit card number theft. And the credit card number theft did not include email information. So you probably received the notice because your email address was taken.
“No portion of this report should be released to the media, the general public, or over non-secure Internet
servers”
Ok, who leaked the FBI report?
The NSA?
Heh!Heh! Yeah! Really! 🙂
One thing that strikes me is that the POS software really ought not have any card data in memory once the transaction is complete. But the implication from the SecureWorks pdf file is that the malware would scrape the ram once per hour. Although I suppose it is possible that the reverse engineering in the PDF is either simplified for presentation or it isn’t quite correct.
Best practices would involve zeroing any memory that contains sensitive data like this before releasing it – the idea being that you keep it for the shortest period of time that you need it and then erase all traces.
No. The malware ran as a service and “scraped” data constantly, writing it to a file. It tries to move it to the dump server once an hour.
Thanks for this insightful research.I’m continually amazed at the lack of real information in the media regarding this breach.
I have been intensely curious as to how such a large volume of data could be stored within and transit undetected through Target’s intranet out to the ‘real world’.
And, a SQL injection to initiate the attack? That is stunning — it’s just so Y2K.
Such a glaring oversight speaks volumes about the lack of internal security controls at Target. Shareholders should take note.
I imagine they spend more money on figuring out which employees shoplift than what their internal IT systems are doing.
Thanks again for your reporting.
The glory of outsourcing all your IT needs is that now you and all the other companies using that same IT provider are vulnerable to the same things.
Sad that the executives responsible for shoving IT into an outside role won’t ever be held responsible for their poor decisions.
I did some IT work with Target during college through a school program. Their internal IT department is HUGE and is definitely not outsourced. They’re actually pretty revolutionary, yeah the retail side is a lot of older windows server stuff, but their cloud and big data was pretty cutting edge.
Go to Target’s jobs website, using the “Search management & corporate careers” field search for “software”, and note how many jobs are located in Karnataka, Bangalore, India.
You too can be a Peggy!
To my knowledge, the whole point of CVV code is in fact that it’s not on the magnetic strip at all. It’s just printed on the card itself. The idea behind it is to assure that card was physically present at the time of transaction.
You notice how some stores are now aasking you to handle the card to the cashier after you swiped it? My undestanding that original idea was to let cashier enter the CVV code from the card. But in all places where I see that happening they all entering last 4 digits of the card number. All they do is verify that what is encoded on the card magnetic strip is what printed on the card.
Again, from my knowledge it’s more difficult to reverse the transaction if it accompanied by CVV code.
Correct. This is usually so the cashier can hold and look at the hologram.
Also, some stores POS systems would require entry of the Last-Four digits. This is purely to have the cashier look at the embossed numbers on the front, ensure they match.
I remember reading about what purchasers of breached data would do. I recall a breach in the past where the credit card track data could be encoded on a 3-inch piece of VHS video tape, and then glued to a piece of cardboard. The fraudsters would purchase gas, often for others, and recieve payment in cash, saying they’d pay with a “Gift Card” or something.
That case broke when the Gas Station manager installed a CCTV camera.
The CVV code is coded in the magnetic strip of the card. CVV2 is the code printed on the card. This helps to the type of transaction..in other words “Card Present” for swiped transactions use the CVV1 coded in the magnetic strip. Internet or Phone based transactions use the CVV2 code to verify the user has the card with them.
The newer chip based cards use a separate security model for each transaction. I haven’t kept up with it, but I think at one point they used a CVV type code that changed with each transaction. The card is in sync with the server in a way similar to RSA tokens. I could be off on this.
>The card is in sync with the server
That was hacked with a “pre-play” attack in 2012.
see the University of Cambridge
http://www.cl.cam.ac.uk/~rja14/Papers/unattack.pdf
more weaknesses of EMV at
http://nc3.mobi/references/#EMV
Jonathan,
Yes you are correct. I read that report when it came out. Again I say and have said it on everyone of Brains blogs related to this and other breaches. Crime is and always will exist. 18 years in the credit card industry and never saw the silver bullet. Same with Cyber/Information Security, it will always exist. Criminals are criminals because they want the easy money, and frankly, it becomes a job. Whatever the motivation for obtaining the money, drugs, women, recognition, organized crime or just to get the money…….they will find a way…..always have and they always will.
A 32 year veteran of law enforcement (15 years robbery homicide, bank robbery (5 FBI most wanted arrest) 10 years Swat Commander) once told me…”criminals always get away with, for a bit, but they always get caught. I don’t care if its 10 years or 30 years later, we always catch them. Their criminals because they have no honor as real people do”.
swattz101, thanks for that explanation. So the data stolen from Target would only be useful for creating duplicate cards and using them in person at stores OR shopping online with merchants who don’t require the input of the CVV2. And if most of the use at stores I can see why the zip code would be handy, so as to not alert the credit card providers.
I always feel uncomfortable providing the CVV2 for online purchases, I’m concerned that it might be stored (or, now, scraped), but I do see the benefit of requiring it.
Changing default passwords is a PCI mandate. Apparently Target isnt PCI compliant or they somehow overlooked this in their internal vulnerability scans that should have caught this.
Based on the documentation from BMC, it is not possible for the users of the software to change the default password on this account or the software will not be able to use it.
BMC made the false assumption that because it had limited login abilities, even though it was an administrative account, it was secure and the default password was nothing to be concerned about. In this case, the issue was not the fault of Target, but of BMC Software. The password in question should have been randomized during each software installation, at the least, and a better method would be the software periodically (automatically) changing the password to a new randomized value.
The hackers didn’t need to use the BMC account to move the data. The BMC account just made it a little easier and probably less noticeable.
During the installation of the product, you can choose to create that account or not create it.
If someone tells you that you can leave your front door locked or unlocked and you leave it unlocked, who is at fault when your house is burgled?
So we finally find out what “Victor’s vector” was; all I can say is, “It was a hell of a week to stop drinking!” :p
“I want every available light dumped on POS systems.”
🙂
Me too Mike! I gotta say that as far as Target management goes, they are probably saying it was the wrong week to quit taking amphetamines too! HA!
http://www.youtube.com/watch?v=VmW-ScmGRMA
😀
“We have to call the Secret Service about a data breach at Target.”
“Target? What is it?”
“It’s a big set of concentric rings people shoot arrows at, but that’s not important right now…”
“Eagle Claw” is an old and well know brand of phishing….er fishing gear.
http://www.eagleclaw.com/
Also the code name for the ill-fated Iranian rescue mission
http://en.wikipedia.org/wiki/Operation_Eagle_Claw
And a martial arts form
http://en.wikipedia.org/wiki/Operation_Eagle_Claw
But the first seems most relevant here. (-;
Insecure enterprise management software is certainly a good find for any attacker looking for a rapid return on investment. All it takes is a vulnerable remote desktop with weak credentials and poor network ACL’s to allow an attacker into such a server and then the dominos fall. When I first noticed this UNC activity in the malware I assumed that the threat actors were leveraging existing and expected network activity between trusted hosts (the PoS terminals, and a management server), or that they were trying to blend in by using credentials seen elsewhere on the Target network. In any event, it’s a lateral movement story and a great case study for why internal network monitoring and alerting is important.
I work with many BMC products inlcuding Bladelogic and BPPM (performance monitoring) and my hunch is that its not BMC software nor the password complexity thats at fault here. The attackers were using commong system processes to pull out cc information to the shared drive. They could have used Sys accounts and service accounts if they so chose.
Target should investigate their internal IT dept or their IT vendor if they outsource their IT ops. The attacker was most likely an ex employee or someone with admin level access to high level systems like BPPM or Bladelogic. Another way of getting access to these BMC admin accounts is running a SQL injection script (assuming Target uses SQL) and piping out the admin password. Either way its someone who was very familiar with Target’s IT infrastructure.
>Either way its someone who was very familiar with Target’s IT infrastructure.
It certainly raises the question about the involvement of an insider, or former insider. But disaster recovery planning includes detailed documentation of network configuration and procedures. Once the bad guys had gotten inside, they might have encountered such documentation.
I also thought that this was the case: it had to be a current or recently departed employee possibly doing this as a way of “getting back” at his employer. I’d heard tell from someone who was in a position to know that Target had indeed outsourced part of its IT operations within the last 18-24 months but this is hearsay from someone who worked there at one time. It sure does seem like it must have been done by someone familiar with the infrastructure and I also think it must have been planned for some time as well. Just from reading this it required technical knowledge and expertise in addition to knowing the infrastructure there.
I totally agree, Markus. The hackers used the BMC account to move files, not to enter the system. They could have used any account to move the files.
The timeline in the SecureWorks report has to be off. If the attackers gained access on 11/27 and deployed the malware on 11/28, this means they mapped the network, compromised systems for the dump and exfil servers, did tons of lateral movement and privilege escalation on different boxes, got these BMC exploits, figured out a network share to use, figured out how to get the malware on all the windows POS boxes, customized the malware to look for the right processes on those boxes, and got it all working without a hitch or tipping off Target’s Info Sec team.
Either they are the best hackers on the planet, they had insider collaboration, or they were on the network long before the 27th.
That struck me as odd as well, but I don’t know how long the miscreants typically need to find their way around a corporate network.
Slightly off topic, but two different branches of TCF bank told my mother today that the target breach exposed actual account numbers (not debit/credit – actually bank account numbers). Yet I can’t find any information on this in the media. Anyone know anything about this? They had her cancel her checking account and set up a new one.
Susan – It sounds like TCF Bank is probably referring to any accounts linked to a Target REDcard.
That would make sense, but she has never had a red card – and they asked her that. Perhaps their staff are misinterpreting a memo.
Target uses “e-check” technology to process checks, so routing numbers & bank account numbers were present in the infected POS terminals. I don’t know if the malware actually read them (foreign crooks like these are more interested in credit & debit card numbers), but it’s entirely possible.
As far as REDcard debit, only new customers would have had bank account data in the POS terminals; existing cardholders’ numbers are in a central Target database. (I know that because Target once allowed me to change the bank account number of a REDcard transaction *after* it was made; my bank closed the old account for unrelated reasons.) Of course, given what’s come out so far, it’s not 100% certain THAT database wasn’t breached too…
Let me clarify that for REDcard debit I was referring to BANK account numbers. Card numbers, CVVs (*not* CVV2s) and encrypted PINs, of course, were included in the breach; but at most that can only be used for fraudulent Target purchases. (The potential of cracking the PIN is probably why Target suggested REDcard debit customers change their PINs; I did that just after Brian reported the breach, before Target even confirmed it.) Draining bank accounts directly via ACH debits requires the routing number & account number, which were actually easier for the malware to acquire from PAPER checks than from REDcard debit.
You guys did see in the BMC document that the Best1_user account could be created on the domain:
There are three account creation options available in the BMC Performance Assurance installation. These are to Create the
BMC Perform Agent User Account:
on the local computer
on the primary domain
do not create the account
How much you want to bet Target created the account on the domain?
Not matter what, when everything is said done. Target’s IT folks dropped the ball.
It’s on them for not taking the proper steps to ensure all accounts having access to servers regardless of the ability to run a batch job was not flagged by a simple audit.
Furthermore, allowing any software to use a built-in accounts with passwords. They failed Security 101 class for sure.
CHANGE DIRECTION – We need a conceptual shift from marginally better locks and vaults toward protecting the vital consumer data by never having critical information at the merchant. The merchant gets paid, the consumer gets billed, and even if crooks grab everything at the merchant, they can’t make purchases. Rather than expend considerable human and financial resources in what will be a perpetual battle between large IT shops and smaller, more nimble, crooks I suggest a simpler solution from the distant past that will stop damage today and in the future.
In the Art of War Sun Tzu wrote, “Hence to fight and conquer in all your battles is not supreme excellence; supreme excellence consists in breaking the enemy’s resistance without fighting.” This is psychological warfare: breaking the enemy’s will to fight. Here, consider removing the crook’s motivation to steal by taking away even the possibility of reward. Think a moment on this question:
If crooks are eventually going to breach the vault,
why put jewels there in the first place?
The challenge is to create a transaction system capable of paying the merchant and billing the consumer without ever exposing the credentials necessary to successfully impersonate that consumer. Such a solution should work within existing transaction and communication infrastructures and serve not only card-present commerce, but growing volumes of electronic and mobile commerce. Even better, the solution should provide additional functionality for operational efficiencies for consumer and merchant and provide benefits to all three parties: consumer, merchant, and provider.
Can it be done? I think so and it would be a cheaper than 300 million EMV cards & readers and a whole lot cheaper than another breach of this size.
Missed this in the above: No panacea, EMV has already been shown to be susceptible to exploits. To use EMV for electronic or mobile commerce, the consumer must have a card scanner, get a temporary code, and manually enter that code into the checkout screen, all of which adds complexity. Also, confidential data becomes plain-text inside the scanners, right where the RAM-scraper exploit existed.
Re EMV and electronic and mobile commerce – see http://www.SmartCardAlliance.org/pages/publications-emv-faq#q12
EMV weaknesses – See http://nc3.mobi/references/#EMV for links to original papers.
Many of these well reasoned comments refer to one or another practice that done wrong. Forget “best practices” some were just plain foolish, like NOT changing default passwords.
Think about how many “things” (elements) have to go right for a transaction, then for millions of transactions a day. If the probability of any “thing” going right is 99.00% then, if there are 69 elements to process a transaction the probability of the whole process being correct ( 1-%correct^elements ) is just 50%. (see tables below) If the probability of each element going right is 99.99% then at 6,931 elements the odds are again 50:50.
I doubt there are 6,000+ elements in processing a single transaction, but even at 10 elements that is 9.56% failure (at 99.00%) or 0.10% (at 99.99%). At 10 million transactions (a low estimate) that means we can expect failures for over 9,000 transactions.
The more complex the system the lower the probability it will function correctly, ESPECIALLY where humans are involved.
This is why we need a change of direction from more complex locks to a simpler system that does the job. As long as the merchant gets paid and the consumer gets billed NOT KEEPING critical information at the merchant is the way to go. What isn’t there can’t get stolen.
See
http://krebsonsecurity.com/2014/01/new-clues-in-the-target-breach/comment-page-1/#comment-226505
%Correct 99.00%
#Elts P(error)
1 1.00%
5 4.90%
10 9.56%
25 22.22%
50 39.50%
69 50.02%
100 63.40%
%Correct 99.99%
#Elts P(error)
1 0.01%
10 0.10%
100 1.00%
500 4.88%
1000 9.52%
5000 39.35%
6931 50.00%
the probability of error is rounded to showing just two digits.
99.99% @10 elements is actually 0.0999550120%
EMV does solve these problems, and most of the vulnerabilities found in EMV so far have been fixed without breaking the rest of the system.
EMV works by doing exactly what you suggest. It removes the merchant from the security of the loop. If a merchant’s security is compromised under EMV, about the worst that could happen is that the money from the transactions would be diverted from the merchant’s account to the thieves’ account.
EMV does two things to secure the account-holders’ money: it separates the concepts of identity, authentication, and authorization; and it moves the security operations to a hardened device owned and deployed by the bank, not the retailer.
In public your identity is not secret, and under EMV it technically does not need to be . Therefore retailers won’t have to be as concerned about protecting your account number, because the account number by itself is useless without the proper authorization to use it. EMV moves authentication to the terminal and the chip – you must enter your PIN into the terminal, where it is then sent to the chip. It is securely verified only inside that tiny computer, and has little to do with the security of the terminal. And only the chip produces the cryptographic authorization needed to transfer the money to the retailer, not the retailer’s terminal.
EMV still has a bit of maturing as these sophisticated attacks continue, but it’s proven remarkably strong at preventing actual fraud in the real world.
EMV may (I repeat may) be protecting the information, but it fails miserably in cost-effectiveness, ease-of-use and, oh yes, it has been compromised and will continue to be compromised. Crooks are not stupid and because they don’t have committee meetings, they are a lot more efficient.
Read the description of how EMV is used in electronic commerce (from a computer) and mobile commerce (from a web-capable cell phone) from the horse’s mouth (see below). I have to have my own reader, another gadget to carry. I have to manually transfer a one-time password from one device to another. What a PITA!
If internet connectivity is not available, or expensive to use, for an offline EMV transaction “… the card and terminal communicate and use issuer-defined risk parameters that are set in the card to determine whether the transaction can be authorized.” (see #q15 below) So I can’t make a purchase because my smart card wasn’t pre-configured for that level of “risk”, even though the cost is within my credit limit.
OR, someone who has cloned my EMV card uses it for low-value purchases where there is no internet used to authenticate. Can’t be done? Already been done: See http://www.theregister.co.uk/2011/10/10/mifare_desfire_smartcard_broken/ referring to researchers at Germany’s Ruhr University. How did they do it? ” [ the researchers ] … extract the secret key material non-invasively, basically by pointing a radio probe at the card and monitoring it as it performs a transaction, … This is something that’s easily replicable with a few thousand dollars and a little amount of time, so it’s practical.”
OR, completely bypass the PIN entry process to get authorization. Can’t be done? Already has been done: see article at
http://www.bbc.co.uk/blogs/newsnight/susanwatts/2010/02/new_flaws_in_chip_and_pin_syst.html
We need a conceptual shift from protection to not needing the critical credentials to pay the merchant and bill the consumer. If the information isn’t there it can’t be compromised. Think about it this way
If the crooks will breach the vault
why put jewels there in the first place?
Jonathan
= =
“For an online transaction, the user would insert the EMV credit or debit card into a handheld reader. Once the user enters the PIN, the reader will display a one-time password which can be used to validate the user’s identity. The user enters the password in the appropriate field on the merchant’s checkout page (or online banking site) and the password is passed back to the issuer for authentication …”
from http://www.smartcardalliance.org/pages/publications-emv-faq#q12
Re offline EMV transactions.
from http://www.smartcardalliance.org/pages/publications-emv-faq#q15
Jonathan,
What you’re missing by focusing on a few small portals of fraud is that such attacks are not scalable. You can’t replicate an RF based card cloning attack to 10,000 cash registers. EMV takes the massive value out of the current systems (leaving only internal targets like funds transfers). It drives these hackers to attack the retailers, not their customers.
Had these hackers stolen ten million dollars from Target’s bank account, a handful of investors would have lost some money. It probably wouldn’t have made the evening news. By stealing a few hundred dollars each from perhaps a hundred thousand cloned cards (out of 40 million, not all will be victims), they scared a nation full of shoppers. One of these outcomes is not like the other.
Jaded,
700 million compromises isn’t “small”. That total includes compromises from 6,000 to 139,000,000. Isn’t that “scalable”? Nor are the number of merchants “few”. Every one of them has to be protected.
EMV is good for card present transactions. Its drawbacks are its installation expense in the US and it is cumbersome for electronic and mobile commerce. ANY lock can be broken. EMV has been broken already. By truly removing the consumer information it can’t be stolen. Hiding it or protecting it has worked well until the last few years and getting worse. The ways crooks get in are few (for now), but NO MATTER how they get in, if it isn’t there, it can’t be stolen.
As for what locks Target wants to put on its own funds that is up to them and their shareholders. I’m a 21st Century consumer and I’d like 21st Century protection.
Of 40 million financial cards compromised in the Target breach, 100,000 (you wrote “perhaps a hundred thousand cloned cards”) is about one-quarter of 1%. I haven’t seen any evidence those will be the only victims. In fact, the article above has a graphic showing offering for sale dumps (charge card information) in quantities of 700,000 and 2,000,000 which, based on 40,000,000, that is 1.75% and 5.00%, many times more than you “perhaps”. Further these are only TWO offerings. Are there more? Who knows?
My own account has been compromised four times, three at some merchant, once by physical theft. Unlike Serena, each time I got a new account number and had to change my many auto bill elements. Some were easy, some were not. Figure two hours for me and I’m fairly well organized. Using that estimate the 40,000,000 financial accounts compromised due to the Target breach will require 80,000,000 hours be invested by consumers in the same endeavor. At 2,000 hours per working year that means the unpaid consumers will spend the equivalent of 40,000 people working for a year or one person working for 40,000 years. At $20/hour whole cost I figure that takes $1.6 Billion dollars out of consumer’s pockets.
Compared to that price, the hypothetical 10 million dollars taken from Target’s coffers is “small”.
To protect consumer transaction information we need a change of direction, one that works for card-present as well as e-commerce and m-commerce, does not impose large expenses on consumers, merchants or providers. Ideally with some other enhanced features. I think there is a way that gets the merchant paid, the consumer billed and protects the information.
Jonathan
Re 700+ million compromises, most were financial, the others not. See
nc3.mobi/references which has references to these and more
6,000 Easton-Bell
90,000 University of Washington Hospital
94,000 Michaels 2011
114,000 AT&T/iPad
1.1 million / Neiman Marcus
2.5 million / Global Payments
24 million / Amazon&Zappos
94 million / TJX companies
103 million / Sony
139 million / Heartland Payment Systems
Re EMV having been broken
nc3.mobi/references/#EMV
Jaded – I misread part of your comment and apologize. You wrote of not being able to scale the radio frequency (RF) exploit used to read the EMV communications from one to one to one to many. You are correct. Scalable or not, it is a weakness. There are more described at http://nc3.mobi/references/#EMV
You also picked a single element from the whole system for rebuttal. You did not counter any of the other arguments that make EMV, as a whole system, expensive to implement (as it requires significant infrastructure change) and cumbersome (requiring multiple communications sessions to and from) for use for the growing volumes of electronic and mobile commerce. Neither does EMV add material functionality.
We need a better way
The best path to the future may not be continued embrace of the past.
Jonathan
Confirming the actual Best1_user password on a valid BMC PAA software install should be a trivial exercise on a Windows system. Do a pwdump7 and copy the hash. See if it matches. Would look something like this:
Best1_user:1004:2E063886AB2A209D2CF5B90FB23F3C75:B9D5BE0831E32B9FDAF6E19F12E0814C:::
Brian
Another excellent piece.
The Recorded Future chart in the article refers to a POS malware incident in Australia in January. I am not aware of this in the MSM. Can you throw any light on this please.
There’s a link in the story to the Recorded Future report that the screenshot is taken from. You can drill down from there.
https://www.recordedfuture.com/live/sc/6xuuqUW5Vo8l
Brian,
I wrote a reply to “jaded”, hit submit, and can’t find it. Was there a length limit or some other rule I broke?
Pls reply via email.
Thx
Jonathan
Did Snowden leak that unclassified FBI report from the PRISM NSA program under section 702 ?
Oi Klebs i didn’t know that you changed you surname to Klebs and you blog name to Klebs on Security .
http://uk.finance.yahoo.com/news/the-5-95-credit-card-scam-on-its-way-to-the-uk-160322565.html
I can stop laughing .I Better take screenshot before they change it .
Ha Ha Ha .
You called him Alberto Gonzalez, its really Albert bro
Ah yes, that bit was pasted from the report. I’ll fix, thanks.
Thanks for the excellent update on the Target situation, Brian. The “mainstream” news media keeps feeding us a lot of lightweight drivel (except when they quote you).
On another front, just warning to all you web warriors: NOT 5 MINUTES after reading Brian’s great story from Nov on the nasty Cryptolocker ransomware, I clicked a website link on google for, of all things, a security threat website, and got smashed with a Cryptolocker attempted attack. Thank goodness, I had already greatly upgraded my computer security since cleaning up the Adobe Flash bug that first brought me to KrebsOnSecurity a couple months ago. That bug was picked up on a respected business magazine website. Safe, right? Now I have antivirus, pc cleanup AND realtime anti-malware protection on my computer. This crazy new ransomware got clipped, nipped in the bud, snatched up and carted out by my malware program before it could launch, but it was scary. Chalk up one for our side, but I have to say, the web is starting to feel like a very crazy place.
Perhaps we are all too quick to point our fingers at the Retailers that keep getting broken into? Why have we not looked at the arm that is attached to those fingers and see the that Credit Card Industry has know for years that the process that they use for credit authorization is broken and needs to be fixed. In the old days the same process was defeated by stealing carbon copies out of the trash…..today they steal those same numbers from the POS, servers and anywhere that the data is sent and not encrypted. PCI and the efforts that they ask the Retailers to jump through, while good at making the systems more “secure”, are nothing more than a band-aid on an amputated arm….and that’s just my opinion.
So Credit Card Companies out there…..fix your process so that if my number gets stolen, no one can use it. If you can’t figure out how to do this….I know there are companies that can.
Rick is correct. Security infrastructure may be broken and poorly administrated in the networked world; but this doesn’t mean the credit card transaction system should suffer a similar fate. The entire installation from front to back end should be bulletproof, firewalled, monitored, guaranteed. To be honest, I don’t think there is anything particularly brilliant about this attack nor do I think that similar attacks of greater devastation won’t happen in the future. The architecture of the attack: SQL injection, hacking a Windows domain account, dropping a (mal)firmware upgrade on the POS terminal… This could be a template for attacking bank teller terminals, trader workstations, or drone controllers, or nuclear power plants and let us pray that each of those subsystems is secure. The retail payments system is broken. Companies like Visa and Mastercard should be taking the lead in making sure it works.
If this was a vulnerability caused by a default password, BMC should be ashamed of themselves. Default passwords are an obvious deficiency and putting instructions in the manual to change it, is not deficient.
When I was developing the mainframe security product, ACF2, I had the same issue with ACFUSER, the userid shipped with the system. In IBM’s product, RACF, the userid shipped was IBMUSER and the password shipped with it was SYS1. This struck me as a huge vulnerability because, people do neglect to follow the instructions.
So, I set up ACF2 to have no password for ACFUSER and the first password entered (during installation) became the password. Of course, the instructions also told the installer to delete it after he or she had set up other powerful userids.
My logic was — this was a very powerful account, but, at least each site would have a different password. And, this was 35 years ago. Where’s the logic now?
BMC could have set it up this way or forced a change of password the first time it was used. If this was the vulnerability exploited, the hacker would have had to look elsewhere.
There are so so many “Enterprise” software solutions that state they require Domain Admin or local administrator rights. Typically if a knowledgeable engineer digs in to why it is laziness by the vendor. Instead of determining the actual rights needed they take the easy route of Administrator. Companies have to push back on vendors on not let stuff like this continue as the bad guys will continue to find and exploit these weaknesses.
could not agree more… we’ve seen it a hundred times..but when pushed, most vendors using embedded 2k, xp, or other ‘black box’ OSes will change their authentication architecture. They are equally guilty of using back door admin accounts with default passwords for when their techs come out…
You are so absolutely correct! I see this all of the time. An expert showed up to install a product at the location I am at now and presented his product this way. Said that it had to be done for future Vendor support. I called BS but I’m still the FNG so it happened anyway.
I was unprepared to have to explain to him how to do it and I was in a room full of Windows people who’ll give you anything after you kiss their feet and acknowledge them as the keepers of the kingdom.
Great Point
I think whats more obvious when placing blame is the domain name. Cipher it yourself!
The owner of that is not Target I believe. I also believe it is a Security Domain and not an Operational one. It probably has some Cart Blanche privileges for Audit purposes etc.
Who owns that?
Outsourcing… Who’d have Thunk or Splunked
WSJ is reporting – “We can confirm that the ongoing forensic investigation has indicated that the intruder stole a vendor’s credentials which were used to access our system,” Target spokeswoman Molly Snyder said.
Correct me if I’m wrong here…… the best1_user account wasn’t used to install the malware, it was used by the malware to move files, correct? So BMC’s claim might be correct, you can’t use the account to log in, unless Target altered the account so that they could use it for purposes other than intended by BMC. How did the malware get installed in the first place?
Even if you can’t log on with the best1_user account, you can apparently use it to move files, IF you know the password. How hard would it be to crack a user password without assistance from an insider (disgruntled former BMC developer or Target IT employee)?