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.
You can see how the technique is a simple one and as mentioned is probably scripted once a scanner has determined the website is vuln to whatever recent exploit is out. All they need to do is upload the hacker’s favorite .html meta refresh file and then that link can be used in SPAM or SEO poisoning to send clients they are attempting to start on the infection chain.
In my last blog entry I talked about Netwitness Investigator, and when I got the idea of detecting HTML meta refresh redirection within the response body I immediately thought about Netwitness. Part of the detections Netwintess includes within a default install tracks HTTP 1.0 and 1.1 redirection status codes, however, I did not see a parser that would call out meta refresh redirection. All the HTML/HTTP redirections are useful for detecting the infection chain, so I wanted to see if I could write a parser myself to specifically detect meta refresh then I could combine it with other logic that’s common in driveby attacks. I accept the possibility that Netwitness does have a parser already, but either way I wanted to write one so I could learn the process as this is a very powerful ability of Investigator. Unfortunately I was not able to find any in depth instructions on how to write a .parser file from scratch from Netwitness. I talked to their helpdesk and our Sales team, and received willing effort but ultimately little in documentation or results. RSA appears to me to be pushing use of their professional services folks to get help with home grown flex parsers. I’m not bashing them, I can understand that decision. Maybe it’s because the wrong parser could cause trouble with resources but I’m still disappointed as users of their products need to be able to create custom parsers on the fly to response to the techniques being targeted at them, not wait weeks/months for an available technician, not to mention the cost.
Anyway, there’s not much I can do about it and it’s not like they leave you with zero help. In the investigator administration documents there are short definitions around the XML content key value pairs and a few examples of using a .parser to detect a token within their reassembled metadata. (Bonus: Another good place to see examples of parsers is at C:ProgramDataNetWitnessparsersNwFlex.parser here you can see your current parsers in your local Investigator client). This is what you need to do so you can use metarefresh redirection for creating Netwitness Informer alerts or Investigator custom drills/bookmarks to pivot on when trying to detect suspicious connections. Examples near end of this post.
The actual .parser file is relatively simple being written in XML. I used their example parser as well as trial and error to get it to work first locally on imported pcaps of me going to test URLs on this site (I’ll talk about them at very end) and then had the parser loaded into prod infrastructure, so we can use it in ongoing connections in the future. I’m in the process of trying to write up some of the things I learned while doing so and thought about blogging on that in the future, but to be honest with my near nothing readership numbers it’s probably not worth my time. If you are struggling with the same scenario, maybe leave a comment to motivate me.
Here’s the parser file to download with comments for those who might want to try it on their setup. Use at your own risk as with anything downloaded off the inet. I highly recommend locally imported pcaps first. WordPress.com doesn’t allow .txt (too funny), so I need to post it as a code snippet, hope it doesn’t look too awful.
<?xml version="1.0" encoding="utf-8"?> <parsers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="parsers.xsd"> <!-- This parser was modified by Scott Lockington January 2013 from the Investigator Admin guide example for finding a token. It's meant to trigger on whether the string <meta http-equiv="refresh" is found in the stream. The hex encoding is probably not needed to exempt special characters but since I have no real documentation on what they are I threw it in there. It will put the meta in the Alert key within investigator's output. --> <parser name="METAREFRESH" desc="MetaRefresh"> <declaration> <token name="tmetarefresh" value="<meta http-equiv="refresh"" /> <meta name="alert" key="alert" format="Text" /> </declaration> <match name="tmetarefresh"> <register name="alert" value="MetaRefresh in HTML response" /> </match> </parser> </parsers>
- Save the file with .parser extension to C:Program DataNetWitnessParsers (you might need to create the folder, and be a local admin to do it).
- Close (if open) the Investigator client, then reopen it.
- Goto Edit…Options…Process Tab and look for the name METAREFRESH in the list. If not there goto Help…Show Log and see if there are any errors that might help explain why it didn’t parse correctly.
- Now import the pcap in which you know a metarefresh HTML response exits, into the Investigator client and the name “metarefresh in html response” should appear under the alert section as screen shot below. (IMPORTANT: You need to reimport or refresh the pcap everytime you change something in the .parser file)
Now the bad news, the token keyword flex parser is case sensitive, which means it’s not near as effective as I’d like it to be. I’m looking for a way to make a flex parser case insensitive but as I mentioned the lack of documentation doesn’t make it an easy task. From what I read it is not possible, perhaps I can write a regex that will match on either case, but I shouldn’t have to invoke a regex engine for something so uncomplicated. I would probably have to use regex with a search parser which is a different animal altogether than a flex parser. Anyway that’s my idea, here is a recent example of how it could have detected attacks outlined by security companies.
McAfee’s recent blog entry here on the Redkit exploit pack, shows an example of meta refresh sending victims into the infection chain. Ending in a java or pdf exploit depending on what version of either you are running.
This blog entry is getting long, if you’re still reading thanks, and this is the payoff section. You’re probably saying, so what I can detect all the meta refreshes my users hit while surfing the web, big deal. You are partly right as even though meta refresh is generally considered to be depreciated, it’s still in a fair amount of use. I noticed, especially when sites redirect you not to a separate domain but to another folder within the same site. What you’ll want to do is use it to create alerts or manual custom drill’s along with other NW metadata that can narrow down just the potentially shady redirection. That’s what we security analysts get paid for after all, right?
Some examples I’ve thought up at this point are shared below. They are not perfect but should make the number of detections manageable for a medium sized network. I’ve included the more acceptable way to redirect users which is HTTP status codes such as 301 and 302, this will significantly increase your detections, try it both ways and see what works for you. Use these in an Informer alert or Investigator custom drill.
alert = metarefresh in html response || risk.info = http1.0 server location redirect || risk.info = http1.1 server location redirect && filetype = windows executable && country.dst != “united states” && filename != “putty.exe”
// Redirection to windows exe that is not from an IP in USA just so it doesn’t alert so much you ignore it. I’d remove that classification in investigator custom drills. Putty and wget downloads will FP on this the most.
alert = metarefresh in html response || risk.info = http1.0 server location redirect || risk.info = http1.1 server location redirect && filetype begins java_
// Redirection to a .jar or .class file
alert = metarefresh in html response || risk.info = http1.0 server location redirect || risk.info = http1.1 server location redirect && filetype contains encoded
//Redirection to an encoded filetype, this will probably be too noisy to email alert.
alert = metarefresh in html response && filetype contains packer
//Just MetaRefresh redirection to a file with a packer signature this will probably be too noisy to email alert.
Go ahead and let your imagination/experience create more alerts and I’d appreciate you sharing them in the comments or my contact form.
PS: One more thing. I created 2 .html files on this site that allow you to test this parser feel free to use them as needed, just remember to clear your browser or proxy cache or you might get back 304 Not Modified instead of metarefresh on subsequent visits.
Happy Hunting, and as usual any corrections or thoughts are welcome in the comment section