Slides from Lockdown 2012

I had the pleasure of presenting at the University of Wisconsin's Lockdown 2012 Security Conference (http://www.cio.wisc.edu/lockdown-2012-presentations.aspx).  It was a great conference and I had interesting conversations with attendees and the other speakers.  Though small, year after year, the conference is able to attract important speakers who also present at Blackhat and RSA, so I encourage folks to check it out next year.

My presentation was titled "Detection is the New Prevention" and closely mirrored an earlier blog post of the same title.  The slide deck contains a lot of ELSA screenshots showing how ELSA and Big Data are critical when preventative measures fail.  Of particular note, I walk through some advanced ELSA features including how to setup local databases to leverage org-specific data in analytics.  I also walk through the basics of performing correlated searches in ELSA.

You can find the slides here: https://docs.google.com/open?id=0By1KXg1ivlIeN18yOWZ6a1dGTFk

You can also find slides from my YAPC:NA (Perl programmer's conference) which detail the inner-workings and design of ELSA here:  https://docs.google.com/open?id=0By1KXg1ivlIeQW1uYTZzV2FMX1E

Deobfuscating XOR Executables

Several exploit kits are going to great lengths to obfuscate distributed binaries with a simple XOR key to evade network-based anti-virus and IDS.  This is a highly effective technique because it significantly burdens researchers and evades most signature-based detection.  At the very least, it creates trivial but annoying hurdles for analysis because an extra deobfuscation step must be made before putting a sample through the normal testing cycles in sandboxes, VirusTotal.com, etc.

As of tonight, StreamDB will now attempt to deobfuscate any streams it finds that have HTTP objects which contain unknown types of data using a couple of different algorithms.  It will display the still-obfuscated executable, but change the description to add "XOR obfuscated."  However, when extracting the file by object ID (streamdb/?oid=<oid>), as done when grabbing a file to submit to a sandbox or VirusTotal, it will return the deobfuscated version.

So, a file that normally would look like this:

0000000: 2f9f 9425 62c5 c425 2d9f 9425 2b9f 9b25  /..%b..%-..%+..%
0000010: d060 9425 979f 9425 2f9f 9425 6f9f 8e25  .`.%...%/..%o..%
0000020: 2f9f 9425 2f9f 9425 2f9f 9425 2f9f 9425  /..%/..%/..%/..%
0000030: 2f9f 9425 2f9f 9425 2f9f 9425 2f9f 9425  /..%/..%/..%/..%
0000040: 2f9e 9425 958f 942b 302b 9de8 0e27 9569  /..%...+0+...'.i
0000050: e2be 04b5 7bf7 fd56 0fef e64a 48ed f548  ....{..V...JH..H
0000060: 0ff2 e156 5bbf f640 0fed e14b 0fea fa41  ...V[..@...K...A
0000070: 4aed b472 46f1 a717 2295 b012 2f9f 9425  J..rF...".../..%
0000080: 2f9f 9425 2f9f 9425 2f9f 9425 2f9f 9425  /..%/..%/..%/..%
0000090: 2f9f 9425 2f9f 9425 2f9f 9425 2f9f 9425  /..%/..%/..%/..%
00000a0: 2f9f 9425 2f9f 9425 2f9f 9425 2f9f 9425  /..%/..%/..%/..%
00000b0: 2f9f 9425 2f9f 9425 2f9f 9425 2f9f 9425  /..%/..%/..%/..%
00000c0: 2f9f 9425 2f9f 9425 2f9f 9425 2f9f 9425  /..%/..%/..%/..%
00000d0: 2f9f 9425 2f9f 9425 2f9f 9425 2f9f 9425  /..%/..%/..%/..%
00000e0: 2f9f 9425 2f9f 9425 2f9f 9425 2f9f 9425  /..%/..%/..%/..%
00000f0: 2f9f 9425 2f9f 9425 2f9f 9425 2f9f 9425  /..%/..%/..%/..%

Will be correctly downloaded to look like this:

0000000: 4d5a 5000 0200 0000 0400 0f00 ffff 0000  MZP.............
0000010: b800 0000 0000 0000 4000 1a00 0000 0000  ........@.......
0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000030: 0000 0000 0000 0000 0000 0000 0001 0000  ................
0000040: ba10 000e 1fb4 09cd 21b8 014c cd21 9090  ........!..L.!..
0000050: 5468 6973 2070 726f 6772 616d 206d 7573  This program mus
0000060: 7420 6265 2072 756e 2075 6e64 6572 2057  t be run under W
0000070: 696e 3332 0d0a 2437 0000 0000 0000 0000  in32..$7........
0000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000100: 5045 0000 4c01 0300 195e 422a 0000 0000  PE..L....^B*....

Additionally, there is an experimental feature for auto-submission to VirusTotal.com if you configure the API key in the streamdb.conf file and download the Perl API for VirusTotal.  There is also an example of submitting the code to an internal sandbox, like CuckooBox.org via your own custom submission page.  To submit a sample, add submit=executable (or any type of file) to the StreamDB query.

Detection is the New Prevention

Like most large orgs, over the past few months, we've been dealing with many phishing campaigns which spread from infected webmail accounts, scrape the contact list, and propagate their phishing payload.  The catch is that when the spam comes from whitelisted orgs, the phishing all gets delivered because the spam filters either completely whitelist or are less guarded against mail coming from the authenticated mail servers of large orgs.  As a result, there is a higher success rate right now because so many legitimate accounts are compromised in so many orgs across the globe right now.

After a few painful incidents in which it took days to clean all of the infected accounts, I'm pleased to say we've honed our incident response plan for this scenario to the point where it is very effective:

Prevention
Our user awareness training teaches that any suspicious emails are to be reported immediately as phishing instead of normal spam.  The recent incidents have kept this in the forefront of our users' minds.  In the future, we may begin using testing services or our own SP Toolkit instance to simulate phishing campaigns.

Detection
Our users became our initial detection mechanisms.  With the spam gateways letting lots of phishing messages through and with phishing subject lines that are too varied to filter manually, the last line of defense and chance for detection is the user.

Containment
We streamlined and formalized our procedures for mass phishing scenarios.  Our staff in key roles knew ahead of time exactly what to do and when.  Specifically:

1. Lock an account
2. Force a logout
3. Purge all email boxes of a specific subject line
4. Monitor for successful phishes
5. Block related on IP's and web sites

Monitoring for successful phishes is where ELSA comes in.  With ELSA logging URL's, we were able to take a given phishing email and monitor for any access to the phishing URL's.  StreamDB would then be used to pull out the POST data to show exactly which user submitted credentials to the phishing site so that containment procedures could be followed.

However, ELSA gives us the ability to go deeper than that and use generalizations from the phishing campaigns our users notice to find phishing that has gone unreported.

Fishing for Phishing with ELSA
In our case, a user reported a phishing email which had a URL of:

hxxp://www.pirini-trade .hr/narudzba/use/web/form1.html

My staff searched ELSA for:

site:www.pirini-trade.hr

No hits, so that particular email failed in its phishing attempt.  However, what if other phishing emails went out with a similar format?  Let's try some other searches:

uri:narudzba

Nope.

uri:"use/web/form1.html"

Nope.
How about this?

+method:POST +uri:use +uri:form1.html

Nope.
Just this:

+uri:use +uri:form1.html

Ok, now we've got some very interesting hits, but no POST's:
GET www.charlesgorley.ca /form/use/Text/form1.html
That looks very similar, but did anyone post data?

+method:POST +site:www.charlesgorley.ca

Hit!

POST www.charlesgorley.ca /form/use/Text/process.php

So, we can use this for our query:

+method:POST +uri:use +referer:form1.html

Set it to alert, and now we've got some decent coverage for variants of this campaign.  If it continues, writing this into a Suricata alert may even be a good idea.  In the meantime, we initiate our incident response plan for this user account.

Detection as Prevention
So, this is great, but how is this prevention as the account was already compromised?  In the case of this example, the POST we found was two days ago.  The key concept to understand is that even though the credentials are compromised, they are not used immediately.  In fact, we have noticed an average turnaround of six days between account compromise and account misuse.  The criminals harvesting the credentials have staff, code, and infrastructure to maintain just like the good guys, so all but the very best lack automation when it comes to actually utilizing the accounts for further phishing.  In fact, our experience has shown an organizational structure much more akin to sweatshop labor than elaborate and sophisticated technology.  Specifically, it is more economical for the criminals to pay low-wage workers to perform the mundane tasks of exploiting compromised accounts to send spam than it is to write scripts to do it.

How do we know this?  The attackers in our previous phishing attacks have all been from a few distinct geographic locations (Spain, France, and Nigeria) and have a distinct operational signature.  They use a browser plugin called "Crazy Browser" which allows a basic Internet Explorer instance to have multiple sub-windows open at the same time in one IE window.  The most likely reason to do this is for easy copy-and-paste between their personal email from which they receive orders from their criminal boss and the various webmail accounts they're logged into for the purposes of spamming.  The point is, if you need a lot of browser windows open, then you're obviously not doing a lot of scripting, and there is most certainly a human involved in the account use.

So, why is this important in shaping our IR plan?  It means that if we know it will be several days between account compromise and account misuse, we can lock down the account before it is misused with sufficiently fast detection.  Yes, the initial prevention via spam filter failed, and the phishtank.com coverage did not show up until a day after the phish was delivered, but from a business perspective, we were able to detect the compromise in time to prevent it from becoming a problem for the business.  ELSA enhances our detection abilities by letting us retroactively investigate phishes based on new leads.

I'm not the first to suggest that detection is the new prevention, but I think it's important to use examples to show how the two are intertwined, and what that means for the business.  Specifically, it means that visibility and analytics are more valuable than (or at least necessary alongside) traditional preventative measures, and we as security professionals need to arm our orgs with the tactical resources to provide these capabilities.

Picking Up the Pieces

(When AV Fails)

Managing alerts with ELSA makes it easy to unobtrusively monitor for events that aren't necessarily noteworthy in and of themselves.  One such alert I have is for Symantec Anti-virus alerts, which get logged to the Windows eventlog as event ID 51.  Using eventlog-to-syslog, all of our Windows event logs are forwarded to ELSA.  We regularly see cases in which Symantec logs an alert to the local Windows event log but fails to forward the event to the Symantec management server.  This lets us see the alerts that fall through the cracks.  So, using the search:

eventid:51 program:symantec_antivirus

I get an event back that looks like this:

51: Security Risk Found!Trojan Horse in File: E:\Profile\<user name redacted>\Application Data\BE6CCC87FECC\prf275.tmp by: Auto-Protect scan. Action: Quarantine succeeded : Access denied. Action Description: The file was quarantined successfully.

This log was sent by a network file server, not the client desktop.  By the looks of things, AV did its job and this host is fine.  Just to be sure, I wanted a closer look.  Taking the name of the user from the profile directory, I did a follow-up ELSA search for just the user's name:

<user name redacted>

Which returned the domain controller log showing me which workstation they were logged in from at the time:

672: NT AUTHORITY\SYSTEM: Authentication Ticket Request: User Name: <user name redacted> Supplied Realm Name: <redacted> User ID: %{S-1-5-21-3772051035-1815270206-2219246618-5753} Service Name: krbtgt Service ID: %{S-1-5-21-3772051035-1815270206-2219246618-502} Ticket Options: 0x40810010 Result Code: - Ticket Encryption Type: 0x17 Pre-Authentication Type: 2 Client Address: 10.102.210.89 Certificate Issuer Name: Certificate Serial Number: Certificate Thumbprint:

This told me the user was at IP 10.102.210.89.  I wanted to see what IDS alerts we got during that time, so I searched for:

10.102.210.89 class:snort

and got:

[1:2014170:2] ET POLICY HTTP Request to .su TLD (Soviet Union) Often Malware Related [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 10.102.210.89:2676 -> 78.159.112.131:80

Which is suspicious.  However, we've seen plenty of legitimate sites using .su domains, so this in and of itself doesn't prove anything.  Again, we need to investigate further:

10.102.210.89 class:url

shows:

10.102.210.89|78.159.112.131|GET|imagedumper.su|/imagedump/image.php?size=0&imageid=0&resize=0&data=&thumbnail=1|-|B7B2BAC0C0C0A4ABA3C2C09F92908A9185A8C6C6C1C4C7DEC5C7C3DEAE8FC2C6C0C4\\0\\AK-81|,su,imagedumper.su|200|22528|6869

This looks even more suspicious, but still isn't enough to confirm a compromise.  What else was the host up to?  I wanted to see a list of every site they went to within a minute or so:

10.102.210.89 class:url groupby:site

This returned a list of about a hundred sites, including some very suspicious looking site names:

75686f68.kz

626f6f686f6f.ws

Something is definitely up.  So, what was the content returned by the request to imagedumper.su?  I use the StreamDB plugin to quickly pull the packet content, which shows that this was actually an executable download:

Returning 4 of 2 at offset 0 from Fri Mar  2 07:51:51 2012 to Fri Mar  2 07:51:51 2012 (92 ms)

2012-03-02 07:51:51 10.102.210.89:3812 <- 78.159.112.131:80 5s 22968 bytes Time cutoff

GET imagedumper.su/imagedump/image.php?size=0&imageid=0&resize=0&data=&thumbnail=1

oid=18043-3966842627-452-0

GET /imagedump/image.php?size=0&imageid=0&resize=0&data=&thumbnail=1
Cache-Control: no-cache
Host: imagedumper.su
User-Agent: B7B2BAC0C0C0A4ABA3C2C09F92908A9185A8C6C6C1C4C7DEC5C7C3DEAE8FC2C6C0C4|0|AK-81
X-HTTP-Version: 1.1



200 MS-DOS executable PE  for MS Windows (GUI) Intel 80386 32-bit, UPX compressed

oid=18043-3966843079-22968-0

200 OK
Date: Fri, 02 Mar 2012 16:04:33 GMT
Retry-After: 61867
Server: Apache/2.2.16 (Debian)
Content-Length: 22528
Content-Type: text/html
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-HTTP-Version: 1.1
X-Powered-By: PHP/5.3.3-7+squeeze7

MZ......................@.............................................    .!..L.!This program cannot be run in DOS mode.

$...........A...A...A...8...@.......@...RichA...........PE..L......C.....

So, I extract the executable using the object ID: streamdb/?oid=18043-3966843079-22968-0 and save that to my analysis machine.  I then upload it to the malwr.com online sandbox:

http://malwr.com/analysis/00b714468f1bc2254559dd8fd84186f1/

This shows me that the file should make a DNS request to 1051811156619.com.  Did this happen?  A quick ELSA search through Bro DNS logs confirms that it did:

1051811156619.com

shows:

1330696345.046917|2NMPpT5BTo|<DNS server redacted>|28707|209.236.76.107|53|udp|52601|1051811156619.com|1|C_INTERNET|1|A|0|NOERROR|F|T|F|F|F|0|207.112.46.80|3600.000000

So, our host did in fact execute the binary and make the DNS lookup, despite the Symantec log indicating that it was quarantined!  What did our host do with the answer it got?  Another ELSA search for the DNS answer IP:

207.112.46.80

shows:

Deny tcp src inside:10.102.210.89/3820 dst OUTSIDE:207.112.46.80/20001 by access-group "CSM_FW_ACL_inside" [0xfeb273c6, 0x0]

So, our strict outbound firewall policy is denying our host from connecting to this IP on a weird port.  The host is definitely compromised, but the command-and-control (C2) channel is being blocked.  Based on this, I decide that we need to have an IDS signature for this.  The question is, was the imagedumper.su web request a check-in or was it just a loader?  A quick ELSA query

+uri:"/imagedump/image.php"

shows that there haven't been any other requests to any other sites using that URI and the host makes this request regularly, so this is a good one for a sig.  As a result, I submitted the following to Emerging Threats:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Win32/Kryptik.ABUD Checkin"; flow:established,to_server; content:"/imagedump/image.php"; http_uri; reference:url,http://malwr.com/analysis/00b714468f1bc2254559dd8fd84186f1/; classtype:trojan-activity; sid:x; rev:1;)

So, what appeared to be a simple case of AV quarantining a virus proved to be an indicator of a full compromise which has been going on for days.  Performing this kind of investigation without ELSA and StreamDB is certainly possible, but I guarantee it would've taken longer than the five minutes it took me, beginning to end.  In total, the following information was needed:

• AV console logs/alerts from file server
• Windows logs from AD controller
• IDS logs
• URL logs
• DNS logs
• Full packet capture

If any one of these information sources had been missing, then we would not be able to confirm a compromise.  This just goes to show how complicated the security landscape is getting, and how much effort it takes to get it right.

Hunting with ELSA Transforms

One of the talks at the Bro Workshop 2011 showed all of the amazing things you can do with Bro logs when manipulating them in Splunk by changing the content of the fields displayed. This reminded me that I've been planning on adding transforms to ELSA for some time, and I've finally got the first working version available!

Transforms

Transforms are post-search display filters that data is passed through to modify what is shown the user. For ELSA, this means that when the search engine is finished with its normal search, it will pass the list of results to a chain of filters strung together with pipes which can add fields or filter results. Currently, ELSA ships with the following transforms which add fields:

• Whois
• DNSDB (via account with dnsdb.isc.org)
• CIF (via local instance of Collective-Intelligence-Framework.googlecode.com)

and the following utility transforms:

• grep
• filter
• sum

Below is an example of a simple search which has Whois data added to each entry:

The query is a standard ELSA query, but using the pipe character (“|”) it is possible to send the results through the “whois” transform, which will add fields like country code “cc” and description “descr.” This can be crucial for analysts as they investigate because it saves them having to lookup IP addresses individually. As with everything in ELSA, the goal is to make delivering data as quick and effortless as possible to encourage investigation above and beyond typical searches. This makes for great hunting.

Hunting++

One easy way to start looking for anomalies in your IDS logs is to match up otherwise innocuous or “policy” signatures with anomalous locations or networks. In the screenshot below, you can see a search for executables downloaded from country code “ua” (Ukraine).

Using the info plugin (by clicking the link next to the log entry) shows the StreamDB output

in which you can clearly see that this is a download of “info.exe” caused by a Blackhole Exploit Kit due to the tell-tale “w.php?f=16&e=0” (which indicates that is is an update to an already-infected machine).

Setting Up Transforms

By default, whois will work with the default dummy configuration which declares local RFC1918 space as “MyOrg” as specified by your “known_orgs” entry in the elsa_web.conf under “transforms/whois.” The local IP will have the “customer” field added, which is specified by the “known_subnets” entry. ELSA ships with examples included, so you should only have to edit what already exists.

If you're upgrading ELSA, you may need to add a Perl module for faster result caching, as described below. To add it, run “sudo cpanm CHI::Driver::DBI” or ELSA will use memory-only caching, which will not persist across Apache restarts. This module is included in the install.sh.

Using Transforms

The main caveat to transforms is that you cannot search solely based on them. That's because they are applied after searches are finished, and can only be used to display additional information. This also means that the transforms are only applied to the number of results being returned. You may need to increase the number of results using the “limit” keyword to have the transforms applied to up to 1000 results. As an example, if you wanted to find all downloads with IP addresses related to Google, you would do this:

+sig_msg:exe limit:1000 | whois | grep(descr,google)

The main search is for 1000 alerts with “exe” in the message, which then has the whois fields added (cc, description, org), and then only records with a description matching “google” are returned. The grep and filter transforms are case-insensitive regular expressions on both the field name and the field value. If you want to search all fields for a given value, you can use the dot “.” instead of a field name, like this:

+sig_msg:exe limit:1000 | whois | grep(.,google)

All transform information is cached in the database to speed up result times. Generally, whois lookups are quite fast, but not nearly as fast as ELSA results usually are. However, if you run a search with a transform and then run it again with a different grep, filter, or sum, it should return almost instantly because it is using cached data.

Other Transforms

ELSA also ships with the dnsdb and cif transforms in addition to the whois transform. In order to use the dnsdb transform, you will need a working API key from ISC, which is free to non-profits. Contact them at dnsdb.isc.org for additional details. Below is a screenshot of what it looks like when you add on the passive DNS hosts to your search by passing the results through dnsdb:

It's verbose, but in combination with grep or filter, it can be very helpful.

The cif transform hooks into a local instance of the Collective Intelligence Framework which applies blacklist information as well as whois info to your results. Here's another hunting trip, this time looking for any IP's listed as type “malicious” from which there were downloads:

To use the CIF transform, you'll either need a local instance setup (highly recommended!) or a friendly org that is willing to give you an API key to their instance. In either case, edit the elsa_web.conf file to add the server name, IP, and apikey under “transforms/cif.”

Adding Transforms

Creating your own transforms is not entirely trivial, but isn't too hard. Take a look at the current ones in the web/lib/Transform directory, and with a lot of copy and paste, you should be able to hack your own together. If you get stuck, please drop us a note on the mailing list (http://groups.google.com/group/enterprise-log-search-and-archive).

Lizamoon: Knowing is Half the Battle

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:
site:lizamoon.com

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:
site:lizamoon.com content_length>=1

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 ->; 95.64.9.18:80 0s 594 bytes RST GET lizamoon.com/ur.php
oid=12447-2986004740-594-0
GET /ur.php
Connection: Keep-Alive Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Host: lizamoon.com
Referer: http://www.designbasics.com/search/cdl_template/cdl-photo.asp?sPlanNo=24059&Exposure=33a-400&Path=http://www.designbasics.com/designs/24000/&ViewType=UPPER&IsPhoto=False&lPath=http://www.designbasics.com/designs/24000/&HomeTour=False&PlanName=Chatham&SquareFeet=1593&MaxWidth=&MaxDepth=
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 <- 95.64.9.18:80 0s 975 bytes RST 200 ASCII text, with very long lines, with no line terminators
oid=12447-2986005334-975-0
200 OK
Connection: Keep-Alive
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
Content-Length: 650
Content-Type: text/html
Keep-Alive: timeout=5, max=100 Set-Cookie: click888=1; expires=Wed, 27-Apr-2011 22:56:18 GMT
X-HTTP-Version: 1.1
X-Powered-By: PHP/5.3.3
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:
site:defender-nrpr.in
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:
site:lizamoon.com groupby:referer

This shows us the top unique page URI's that are linking to the malicious site. What IP addresses are serving lizamoon.com? ELSA:
site:lizamoon.com groupby:dstip
Who went there?
site:lizamoon.com groupby:srcip

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.