I recently got a little funding for my honeynet and bought some new hardware for it. The major additions was some 3ware equipment, new processor and motherboard and lots of hard drives. I put 8 500GB sata II seagate ES drives in the box and a 3ware 9650SE as the raid controller. I finally made the move to vmware as my honeynet platform - expanding the honeynet from 5 to 20 machines. I'm currently building up a new website for it and adding some services to be exploited. I also moved away from the the honeynet project's roo cdrom - it just wasn't cutting it anymore. Snort 2.3 is way too outdated.
I re-used my old honeywall hardware and loaded fedora core 8 on the box and I loaded snort and snort running in inline mode, argus, tcpdump, swatch, sebek-server and some other goodies. The iptables configuration was created using fwbuilder.
So ultimately the honeynet is now a hybrid with a physical box for the honeywall and vmware based honeypots. I'm somewhat excited and hopeful that people will attack it, but I guess time will tell.
I'd like to add some automation to the activities on the honeypots using autohotkey or autoit and robotask.
I was pretty shocked to find that one of my hosts was almost immediately getting dinged with sasser.b - yeah I said sasser. I'm also getting some potshots taken at the nepenthes collector. Just yesterday I picked up a binary named msnnmaneger.exe (an sdbot variant).
Sunday, December 30, 2007
Wednesday, December 19, 2007
Tool Marks
I was reading a paper on tool marks and trace evidence and started thinking of how that translates to digital forensics. The connection is actually obvious.
From the paper: "The use and application of a variety of tools is commonplace during the commission of various criminal acts. By their very nature, the use of tools typically involves the application of relatively large amounts of force to gain a mechanical advantage in performing a work related task."
As we are well aware this is where Locard's name gets thrown in and everyone says "Ahh, transfer evidence".
In the digital realm we experience much the same thing. When an intrusion occurs, a variety of tools are used to exert a rather large amount of force (exploit, brute force, other means of gaining access) in attempt to gain access to the victim. We commonly recover these tools on investigation, but in order to reconstruct the incident we need to be able to determine how they were used during the attack, Their purpose and that the attacker did in fact use them. This is where tool marks come in to play.
The execution of a tool will leave a mark on a system, just as using a tool to gain entry will leave striations or other markings. With luck we might have a cross transfer - that is when the tool leaves a mark and parts of the object are transferred to the tool.
Here's an example:
Let's look at a hackerdefender attack that's been in process for a while. The attacker gained access to an exposed system by exploiting a vulnerability. The attacker downloads a toolkit on to the system consisting of smbscan, pwdump, and a few other tools. The attacker proceeds to offload the SAM, crack the admin password, then smbscans the network and installs rootkits all over the place.
As a tool leaves a mark on the surface it touches, the digital tool will hopefully provide us with tool marks and other transfer.
There are 4 major tool mark categories:
Striated - This is when two objects effectively scrape each other and the tool leaves a mark on the opposing object or vice versa. This is typically seen as lines from the marks - think pliers... The harder object will leave the mark on the softer object.
Impressed - The harder tool will leave an impression of itself on the softer object.
Crush or cut marks - When a tool exerts force on both sides of the object and crushes or cuts it. Imagine bolt cutters...
multi stroke - a tool used in a repetitive movement will leave multi stroke marks.
Time to bring this in to the digital realm...
Striated tool markings obviously can't exist or do they? Just as a tool has a "signature" it leaves on a softer material, a digital tool will leave markings on the victim. Refer back to the HXDEF example. The tool used to gain entry to patient zero will have left tool markings on the system and the network. Polymorphic code aside, the tool as used by the attacker will leave trace & transfer on the network. On the system you can expect to find a wealth of trace & transfer. A digital tool mark isn't about hardness however, it's about the effect it has on the system. Hacker defender has a definitive stria. It has an ini file, and many customizations can be made by the tool "manufacturer". Consider this tool striation and just as it happens in the real world the striations are unique because of tool usage and "manufacturing". You can see many of these unique striations on the network as well as the host.
Tool impressions - A physical tool will leave an impression if it's pressed in to a softer material. The digital tool will leave impressions of itself on a victim as it's buried in the system. The files in the toolkit that was downloaded by the attacker leaves an impression of themselves on the filesystem. These can be collected and analyzed.
Crush or cut marks are a bit tougher to identify in a digital realm.
Multi-stroke tools would be a saw, or any tool that it used in a repetitive motion to gain entry. Let's use the example above. SMBscan would be an example of a multi stroke tool. It uses a repetitive motion to gain entry to systems. It will leave marks of a definitive pattern.
So what's the big deal? Well if we start to look at tool marks we can begin to classify things a bit better and respond more efficiently. Tool marks are important to reconstruction and investigation. Tool marks can be broken in to class characteristics and individual characteristics. These start to become important as does the predictive nature of any assumptive hypothesis we can derive. Many of us do this already. When you see a hxdef.ini on a system, and there's an odd port open, you may inherently assume "uhoh weve got a hacker defender intrusion". This can be right or wrong. If you've developed a tool mark library you can refer to it during your investigations. Developing a tool mark library consisting of class and individual characteristics can assist any investigation by adding predictive power to your assumptive hypotheses.
EDIT 12/20/07 - The paper was: The Synergistic Nature of Trace Evidence and Tool Mark Examinations by Vincent J. Desiderio and George W. Chin
From the paper: "The use and application of a variety of tools is commonplace during the commission of various criminal acts. By their very nature, the use of tools typically involves the application of relatively large amounts of force to gain a mechanical advantage in performing a work related task."
As we are well aware this is where Locard's name gets thrown in and everyone says "Ahh, transfer evidence".
In the digital realm we experience much the same thing. When an intrusion occurs, a variety of tools are used to exert a rather large amount of force (exploit, brute force, other means of gaining access) in attempt to gain access to the victim. We commonly recover these tools on investigation, but in order to reconstruct the incident we need to be able to determine how they were used during the attack, Their purpose and that the attacker did in fact use them. This is where tool marks come in to play.
The execution of a tool will leave a mark on a system, just as using a tool to gain entry will leave striations or other markings. With luck we might have a cross transfer - that is when the tool leaves a mark and parts of the object are transferred to the tool.
Here's an example:
Let's look at a hackerdefender attack that's been in process for a while. The attacker gained access to an exposed system by exploiting a vulnerability. The attacker downloads a toolkit on to the system consisting of smbscan, pwdump, and a few other tools. The attacker proceeds to offload the SAM, crack the admin password, then smbscans the network and installs rootkits all over the place.
As a tool leaves a mark on the surface it touches, the digital tool will hopefully provide us with tool marks and other transfer.
There are 4 major tool mark categories:
Striated - This is when two objects effectively scrape each other and the tool leaves a mark on the opposing object or vice versa. This is typically seen as lines from the marks - think pliers... The harder object will leave the mark on the softer object.
Impressed - The harder tool will leave an impression of itself on the softer object.
Crush or cut marks - When a tool exerts force on both sides of the object and crushes or cuts it. Imagine bolt cutters...
multi stroke - a tool used in a repetitive movement will leave multi stroke marks.
Time to bring this in to the digital realm...
Striated tool markings obviously can't exist or do they? Just as a tool has a "signature" it leaves on a softer material, a digital tool will leave markings on the victim. Refer back to the HXDEF example. The tool used to gain entry to patient zero will have left tool markings on the system and the network. Polymorphic code aside, the tool as used by the attacker will leave trace & transfer on the network. On the system you can expect to find a wealth of trace & transfer. A digital tool mark isn't about hardness however, it's about the effect it has on the system. Hacker defender has a definitive stria. It has an ini file, and many customizations can be made by the tool "manufacturer". Consider this tool striation and just as it happens in the real world the striations are unique because of tool usage and "manufacturing". You can see many of these unique striations on the network as well as the host.
Tool impressions - A physical tool will leave an impression if it's pressed in to a softer material. The digital tool will leave impressions of itself on a victim as it's buried in the system. The files in the toolkit that was downloaded by the attacker leaves an impression of themselves on the filesystem. These can be collected and analyzed.
Crush or cut marks are a bit tougher to identify in a digital realm.
Multi-stroke tools would be a saw, or any tool that it used in a repetitive motion to gain entry. Let's use the example above. SMBscan would be an example of a multi stroke tool. It uses a repetitive motion to gain entry to systems. It will leave marks of a definitive pattern.
So what's the big deal? Well if we start to look at tool marks we can begin to classify things a bit better and respond more efficiently. Tool marks are important to reconstruction and investigation. Tool marks can be broken in to class characteristics and individual characteristics. These start to become important as does the predictive nature of any assumptive hypothesis we can derive. Many of us do this already. When you see a hxdef.ini on a system, and there's an odd port open, you may inherently assume "uhoh weve got a hacker defender intrusion". This can be right or wrong. If you've developed a tool mark library you can refer to it during your investigations. Developing a tool mark library consisting of class and individual characteristics can assist any investigation by adding predictive power to your assumptive hypotheses.
EDIT 12/20/07 - The paper was: The Synergistic Nature of Trace Evidence and Tool Mark Examinations by Vincent J. Desiderio and George W. Chin
Thursday, December 13, 2007
Can't take that host down?
How many times has this happened to you? You are called in to respond and you just can't take a system down? We all know about live response at this point. There are plenty of vendors out there that sell software, and there are plenty of open source tools.
What's another major component of live response? How about the network? If you can't take the system down you need as much real time data as possible to come to any form of conclusion.
Enter the Teeny Tap.
Here's mine in the box:
This is probably one of my most favorite devices and most worthwhile addition to my jump kit after the essentials. I've used mine in a number of incidents. So how exactly do you use the teeny tap in an incident?
I'd start by saying it depends. Are you responding to one host or looking at an entire network? Let's look at a single host for starters. You've arrived on scene, conducted your initial interviews, have your initial threat assessment complete and have identified the host.
How to proceed from here:
Follow your standard practices (photograph in-situ, identify peripherals etc.)
Locate the network cable from the host.
Locate an electrical outlet.
Unpack your tap.
Connect power and cables to the tap.
Connect monitoring sensor to the correct cables and power it up.
Log in to your sensor and start your collection software (tcpdump, wireshark, snort, argus etc). I tend to use argus and tcpdump and then I post process with a number of tools.
Now for the important step. Connect the host to the tap and the tap to the other end point(could be the wall jack, a switch, a cable modem).
Now you are monitoring the network connections to/from the host and you can begin your live response.
When tapping in to a network follow the same steps as above, but you should change your insertion point to the perimeter. Depending on the situation, you may want to just tap the perimeter, but be aware that this may not capture internal host-host communications.
When you're done collecting data, stop your collection software, save the file and hash it. Never work from this file. This file is to be treated as your original and you should only work from exact copies of it. If you're transmitting live response data over the network be sure to identify your host and your data streams so as to prevent any claims of contamination.
A few gotchas:
You'll probably want to bond interfaces on the monitoring sensor. If you don't then you'll need to set your monitoring software to have a few instances (one per NIC) and you'll have to combine the streams after the fact.
Make sure your cabling is correct.
I'll probably add some more documentation to this at another point...
Thoughts?
What's another major component of live response? How about the network? If you can't take the system down you need as much real time data as possible to come to any form of conclusion.
Enter the Teeny Tap.
Here's mine in the box:
This is probably one of my most favorite devices and most worthwhile addition to my jump kit after the essentials. I've used mine in a number of incidents. So how exactly do you use the teeny tap in an incident?
I'd start by saying it depends. Are you responding to one host or looking at an entire network? Let's look at a single host for starters. You've arrived on scene, conducted your initial interviews, have your initial threat assessment complete and have identified the host.
How to proceed from here:
Follow your standard practices (photograph in-situ, identify peripherals etc.)
Locate the network cable from the host.
Locate an electrical outlet.
Unpack your tap.
Connect power and cables to the tap.
Connect monitoring sensor to the correct cables and power it up.
Log in to your sensor and start your collection software (tcpdump, wireshark, snort, argus etc). I tend to use argus and tcpdump and then I post process with a number of tools.
Now for the important step. Connect the host to the tap and the tap to the other end point(could be the wall jack, a switch, a cable modem).
Now you are monitoring the network connections to/from the host and you can begin your live response.
When tapping in to a network follow the same steps as above, but you should change your insertion point to the perimeter. Depending on the situation, you may want to just tap the perimeter, but be aware that this may not capture internal host-host communications.
When you're done collecting data, stop your collection software, save the file and hash it. Never work from this file. This file is to be treated as your original and you should only work from exact copies of it. If you're transmitting live response data over the network be sure to identify your host and your data streams so as to prevent any claims of contamination.
A few gotchas:
You'll probably want to bond interfaces on the monitoring sensor. If you don't then you'll need to set your monitoring software to have a few instances (one per NIC) and you'll have to combine the streams after the fact.
Make sure your cabling is correct.
I'll probably add some more documentation to this at another point...
Thoughts?
Friday, December 7, 2007
I've lost my mojo!
Kidding...I'm kidding.
I was reading through some stuff today and started to get inspired by portable virtual computing environments.
One such environment is MojoPac.
I installed Mojopac freedom on my windows xp virtual machine while running Inctrl5. Other than the insane amount of changes to the system, the major change is the creation of HKLM\RINGTHREE\VM1\REGISTRYMACHINE\SOFTWARE. There's simply too much to post here so suffice it to say it looks like it takes a veritable snapshot of your computer's most important components and copies them to a USB key (in my case my Corsair Voyager GT).
During install I was asked to register with mojopac/ringcube, which I did.
When mojopac actually starts up it looks exactly like an embedded XP configuration would - just the basics. The fun begins when you install software. I proceeded to install two programs in to my new mojopac: metasploit and firefox.
I'll obviously need to do some more work on this but so far...
It leaves traces such as this:
Prefetch files for any application executed from within mojopac:
These are particularly interesting because they blatantly indicate that mojopac was used.
Strings output from the firefox prefetch:
FIREFOX.EXE
@\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\NTDLL.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\KERNEL32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\UNICODE.NLS
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\LOCALE.NLS
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SORTTBLS.NLS
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\RINGTHREE\BIN\MOJOPAC.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\USER32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\GDI32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SHELL32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\MSVCRT.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\ADVAPI32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\RPCRT4.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SHLWAPI.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\VERSION.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\JS3250.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\NSPR4.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\WSOCK32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\WS2_32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\WS2HELP.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\WINMM.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\XPCOM_CORE.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\PLC4.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\PLDS4.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\OLE32.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\SMIME3.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\NSS3.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\SOFTOKN3.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\SSL3.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\XPCOM_COMPAT.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\COMDLG32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\WINSXS\X86_MICROSOFT.WINDOWS.COMMON-CONTROLS_6595B64144CCF1DF_6.0.2600.2180_X-WW_A84F1FF9\COMCTL32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\OLEAUT32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\WINSPOOL.DRV
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\CTYPE.NLS
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SORTKEY.NLS
\DEVICE\HARDDISKVOLUME1\WINDOWS\WINDOWSSHELL.MANIFEST
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\LIB\REX\PROTO\HTTP\PACKET.RB
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\RPCSS.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\UXTHEME.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SETUPAPI.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\LIB\REX\PROTO\HTTP\REQUEST.RB
\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\MOZILLA\FIREFOX\PROFILES\NXULDVV7.DEFAULT\COMPATIBILITY.INI
\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\MOZILLA\FIREFOX\PROFILES\NXULDVV7.DEFAULT\EXTENSIONS.INI
MEP
M\\DEVICE\HARDDISK1\DP(1)0-0+5
\DEVICE\HARDDISK1\DP(1)0-0+5\
4\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\
<\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\
M\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\
U\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\MOZILLA\
]\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\MOZILLA\FIREFOX\
f\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\MOZILLA\FIREFOX\PROFILES\
w\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\MOZILLA\FIREFOX\PROFILES\NXULDVV7.DEFAULT\
+\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\
6\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\
A\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\
K\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\
O\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\LIB\
S\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\LIB\REX\
Y\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\LIB\REX\PROTO\
^\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\LIB\REX\PROTO\HTTP\
;\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\
5\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\RINGTHREE\
9\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\RINGTHREE\BIN\
\DEVICE\HARDDISKVOLUME1
\DEVICE\HARDDISKVOLUME1\
\DEVICE\HARDDISKVOLUME1\WINDOWS\
)\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\
'\DEVICE\HARDDISKVOLUME1\WINDOWS\WINSXS\
z\DEVICE\HARDDISKVOLUME1\WINDOWS\WINSXS\X86_MICROSOFT.WINDOWS.COMMON-CONTROLS_6595B64144CCF1DF_6.0.2600.2180_X-WW_A84F1FF9\
EVICE
SCCA
Pz8!
`q{
#'
@#'
`#'
$'
`0W
It appears that mojopac uses some linking to system binaries and makes some use of side by side assemblies but when it uses an application installed in a mojopac device it runs from this location: \DEVICE|HARDDISKVOLUME1\DP(1)0-0+5\[...]
I haven't devised what the significance of the DP(1)... is yet other than it being the volume. Anyone know?
It also leaves autorun traces in:
HKU\SID\Software\microsoft\windows\currentversion\mountpoints2
MRU
The easiest way to identify the use of mojopac is looking for signs of the following:
RingThreeSynchronizer
RingThreeMainWin32
Prefetch files exist for both.
In addition you must be administrator of the machine to use mojopac unless an add on is installed..
More on this later.
I was reading through some stuff today and started to get inspired by portable virtual computing environments.
One such environment is MojoPac.
I installed Mojopac freedom on my windows xp virtual machine while running Inctrl5. Other than the insane amount of changes to the system, the major change is the creation of HKLM\RINGTHREE\VM1\REGISTRYMACHINE\SOFTWARE. There's simply too much to post here so suffice it to say it looks like it takes a veritable snapshot of your computer's most important components and copies them to a USB key (in my case my Corsair Voyager GT).
During install I was asked to register with mojopac/ringcube, which I did.
When mojopac actually starts up it looks exactly like an embedded XP configuration would - just the basics. The fun begins when you install software. I proceeded to install two programs in to my new mojopac: metasploit and firefox.
I'll obviously need to do some more work on this but so far...
It leaves traces such as this:
Prefetch files for any application executed from within mojopac:
These are particularly interesting because they blatantly indicate that mojopac was used.
Strings output from the firefox prefetch:
FIREFOX.EXE
@\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\NTDLL.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\KERNEL32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\UNICODE.NLS
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\LOCALE.NLS
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SORTTBLS.NLS
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\RINGTHREE\BIN\MOJOPAC.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\USER32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\GDI32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SHELL32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\MSVCRT.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\ADVAPI32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\RPCRT4.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SHLWAPI.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\VERSION.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\JS3250.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\NSPR4.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\WSOCK32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\WS2_32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\WS2HELP.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\WINMM.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\XPCOM_CORE.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\PLC4.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\PLDS4.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\OLE32.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\SMIME3.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\NSS3.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\SOFTOKN3.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\SSL3.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\XPCOM_COMPAT.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\COMDLG32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\WINSXS\X86_MICROSOFT.WINDOWS.COMMON-CONTROLS_6595B64144CCF1DF_6.0.2600.2180_X-WW_A84F1FF9\COMCTL32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\OLEAUT32.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\WINSPOOL.DRV
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\CTYPE.NLS
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SORTKEY.NLS
\DEVICE\HARDDISKVOLUME1\WINDOWS\WINDOWSSHELL.MANIFEST
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\LIB\REX\PROTO\HTTP\PACKET.RB
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\RPCSS.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\UXTHEME.DLL
\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\SETUPAPI.DLL
\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\LIB\REX\PROTO\HTTP\REQUEST.RB
\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\MOZILLA\FIREFOX\PROFILES\NXULDVV7.DEFAULT\COMPATIBILITY.INI
\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\MOZILLA\FIREFOX\PROFILES\NXULDVV7.DEFAULT\EXTENSIONS.INI
MEP
M\\DEVICE\HARDDISK1\DP(1)0-0+5
\DEVICE\HARDDISK1\DP(1)0-0+5\
4\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\
<\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\
M\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\
U\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\MOZILLA\
]\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\MOZILLA\FIREFOX\
f\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\MOZILLA\FIREFOX\PROFILES\
w\DEVICE\HARDDISK1\DP(1)0-0+5\DOCUMENTS AND SETTINGS\EVILMAN\APPLICATION DATA\MOZILLA\FIREFOX\PROFILES\NXULDVV7.DEFAULT\
+\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\
6\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\
A\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\
K\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\
O\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\LIB\
S\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\LIB\REX\
Y\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\LIB\REX\PROTO\
^\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\METASPLOIT\FRAMEWORK3\FRAMEWORK\LIB\REX\PROTO\HTTP\
;\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\MOZILLA FIREFOX\
5\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\RINGTHREE\
9\DEVICE\HARDDISK1\DP(1)0-0+5\PROGRAM FILES\RINGTHREE\BIN\
\DEVICE\HARDDISKVOLUME1
\DEVICE\HARDDISKVOLUME1\
\DEVICE\HARDDISKVOLUME1\WINDOWS\
)\DEVICE\HARDDISKVOLUME1\WINDOWS\SYSTEM32\
'\DEVICE\HARDDISKVOLUME1\WINDOWS\WINSXS\
z\DEVICE\HARDDISKVOLUME1\WINDOWS\WINSXS\X86_MICROSOFT.WINDOWS.COMMON-CONTROLS_6595B64144CCF1DF_6.0.2600.2180_X-WW_A84F1FF9\
EVICE
SCCA
Pz8!
`q{
#'
@#'
`#'
$'
`0W
It appears that mojopac uses some linking to system binaries and makes some use of side by side assemblies but when it uses an application installed in a mojopac device it runs from this location: \DEVICE|HARDDISKVOLUME1\DP(1)0-0+5\[...]
I haven't devised what the significance of the DP(1)... is yet other than it being the volume. Anyone know?
It also leaves autorun traces in:
HKU\SID\Software\microsoft\windows\currentversion\mountpoints2
MRU
The easiest way to identify the use of mojopac is looking for signs of the following:
RingThreeSynchronizer
RingThreeMainWin32
Prefetch files exist for both.
In addition you must be administrator of the machine to use mojopac unless an add on is installed..
Sunday, December 2, 2007
Putting the Forensics in Anti-Forensics
There's a lot of noise about Anti-forensics still so while working on some material for a presentation and IR course, I started working on some fancy videos of what an attack looks like, versus what your average live response utility will collect. I started creating this to illustrate a few points.
1) Do you trust your tools?
2) The average tool is not capable of providing enough information when facing modern attacks.
3) An investigation does not begin and end on the disk.
Imagine this scenario:
The IT department at a client of yours calls you up one day and says "Our computers have been acting funny the past few days, and we've checked them but can't find anything out of the ordinary. Can you bring your kit and take a deeper look at the network and systems to see if you can find anything?"
You arrive and as part of your incident investigation methodology, you put an emergency NSM sensor at the perimeter of the network doing a full capture. Almost immediately you start seeing odd things occuring, and you hear a shout from down the hall, calling your name. You grab a CD and walk down the hall. Arriving at the secretaries desk you see her and the IT guy talking and they look elated when they see you.
You pop in your trusty Helix CD and run WFT.
AAron Walters was kind enough to host this data for me. Thanks AAron!
Download the data here. The MD5 is here.
You'll find the video of "whodunnit" in the file above. Watch it beforehand if you want to cheat, but I would hope some would want to analyze before looking at the answer.
So, now refer to my points above.
1) Do you trust your tools?
Trust is mainly about reliability and confidence. How confident are you that your tools are showing you accurate information? How reliable is the data output?
2) The average tool is not capable of providing enough information when facing modern attacks.
As attacks get more complex, the dataset grows, and likewise becomes more complex, and obscure in revealing useful information. The average "forensic" tool of today can't compete. You may be required to throw out the protocol book once in a while in favor of getting the job done.
3) An investigation does not begin and end on the disk.
Like I said attacks are getting more complex. Forensics is not simply about data collection from one source. There are many data points in an investigation, and we can't afford to limit ourselves to just the disk, for there is information elsewhere that may not exist on disk.
Enjoy. If you find interesting bits of data, please post them as a reply on on your own blog/site and provide a link.
1) Do you trust your tools?
2) The average tool is not capable of providing enough information when facing modern attacks.
3) An investigation does not begin and end on the disk.
Imagine this scenario:
The IT department at a client of yours calls you up one day and says "Our computers have been acting funny the past few days, and we've checked them but can't find anything out of the ordinary. Can you bring your kit and take a deeper look at the network and systems to see if you can find anything?"
You arrive and as part of your incident investigation methodology, you put an emergency NSM sensor at the perimeter of the network doing a full capture. Almost immediately you start seeing odd things occuring, and you hear a shout from down the hall, calling your name. You grab a CD and walk down the hall. Arriving at the secretaries desk you see her and the IT guy talking and they look elated when they see you.
You pop in your trusty Helix CD and run WFT.
AAron Walters was kind enough to host this data for me. Thanks AAron!
Download the data here. The MD5 is here.
You'll find the video of "whodunnit" in the file above. Watch it beforehand if you want to cheat, but I would hope some would want to analyze before looking at the answer.
So, now refer to my points above.
1) Do you trust your tools?
Trust is mainly about reliability and confidence. How confident are you that your tools are showing you accurate information? How reliable is the data output?
2) The average tool is not capable of providing enough information when facing modern attacks.
As attacks get more complex, the dataset grows, and likewise becomes more complex, and obscure in revealing useful information. The average "forensic" tool of today can't compete. You may be required to throw out the protocol book once in a while in favor of getting the job done.
3) An investigation does not begin and end on the disk.
Like I said attacks are getting more complex. Forensics is not simply about data collection from one source. There are many data points in an investigation, and we can't afford to limit ourselves to just the disk, for there is information elsewhere that may not exist on disk.
Enjoy. If you find interesting bits of data, please post them as a reply on on your own blog/site and provide a link.
Collecting physical memory
I was recently looking at a memory collection of about 4GB and started thinking about the order of volatility. A 4GB memory capture to a USB key can take an inordinate amount of time, and during that time the other volatile data on the system is not only changing, it's potentially disappearing. Take for instance a netstat command that shows a connection that's ESTABLISHED. While collecting memory and nothing else on the system that connection would go from ESTABLISHED to CLOSED, to disappearing all together from your state table. While this information can certainly be collected from memory, it's still collected when you run netstat (or other similar network state table collection software). So what's my point?
Well I suppose it requires more experimentation with the concept but is it necessary to collect network state information externally if you're already collecting ram contents which contains the same state information? My thoughts are no, although it does give you network state during two points in time, which may be a more accurate "smear". Would forking the memory capture process to collect network state at the same time make more sense? It would create a bigger footprint, but the network state would be captured independently of memory, at the same time.
What are your thoughts?
EDIT: 12/4/07 changed wording about ESTABLISHED connection.
Well I suppose it requires more experimentation with the concept but is it necessary to collect network state information externally if you're already collecting ram contents which contains the same state information? My thoughts are no, although it does give you network state during two points in time, which may be a more accurate "smear". Would forking the memory capture process to collect network state at the same time make more sense? It would create a bigger footprint, but the network state would be captured independently of memory, at the same time.
What are your thoughts?
EDIT: 12/4/07 changed wording about ESTABLISHED connection.
Subscribe to:
Posts (Atom)
