In my last post, I showed the different log sources that are readily available for collection, including a custom one: httpry_logger. Having a detailed record of every URL visited that is instantly accessible via ELSA makes incident response for well-publicized events very simple. This week, many news sites reported on a new attack made famous by Websense. Across the globe, IT security analysts were asking themselves (and, in many cases, being asked by management), if anyone had been affected by the malicious links the attack had scattered over hundreds of thousands of web sites. Depending on the tools available to the analyst, this can be a time-consuming task. With ELSA being fed by httpry_logger, however, this question can be answered while your boss is still standing at your desk!
The question: Did anyone visit the malicious web page, lizamoon.com (now offline), and if so, what happened? In ELSA query language, which is intentionally very similar to Google query language, the query is:
There are lots of hits, and your boss looks worried! Looks like a lot of cross-site scripting (XSS) in there. However, Websense reported that the site had already been taken offline. As you can see, many of these requests did not receive a response. So, let's drill down a bit and ask: who visited the malicious site and got data back? ELSA:
That looks better, but there are still a few hits. We need to drill down to see what the malicious content was. For this, we'll need to use a different tool, StreamDB, which I will describe in detail in a later post. For now, let's have a look at the StreamDB output for our query:
Returning 2 of 2 at offset 0 from Mon Mar 28 17:57:17 2011 to Mon Mar 28
17:57:17 2011 2011-03-28 17:57:17 x.x.x2.4:57986 ->; 18.104.22.168:80 0s 594 bytes RST GET lizamoon.com/ur.php
Connection: Keep-Alive Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 1.0.3705; InfoPath.1; .NET CLR 2.0.50727; MS-RTC LM 8) X-HTTP-Version: 1.1
2011-03-28 17:57:17 x.x.x2.4:57986 <- 22.214.171.124:80 0s 975 bytes RST 200 ASCII text, with very long lines, with no line terminators
Date: Mon, 28 Mar 2011 22:56:18 GMT
Server: Apache/2.2.17 (FreeBSD) mod_ssl/2.2.17 OpenSSL/0.9.8n DAV/2 PHP/5.3.3
Keep-Alive: timeout=5, max=100 Set-Cookie: click888=1; expires=Wed, 27-Apr-2011 22:56:18 GMT
document.location = 'http://defender-nrpr.in/scan1b/237?sessionId=0500(snip)
So, content did indeed come down, and obviously, the goal is to set the browser's location to the next malicious site, defender-nrpr.in. We can then use ELSA to see if the client did follow to that site:
No results found, so our client is ok! So what did our client do? We do an ELSA query for that client IP for the few seconds around the request and see that there were no other suspicious requests. Looks like everything is fine, and management can rest easy.
Let's dig a little deeper in ELSA to see what other information we can find out about lizamoon. What are the hacked sites that are funneling traffic to the malicious drop site? ELSA:
This shows us the top unique page URI's that are linking to the malicious site. What IP addresses are serving lizamoon.com? ELSA:
Who went there?
Because each one of these queries finishes in a second or two, we can answer all of these questions in under thirty seconds—short enough to do while your boss is right there! This process of broad queries followed by drill-downs is the staple of efficient investigation. A lot of tools, (Websense, for instance), will give you the ability to do the broad queries, and to some extent, drill-down, but the difference is that the follow-up queries take far more time in large organizations, which can make your analysts less likely to follow every lead as they have to constantly prioritize their time. Queries that take almost no time are much more likely to be made. So if knowing is half the battle, then asking the questions is the other half.