A Look Back At The Target Breach of 2013

Not all breaches are due to technical failures. Most of the time, the technology is available or in place but not being utilized effectively. In the case of Target, there were operational security failures that lead to the breach, and policy failures that increased the damage caused. Target got hacked as we all know, during the busiest season of the retail year. It was the first major breach that I was really aware of, and I studied it while it was happening at school.

As a student, I wasn’t aware of compliance, risk management, or the technical aspects of the breach, but found it interesting enough to go back to. As a professional now, I look back at what happened and I am able to consume and understand the events. I will dissect the events, how investigators believe it happened, and what you can do to prevent it from occurring in your enterprise.

The first failure of Target was a paper put out by Microsoft that was a piece talking about how enterprises could implement their technology. It was a case study of Target that provided intimate details of how their infrastructure was configured. This included their naming system, how their network was configured, and how they used SCCM to send updates to their Point of Sale (POS) systems. It also included information about their portal for contractors. This report was unavailable at the time of this article, as should be expected.

Many companies create a back door portal into their network for billing and contract purposes. A google search of target’s public information provided a list of companies who had contracts with Target, another OPSEC failure. The criminals probably sent out phishing e-mails to all of these companies. All it took was for one to respond in order for them to gain access to Target’s internal network via the vendor portal. Knowing the infrastructure of Target’s enterprise, they found ways to move laterally through the system to the SCCM server. The POS system operated independently of the rest of the network aside from getting updates and patches through SCCM, the endpoint monitoring from the security system, authentication and DNS according to reports.

It is believed that hackers found an ingenious way of accessing the POS systems at an unspecified amount of stores: using SCCM. They crafted malware, uploaded it the SSCM server and configured it for distribution. It is believed that the malware was crafted specifically for this hack therefore signature based antivirus software wouldn’t be able to detect it. Once inside the POS systems, the malware was designed to scrape credit card information and send it off to multiple sites across the United States and dumped onto servers for later retrieval by the hackers. The malware was designed to snag the information as the cards were swiped, taking it from memory and saving them as a .dll file.

Knowing that some POS terminals did not have their own internet access, they crafted the malware to utilize netbios to send this .dll file to a compromised host over TCP port 139, 443, or 80. Once the host had collected .dll files, it was programmed to send a ping to the remote servers alerting the thieves that more card information was available. They would then move the data manually to their out-of-network servers to move the information overseas.

There are failures here at multiple levels. Target should not have allowed Microsoft to divulge the inner workings of their network. Criminals will still conduct footprinting and scanning to try to gain this information, but with such intimate details it made the work of this job a lot easier. If a hacker has the naming convention, the infrastructure used, they can research the potential exploits before even touching your system. Make them work hard for this information, and if it is difficult enough, they may target elsewhere.

Knowing that there is a vendor portal made it easy to find information about the portal. The public-facing website that vendors would go to in order to login had a list of all the vendors. This list is another OPSEC fail. Once again, make them work for that list. The company that got exploited by phishing was using a free antivirus software not meant for commercial use. Target can and should require all companies that work with it to have better security. A company’s security is only as good as its weakest link, and therefore Target should require companies with access to this portal have the same standard of security as their own enterprise has. An anti-malware system that is designed for commercial use, 2-factor authentication with a token should be required, and Target could test their network prior to being allow access.

The malware was designed to be undetectable to signature based systems, but should have been detected early by behavior based systems. Target was using a FireEye system that was behavior based, however it was not configured to block malicious activity. When new systems like these are put into place, they have to go through what is called a tuning process. The system is set to log and alert every single activity on a network. In some systems every process, every packet, every byte that is transferred gets scanned and if the behavior sets off an alert, the security team must act in order to stop the activity.

This is a major problem because the time to perform tuning should not be the busiest time of the year. I do not know what their business and security goals were specifically, but for the system to be tuning and not actively blocking threats during and around the Christmas shopping season seems crazy to me. They have the most customers during this time of year, and almost any other time of the year would have been better to implement a new system. The attack spanned from Nov 27th to approximately Dec 15th 2013, and only lasted this long because it took more than two weeks to finally get to the alerts containing this malicious activity. Reports don’t go into detail but there seemed to be a disconnect between the security team in Bangalore and the headquarters in Minnesota as well.

Target had passed its compliance audits earlier in the year. This is another example of companies that don’t show a care for security, who rely on the compliance and regulation of government and professional organizations to come up with standards. PCI-DSS compliance at the time left Target vulnerable.

Most of Target's failures were not really technical ones. Due to business decisions made by the company, following a poor risk management policy, they failed their customers. They decided to just meet the bare minimums and it ended up hurting their company, their customers, and retail in general. If a company wants to take security seriously, they will exceed compliance standards using industry standard practices.

Sources: Krebs on security(https://krebsonsecurity.com/2013/12/sources-target-investigating-data-breach/), Sans(https://www.sans.org/reading-room/whitepapers/casestudies/case-study-critical-controls-prevented-target-breach-35412) and zdnet (https://www.zdnet.com/article/anatomy-of-the-target-data-breach-missed-opportunities-and-lessons-learned/)

Main Image Credit : The awesome piece of artwork used to head this article is called 'Targeting' and it was created by graphic designer Sandor.



Jon is currently working as a security consultant for a major software company. He runs his career advice blog, is studying Digital Forensics postgraduate and hacking as a hobby.

Read More
A Look Back At The Target Breach of 2013
Share this

Subscribe to Secjuice.com