Detecting Infection Chain Redirections with custom Netwitness Flex Parser

In my ongoing battle with those who feel they should have their way with the computers I defend, I recently had an idea around detecting a common part of the infection chain.  That term, to me, is the process of exploitation often used in drive by attacks to thwart IP and domain blacklisting along with making attribution harder as the target is often bounced between several IPs/domains in different countries through dynamic DNS techniques.  This certainly makes it hard to determine what IPs/domains are links in that infection chain at any particular moment, and admittedly it is not what my toolset is best suited for.  That’s the job of the many different services who specialize in such things (ex. Malwaredomainlist.com, spamhaus.org, Bluecoat, etc).  My task is to try and detect the techniques and malware bad guys use to get their main task completed: run code of their choice inside my network.  Along that vein, after investigating a recent driveby landing page on a compromised site that it was easily the 3rd time I’ve seen use of an HTML page that incorporated the somewhat depreciated HTML Meta Refresh technique to move the user to the next link in the infection chain.  This made sense to me as once they are able to compromise a wordpress blog, discussion forum site, ftp brute force, etc they often get upload permissions and it is then trivial, or even scriptable to upload a .html file they have saved somewhere to redirect the user with some unsuspecting message like “Loading…”  Here is the example that triggered my thought during that investigation.  In this example a html file was uploaded to the good site http://dropyourtalent.com at /rumyn.html, click pic to make larger.

blacole landing page

Continue reading

Advertisements

RSA Netwitness Investigator Regular Expressions

In the blog post below (here) I talked about my theory to detect DGAs by looking for consecutive consonants in a row within a URL.  However my SNORT rule does not work like I wanted it to.  I thought the rule would look for the HOST: portion of the HTTP header and start the regex match after colon and whitespace. When what it seems to do is trying to match the whole line as one entity including the word HOST, this causes the match to fail if there are ANY vowels in the line vs. only caring if there are x number of consonants in a row before or after a vowel.  So I figured I’d leverage another tool, RSA’s Netwitness network forensics product would work. You can download a home version of the tool here.

Netwitness investigator allows users to use RegEx to filter the packet capture data including of course web surfing.  As I understand it they use the BOOST RegEx engine as opposed to the PCRE engine I’m more familiar with. Either way, there doesn’t seem to be a lot of documentation included with the product around the needed syntax. So I recommend you try just throwing in your regex and see what happens as Investigator will do some sanity checking. Taking my own advice I entered my SNORT regex as a custom drill in the alias.host field (a helpful message from an experienced Netwitness user made me realize I shouldn’t assume readers knew I was using a custom drill for this filter).  As you will quickly learn you need to backslash escape most non alpha-numeric characters until it works.  The pic below shows the error checking where I intentionally left off the backslash escape character in front of the comma in the repetition operator {9,}

regex_validation

Continue reading