Bank Systems & Technology is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk Management

04:56 PM
Connect Directly

Cloudy with a Chance of Fraudulent ATM Cash-Outs, Part 3

Speculations for how hackers managed to steal the credit and debit card data for millions of Target customers last December.

With the Federal Financial Institutions Examination Council (FFIEC) ATM attack warnings and the anatomy of advanced persistent threat (APT) attacks as context, let’s see how the APT attack phases come together in a real-life scenario — the 2013 Target hack. 

Last December, a commercial furor erupted when the media reported that a bunch of European cybercriminals hacked Target, one of the nation’s largest retailers. The hackers managed to steal the payment card details for nearly 40 million credit and debit cards used to shop at Target.

The hackers accomplished this by installing malware on the point of sale (POS) terminals used to process card payments. The malware read the card information from the terminals’ RAM every time a card was processed and periodically transferred this data to an internal server, which the hackers had commandeered and designated as a central dump to stash their loot. Later, another malware transferred this data out of the network over FTP.

To state in a nutshell, the hackers turned Target’s entire payment processing network into a farm that harvested shoppers’ payment card details. How did that happen? Here are the speculations:

Initial breakthrough

There are two ways in which the hackers might have gained their initial foothold. One theory is that they exploited the flaws in Target’s WiFi implementation. Since October 2012, Target has been providing free WiFi to shoppers in its stores.

Alternatively, the hackers may not have directly broken into Target’s network but went a different route by compromising the retailer’s HVAC vendor, which supposedly failed to implement strong anti-malware software. Attackers phished and stole credentials of the vendor’s employees, who accessed project management software provided by Target to submit bills. Administrators of the Target network apparently accessed this application using their Active Directory credentials.

What does it mean if hackers indeed compromised Target’s vendor?

  • The attackers scoped out Target well enough to know which business associates or service providers had access to Target’s network or apps.
  • The retailer failed to authenticate vendor access using multifactor authentication. Similarly, it shows that vendor interactions with the internal network — if any — were not securely cordoned off.
  • There could have been SQL or XML vulnerabilities in the vendor-facing software.

Infecting POS systems with malware

It’s highly likely that the attackers compromised Target’s configuration management software, which is Microsoft System Center Configuration Manager (SCCM), and passed their malware onto POS systems as legitimate “updates.” That’s quite an ingenious way of delivering payload. If that’s the case, then it reveals two important things:

  • The hackers knew the Target network like the back of their hands. But that’s quite easy when case studies are floating around the Internet like the Microsoft case study that reveals SCCM 2007 managed updates to devices on the Target network. Note: MS has since removed the dubious case study from its site.
  • If SCCM had been compromised and used to distribute the malware, administrator-level credentials that had operational capabilities on the SCCM server were probably also compromised.

Malware hiding in plain sight

It appears that the malware masqueraded as a system file under the image name svchosts.exe. The hackers likely rewrote the malware code and reintroduced it into Target’s network more than once. Now, this suggests:

  • System file integrity monitoring was not done or ignored.
  • SIEM warnings were ignored as false positives.

The malware and its operation

The malware was designed to read card information from the random access memory of the POS system that it resided on. It stored this data locally at %Windir%\system32\winxml.dll. Between 10 a.m. and 6 p.m. every day, the malware connected to the central dump server, mapped a drive on it, dumped the data and disconnected the drive. For this, it used a “net use” command under the privileges of an application account of BMC server management software. Here, noteworthy points include:

  • Surprisingly, the POS terminal was allowed to communicate to a server other than a payment processing server.
  • Privileged accounts are everywhere, even in applications, and can be exploited if not protected by best security practices.
  • Privileged account auditing can be a crucial security step.

Exfiltrating data out of Target’s network

Another malware moved the card information stashed on the central dump server over FTP to servers of a hijacked website. As a subterfuge, the data was bounced off of several such servers before being dropped off on a server in Russia.

Prasanna Kumar Singh is a marketing analyst for ManageEngine, the real-time IT management company. For more information on ManageEngine, a division of Zoho Corp., please visit; follow the company blog at; on Facebook at ... View Full Bio

Register for Bank Systems & Technology Newsletters
Bank Systems & Technology Radio
Archived Audio Interviews
Join Bank Systems & Technology Associate Editor Bryan Yurcan, and guests Karen Massey and Jerry Silva from IDC Financial Insights, for a conversation about the firm's 11th annual FinTech rankings.