The Attack. Equifax Hackers Stole 200k Credit Card Accounts in One Fell Swoop – Period! As widely reported on September 17, 2017, Visa and MasterCard have been sending confidential alerts to financial institutions across the United States this week, warning them about more than 200,000 credit cards that were stolen in the epic data breach announced last week at big-three credit bureau Equifax. At first glance, the private notices obtained by KrebsOnSecurity appear to suggest that hackers initially breached Equifax starting in November 2016. But Equifax says the accounts were all stolen at the same time — when hackers accessed the company’s systems in mid-May 2017. Sounds so familiar? Remember the Target hacking, Sony hacking, etc.
In all of these, here are a few introspections.
The Motive and What the Attacker is Looking For.
It might just begin with the attacker looking for one item i.e. looking for one folder, one credit card number, or one social security number. To initiate hacking, the attacker often starts by conducting social engineering research to pinpoint vulnerable systems including websites. In the process maybe he finds SQL injection vulnerability on a website, and then steals a few things slowly to not trip an IPS or throw to many queries at the database system. The attacker is not in a rush, but just wants to buy some TVs and some pants from Old Navy. Stealing 200,000 credit card accounts would surely have a larger system impact and higher chance of detection than stealing say 100 or stealing the 20,000 over the course of a year. Maybe the attacker is looking for a few small files in your legal folder on a file share. It behooves to think of this mentality as the slow and patient attacker. This is the attacker that is interested in the whole pie, but just eats a small piece of the crust and works his way to the center….slowly.
On the frontline we as security experts can imagine the thought behind an attacker and what methodologies to effectively conduct targeted attacks. GSM based ATM skimmers are a good example of a slow and strategic attack. An attacker places the skimmer on the ATM and 10 or 15 cards may be swiped in the course of a few days. Even if the device is then detected, the attacker can cash-out between 20-25k Euros if the device is in Europe. This isn’t an extremely large scale attack, but it is targeted and effective. Brian Krebs has a fantastic post on this subject, as part of his ongoing series of ATM skimmer research available at: http://krebsonsecurity.com/2010/06/sophisticated-atm-skimmer-transmits-….
Start by imagining an attacker looking to use malware to reach an objective. We imagine that an attacker writes malicious code, and continuously tweaks the code until it bypasses antivirus. Now, an attacker doesn’t need to write code that bypasses all antivirus software, assuming that the attack is targeted at a specific company. The attacker only needs to footprint their Antivirus structure (perhaps by some crafty social engineering). The attacker determines that the company uses Antivirus Software A, works with Virus Total to get past the possibility of detection, and then attacks the company.
A typical (good) example of a “low and slow” attack is Albert Gonzalez and the Heartland breach. Gonzalez and his team slowly penetrated each defense in the TJX network (including Wi-Fi, SQL injection, etc.) and used custom malware on several corporate systems in order to attacks which allowed him to steal information. He did this slowly over the course of a year. Depending on the motivations of the attacker, getting one compromised PC may be enough to fulfill his or hers goals, or in Gonzalez’s case a few servers. Or maybe there is a bit more sophistication and the attack needs to spread between machines or perform command and control like operations. Regardless, if the attacker is smart, he or she will know that it is a limited amount of time before the virus is detected, if it’s noisy, by means of anomaly detection for example like network traffic patterns.
For most attacks, the entry gates are vulnerable exposed systems such as Web applications which are a common avenue for attackers to gain access into a system. Targeting web application vulnerabilities seems to be significantly more successful than the DDoS attacks such as those that the folks from Anonymous are doing. Disrupting a service is great, but to an attacker, stealing something of value is greater. An attacker performing a targeted attack can go in and quickly and strategically steal some data, maybe just a few credit card numbers or a confidential folder share, and leave a backdoor to slowly elicit more information. The chances of detecting his presence and what the he did are more difficult since, the attack was strategically targeted. In addition, if an attacker is trying to leave a backdoor to get back in, web shells make the job easier, since all the command and control will go through common ports (443/80). A smart attacker will even encrypt or hide his or her shell in some ASP page on a web server. So, they gain access to a web server, do some damage, and leave a small shell behind obfuscated and encrypted in some directory masked by the presence of thousands other web files. And the attacker can write a backdoor from scratch, to ensure that the payload isn’t picked up by an IPS or a virus scanner.
So, what do all of this things have in common? These attackers have the resources, targeted goals and the patience to do stuff right. Then the obvious question is “What can we do to protect our assets?”
Leveraging Similar Controls and Slightly Adjusting them for the Strategic Bad Guys
As intriguing as it may be, the key question is “how do we can detect a smarter and more patient attacker?” Given that custom malware and web shells are inevitable, any savvy PHP or C developer can write malicious that won’t be detected. Then the question is, as frontline security experts, what controls do we put in place to prevent the inevitable? The solution is a combination of prevention, limitation of exposure, and security education and training. Remember the classic HR example: If Joe in HR is tricked into downloading my malicious PDF, and I am able to copy the HR folder to my external server and then get out, how will I know this happened? The attacker may have left an audit trail, but didn’t spend a whole lot of time doing bad stuff. If my web applications are not going through security assessments, how can an organization be confident that an attacker won’t find an exploit, and sit patiently on the webserver collecting information over the course of a year? Assessing web applications and remediating any identified security issues will make an attacker’s job more difficult. In addition, limiting the exposure of data by keeping authorization in control will help mitigate data leak to unauthorized users. And security training for employees is a must, as often times they are the culprits that open the malicious PDF. Proactive planning, segmentation, and better forensics are also necessary for helping reduce the damage of this type of attack. By planning out where the data is and how important it is, segmentation and controls can be put into place to limit the exposure of data compromise. As supported by decade old studies, the insider threat is real and has always been there. All we need to do is to take security controls more seriously and come to realize that an attacker may already be in our organization, and plan for what we do to mitigate that risk.
