Analyzing an intrusion Part I - Establish Time-0

Recently I described a technique used by real world investigators to determine Time of Death for victims and how it could possibly be applied to digital investigations. I'd like to take some time to detail a recent compromise of one of my honeypots and take what may be viewed by some as theory, and put it in to practice.

Just when I thought all was quiet, someone decided to set off just about every alarm I had while using the recent RPC based DNS vulnerability as an attack vector. In addition to the sources of evidence I am searching through, I believe I have found an obscure technique used by attackers to hide their actions. I can't say whether this is a new technique or not, but I've never seen it attempted until now.

Let's start with what I know based on Environmental sources of evidence.

On Sunday Apr 22, 2007, I began receiving alerts from the honeynet indicating an incredibly sloppy port scan. I'll add some commentary in italics to this as I go on.

[**] [122:1:0] (portscan) TCP Portscan [**]
04/22-22:09:22.512490 198.64.140.203 -> 10.10.62.102
PROTO255 TTL:0 TOS:0x0 ID:61227 IpLen:20 DgmLen:160

Like most people, I thought "yeah big deal another port scan", but then again, this has been a dormant honeynet until now.

This is what NIST likes to call a precursor. If you've read their SP-800 docs on incident response, you'll understand. While precursors are commonly ignored, they should be filed away in the back of the incident responder or investigator's mind. In addition to this being a precursor, it's also the Reconnaisance phase of an attack cycle.

Again, recall what I learned in the Hacking By Numbers course - Speed vs stealth is the name of the game today.
Starting at Port 1 the attacker scanned every port on my Windows Server 2003 SP1 honeypot. This scan lasted all the way up until it reached tcp port 3439.

What was the objective for the scan? If you've read anything about the vulnerablity and subsequent exploits surrounding it, the typical attack will scan in search of the port that RPC interface for DNS is listening on so it can communicate with the DNS service. This is what allows SA's to use the MMC from another computer to access dnsmgmt.msc.

In this case RPC was listening on tcp port 1040, one of those ephemeral "magic ports".

Luckily, the bleeding snort rules caught this event.

[**] [1:2003592:1] BLEEDING-EDGE CURRENT EVENTS Vulnerable DNS RPC Bind [**]
[Priority: 0]
04/22-22:09:39.106014 198.64.140.203:4312 -> 10.10.62.102:1040
TCP TTL:113 TOS:0x0 ID:16339 IpLen:20 DgmLen:684 DF
***AP*** Seq: 0x5EBD95C1 Ack: 0xB000C175 Win: 0x4470 TcpLen: 20
[Xref => http://doc.bleedingthreats.net/bin/view/Main/MSRpcDns]

[**] [1:2003587:4] BLEEDING-EDGE CURRENT EVENTS MS DNS DCE-RPC Temporary Rule - Possible Attack [**]
[Classification: Attempted Administrator Privilege Gain] [Priority: 1]
04/22-22:09:39.106014 198.64.140.203:4312 -> 10.10.62.102:1040
TCP TTL:113 TOS:0x0 ID:16339 IpLen:20 DgmLen:684 DF
***AP*** Seq: 0x5EBD95C1 Ack: 0xB000C175 Win: 0x4470 TcpLen: 20
[Xref => http://isc.sans.org/diary.html?storyid=2627][Xref => http://erratasec.blogspot.com/2007/04/news-from-microsoft-dns-0day-being.html]


Now that we have some background information we can work on establishing Time-0.

According to the honeywall The scan began at 22:09:22 GMT. Port 1040 was re-visited at 22:09:39 GMT and the Shellcode was delivered through an RPC packet containing a bind request to get access to the following UUID: 50abc2a4-574d-40b3-9d66-ee4fd5fba076. This UUID just happens to be the DNS server. Once the exploit is is delivered, a reverse shell is opened. The final FIN sequence after the delivery of the exploit was at 22:09:51 GMT.

The attacker went from Recon to successful exploitation in 29 seconds!

Unfortunately, one source of evidence isn't enough. We need to be able to corroborate what was captured. Some folks upstream provided me with some data from their anomaly detection system. You'll notice a slight time skew between the two sources.

Sun Apr 22 18:09:42 2007 (local time)
198.64.140.203:4312<--TCP-->10.10.62.102:1040
................................;.$\.................]..........+.H`..........(.X
........t............m....1040...................................................

Now, it's a little confusing because the anomaly detection system decides what part of a packet to capture with it's own AI, but we can look at the content of the TCP stream of this flow to find out where it get's the information from.

This is the content of the bind request of the attacker. The honeywall picked it up at 22:09:39 GMT.
................................;.$\.................]..........+.H`..........(..
........t............m....1040...................................................


Looks pretty close doesn't it? The X in the packet from the anomaly detection system seems to be some form of marker or delimeter because it doesn't exist in the full capture I have. I'll be confirming this with the data providers.

Based on the Environmental evidence presented here and the corroborated data from the anomaly detection system we can establish Time-0 as falling between 22:09:39 GMT and 22:09:51 GMT.

As of now, I'm waiting for some netflow logs to be sent to me for further corroboration of the evidence.