For this week’s discussion, research a publicized hack that includes some form of malware as the attack vector that was used. Return to this discussion with the significance of the hack, such as what system(s) were hacked, what information was breached, and what malware was specifically deployed to perform the hack. Remember to provide the URL for the article(s) you researched.
Reader Interactions
Comments
Leave a Reply
You must be logged in to post a comment.
Duy Nguyen says
Heartland Payment Systems, a major payment processing company experienced a breach in 2008 and reported a loss of more than 45 million customer’s data. The company stated that card numbers, expirations dates and in some cases cardholder’s names we exposed. Heartland’s systems were compromised with SQL injections to install sniffers that grabbed packets of transactions where financial data were exposed. The sniffer compromised systems months earlier but Heartland was only alerted when suspicious activities were reported by Visa and MasterCard auditors.
SQL injections are the input of SQL commands in entry fields such as username and passwords on a login page of a website. These SQL commands are injected to attack the database, HTML, JavaScript, or XSLT. Based on the analysis, SQL injection could have been mitigating with basic parameter database queries. There are other forms of mitigations techniques for SQL injection prevention, but another basic one was a blacklist of characters with SQL meanings from the entry fields.
Another control that failed Heartland was an Intrusion Detection system. They were unaware of their exposure for months and countless packets of PII were captured, at the end, they were still unable to count the amount of data loss.
Vince Kelly says
SANS Institute InfoSec Reading Room Case Study:
“Critical Controls that Could have Prevented the Target Breach”
https://www.sans.org/reading-room/whitepapers/casestudies/paper/35412
In December of 2013 over 40 million credit cards were stolen from nearly 2000 Target stores by accessing data on their POS systems. The sophistication of the attack was truly extraordinary on multiple levels.
Providing complete detail on all of the reconnaissance, infiltration and exfiltration techniques used in this attack would literally turn this post into a book so I’ll just provide highlights on some of the methods that were used to plant the malware into the POS machines and then provide detail on how the malware was able to figure out where the credit card data was stored in the POS device memory so that it could then grab it and exfiltrate it to various drop sites around the world.
Reconnaissance by the attacker(s) revealed that:
1. That Target used many 3rd party vendors to take care of its facility’s. They used this information to go after one of Targets HVAC vendors who had access to their network,
2. Target had allowed its basic, generic network diagrams to be placed out on Microsoft’s web site as part of a customer case study describing how Target used Microsoft’s System Configuration Center Manager (SCCM) to deploy security patches and software updates to their global POS infrastructure.
The Infiltration Phase:
– The attackers then successfully penetrated the Target network by using a Spear Phishing attack to get one of Target’s vendors to install a derivative of the ZeuS banking Trojan malware. The ZeuS Trojan stole the vendors login credentials which they then used to gain access to the Target infrastructure.
– The attackers were able to root around undetected until they found a vulnerable MS Domain Controller that allowed them to pivot into and install their malware on the SCCM server that they had read about. SCCM software updates to POS devices were automatic, so it didn’t matter if a POS wasn’t actually online when the malware was installed on the SCCM server because the POS devices always pulled down the latest software from the SCCM server every time they booted up.
In effect, ironically, this allowed the attackers to use Targets own operational security processes against itself!
The Attack Phase
The attack itself was thought to be the first recorded appearance of a direct in-memory malware attack.
Once the malware was deposited and automatically executed on the POS device by the SCCM process, it would begin searching through the list of running processes running on the operating system until it came across the processes that handled credit cards for the POS device. The malware was able to identify the process by comparing the programs name against a list of known POS processing software that had been coded into it. The interesting thing here was that the malware conducted its search process with a very low privilege level so that its activities wouldn’t raise suspicions.
Once it identified the process, the malware escalated its execution privilege’s and attached itself to the same memory address space as the POS CC software (i.e., it could read the same memory as the legitimate program).
The fact that the malware had made it all the way into the POS machine was impressive, but given that credit card numbers are encrypted by the POS device software after they are scanned in would make it seem like all of that effort was wasted – right? Wrong! The malware was able to find the temporary buffer location in memory where the credit cards are stored before the encryption process grabs them.
This allowed the malware get hold of the credit card numbers BEFORE the encryption routine had a chance to actually run. And given the fact that the POS software always put the CC information in the same place in memory every single time, all the malware had to do was wait until it saw that memory location change and then siphon off the new information as it was placed into that buffer.
The malware was able to find that buffer in the first place by searching through the program codes data segments (its stack and heap memory spaces) and then match strings of contiguous numbers that it found against known credit card formats. Once it found a string of numbers that matched the format, it knew that it had a credit card.
Exfiltration Phase:
Finally, the malware then created ‘batches’ of stolen credit card information which it then simply exfiltrated by depositing the batches at drop locations all over the world using FTP – and then went back to work stealing more CC information!
Another ironic thing about this attack that it actually had been detected by Target personnel while it was underway by way of a newly installed IDS system. The IDS warnings were ignored however because the device had only recently been deployed and was still going through its preliminary learning/training phases – so the warnings weren’t taken seriously!
Dan Bilenker says
Bank Servers Hacked to Trick ATMs into Spitting Out Millions in Cash
“The investigators analyzed 10 malware samples associated with FASTCash cyber attacks and found that attackers remotely compromise payment “switch application servers” within the targeted banks to facilitate fraudulent transactions.”
Imagine that you have no money in your bank account, yet you are able to go to an ATM with your debit card, and withdraw $10,000 and the bank has no idea. Essentially, this hack compromises switch application servers, and validates user requests without verifying available balance information.
Now, for the best part! Guess how they did it….*DRUM ROLL PLEASE*….SPEAR PHISHING. Well, Spear Phishing with an executable payload. Once the users opened the emails, the malware was deployed onto the network, and made it’s way to the servers.
More specifically,
“authorities believe that the APT threat actors used spear-phishing emails, containing malicious Windows executable, against employees in different banks. Once opened, the executable infected bank employees’ computers with Windows-based malware, allowing hackers to move laterally through a bank’s network using legitimate credentials and deploy malware onto the payment switch application server.”
https://thehackernews.com/2018/10/bank-atm-hacking.html
Vince Kelly says
…”Though most compromised switch application servers were found running unsupported IBM Advanced Interactive eXecutive (AIX) operating system versions, investigators found no evidence that attackers exploited any vulnerability in AIX operating system.”
What’s amazing to me is the fact that:
1. There was no internal detection of what MUST have been suspicious traffic in and out of the switch application server by an IDS/IPS or the security staff – *somebody* was asleep at the wheel
2. That the financial institutions responsible for the switch application servers could even pass an internal or external audit of their critical systems (I don’t know anything about ATMs but I’d definitely put the switch application servers in the ‘critical’ systems category).
Heads *should* roll but of course you know they won’t