How One Fake DLL Carried 40 Million Cards Out of Target

Introduction

For about two weeks in December 2013, a compromised server inside Target's network sent stolen card data to outside FTP servers, unencrypted, about once an hour. The data came from registers Target owned and managed, and Target's own systems logged parts of the attack. On December 19, Target disclosed that about 40 million payment card accounts were affected. Below, we trace how the attackers got in, how the card data left, what it cost Target, and the one control that would have stopped the file on its way out.

How a Contractor's Login Let Them In

Target told the Senate Commerce Committee that intruders appear to have entered its systems on November 12, 2013, using credentials stolen from an HVAC vendor. Those credentials opened a portal for billing and project management, not the payment network—the route from that portal to the registers is the one part of the attack Target never fully explained.

A Login Built for Billing

The vendor was Fazio Mechanical, a refrigeration contractor. Its statement says its connection was "exclusively for electronic billing, contract submission and project management," and that it "does not perform remote monitoring or control of heating, cooling or refrigeration systems for Target."

Target's written answers to Congress confirm that the credentials provided access to an external-facing Citrix platform used for construction project management and invoicing. Although early press coverage raised the possibility that the attackers entered through an HVAC system, Fazio denied having that access, and none of the primary records cited here supports that theory.

The Gap Target Never Explained

The Senate Commerce Committee's majority staff published its "Kill Chain" analysis on March 26, 2014, the day before Target CFO John Mulligan told the committee he did not know how the attackers reached the POS terminals.

Target's written account came in answers to questions a House Energy and Commerce subcommittee sent on June 18, 2014. In the hearing volume, it says the intruders reached a segmented Citrix platform and then "circumvented several firewalls and other access control technologies in order to deploy memory-scraping malware to Target POS registers." The attackers did not use the vendor's credentials to access the card readers, and Target said it did not allow direct remote access to its registers.

How the Cards Slipped Out

Whatever route the attackers took past those firewalls, the malware reached a small number of registers between November 15 and 28, and most of Target's registers by November 30, according to investigators. From that point the malware reports trace every step, from the memory of each register to a file on an internal server and out to the internet over FTP.

Malware on the Registers

To build an authorization request, the register's point-of-sale software held each card's track data in memory, and CFO Mulligan told the Senate the malware captured it before Target's systems encrypted it. 

According to Dell SecureWorks' analysis, the malware installed itself as a Windows service named POSWDS, running from svchosts.exe, one letter off the real svchost.exe. The service opened a separate process, pos.exe, read its memory in 10-megabyte chunks, and picked out Track 1 and Track 2 data.

The joint report by the Secret Service, US-CERT and iSIGHT Partners describes it "incrementally saving data to %windir%\system32\winxml.dll" and tells defenders to look for that file. Dell's researchers found the contents Base64-encoded in a custom alphabet. A scan for card-number patterns in that file wouldn’t have matched anything.

A Borrowed Login Moves the Files

About an hour after the service started, the malware moved the file; every seven hours after that, it checked the local clock and moved the file only between 10 a.m. and 6 p.m. To move it, each register mapped an internal server's administrative share with a password written into the command:

net use S: \\10.116.240.31\c$\WINDOWS\twain_32 /user:ttcopscli3acs\Best1_user BackupU$r

The file landed on the share, renamed with the register's name and the day, month, and hour, and net use S: /del removed the mapping. Dell's researchers say Best1_user appears to belong to BMC Software's Patrol performance product, an account BMC's documentation describes as normally restricted, which the attackers may have taken over.

The banks' class-certification brief alleges that on November 25 an employee in Target's security operations center emailed about someone "using a service account to access all the registers in one store." The first upload of stolen card data occurred a week later.

Out Over FTP

A second compromised host, outside the payment environment and able to reach both the staging server and the internet, did the sending, Dell's researchers say. It worked in three steps:

1. PsExec pulled the combined dump, twain_32a.dll, from the staging server.
2. The malware wrote an FTP script to cmd.txt.
3. Windows' built-in ftp.exe ran that script against three outside FTP servers.

Later versions installed themselves as a service named "BladeLogic," after BMC's server automation product. That script ran about every hour, and some versions only between 10 a.m. and 6 p.m., which Dell's researchers read as an attempt to send traffic only at peak network use. 

The Senate staff report, citing security researchers, says the data left over FTP "in plain text" for about two weeks from December 2, 2013. Dell's researchers believe the three drop servers were legitimate FTP sites whose credentials the attackers had stolen. A blocklist of known-bad hosts would not have listed them.

Why Segmentation Didn't Stop It

MITRE ATT&CK® lists the register-to-server copy as T1074.002, Remote Data Staging. As of version 19.2 it gives a detection strategy and no mitigations, with its standard line that such a technique "cannot be easily mitigated with preventive controls since it is based on the abuse of system features."

The Senate staff report named a control for the step after it, allowlisting approved FTP servers, so that an upload to an unknown server would stand out. Dell's researchers say they don’t know whether Target filtered outbound traffic strictly or the attackers "just located a host that was permitted to make FTP connections to the Internet."

Neither step depends on the device being a register. 

A service account that can map another machine's share, and a host that reaches both a protected segment and the internet, build the same route out of a fleet of laptops, desktops, or virtual desktops.

What the Breach Cost Target

Target disclosed about 40 million affected payment card accounts on December 19, 2013. On January 10, 2014, it added that personal details had been breached for up to 70 million people and cut its fourth-quarter financial forecast.

Five Years of State Rules

Target's first SEC filing to mention the breach was an earnings Form 8-K on February 26, 2014, 69 days after disclosure. The SEC's enforcement staff closed its investigation in 2015 without recommending action, and the FTC's case records don't list any enforcement actions over the breach.

The 2017 assurance of voluntary compliance was signed with 46 states and the District of Columbia for $18.5 million. It required that the cardholder data environment "shall be segmented," two-factor authentication on a "reasonable and risk-based approach," and controls "such as, for example, an application whitelisting solution" on point-of-sale terminals and in-store point-of-sale servers.

Target told the Senate in March 2014 that it had accelerated a whitelisting rollout on its registers, and told the House it already ran file integrity monitoring and security event monitoring on them in 2013. 

The five-year term ran out around May 2022, and the obligations split two ways:

• Lapsed: segmentation, access control, file integrity monitoring, whitelisting, PCI DSS compliance, the security executive role, and encryption on laptops, desktops, and data in transit.
• Still in force: logging, penetration testing, change control, and encrypting card data through each transaction.

$202 Million After Insurance

Target's FY2016 Form 10-K puts cumulative breach expenses at $292 million, less $90 million of insurance recoveries, for $202 million net through January 2017. Insurance covered less than a third of the gross. The total includes the $10 million consumer settlement and up to $67 million for Visa issuers, both reached in 2015. 

The banks' class settlement agreement set a fund of up to $39.36 million, all of it paid by Target, including $19.1 million toward Mastercard's account-compromise recovery program.

What Target Had in Place

By Target's own account, this is what it had in place:

• Alerts. A spokeswoman told reporters in March 2014 that “a small amount of their activity was logged and surfaced to our team,” in a queue Mulligan told the Senate runs to “hundreds of alerts every day.”
• Malware detection. A tool Target began adding in 2013 “was not yet fully integrated at the time of the breach,” its written answers say.
• Data loss prevention. The same answers say a tool ran “throughout Target’s network to scan data at rest and in motion.”
• PCI compliance. Target was certified on September 20, 2013, and the card networks’ forensic investigator later claimed it was not in compliance at the time.
• Ownership. Target had no chief information security officer. Data security had reported to several different executives, and supervisory security posts were vacant and covered on an interim basis.

The card file still left.

Neiman Marcus's written answers to the Senate Judiciary Committee describe the same disguise. Card-scraping malware ran under a name almost identical to its own point-of-sale software, and its endpoint logs recorded it about 60,000 times over three and a half months, around 1% or less of each day's entries.

How Our Platform Would Have Seen It

The ORION Security Data Loss Threat Model puts Target's exit on path T3, Upload to Untrusted Application: enterprise data leaving a managed device for an unmanaged app, a service the organization does not approve or govern. The nearest worked example is T3.2, Upload to File Transfer Service: a file exported on a company device and uploaded to an outside file transfer service; Target's version ran the same way, with ftp.exe in place of a browser.

On Target’s route, the decision point is the upload. A sensitive file leaving a managed endpoint for an outside server is the movement ORION puts a verdict on, and every earlier move gives that verdict its context.

Target’s DLP tool scanned data at rest and in motion, but a content scan finds no card number in a file encoded like that, so our verdict comes from context instead. A file that began as a disguised DLL in a register’s system folder, moved under a monitoring tool’s login, is heading for a server with no business relationship on record. It becomes a decision at the move rather than another entry in a security queue of hundreds a day.

ORION Security’s verdict rests on two signals, and neither has to read the card numbers. Data lineage tracks where the file came from, and identity and environment context test whether the movement is expected for that account on that device. ORION then returns an allow, warn, or deny verdict.

Target’s certificate said it was PCI compliant. The card networks’ investigator later claimed it was not, but that argument came after 40 million cards were gone.

ORION keeps a record of each verdict, which shows what the control did on the day it mattered. It also puts scope on the record before a forensic investigator arrives, and scope is what sizes the notification.

Conclusion

Mulligan could not tell the Senate how the attackers reached the registers, but the malware reports show exactly how the cards left. A disguised file was moved off each register to an internal share and uploaded from a host allowed to use FTP. That upload is path T3 in our Data Loss Threat Model, the step where a managed device hands data to an unmanaged app. Today, that same path runs from laptops, desktops, and virtual desktops as easily as it did from a register.

Book a demo to see ORION put a verdict on a file as it leaves a managed endpoint, the step where Target's card data went out, and nothing stopped it.

FAQs

Where Does POS Malware Become Visible to Endpoint DLP?

It becomes visible when it writes stolen data to disk or moves it. Target's malware saved card data to winxml.dll, a file the joint government-industry report told defenders to look for, and each register then copied that file to an internal server. With ORION Security, a file leaving a managed device gets a verdict based on where it came from and where it is going, so encoding doesn't hide it.

Which Changes on a POS Register Should Trigger Review?

Treat a process that opens the POS software's memory, a new service, a new file in the system folder, or a share mapped from the register as an incident, since none belongs on a one-program device. Target already ran file integrity monitoring on its registers in 2013, so evidence can exist without a decision. ORION adds a verdict on the file's movement, and data lineage keeps its history.

Why Did Target's Attackers Need a Staging Server?

According to Dell's researchers, they needed a way to move card data from registers inside the payment environment to a host outside it that could reach the internet. Every segmented network has hosts that bridge it to the internet, and those are the ones to watch. ORION puts a verdict on sensitive data leaving managed devices, wherever it is headed.

What Did Target's PCI Certificate Prove?

It showed Target's environment met the standard when assessed on September 20, 2013, two months before the malware reached the registers. A certificate describes the environment on the day it was assessed. ORION keeps each movement and its verdict as it happened, so the evidence exists no matter how a compliance argument goes.

Should Service Accounts Be Able to Move Files Off Endpoints?

Only for a named, exceptional reason, and PCI DSS v4.0.1 now expects interactive use of system accounts to be prevented unless one applies. Target's staging ran under one BMC tool's login, used from every infected register to map another server's administrative share. ORION judges the file's movement, so a borrowed login doesn't make a disguised file's trip off a device look routine.

Sources

• A "Kill Chain" Analysis of the 2013 Target Data Breach. Senate Committee on Commerce, Science, and Transportation, Majority Staff, March 26, 2014.
• Protecting Personal Consumer Information from Cyber Attacks and Data Breaches, S. Hrg. 113-531. U.S. Senate Committee on Commerce, Science, and Transportation, March 26, 2014.
• Privacy in the Digital Age: Preventing Data Breaches and Combating Cyber Crime, S. Hrg. 113-654. U.S. Senate Committee on the Judiciary, February 4, 2014.
• Protecting Consumer Information: Can Data Breaches Be Prevented?, Serial No. 113-115. U.S. House Committee on Energy and Commerce, February 5, 2014.
• Target Declined to Act on Early Alert of Cyber Breach. CNBC (Reuters), March 13, 2014.
• Inside a Targeted Point-of-Sale Data Breach. Dell SecureWorks, January 24, 2014.
• KAPTOXA Point-of-Sale Compromise. U.S. Secret Service, US-CERT and iSIGHT Partners, January 14, 2014.
• Statement on Target Data Breach. Fazio Mechanical Services, February 2014.
• Target Hackers Broke in Via HVAC Company. Krebs on Security, February 5, 2014.
• Data Staged: Remote Data Staging (T1074.002). MITRE ATT&CK.
• Target Confirms Unauthorized Access to Payment Card Data in U.S. Stores. Target Corporation, December 19, 2013.
• Target Provides Update on Data Breach and Financial Performance. Target Corporation, January 10, 2014.
• Form 8-K, Fourth Quarter 2013 Results. Target Corporation, U.S. Securities and Exchange Commission, February 26, 2014.
• Form 10-K, Fiscal 2014. Target Corporation, U.S. Securities and Exchange Commission, March 13, 2015.
• Form 10-Q, Second Quarter 2015. Target Corporation, U.S. Securities and Exchange Commission, August 25, 2015.
• Form 10-K, Fiscal 2016. Target Corporation, U.S. Securities and Exchange Commission, March 8, 2017.
• Memorandum in Support of Class Certification (Doc. 559), In re Target Corporation Customer Data Security Breach Litigation, MDL No. 14-2522. U.S. District Court, District of Minnesota, August 20, 2015.
• Settlement Agreement (Doc. 653-1), In re Target Corporation Customer Data Security Breach Litigation, MDL No. 14-2522. U.S. District Court, District of Minnesota, December 2, 2015.
• Assurance of Voluntary Compliance, In re Target Corporation. Attorneys General of 46 States and the District of Columbia, May 23, 2017.

‍