The Small, Strategic, and Utterly Transparent Attack

What is the attacker looking for?

Maybe the attacker is looking for one folder, one credit card number, or one social security number.  Maybe the attacker finds SQL injection vulnerability on a website, and the attacker 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 40,000 credit card numbers would surely have a larger system impact and higher chance of detection than stealing 10 or stealing the 40,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.    I like 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.

As security experts, we 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.

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 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.

Web applications 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 the 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 though 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.

What do all these things have in common?  These attackers have targeted goals and the patience to do stuff right.   What can we do to protect our assets?

Similar Controls Slightly Adjusted for the Strategic Bad Guys

So how do we detect a smarter, more patient attacker?   Custom malware and web shells are inevitable.  Any savvy PHP or C developer can write malicious that won’t be detected.  The question is, as 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.  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.  We need 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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s