Last week, Target told reporters at The Wall Street Journal and Reuters that the initial intrusion into its systems was traced back to network credentials that were stolen from a third party vendor. Sources now tell KrebsOnSecurity that the vendor in question was a refrigeration, heating and air conditioning subcontractor that has worked at a number of locations at Target and other top retailers.
Sources close to the investigation said the attackers first broke into the retailer’s network on Nov. 15, 2013 using network credentials stolen from Fazio Mechanical Services, a Sharpsburg, Penn.-based provider of refrigeration and HVAC systems.
Fazio president Ross Fazio confirmed that the U.S. Secret Service visited his company’s offices in connection with the Target investigation, but said he was not present when the visit occurred. Fazio Vice President Daniel Mitsch declined to answer questions about the visit. According to the company’s homepage, Fazio Mechanical also has done refrigeration and HVAC projects for specific Trader Joe’s, Whole Foods and BJ’s Wholesale Club locations in Pennsylvania, Maryland, Ohio, Virginia and West Virginia.
Target spokeswoman Molly Snyder said the company had no additional information to share, citing a “very active and ongoing investigation.”
It’s not immediately clear why Target would have given an HVAC company external network access, or why that access would not be cordoned off from Target’s payment system network. But according to a cybersecurity expert at a large retailer who asked not to be named because he did not have permission to speak on the record, it is common for large retail operations to have a team that routinely monitors energy consumption and temperatures in stores to save on costs (particularly at night) and to alert store managers if temperatures in the stores fluctuate outside of an acceptable range that could prevent customers from shopping at the store.
“To support this solution, vendors need to be able to remote into the system in order to do maintenance (updates, patches, etc.) or to troubleshoot glitches and connectivity issues with the software,” the source said. “This feeds into the topic of cost savings, with so many solutions in a given organization. And to save on head count, it is sometimes beneficial to allow a vendor to support versus train or hire extra people.”
CASING THE JOINT
Investigators also shared additional details about the timeline of the breach and how the attackers moved stolen data off of Target’s network.
Sources said that between Nov. 15 and Nov. 28 (Thanksgiving and the day before Black Friday), the attackers succeeded in uploading their card-stealing malicious software to a small number of cash registers within Target stores.
Those same sources said the attackers used this time to test that their point-of-sale malware was working as designed.
By the end of the month — just two days later — the intruders had pushed their malware to a majority of Target’s point-of-sale devices, and were actively collecting card records from live customer transactions, investigators told this reporter. Target has said that the breach exposed approximately 40 million debit and credit card accounts between Nov. 27 and Dec. 15, 2013.
While some reports on the Target breach said the stolen card data was offloaded via FTP communications to a location in Russia, sources close to the case say much of the purloined financial information was transmitted to several “drop” locations.
These were essentially compromised computers in the United States and elsewhere that were used to house the stolen data and that could be safely accessed by the suspected perpetrators in Eastern Europe and Russia.
For example, card data stolen from Target’s network was stashed on hacked computer servers belonging to a business in Miami, while another drop server resided in Brazil.
Investigators say the United States is currently requesting mutual legal assistance from Brazilian authorities to gain access to the Target data on the server there.
It remains unclear when the dust settles from this investigation whether Target will be liable for failing to adhere to payment card industry (PCI) security standards, violations that can come with hefty fines.
Avivah Litan, a fraud analyst with Gartner Inc., said that although the current PCI standard (PDF) does not require organizations to maintain separate networks for payment and non-payment operations (page 7), it does require merchants to incorporate two-factor authentication for remote network access originating from outside the network by personnel and all third parties — including vendor access for support or maintenance (see section 8.3).
In any case, Litan estimates that Target could be facing losses of up to $420 million as a result of this breach, including reimbursement associated with banks recovering the costs of reissuing millions of cards; fines from the card brands for PCI non-compliance; and direct Target customer service costs, including legal fees and credit monitoring for tens of millions of customers impacted by the breach.
Litan notes these estimates do not take into account the amounts Target will spend in the short run implementing technology at their checkout counters to accept more secure chip-and-PINcredit and debit cards. In testimony before lawmakers on Capitol Hill yesterday, Target’s executive vice president and chief financial officer said upgrading the retailer’s systems to handle chip-and-PIN could cost $100 million.
Target may be able to cover some of those costs through a mesh network of business insurance claims. According to a Jan. 19 story at businessinsurance.com, Target has at least $100 million of cyber insurance and $65 million of directors and officers liability coverage.
Syrian Electronic Army Claims Control Over Facebook.Com Domain
The Syrian Electronic Army is claiming to have taken control over the domain Facebook.com, likely through hacking into the domain administrator account at the social network's Domain Registrar.
In a Tweet Wednesday evening, the hackers wished Facebook founder Mark Zuckerberg a happy birthday, along with an extra note: "Happy Birthday Mark! Facebook.com owned by #SEA," the Tweet read.
The domain information below is what showed as of 6:35 EST. The hackers have appeared to modify the three primary registrant contacts, though the domain name servers do not appear to have been modified.
The image of the domain contacts details below was a screenshot take by SecurityWeek:
Update: As of 7:00PM the registrant contact details were restored to "email@example.com", indicating that MarkMonitor and Facebook were able to react quickly before any damage was done.
The hackers said that in response to being hacked, MarkMonitor took down the domain management portal and posted an alleged screenshot:
The company's registrar, MarkMonitor, is steward to many of the Internet's biggest brands and does have strong security policies and options in place. It's likely that while the attackers may have accessed an admin account, the ability to change the DNS records may require further authenication, but that is unclear. However, the hackers did make a follow-up post to Twitter saying they did change the namesevers. "We changed the nameservers, but it's taking too much time..," the Tweet said.
When asked about a similar incident targeting PayPal's UK domain over the weekend, MarkMonitor told SecurityWeek that it does take security seriously but is unable to comment. "We also have a policy where we never comment on clients - including neither comfirming nor denying if a company is a client," a MarkMonitor spokesperson toldSecurityWeek on Saturday.
The Syrian Electronic Army has been responsible for several recent attacks, including one last week against PayPal, and others last year that targeted the AFP’s Twitter account and three CBS News accounts, all in support of Syria’s President Assad. In May, the group hacked into the Associated Press's Twitter account and falsely reported that President Barack Obama had been injured after two blasts at the White House.
Last month, the group was assumed to be behind an attack against Microsoft in an incident where attackers breached the email accounts of a “select number” of employees, and obtained access to documents associated with law enforcement inquiries.
Ever since news broke that thieves stole more than 40 million debit and credit card accounts from Target using a strain of Point-Of-Sale malware known as BlackPOS, much speculation has swirled around unanswered questions, such as how this malware was introduced into the network, and what mechanisms were used to infect thousands of Target’s cash registers.
Recently, I spoke at length with Tom Arnold and Paul Guthrie, co-founders of PSC, a security firm that consults for businesses on payment security and compliance. In early 2013, these two experts worked directly on a retail data breach that involved a version of BlackPOS. They agreed to talk about their knowledge of this malware, and how the attackers worked to defeat the security of the retail client (not named in this story).
While some of this discussion may be geektacular at times (what I affectionately like to call “Geek Factor 5″), there’s something in here for everyone. Their observations about the methods and approaches used in this attack point to an adversary that is skilled, organized, patient and thorough.
So you first saw BlackPOS at a retailer in early January 2013?
Tom: Yes, it did seem like a game changer at that point because of the way it hooked into the POS system. By that I mean the fact that it hooks into the POS process, and it’s not just a general memory scraper like some people have stated.
Help me understand the distinction between a memory scraper and malware that runs completely in memory?
Tom: Well, it’s very specific. It’s what’s called an inter-process communications hook. If you look at a memory scraper — so if you were to dump the memory on your laptop right now — you would get this big old blob of information and you would have to filter through it to find what you’re looking for. But this [malware] is very specific: It’s very much designed for the POS system it’s running on, because it knows exactly where to hook and where the memory location is going to be when the data it’s looking for is flowing through it. But if you look at what it captures, it captures only the track data [information stored on the magnetic strip on the backs of cards]. So, it’s actually very, very sophisticated and that’s why I think this isn’t just a teenage hacker who put this together in his basement. I think this is a more sophisticated development effort. [HP last week published some interesting, uber-geeky details about the memory behavior of the version of BlackPOS found at Target].
Paul: It certainly hooks into a specific process, but we did not figure out if it was just good at scraping the memory of that process, or whether it actually altered the process to hook into the code somehow. That part of the code was obfuscated and not reviewed during the engagement.
What did you think of the iSight paper?
Tom: The iSight paper was good, and what it described was very similar to what we saw in the first variants of BlackPOS. But it didn’t talk about how it appeared on the network or where it came from or how a retailer might defend themselves against it.
In your prior experience with BlackPOS, has it been used against the same POS that Target uses? A source who seemed to have a clue told me that their setup was somewhat homegrown.
Tom: That I don’t know. I haven’t really looked at what Target uses. With a homegrown system, the problem is if you’re going to build a process hook, you have to have a test environment, you have to know what you’re looking at and what memory addresses to go after, and that’s not exactly something that gets published.
Paul: Target has a homegrown POS.
So you think it’s likely they were using some off-the-shelf equipment and software? Wouldn’t it be enough for the attackers in this case to have obtained a physical point of sale device that was once used at Target?
Tom: If they have one, sure, that would be different. I don’t know if they’re using a commercial product. A lot of the big retailers use commercial products and will customize those with their back end system. But at the front end and what happens at front of the house…a lot of those are just retail off-the-shelf applications. A lot of those retailers, when you have a hard disk that breaks on one of the [checkout] lanes, they’ve got an outsourced service provider of that POS that comes out there with a new hard disk and fixes it.
How do the bad guys break in, and how do they actually get the malware pushed out to the point-of-sale?
Tom: A lot of the POS systems use whitelisting software of some kind, such as Bit9 or SolidCore. Those two companies are the two you see most out there in the industry.
Paul: It could also come in through the point-of-sale application update process.
By whitelisting, you mean sort of the opposite approach of antivirus, right? As in, if the file or program isn’t approved by the whitelisting software, it simply won’t run on the system?
Tom: The software update processes at a point-of-sale that is running one of those [whitelisting applications] has to come through one of the software update channels and has to be reviewed for the update and approved. And when it’s approved, the whitelisting software says okay this patch is approved to come online.
It’s probably a good idea at this point to make sure we’re defining the terminology in a uniform way. When you think of point-of-sale device, are you talking about the cash register, or the card swipe terminal, or…
Tom: I’m using point-of-sale to mean the payment application that is running on the cash register. The vast majority of those devices, when you check out at the grocery store or large retailer, those are just PCs, and yes they’re mostly running Windows XP or WEPOS as their operating system. But above that, you have what I call the point-of-sale, or the point-of-sale application, and that’s the stuff that the cashier is interfacing with at the time you’re checking out. It’s a software application, running as multiple pieces of software inside the register itself. And whitelisting is put on to protect the register from any sort of unsolicited modification. A lot of the attacks before this [whitelisting became more broadly used] involved where you corrupt a sales clerk to put a USB stick in the cash register and infect the PC with some malware. But by using a whitelisting software, the USB stick will not work and the operations personnel back in the head office will get notified that something isn’t right with that register.
If they get past a whitelisting system, doesn’t that suggest that someone on the inside would have to be involved?
Tom: No, not really. You have to also consider the distribution server that distributes the point-of-sale software.
Paul: Right… three possible ways… it could come through a legitimate update channel, or the retailer was lax in their update procedures, or the attackers hacked the console of the whitelisting software and just whitelisted it themselves.