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
