Detecting Malicious PDF’s With Advanced Correlation

A recently released Symantec report estimates that 65% of all targeted attacks in 2010 were executed using malicious PDFs.  According to the study, this is a 12.4% increase from 2009.  ”If this trend were to continue at the same rate it has for the last year, by mid-2011, 76% of targeted malware could be used for PDF-based attacks”, the study continues.

Adobe and Microsoft do their best to keep these vulnerabilities patched but often times, and especially in the case of a targeted attack this is not enough.  Some antivirus vendors will scan PDFs for the presence of embedded executables, shell code or malicious Javascript while others rely on older signature based detection to identify malicious PDFs.  Depending on your AV vendor, you may or may not be able to thwart and prevent the execution of a malicious PDF on your network.

In the event that something gets through and also gets executed, let’s look at how you could detect the attack using correlation rules within your SIEM.AI Engine Rule Blocks

For this experiment I looked at a number of malicious PDFs including MD5:411406d5ace2201e5dd73ce8e696b03b. When run, this file exploits a remote memory corruption vulnerability that causes the application to crash while processing the malicious .PDF file. The issue kicks off when the reader tries to initialize the file cooltype.dll.    When run, this file crashes Adobe generating an event that’s resulting behavior will be the basis for one of our primary advanced correlation rule blocks.

3/24/2011 8:16 PM TYPE=Error USER= COMP=XXXXX SORC=Application Error CATG=(0) EVID=1000 MESG=Faulting application acrord32.exe, version, faulting module unknown, version, fault address 0x6753e2ed.

From there we look for some more specific rule blocks.  One that could be valuable would be a block for a File Integrity Monitor log indicating that someone opened/read cooltype.dll.  As cooltype.dll attacks were not isolated to this particular vulnerability (CVE-2010-2883,CVE-2010-3654, and CVE-2010-1241) this could play well in a number of hands.

While these two events alone might help shed light on possible attacks, they can also be prone to false positives requiring that you fine-tune the blocks a bit more on this rule.  The next blocks are somewhat dependent on your environment and what devices you are logging.  The basic behavior, however, will remain the same regardless of what devices you are collecting from and the various vendors.

The next block is more general because we are now just looking for basic malicious behavior.  If your first line defenses didn’t prevent the infiltration and the PDF was executed, there is a good chance it will need to phone home to download a payload.   This can be done in a number of ways, so we will add a few rule blocks to monitor for some of those possible scenarios.

You may already have rules in place to monitor for outbound SMTP connections from machines that should not be generating such traffic, but the threshold is likely in place to only alert on a large number of instances.  In the case of a targeted attack we would not expect this kind of general spambot behavior.  Try setting the threshold much lower for this rule, perhaps even on an instance of one outbound SMTP connection.

It may try to phone home VIA HTTP on port 80, so we’ll add a rule block that checks routers, firewalls and/or NetFlow-generating devices for any source of port 80 traffic not originating from a known web server.  We may also want to watch for traffic on port 80 that is not HTTP.  In the case of a targeted attack, privacy is typically important to the attacker.  Outbound SSL traffic might be considered significant in this situation.

We don’t want to leave out the low hanging fruit so we can include rule blocks on a classification or common event of malware detected correlated against any IDS alerts that may have occurred within a relevant time span.  We might also add criteria for older communication methods like IRC just to be safe.  In the event that the initial exploit does not crash Adobe in a way that triggers an event log we would also layer in a second line of defense on our primary rule block. Using one of LogRhythm’s endpoint monitoring capabilities, we can monitor process explorer and take note of the acrord32.exe process starting within a relevant time frame of the subsequent events.

Periodic maintenance of these rules is necessary to keep them relevant. Stay current on zero day (Adobe and Microsoft) exploits and pay attention to what files they are working against. Incorporate these target files (cooltype.dll) into rules whenever possible. Ideally this would be before patches are released.

There will never be a silver bullet to detect malicious attacks.  But with creative use of your SIEM’s advanced correlation rules you can alert on some very interesting behavior.  Obviously you should start with the basics and keep your systems patched.   But in the event that something slips through your 1st line defenses, why not exercise your SIEM solution to the fullest to help keep your network secure?

Tags: , , ,

0 Comments | Security


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>