Case-study – Target Data Breach 2013

The Target data breach started during an unspecified time in the year 2013. However, it became publicly known around Dec. 2013. Hackers gained access to more than 40 million credit and debit card information through malware on Target’s Point-Of-Sale (POS) systems. The Target Company never publicly released details of the breach, and probably never will, but enough information exists online and within the cybersecurity community to piece together what likely happened during the breach. This information can help people prevent similar attacks in the future. Figure 1 is a diagram illustrating the Target data breach with a timeline. Information was collected from a number of sources (US Senate Report, 2014; Kassner, 2015; Krebs on Security, 2015; Cyphort, 2014). The Target breach represents a typical class of cyber threats called Advanced Persistent Threats (APT). APT is a set of stealthy and continuous cyber hacking processes with the intention of stealing high-value data and information from targeted organizations. Second, the Target breach happened in 2013, short enough so that lessons learned are not out of date, and also long enough so that there are sufficient details available to piece things together. Third, the Target breach is a high-profile case.

Figure 1

Discussion questions

Use your own words to explain what happened in the Target data breach. 

The  2013 Target data breach case occurred between October 2013  and Dec. 2013. The malicious perpetrators gained access to Target POS  central network &  servers through stolen credentials of a 3rd party contractor/vendor in Nov 2013. They escalated privileges using the hacked vendor account and then installed malware to capture names, email addresses, credit card data, and other information

The HVAC contractor’s credentials were compromised by email phishing. Please propose at least two security mechanisms to guard against email phishing.  

• Security awareness training with phishing campaigns will reveal reckless staff who aren’t cautious about clicks.
• Setting up proper Conditional Access policies to block unauthorized logins. For example, If they aren’t logging in from any of any trusted locations (the external IPs of the office premises) then they need multifactor authentication.

If you are a hacker, please propose a scheme for a phishing email attack. Be as real as possible:

As the attacker, I would first start off with deep research on data I have gleaned from a carefully curated list of likely vulnerable HVAC contractors/suppliers who must have added some social proof of their affiliation with Target or ongoing business deals to their web pages or social media sites. Since it’s a relatively small group list  I will send them highly targeted phishing emails with malicious links to steal their passwords by having them log in to a fake target contractor portal (that I set up) with some form of personalization included – perhaps the person’s name etc. I will send these phishing emails with the spoofed email address of the “key contact” target employee(s) who the vendors most likely liaise or send their reports.  Personalization and detailed knowledge of my list of victim vendors and their businesses will be the hallmark of this process.  When they click the link in the email, they are taken to a webpage that looks, more or less, like the official target portal. Unknown to them this site is actually designed to steal their information. A pop-up alert will say there is a problem with their account and ask them to confirm their login and password. After entering your credentials on the page that appears, I will then send them to the actual institution to enter their information a second time. By steering them to a legitimate institution, they won’t be immediately suspicious that their information was stolen…to reduce the chances of them changing the login details I just stole from them. 

The stolen credentials alone are not enough to access the company’s POS devices. The hackers then acquired elevated rights that allowed them to navigate the company’s network and deploy malware. This process is called Privilege Escalation. Name as many ways as you know to do privilege escalation. 

• Dumping the SAM file. 
• Retrieving the /etc/passwd file – and then simply enumerate the usernames of that particular system
• Inject malicious code into system processes with weak permissions
• Exploit sensitive information stored in shared folders (using Metasploit)
• By replacing one of the legitimate DLLs with a specially crafted malicious DLL.

For privilege escalation, the hackers need to do vulnerability scanning on the Target network. Please propose as many ways as you know to do vulnerability scanning. 

1. Enumeration – With enumeration, hackers can gather and exploit critical system information, including IPtables and Routing tables, Unmounted File Systems and additional drives, Usernames & passwords (user enumeration), Audit configurations, Service settings, DNS and SNMP details, Hostnames, etc.
2. Kernel Exploits – One commonly known vulnerability is due to legacy kernel versions being excluded from security patches. As a result, some hackers could simply download, compile and run an exploit to perform a privilege escalation method
3. SUDO Right Exploitation – The Substitute User Do (SUDO) program lets a user run Linux commands using the permissions and privileges of another user. Unfortunately, this means that an external actor can exploit a user’s SUDO access to gain account administrator root privileges.
4. Access Token Manipulation – (in windows) including duplicating access tokens, creating new processes with duplicated tokens, and creating tokens using username-password combinations.
5. Bypass User Account Control – The User Account Control (UAC) system dissociates administrators from regular users. By limiting all machines to standard user permissions, the UAC helps to prevent malware from compromising the OS. With a compromised UAC, attackers can escalate privileges to execute administrative functions for a full-blown system attack.

6.  POS machines on the market are vulnerable to viruses and malware. Please propose a few measures to enhance POS security.

Update POS  systems. Outdated, unsupported operating systems are a significant risk as they provide more unpatched vulnerabilities to malware authors. Windows XP-based systems used in many retail environments are vulnerable as they lack some of the more advanced security features of newer versions. In terms of security, POS systems should only use up-to-date and well-supported operating systems.

Use whitelist technology. Whitelisting can protect against unauthorized applications running on POS systems. Whitelisting allows only pre-approved apps to run on a system.

Isolate your POS system. Isolating POS systems on a network reduce the potential attack surface and make it easier to detect suspicious activity. Keeping data segmented allows it to be stored in different locations.

Use code signing. Code signing is a cryptographic value signed in a specific binary executable file as a tamper-verifiable control. Code signing ensures that each program is checked before running to prevent tampering with the system.

Use chip readers. The EMV technology used by the chip cards allows customers to avoid shifting. Magnetic stripes contain unchanging data, but chips in EMV cards generate a unique transaction code each time. The EMV chip makes it difficult to copy payment card data.

Restrict physical access. Physical access and user privileges to point-of-sale systems must also be tightly managed. For example, if an employee uses a POS terminal to browse the internet, it can expose the system to security risks. Ideally, the administrator account should be tightly protected and the activities of other users strictly limited.

Target ignored many alerts from their network security devices because of alert overload and false positives. If you are the Target CTO, what would you do to alleviate the problem of alert overload? 

There are several ways to prevent (or at least minimize) alert overload: 

1. Share the workload between staff members — make sure each staff member has a manageable number of alerts to deal with, and that the alerts they receive are relevant 
2. Optimize alert settings in each system — if you understand normal user behavior for your site, you can adjust alert thresholds to only notify you of unusual activity
3. Switch to a system with a low false positive rate — using systems with a proven track record of low false positives ensures you’re only alerted to genuine threats.

 

References 

[1] Cai, Yu, and Todd Arney. “Using Case Studies To Teach Cybersecurity Courses.” Journal of Cybersecurity Education, Research and Practice 2018.2 (2018).