Updated Feb. 20, 2014 to include newly available attack details, including the initial compromise of a 3rd party contractor and the malware masquerading as legitimate system management utilities.

If you’re a US shopper, there’s almost a 50% chance that your information was compromised in the Target breach. The personal and financial information of approximately 110 million people, comprising 11 GB of data, was stolen in a successful compromise during the Christmas shopping season. The attackers persisted undetected for almost 2 weeks, and is attributed to a cyber criminal in the Ukraine.

Anatomy of the Breach

At the time of the attack, none of the anti-virus solutions on the market would have—or did—detect the malware, dubbed Trojan.POSRAM, a variant of BlackPOS. In fact, even as of a couple of weeks into the forensics investigation, signature-based anti-virus was ineffective in detecting the POS trojan.

How to Protect Against a Similar Attack

So how can fellow retailers and other enterprises avoid this fate? Let’s break down the phases of the compromise:

1. Contractor Compromise

A Target HVAC contractor fell victim to a phishing attack in which Citadel malware, a variant of the Zeus banking Trojan, was installed. Citadel captures keystrokes and takes screen grabs, and targets login credentials. While many anti-malware solutions will identify Zeus and Citadel, the 3rd party had deployed Malwarebytes free edition, which doesn’t offer real-time protection.

• Just about any commercial anti-malware solutions would have detected and prevented installation of Citadel, which is well-known. While anti-malware is simply best practices—and mandated by all prescriptive compliance contracts, such as PCI DSS (at least anti-virus, if not full endpoint protection)—Target would have little control over the entire contractor and partner ecosystem unless they required endpoint protection by contract—and conducted regular audits. Target could have paid for licenses of fraud and malware protection software for any endpoints to be allowed access to their portals, or at least mandated two-factor authentication for more than just contractors who have internal access to sensitive information. There are solutions that register with their associated web applications to ensure that the endpoint has appropriate protection before being allowed to access enterprise resources.

2. Web Server Compromise

There are a few potential targets the attackers gained access to with the contractor’s credentials: the Ariba contractor purchase management portal, Target’s Partners Online portal, and Target’s Property Development Portal. It appears as though Ariba is a cloud service and not directly connected to any of Target’s networks, which leaves the other two as likely avenues of attack. It’s possible that attackers abused a vulnerability in the web application, such as SQL injection, XSS, or possibly a zero-day, to gain a point of presence and escalate privileges, then attack internal systems.

• Assuming Target wrote some of the code that runs on the web server, a secure development process (aka, Secure Development Life Cycle, or SDLC), including training developers on secure coding practices, as well as performing source code reviews and automated scans, can help reduce the vulnerabilities.
• An appropriate operationalization process can reduce the threat surface. Hardening systems to only start necessary services and imposing strong authentication—including changing default passwords—should be a required pre-configuration step, in addition to performing automated vulnerability scanning before putting new software into production.
• Ongoing system maintenance must include keeping up to date on patches and regularly scanning exposed applications to help identify known vulnerabilities and mitigate them before the attackers find and exploit them.
• Speaking of which, the attacker may have generated some noise as evidence of scanning and attempted exploitation. Network IPS and a Security Intelligence System that includes network activity monitoring can provide early alerting to suspicious activity and help organization to respond early in the kill chain, in many cases before critical assets are compromised or data exfiltrated. In the case of well-known vulnerabilities, such as SQL injection, many IPSes will block the exploit activity.

3. Windows File Server and POS Systems Compromises

The internal system may have been compromised through the same latent vulnerabilities as the web server or a default password was left unchanged. All the mitigation strategies for the web server apply here (see #1). In addition:

• Network monitoring can detect network scanning as the attacker maps out the landscape, looking for vulnerable systems.
• Firewall rule analysis, particular those that protect assets containing PCI data, can flag risky protocols and flow directions. For example, there’s little reason for POS systems to mount Windows shares or send regular ICMP packets.

Note that the contractor mentioned earlier may have had direct access into Target’s network to remotely monitor and manage HVAC equipment. This is pure speculation and the contractor claims that their access was solely to external systems; however, many organizations do allow contractors internal access to monitor and maintain facilities equipment as well as IT systems. Providing direct access to 3rd parties demands strong security controls and governance over the systems they use to access customer systems.

New details have come to light about the credentials used by the malware: the username, “Best1_user”, and password, “BackupU$r”, appear to be related to BMC Software’s Performance Assurance for Microsoft Servers. In addition, a service was installed called “bladelogic.exe”, implying BMC’s BladeLogic software. BMC has claimed that none of their executables are so named, and that the password is not one generated by any of their software systems. If true, then the attackers were simply hiding their malware by making it appear to be legitimate system utilities used by Target. It does show the sophistication of the campaign: the attackers gathered enough intelligence and modified their software to blend in with the native target environment.

4. Installation and Execution of POS Trojan

The malware installed on the POS systems scans memory for clear-text copies of credit card data, known as RAM scraping, which is a decidedly uncommon activity for an application.

• Monitoring systems for new services and registry entries using dynamic configuration management may have detected the malware, assuming it didn’t employ sophisticated evasive measure.
• Application sandboxing and endpoint behavior anomaly detection can prevent cross-application data access and identify suspicious application activity, such as RAM scraping.

5. Sending Stolen Data to the Internal Rally Point

The malware creates a temporary Windows share, moves the stolen credit card data to the central repository, then removes the share. After a load of data is moved, the malware on the POS sends a custom crafted ICMP (i.e., network ping) packet containing a notification string that malware on the file server listens for.

• Network activity monitoring can identify new activity, such as regular pings suddenly emitting from systems containing sensitive information, the POS systems in this case. It can also recognize strange behavior such as regular, but transient, Windows shares being created and removed shortly thereafter.
• Deep packet inspection can look for string patterns in ICMP packets, but that would require some foreknowledge of the specific malware behavior. Similarly, looking for  registry entries containing “POSWDS” would only detect this specific threat; attackers could easily change the strings or obfuscate them to evade detection.

6. Exfiltration of Stolen Data to External FTP Servers

Data was exfiltrated on a regular basis to FTP servers in Russia.

• If the data was sent in the clear, network activity monitoring that includes string pattern identification would have been able to identify text containing credit card information leaving the private network.
• If encrypted, network activity monitoring with anomaly detection may have identified suspicious traffic, particularly if FTP to external servers was prohibited by policy, and especially to geographies known for internet crime, such as countries in the Eastern Bloc.

Protecting Against Future, Sophisticated Attacks

There are many measures we can implement with the benefit of hindsight; yet, they’re all reactive and specific to this threat, much like why we have to take off our shoes when going through airport security. The nature of APTs is they are unique and unpredictable. I’ve tried to make the steps above as generic as possible so they apply to not just the Target breach. Other steps retailers can take with the Target breach as an example in the rearview mirror are:

• Profile the behavior of POS systems and alert on any configuration changes and application or network activity that violates the expected baseline. Enterprises should identify mission critical assets and treat them the same way that the energy and utilities industry treat operational technology (OT) separate from IT systems. They employ a concept called a “data diode“, meaning OT systems can only interact with IT systems and not the other way around. This wouldn’t prevent exfiltration of the data from the POS systems, but it would have helped prevent malware infection in the first place.
• Profile default ping payloads or sizes and configure IPSes and deep packet inspection  to detect and alert on non-standard ping packets.
• Similarly, identify anomalous behavior, such as network traffic on port 443 that’s not a proper SSL connection, which may indicate malware trying to hide its activity as a well known protocol, or DNS queries that contain exfiltrated data instead of proper queries (.e.g., strings that don’t look like domains or non-standard resource record types).

• When all else fails, a well deployed Security Intelligence System and log management system can provide total visibility for speedy and complete forensics, early in the process if the compromise is detected before data is stolen, or after a severe breach when accurate impact analysis is critical: Which systems were compromised? How many customers were affected? how much of the data comprised personal information? Instrument everything feasible, including POS systems and network activity, and enrich it with context from vulnerability assessment tools, change management transactions, and security intelligence feeds.

Prepare for the Worst, Hope for the Best

In the final analysis, there is no perfect or foolproof detection and prevention technology; however, with appropriate architecture, policies, and technology, retailers can increase their odds of beating the bad guys.

And don’t forget to plan for incident response. Optimally, your plan should include detection, response and escalation, engaging law enforcement as appropriate, preservation of evidence, compliance with regulations and contractual agreements, customer and press notification, and public relations. If you contract with an external emergency response agency, engage them in advance so they can help you prepare for a breach and gather context about your environment. Finally, test your process regularly; there’s nothing worse than forgetting to label which closet contains the life preservers when the sea is rushing in through the portholes.

Note: Information provided in IBM blog entries is derived from research by the author and/or the IBM X-Force.  It does not contain, nor is it derived from, any confidential information shared with IBM.