With this background, I made a surprising discovery about the way people appear to be using the VRT rules: none of them were employing, or were even really aware of, what I call our "Don't Do That" rules - anomaly detection signatures that find attempts to obfuscate bad behavior, interesting new 0-day, and other generically bad stuff. Since we've found these rules useful, and have had positive feedback from users who are running them, I've decided to highlight some of the more interesting rules in this group, both to make time-starved analysts aware of them, and to solicit further feedback on their use in the wild.
So, without further ado, here are the rules, and the logic behind them:
- "POLICY Adobe PDF start-of-file alternate header obfuscation attempt" / SID 16354 - This looks for a technically valid, but non-standard PDF header. Will it fire on legacy documents and other odd, but perfectly valid, files? Sure. Will it also find documents where attackers are deliberately trying to evade detection by IDS, antivirus, etc.? Definitely. Given the flood of PDF exploits we've seen in the wild over the past year or so, we figure that the more tools your analysts have for finding non-standard PDFs, the better.
- "POLICY Adobe PDF alternate file magic obfuscation" / SID 16390 - Same concept as SID 16354, slightly different part of the file specification.
- "SQL oversized cast statement - possible sql injection obfuscation" / SID 13791 - The SQL cast() function on its own is part of any database programmer's repertoire. However, it generally doesn't appear directly in a URI - and more importantly, when it does, the data inside of the parentheses is generally under 250 characters (if the data is actually that long, it's inside of a variable somewhere - nobody wants to manually type out a string that size). Since we've seen tons of SQL-injector malware that employs calls to cast() with huge chunks of data, however, this was introduced as an easy way to catch lots of different types of malware in one fell swoop.
- "SQL oversized convert statement - possible sql injection obfuscation" / SID 13987 - Same logic as SID 13791, only with an alternate SQL function.
- "SQL large number of calls to ascii function - possible sql injection obfuscation" / SID 13988 - As with SID 13791, most malware being injected into a database is going to be obfuscated. The ascii() function simply converts a hexadecimal character into its ASCII equivalent, a common obfuscation technique. This rule looks for five calls to this function within a single request, which we feel strikes a balance between detecting malware that uses the call and skipping over legitimate programming uses for ascii().
- "SQL large number of calls to char function - possible sql injection obfuscation" / SID 13989 - Same concept as SID 13988, different function.
- "SQL large number of calls to concat function - possible sql injection obfuscation" / SID 14008 - Same concept as SID 13988, different function.
)). This rule looks for such calls with a minimum of 250 bytes of data inside the unescape() call - something which happens very rarely in legitimate traffic, but all the time in attacks of this type.
");. Metasploit has a built-in function that does just this for the unescape() function, which, as just noted, is often used to obfuscate client-side attacks. Since a legitimate web page has little to no reason to redeclare the name of the unescape() function, this rule looks for such behavior as an indicator of malicious intent.
- "EXPLOIT Possible Adobe PDF ActionScript byte_array heap spray attempt" / SID 15728 - Same detection as SID 15729, only used in conjunction with a flowbit that looks for files declared as PDFs (SID 15729 looks for files declared as SWF). You can thank Adobe for allowing people to embed Flash in PDFs on this one.
- "WEB-MISC text/html content-type without HTML - possible malware C&C" / SID 16460 - This rule came out of an analysis of the Zeus trojan, as well as other nasty pieces of malware. Since Zeus encrypts all of its command and control data, yet declares in the HTTP headers that the traffic will be of type "text/html", this rule looks for HTTP packets which declare that content type, but which do not actually contain plaintext HTML. In our testing, this found Zeus reliably, and picked up on other pieces of malware as well. Given the fact that HTTP servers do lots of strange things in the wild, we're very interested in seeing any false positives you might have on this rule, so we can account for whatever odd thing the servers you're interacting with are doing.
- "POLICY Suspicious .cn dns query" / SID 15167 - Most security analysts have seen malware hosted on insane domain names like qxpvfsztr.cn - and all it takes it one look at a name like that to know that something really fishy is going on. This rule helps your IDS find such names, by searching for DNS queries for .cn (i.e. Chinese) domains that contain 5 or more consonants in a row.
- "POLICY Suspicious .ru dns query" / SID 15168 - Same concept as SID 15168, except with .ru (i.e. Russian) domains.
- "WEB-ACTIVEX obfuscated ActiveX object instantiation via unescape" / SID 16573 - Metasploit sometimes hides the name of the ActiveX controls it is attempting to exploit by hex-encoding it. There is no legitimate reason to have the name of an ActiveX object that you're instantiating encoded, so we detect this behavior as likely malicious.
- "WEB-ACTIVEX obfuscated ActiveX object instantiation via fromCharCode" / SID 16574 - Same concept as SID 16574, but looking for a different function to decode the name of the control.
We're always constantly thinking about new anomaly detection rules that we could add - for example, we're currently considering a rule that looks for, in essence, "var shellcode = ". Since we know that there are lots of good analysts out there who have written their own anomaly rules, if you have anything you'd like to share with us, drop us a line at email@example.com or start up a thread on the Snort-Sigs mailing list. Also, if you find that any of these rules are flagging a high percentage of normal traffic, send us samples at firstname.lastname@example.org, so that we can fix things, both for you and the community at large.