Twelfth day of Hackmas: The day 40 million credit card details were stolen via a company’s Air Conditioning unit
Up until 2013, Fazio Mechanical Services was a relatively unknown refrigeration and HVAC system provider. Little did anyone know that by hacking Fazio attackers would gain access to Target’s Point of Sale system.
And all it took was 11 steps.
Step 1 – Steal Credentials
In order to target Target, the attackers needed a doorway. Fazio supplied Air Conditioning units to Target and these units were connected into the main Target network.
Stealing the credentials was relatively simple: Malware (in this case Citadel) was installed into the Fazio network via an email phishing campaign.
Yep. Just send an email and people will click on it.
Step 2 – Connect in using the stolen credentials
The credentials stolen from Fazio granted the attackers access into Target-hosted web services which were dedicated to their vendors.
“[Fazio] does not perform remote monitoring or control of heating, cooling or refrigeration systems for Target. Our data connection with Target was exclusively for electronic billing, contract submission and project management.”
The web application used by Fazio was very limited and despite the fact that attackers now had access to an internal web application hosted on the Target network, they would have been unable to execute any commands. Without the ability to execute commands the attackers really couldn’t do much (except perhaps muck around with the temperature).
Step 3: Exploit a web application vulnerability
As per usual, the web application in use had a vulnerability and the attackers only needed to find it. The attackers worked out that the Windows system in use had no usable vulnerabilities, but the PHP component did.
“This file suggests that the attackers were able to upload a PHP file by leveraging a vulnerability within the web application,” An Aorato report concludes. “The reason is that it is likely the web application has an upload functionality meant to upload legitimate documents (say, invoices). But as often happens in web applications, no security checks were performed in order to ensure that executable files are not uploaded.”
The malicious code was probably some kind of “web shell” which is a web-based backdoor. This backdoor would have allowed the attackers to upload files and execute commands as they pleased.
Many of the exploits used by the attackers were hidden in plain sight, most likely because they knew that this particular attack would be a once off. Therefore the attackers wouldn’t have wanted to invest too much time and infrastructure hiding their tracks.
Step 4 – Find the right targets
Now that the attackers were in they had to perform some reconnaissance. They could run commands within the network but they needed to know more about the internal network structure of Target’s network: i.e. they needed to find where Target stored customer information including credit card information.
They used a simple query on Target’s Active Directory to narrow down their search to the core database servers.
Step 5 – Obtain administrative access
Here the attackers needed to move quickly. They used a hacking technique called “pass-the-hash” that allowed the attackers to impersonate an Administrator – which would last only as long until the actual Administrator changed their password.
Step 6 – Create a new administrator account
In order to evade detection, the attackers then needed to setup their own administrator account which would allow them remote access.
The stolen credentials from Step 5 would have allowed them to create a new administrative account – which they did. They called this user “best1_user” which is the same username used by BMC’s Bladelogic Server Automation product.
This is obviously abnormal behaviour within a network and if Target admins had been notified they could have shutdown the hack at this point.
Step 7 – Hit the target computers
With their new administrative credentials, the attackers could now proceed to go after their targets. They first needed to bypass firewalls and other network-based security solutions that limit direct access to targets. They also should block the running of processes remotely on machines.
The attackers ended up using hacking tools to jump via various servers that were not tuned to look for suspicious behaviour until they landed on their target machines.
Ultimately the tools the attackers used needed the administrator account to run, so if the Target admins had been looking they could have shut the attack down.
Step 8: Steal the data… but there was a hiccup
The attackers at this point would have searched through the key databases looking for Personal Identifiable Information (PII). However because Target was PCI compliant, the database servers didn’t store any credit card information.
The attackers were able to steal the PII of 70 million Target customers, but not the credit card information that they came for.
Step 9: Plan B – attack the POS machines
The attackers had probably assumed that they would have all of the credit card information by Step 8, so hitting the POS machines was probably not the initial target of the attackers. The POS machine attack would have been a contingency.
Using the intelligence they had gathered during the previous steps, the attackers installed their malware onto the POS machines. The malware (named Kaptoxa) scanned the memory of infected machines and saved the credit card details.
Reports suggest that this was the only step that required custom-made malware rather than common, legal, IT tools.
At this point no level of Antivirus would have helped.
Step 10: Get the data out of the POS machines
The malware sent data to an internal file share using a windows command and their administrative account. It would periodically send data out using this method.
Step 11: Get the data out of the network
Again using the Target administration account, the attackers could then send the data out of the Target network undetected.
Could this have been prevented?
There’s a number of ways and points in this whole hack that could have prevented this breach.
- Educate staff not to click on stuff (step 1)
- Patch systems (step 3)
- Looking for abnormal behaviour (step 4 would have increased server usage to abnormal levels)
- Looking for abnormal behaviour (step 6 should have triggered an alarm for sensitive user creation and abnormal user behaviour)
- Looking for abnormal behaviour (step 7 should have triggered an alarm for remote code execution)
- Looking for abnormal behaviour (step 10 should have triggered an alarm for sensitive user creation and abnormal user behaviour)
Read more here