New Perl module on CPAN
I received an email this morning that directed me to a "new" Perl module called Parse::Win32Registry. From the description, the module allows you to read the keys and values of a registry file without going through the Windows API. Very cool! This goes a step or two beyond my own Perl code for doing this, as it uses an Object Oriented approach (it also covers the Win95 Registry files, as well).
Even though this one isn't up on the ActiveState site yet, it looks like a great option, and will be extremely useful. The install went really easy for me...I downloaded the .tar.gz file, extracted everything, and just copied the contents of the \lib directory into my C:\Perl\site\lib directory. From there, I began running tests with the sample file, and things went really well.
Some of you are probably looking at this thinking, "yeah...whatever." Well, something like this can make parsing through Registry files to get all sorts of data much, much easier. I can also see this being used to parse through the Registry files in XP's System Restore points much easier, even to the point of running 'diffs'.
New CyberSpeak show
Brett's got a new CyberSpeak podcast out...it's a short one this time, folks. Brett mentioned feedback and encouragement in the show - I don't know what kind of feedback he and Ovie get, but like everyone else, I can see the comments on the LibSyn site. These guys are putting forth a great effort, and it can't be easy to parse out the kind of time it takes every week to put the show together. I tend to wonder if the show could be used as a focal point to a sort of extended e-zine for the community. I've thought before about how useful a digital forensics e-zine would be...something practical, useful, hands-on...not at an academic level, but more on the level of "here's what you can do, and here's how you do it". Since there's a wide range of subjects out there (I'm interested in Windows systems, Brett mentioned Macs in today's show...) I don't think that it would be too hard to put something together each week...folks sending in links to articles, etc. Using the LibSyn site, or some other site (like what the Hak5 guys do with their show notes in a Wiki format), a neat little e-zine can be put together each week/month, with lots of folks contributing. Just a thought...
Desktop Capture Software
Oh, and if anyone has any input or thoughts on some good, free desktop capture software, drop me a line. I want to capture my desktop while I speak into the mic on my laptop, so I can record HOW-TOs for my next book. I think that following along visually is better for some folks (and probably much more interesting) that reading a bunch of steps. Right now, I'm considering WebEx Recorder, but would like to get some input on other options. The requirements are simple...good quality output (with regards to video and audio), and the recorder and player should both be freely available. I know that the IronGeek uses CamStudio...anyone have any thoughts or input on that?
The Windows Incident Response Blog is dedicated to the myriad information surrounding and inherent to the topics of IR and digital analysis of Windows systems. This blog provides information in support of my books; "Windows Forensic Analysis" (1st thru 4th editions), "Windows Registry Forensics", as well as the book I co-authored with Cory Altheide, "Digital Forensics with Open Source Tools".
Pages
▼
Monday, October 30, 2006
Friday, October 27, 2006
It Bears Repeating
There are just somethings that you can't say often enough. For example, tell the ones you love that you love them. Also, tell them that when they suspect an incident, do NOT shut the system off!
Think of Brad Pitt and Ed Norton (no, not that way!!) in Fight Club, but paraphrase..."the first rule of incident response is...don't panic. The second rule of incident response is...DO NOT PANIC!!"
Okay, let's go back to the beginning...well, maybe not that far. Let's go back to an InformationWeek article published in Aug, 2006, in which Kevin Mandia was quoted...here's one interesting quote:
One of the worst things users can do if they think their systems have been compromised by a hacker is to shut off their PCs, because doing so prevents an investigator from analyzing the contents of the machine's RAM, which often contains useful forensic evidence, Mandia said.
So, what do you think? Is he right? Don't say, "well, yeah, he must be...he's Kevin Mandia!" Think about it. While you're doing that, let me give you a scenario...you're an admin, and you detect anomalous traffic on your network. First, you see entries in firewall or IDS logs. You may even turn on a sniffer to capture network traffic information. So let's say that at that point, you determine that a specific system is connecting to a server on the Internet on an extremely high port, and the traffic appears to be IRC traffic. What do you do? More importantly, what do you want to know?
The usual scenario continues like this...the system is taken offline and shutdown, and stored in an office someplace. An outside third party may be contacted to provide assistance. At this point, once the incident is reported to management, the questions become...what is our risk or exposure? Was sensitive information taken? Were other machines affected? If so, how many?
This is where panic ensues, because not only do most organizations not know the answers to the questions, but they don't know how to get the answers themselves, either. Here's another quote from the article:
...Mandia said rumors of a kernel level rootkits always arise within the company that's being analyzed.
You'll see this in the public lists a lot..."I don't know what this issue is, and I really haven't done any sort of investigation...it's just easier to assume that it's a rootkit, because at the very least, that says the attacker is a lot smarter than me." Just the term rootkit implies a certain sexiness to the incident, doesn't it? After all, it implies that you've got something someone else wants, and an incredibly sophisticated attacker, a cyberninja, is coming after you. In some cases, it ends up being just a rumor.
The point of all this is that many times, the questions that management has about an incident cannot be answered, at least not definitively, if the first step is to shut down the system. At the very least, if you have detected anomalous traffic on your network, and traced it back to a specific system, rather than shutting the system off, take that additional step to collect process and process-to-port mapping info (for a list of tools, see chapter 5 of my first book) from the system. That way, you've closed the loop...you've not only tied the traffic to a system, but you've also tied it to a specific process on the system.
Of course, if you're going to go that far, you might was well use something like the Forensic Server Project to gather even more information.
Think of Brad Pitt and Ed Norton (no, not that way!!) in Fight Club, but paraphrase..."the first rule of incident response is...don't panic. The second rule of incident response is...DO NOT PANIC!!"
Okay, let's go back to the beginning...well, maybe not that far. Let's go back to an InformationWeek article published in Aug, 2006, in which Kevin Mandia was quoted...here's one interesting quote:
One of the worst things users can do if they think their systems have been compromised by a hacker is to shut off their PCs, because doing so prevents an investigator from analyzing the contents of the machine's RAM, which often contains useful forensic evidence, Mandia said.
So, what do you think? Is he right? Don't say, "well, yeah, he must be...he's Kevin Mandia!" Think about it. While you're doing that, let me give you a scenario...you're an admin, and you detect anomalous traffic on your network. First, you see entries in firewall or IDS logs. You may even turn on a sniffer to capture network traffic information. So let's say that at that point, you determine that a specific system is connecting to a server on the Internet on an extremely high port, and the traffic appears to be IRC traffic. What do you do? More importantly, what do you want to know?
The usual scenario continues like this...the system is taken offline and shutdown, and stored in an office someplace. An outside third party may be contacted to provide assistance. At this point, once the incident is reported to management, the questions become...what is our risk or exposure? Was sensitive information taken? Were other machines affected? If so, how many?
This is where panic ensues, because not only do most organizations not know the answers to the questions, but they don't know how to get the answers themselves, either. Here's another quote from the article:
...Mandia said rumors of a kernel level rootkits always arise within the company that's being analyzed.
You'll see this in the public lists a lot..."I don't know what this issue is, and I really haven't done any sort of investigation...it's just easier to assume that it's a rootkit, because at the very least, that says the attacker is a lot smarter than me." Just the term rootkit implies a certain sexiness to the incident, doesn't it? After all, it implies that you've got something someone else wants, and an incredibly sophisticated attacker, a cyberninja, is coming after you. In some cases, it ends up being just a rumor.
The point of all this is that many times, the questions that management has about an incident cannot be answered, at least not definitively, if the first step is to shut down the system. At the very least, if you have detected anomalous traffic on your network, and traced it back to a specific system, rather than shutting the system off, take that additional step to collect process and process-to-port mapping info (for a list of tools, see chapter 5 of my first book) from the system. That way, you've closed the loop...you've not only tied the traffic to a system, but you've also tied it to a specific process on the system.
Of course, if you're going to go that far, you might was well use something like the Forensic Server Project to gather even more information.
Thursday, October 26, 2006
Windows Memory Updates
Andreas recently released a new tool called poolgrep.pl. This lets you run searches across memory pools, looking for things such as timestamps, IP addresses, etc. You need to start by using poolfinder.pl to develop an index, and from there you can search through various pools for specific items.
This is definitely a start in the right direction. As Andreas has pointed out, the pool header contains a size value, so we know how many bytes the pool occupies. He has also shown that some pool contents can reveal network connections. From here, IMHO, we should focus on "interesting" pooltags, and attempt to understand their structure. Once we do, then this can be added to tools such as poolfinder.pl, and the data parsed and presented accordingly. In addition to network connections, for example, the contents of the clipboard (pool tag = Uscb) may be interesting, as well. MS provides a listing of pooltags in the pooltags.txt file that's part of the Debugger Tools. You can see an online version of the file here.
Also, there's been an update to the SANS ISC Malware Analysis: Tools of the Trade toolkit listing...and it looks like I'd better get cracking on finishing up the tools I've been putting together to address not just Windows 2000 RAM dumps! ;-)
This is definitely a start in the right direction. As Andreas has pointed out, the pool header contains a size value, so we know how many bytes the pool occupies. He has also shown that some pool contents can reveal network connections. From here, IMHO, we should focus on "interesting" pooltags, and attempt to understand their structure. Once we do, then this can be added to tools such as poolfinder.pl, and the data parsed and presented accordingly. In addition to network connections, for example, the contents of the clipboard (pool tag = Uscb) may be interesting, as well. MS provides a listing of pooltags in the pooltags.txt file that's part of the Debugger Tools. You can see an online version of the file here.
Also, there's been an update to the SANS ISC Malware Analysis: Tools of the Trade toolkit listing...and it looks like I'd better get cracking on finishing up the tools I've been putting together to address not just Windows 2000 RAM dumps! ;-)
Monday, October 23, 2006
ForensicZone.com
For those who haven't seen it, you should check out ForensicZone.com, home of PTFinderFE and SSDeepFE. There's also a number of links on the site to cell phone stuff, particularly for forensics. Very cool stuff.
Vista, RAM dumps, and OS detection (oh, my!!)
I received an email from Andreas today, and one of the things he mentioned is that the offset for the Vista kernel in memory is 0x81800000...this could be added to my os detection script. So I made the change to my script and ran it against a memory dump that I had from a Vista machine. Nothing. Nada. No impact, no idea. I opened up the memory dump in UltraEdit and saw that there was nothing at the offset...well, at least no PE header.
I then fired up my Vista RC1 VMWare session, and ran LiveKD to see what it reported the kernel base address as (0x81800000), and then I suspended the session. I opened up the resulting .vmem file and ran the script against it...and saw the following:
File Description : NT Kernel & System
File Version : 6.0.5600.16384 (vista_rc1.060829-2230)
Internal Name : ntkrpamp.exe
Original File Name :
Product Name : Microsoft« Windows« Operating System
Product Version : 6.0.5600.16384
File Description : Boot Man╕╝ ç(╝ ç
File Version : 6.0.5600.16384╜ çp╝ çsta_rc1.060829-2230)
Internal Name :
Original File Name :
Product Name : Microsoft« Winh╛ ç╪╜ ç« Operating System
Product Version :
Very cool. To make this change yourself, just add '0x81800000 => "VistaRC1"' to the %kb hash.
Addendum 24 Oct: Sent by Andreas, and confirmed this morning...add '0x82000000 => "VistaBeta2"' (remove outer single quotes) to the %kb hash in kern.pl.
I then fired up my Vista RC1 VMWare session, and ran LiveKD to see what it reported the kernel base address as (0x81800000), and then I suspended the session. I opened up the resulting .vmem file and ran the script against it...and saw the following:
File Description : NT Kernel & System
File Version : 6.0.5600.16384 (vista_rc1.060829-2230)
Internal Name : ntkrpamp.exe
Original File Name :
Product Name : Microsoft« Windows« Operating System
Product Version : 6.0.5600.16384
File Description : Boot Man╕╝ ç(╝ ç
File Version : 6.0.5600.16384╜ çp╝ çsta_rc1.060829-2230)
Internal Name :
Original File Name :
Product Name : Microsoft« Winh╛ ç╪╜ ç« Operating System
Product Version :
Very cool. To make this change yourself, just add '0x81800000 => "VistaRC1"' to the %kb hash.
Addendum 24 Oct: Sent by Andreas, and confirmed this morning...add '0x82000000 => "VistaBeta2"' (remove outer single quotes) to the %kb hash in kern.pl.
Friday, October 20, 2006
Pool tag finder
Andreas released his poolfinder tool the other day, a Perl script for locating pool tags in a memory dump. This script accompanies a paper he wrote for IMF 2006 (here's his paper from DFRWS 2006).
So, what's a pool tag, and why is it important? According to Andreas, the kernel allocates what's referred to as a "pool" of memory, so that if an application requests some memory that is less than a 4K page, rather than wasting all of that space, only what is required will be allocated. The pool tag header is a way of keeping track of this pool.
The pool header specifies the size of the pool, but there isn't any publicly available method for parsing that pool into something usable. I've used this technique to locate the contents of the Clipboard in the DFRWS 2005 memory challenge dumps, and Andreas has used this to locate network socket activity. Perhaps someone with experience in developing drivers for Windows can assist in developing a methodology for revealing the format of the various structures.
Additional Resources:
Who's using the pool?
How to use PoolMon.exe
Addendum, 23 Oct: I've made some comments to Andreas's blog, and we've gone back and forth a bit. What I'd like to try to do is identify various pool tags that are of interest to forensic examiners (ie, TCPA for network connections, clipboard, etc.). Thanks to Andreas's work, finding the pool tags and their sizes is relatively easy...deciphering them into something readable is something else entirely.
So, what's a pool tag, and why is it important? According to Andreas, the kernel allocates what's referred to as a "pool" of memory, so that if an application requests some memory that is less than a 4K page, rather than wasting all of that space, only what is required will be allocated. The pool tag header is a way of keeping track of this pool.
The pool header specifies the size of the pool, but there isn't any publicly available method for parsing that pool into something usable. I've used this technique to locate the contents of the Clipboard in the DFRWS 2005 memory challenge dumps, and Andreas has used this to locate network socket activity. Perhaps someone with experience in developing drivers for Windows can assist in developing a methodology for revealing the format of the various structures.
Additional Resources:
Who's using the pool?
How to use PoolMon.exe
Addendum, 23 Oct: I've made some comments to Andreas's blog, and we've gone back and forth a bit. What I'd like to try to do is identify various pool tags that are of interest to forensic examiners (ie, TCPA for network connections, clipboard, etc.). Thanks to Andreas's work, finding the pool tags and their sizes is relatively easy...deciphering them into something readable is something else entirely.
Restore Point Forensics
I was doing some digging around the other day, researching System Restore points in XP...they're only in XP (and ME, but we're only concerned with the NT-style Windows OSs), and not something you'll find in 2000 or 2003.
So, what is "System Restore"? SR is a function of XP that creates "restore points" or limited backups of certain important files, depending upon certain triggers. For example, by default, a restore point will be created every calendar day. Also, restore points are created whenever the user installs software. This, of course, means that you could technically have multiple restore points created during a single day. Restore points can be used in case something goes wrong with the installation and the system is affected...the user can select a previous restore point, and "roll back" the system to that point. This is a very cool thing, and I've used it more than once myself. Keep in mind, though, restore points do not affect certain things, such as login passwords or a user's data, so don't be afraid to select a restore point from 3 days ago because you think you might loose that spreadsheet you built yesterday.
So what do restore points mean to us? Well, they're full of a wealth of information about the system. I've presented on the topic of "the Registry as a logfile" in the past, and this is a great example of that. Important files are backed up, but so are portions of the Registry, such as the System and Software files, the user's profile(s), and portions of the SAM. These Registry files have keys in them, and the keys have LastWrite times.
Where do these come into play? I've seen several questions in some of the lists lately, asking about things like "was this user account on the system", or "did the user change their name", as well as other questions where, on the face, would best be answered if there were some way to take a glimpse into the past. Restore points let you do that.
The structure of the restore points is pretty simple. On the root of the system drive, you'll find a "System Volume Information" directory, and beneath that a directory named "_restore{GUID}". Beneath that, you'll have numbered restore points...RP35, RP36, RP37, etc. You get the idea. Within each of these "RP**" directories, you'll have some backed up files (depends on the nature of the restore point), and a file called 'rp.log'. This is a binary file that contains the description string (null terminated string starting at offset 0x10) for the restore point, as well as the FILETIME object of when it was created (QWORD starting at offset 0x210). Finally, there is a snapshot directory holding all of the Registry file backups.
If you're interested in peering into these restore points, but don't have an image available, you can look at them on your own XP system. One way to get some information is through WMI. Using the SystemRestore and SystemRestoreConfig objects, you can get information about each restore point, as well as configuration settings about the System Restore, respectively. I wrote a Perl script to do this...here's an excerpt of what I got on my system:
64 13:28:07 09/27/2006 Installed Windows Live Messenger
65 15:07:48 09/28/2006 System Checkpoint
.
.
.
73 12:45:41 10/09/2006 System Checkpoint
74 14:03:53 10/09/2006 Installed QuickTime
75 19:25:09 10/09/2006 Installed Microsoft .NET Framework 1.1
76 20:21:54 10/10/2006 System Checkpoint
77 20:52:59 10/11/2006 System Checkpoint
78 22:00:48 10/12/2006 System Checkpoint
79 22:20:18 10/12/2006 Installed Windows Media Player 11
80 22:20:41 10/12/2006 Installed Windows XP Wudf01000.
81 10:45:08 10/14/2006 Software Distribution Service 2.0
82 12:35:54 10/18/2006 System Checkpoint
83 18:29:09 10/19/2006 System Checkpoint
84 20:38:49 10/19/2006 Removed ProDiscover IR 4.8a
85 20:43:48 10/19/2006 Installed ProDiscover IR 4.84
Kind of cool. This gives me something of a view of the activity of the system, not only when it was online, but also what was going on. Notice that on 19 Oct, three restore points were created. Not only was the normal System Checkpoint created, but there was a software removal and an installation. This script is very useful, not only for incident response (include it with the FRU and FSP), but also for general system administration. It works remotely as well as locally, and gives the admin some good visibility into the system.
The other interesting thing about this is the order of the restore points. Notice that as the restore point indexes increase, so do the timestamps. If I were to have modified my system time several days ago, things might not appear to be in order...so this is a good little sanity check to see if maybe the system time was modified. It's not definitive, mind you, but a good check.
If you just want to take a look around, go to SysInternals and get a copy of psexec. Once it's on your system, type:
psexec -s cmd
and a command prompt will open, but you'll have SYSTEM level privileges. Then type:
cd \Sys*
cd _restor*
Now, select one of the restore points and cd to that directory, then to the snapshot directory. If you do a 'dir' at this point, you'll see all of the various Registry files that are backed up, each one beginning with "_REGISTRY_MACHINE_*". At this point, you can copy any of these files out to a "normal" directory, and either open the file in a hex editor, or run it through the Offline Registry Parser and see the contents in ASCII. I tried this and dumped out one of the SAM files I found, and saw that I could see the C values that hold group membership information, as well as the F and V values for user's account information. One of the things I've got in the works is a set of scripts that will parse through these files (and the "normal" Registry files), reporting on what it finds...but in a way that's readable to an investigator. So, rather than spewing out binary data for the F and V values for a user account, translate that into something readable, like my UserDump ProScript. Something like this could be used to 'diff' the various files from restore points.
I've developed a ProDiscover ProScript for sorting through the restore points on an XP system, and I'll make it available when the next version is released.
Additional Resources:
Steve Bunting's site (he uses EnCase)
Bobbie Harder's site (links to KB articles)
Windows XP System Restore
Wang's Blog (tells you how to open the RP** Registry files in RegEdit)
Restore Point Log Format
So, what is "System Restore"? SR is a function of XP that creates "restore points" or limited backups of certain important files, depending upon certain triggers. For example, by default, a restore point will be created every calendar day. Also, restore points are created whenever the user installs software. This, of course, means that you could technically have multiple restore points created during a single day. Restore points can be used in case something goes wrong with the installation and the system is affected...the user can select a previous restore point, and "roll back" the system to that point. This is a very cool thing, and I've used it more than once myself. Keep in mind, though, restore points do not affect certain things, such as login passwords or a user's data, so don't be afraid to select a restore point from 3 days ago because you think you might loose that spreadsheet you built yesterday.
So what do restore points mean to us? Well, they're full of a wealth of information about the system. I've presented on the topic of "the Registry as a logfile" in the past, and this is a great example of that. Important files are backed up, but so are portions of the Registry, such as the System and Software files, the user's profile(s), and portions of the SAM. These Registry files have keys in them, and the keys have LastWrite times.
Where do these come into play? I've seen several questions in some of the lists lately, asking about things like "was this user account on the system", or "did the user change their name", as well as other questions where, on the face, would best be answered if there were some way to take a glimpse into the past. Restore points let you do that.
The structure of the restore points is pretty simple. On the root of the system drive, you'll find a "System Volume Information" directory, and beneath that a directory named "_restore{GUID}". Beneath that, you'll have numbered restore points...RP35, RP36, RP37, etc. You get the idea. Within each of these "RP**" directories, you'll have some backed up files (depends on the nature of the restore point), and a file called 'rp.log'. This is a binary file that contains the description string (null terminated string starting at offset 0x10) for the restore point, as well as the FILETIME object of when it was created (QWORD starting at offset 0x210). Finally, there is a snapshot directory holding all of the Registry file backups.
If you're interested in peering into these restore points, but don't have an image available, you can look at them on your own XP system. One way to get some information is through WMI. Using the SystemRestore and SystemRestoreConfig objects, you can get information about each restore point, as well as configuration settings about the System Restore, respectively. I wrote a Perl script to do this...here's an excerpt of what I got on my system:
64 13:28:07 09/27/2006 Installed Windows Live Messenger
65 15:07:48 09/28/2006 System Checkpoint
.
.
.
73 12:45:41 10/09/2006 System Checkpoint
74 14:03:53 10/09/2006 Installed QuickTime
75 19:25:09 10/09/2006 Installed Microsoft .NET Framework 1.1
76 20:21:54 10/10/2006 System Checkpoint
77 20:52:59 10/11/2006 System Checkpoint
78 22:00:48 10/12/2006 System Checkpoint
79 22:20:18 10/12/2006 Installed Windows Media Player 11
80 22:20:41 10/12/2006 Installed Windows XP Wudf01000.
81 10:45:08 10/14/2006 Software Distribution Service 2.0
82 12:35:54 10/18/2006 System Checkpoint
83 18:29:09 10/19/2006 System Checkpoint
84 20:38:49 10/19/2006 Removed ProDiscover IR 4.8a
85 20:43:48 10/19/2006 Installed ProDiscover IR 4.84
Kind of cool. This gives me something of a view of the activity of the system, not only when it was online, but also what was going on. Notice that on 19 Oct, three restore points were created. Not only was the normal System Checkpoint created, but there was a software removal and an installation. This script is very useful, not only for incident response (include it with the FRU and FSP), but also for general system administration. It works remotely as well as locally, and gives the admin some good visibility into the system.
The other interesting thing about this is the order of the restore points. Notice that as the restore point indexes increase, so do the timestamps. If I were to have modified my system time several days ago, things might not appear to be in order...so this is a good little sanity check to see if maybe the system time was modified. It's not definitive, mind you, but a good check.
If you just want to take a look around, go to SysInternals and get a copy of psexec. Once it's on your system, type:
psexec -s cmd
and a command prompt will open, but you'll have SYSTEM level privileges. Then type:
cd \Sys*
cd _restor*
Now, select one of the restore points and cd to that directory, then to the snapshot directory. If you do a 'dir' at this point, you'll see all of the various Registry files that are backed up, each one beginning with "_REGISTRY_MACHINE_*". At this point, you can copy any of these files out to a "normal" directory, and either open the file in a hex editor, or run it through the Offline Registry Parser and see the contents in ASCII. I tried this and dumped out one of the SAM files I found, and saw that I could see the C values that hold group membership information, as well as the F and V values for user's account information. One of the things I've got in the works is a set of scripts that will parse through these files (and the "normal" Registry files), reporting on what it finds...but in a way that's readable to an investigator. So, rather than spewing out binary data for the F and V values for a user account, translate that into something readable, like my UserDump ProScript. Something like this could be used to 'diff' the various files from restore points.
I've developed a ProDiscover ProScript for sorting through the restore points on an XP system, and I'll make it available when the next version is released.
Additional Resources:
Steve Bunting's site (he uses EnCase)
Bobbie Harder's site (links to KB articles)
Windows XP System Restore
Wang's Blog (tells you how to open the RP** Registry files in RegEdit)
Restore Point Log Format
Wednesday, October 11, 2006
New HaxDoor variant
I picked this one up from the Securiteam blog this evening...it seems there's a new HaxDoor variant out. Symantec's technical write-up contains a lot of detail (useful to forensic analysts...the guys on the FIRST list should take note), and even though they do classify this one as a "backdoor", they do actually use the word "rootkit". For further reading:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\
Here's some info from MS on that Winlogon\Notify entry.
One thing I think that's needed is an understanding of how clear, detailed write-ups on things like this are important to the IR/CF community. This sort of thing is very helpful when you're trying to ascertain the sophistication of an intrusion, and perhaps even develop some next steps. Remember, things such as NTFS ADSs and esoteric Registry key entries may be ho-hum boring to a lot of folks, but they're all pieces of the puzzle if you're doing IR/CF.
If you think you may have a rootkit, check out one of these tools.
- Trend Micro
- Sophos (probably the least useful)
- McAfee (click on "Symptoms")
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\
Here's some info from MS on that Winlogon\Notify entry.
One thing I think that's needed is an understanding of how clear, detailed write-ups on things like this are important to the IR/CF community. This sort of thing is very helpful when you're trying to ascertain the sophistication of an intrusion, and perhaps even develop some next steps. Remember, things such as NTFS ADSs and esoteric Registry key entries may be ho-hum boring to a lot of folks, but they're all pieces of the puzzle if you're doing IR/CF.
If you think you may have a rootkit, check out one of these tools.
PTFinder Front End
Andreas posted this on his blog, and I took a look at it...very cool. This is a front-end for running PTFinder, and even allows you to choose which operating system you want to run it against. This makes things a little easier to use.
If you have a RAM dump and don't remember which OS it is, as long as it's between Win2k and Win2K3SP1, you can use my OS detection script.
The neat thing is that you can get output that looks like this. Very cool!
If you have a RAM dump and don't remember which OS it is, as long as it's between Win2k and Win2K3SP1, you can use my OS detection script.
The neat thing is that you can get output that looks like this. Very cool!
Monday, October 09, 2006
Are you a Spider man?
I found an announcement on another list today for Spider, a tool from Cornell University for locating sensitive personal information (SSN, credit card numbers, etc.) on a system.
I'm told that the intended use is to run it against the system after you've acquired an image, which makes sense. Either image the system live, and then run the tool on the rebooted system, or remove the hard drive, image it, replace it, boot it, and then run the tool. I wouldn't recommend it as an initial step in IR, as it will change the MAC times on all of the files, but it is a great idea for IT admins. Many times during an engagement, one of the questions that will be asked is, "Is/was there any sensitive data on the system, and if so, was it accessed/copied?" Well, IT admins can run a tool like this as part of their SOP...after all, if an incident does occur, you're going to be asking that question anyway, right?
Also, through in something like LiveView, particularly if all you have is an image. Boot the image, and run Spider against it. Unfortunately, you're going to have to install .Net on the booted image, but VMWare is great with snapshots.
So, for the Windows version, you need to install the .Net framework first. Note that the documentation for downloading and installing Spider refers to the install file as "spider_nsis.exe", and the Windows version (2.19a) comes as 'setup.exe'. The configuration of the tool is a bit outside the 'norm'...you don't just launch Spider from the command line with switches.
Interesting capabilities include the ability to add regex's, scanning of ADSs, and logging to the Event Log or to syslog.
A great tool, but I really see it being more of an IT admin's SOP than a response tool, 'though it does have it's uses. Keep in mind that the documentation states that you can have a high incident of false positives, but that's the case even with regex searches in EnCase, and just something you have to deal with for now.
I'm told that the intended use is to run it against the system after you've acquired an image, which makes sense. Either image the system live, and then run the tool on the rebooted system, or remove the hard drive, image it, replace it, boot it, and then run the tool. I wouldn't recommend it as an initial step in IR, as it will change the MAC times on all of the files, but it is a great idea for IT admins. Many times during an engagement, one of the questions that will be asked is, "Is/was there any sensitive data on the system, and if so, was it accessed/copied?" Well, IT admins can run a tool like this as part of their SOP...after all, if an incident does occur, you're going to be asking that question anyway, right?
Also, through in something like LiveView, particularly if all you have is an image. Boot the image, and run Spider against it. Unfortunately, you're going to have to install .Net on the booted image, but VMWare is great with snapshots.
So, for the Windows version, you need to install the .Net framework first. Note that the documentation for downloading and installing Spider refers to the install file as "spider_nsis.exe", and the Windows version (2.19a) comes as 'setup.exe'. The configuration of the tool is a bit outside the 'norm'...you don't just launch Spider from the command line with switches.
Interesting capabilities include the ability to add regex's, scanning of ADSs, and logging to the Event Log or to syslog.
A great tool, but I really see it being more of an IT admin's SOP than a response tool, 'though it does have it's uses. Keep in mind that the documentation states that you can have a high incident of false positives, but that's the case even with regex searches in EnCase, and just something you have to deal with for now.
Parsing Registry files
Last week, I mentioned making adaptations to a tool to perform specific tasks. Specifically, adapting the Offline Registry Parser so that instead of dumping all of the stuff in a Registry file, dump specific keys, values and their data, and translate that data into something human-readable (and parsable), rather than simply spewing it to STDOUT.
Where I thought this might be useful is with the SAM file, to start. Run through the file and pull out all of the user information, group membership info, and even the audit policy (translated into something similar to auditpol.exe's output). A side benefit of this is that you could run it against the current SAM file, as well as any located in System Restore points, and get a rough timeline of when changes occurred.
This could also be done for the NTUSER.DAT files.
Another benefit of this is data reduction. Rather than dumping the entire contents of the Software hive, you could extract only those keys, values, and data that you would most usually be interested. From there, you'd have less to analyze, and still have the original data.
Where I thought this might be useful is with the SAM file, to start. Run through the file and pull out all of the user information, group membership info, and even the audit policy (translated into something similar to auditpol.exe's output). A side benefit of this is that you could run it against the current SAM file, as well as any located in System Restore points, and get a rough timeline of when changes occurred.
This could also be done for the NTUSER.DAT files.
Another benefit of this is data reduction. Rather than dumping the entire contents of the Software hive, you could extract only those keys, values, and data that you would most usually be interested. From there, you'd have less to analyze, and still have the original data.
Saturday, October 07, 2006
Innovation
This post is likely to be the first of several, as it's something I've been thinking about for quite a while, and it takes new form and shape every time it pops into my head. So...please bear with me...
We see all the time that cybercrime is increasing in sophistication. We see this in reports and surveys, as well as in quotes. From this, we can assume (correctly) that there is a widening gap in abilities and resources between those committing the crimes, and those investigating the crimes. This gap is created when innovation occurs on one side of the equation, and not on the other.
I guess we need to start with the question, is there a need for innovation in the field of incident response (IR), and consequently computer forensic (CF) analysis?
I know that this is going to open up a whole can of worms, because not everyone who reads this is going to interpret it the same way. Even though I get this question running around inside my brain housing group from time to time, I don't think I really have a solid grasp of the concept yet. I see things and I think to myself, "Hey, we could really use some innovation here", or as in the case of Jesse Kornblum's ssdeep, "Hey, THAT'S an innovation!!"
I know what isn't an innovation, though...hash lists are not an innovation. Not any more. Sorry. 'nuff said.
Let's look at it this way...right now, Windows systems are being investigated all the time. I'm on several public and member-only forums, so I see the questions...some of the same ones appear all the time. There are just some things that folks don't know about yet, or don't have a clear understanding of, and simply don't have the time to research it themselves. From a more general perspective, there are areas of a Windows system that are not investigated on a wide basis, simply due to lack of understanding (of what data is available and how it could affect the investigation). I firmly believe that if there were more of an understanding and more knowledge of these areas, some investigations reap significant benefits.
So, is the innovation need in the area of knowledge, communication, or both?
Vista is bringing about innovations in technology. Un- or under-documented file formats require application-specific innovations (and these include Registry entries, not just binary format).
See what I mean? It's kind of hard to put your finger on, even though it's there...just outside your direct line of vision, like trying to see someone at a distance, at night. On the one hand, cybercrime has a motivation to innovate...money. Innovations are made out of necessity. But what about other cases or issues, such as missing childern? Business innovations in technology and applications (MySpace, Xanga, IM applications, etc.) just naturally require innovations in the areas of understanding, investigations, and subsequently communications. Outside innovations in storage media have led to different (albiet, not new) means of committing information theft and fraud.
Thoughts?
We see all the time that cybercrime is increasing in sophistication. We see this in reports and surveys, as well as in quotes. From this, we can assume (correctly) that there is a widening gap in abilities and resources between those committing the crimes, and those investigating the crimes. This gap is created when innovation occurs on one side of the equation, and not on the other.
I guess we need to start with the question, is there a need for innovation in the field of incident response (IR), and consequently computer forensic (CF) analysis?
I know that this is going to open up a whole can of worms, because not everyone who reads this is going to interpret it the same way. Even though I get this question running around inside my brain housing group from time to time, I don't think I really have a solid grasp of the concept yet. I see things and I think to myself, "Hey, we could really use some innovation here", or as in the case of Jesse Kornblum's ssdeep, "Hey, THAT'S an innovation!!"
I know what isn't an innovation, though...hash lists are not an innovation. Not any more. Sorry. 'nuff said.
Let's look at it this way...right now, Windows systems are being investigated all the time. I'm on several public and member-only forums, so I see the questions...some of the same ones appear all the time. There are just some things that folks don't know about yet, or don't have a clear understanding of, and simply don't have the time to research it themselves. From a more general perspective, there are areas of a Windows system that are not investigated on a wide basis, simply due to lack of understanding (of what data is available and how it could affect the investigation). I firmly believe that if there were more of an understanding and more knowledge of these areas, some investigations reap significant benefits.
So, is the innovation need in the area of knowledge, communication, or both?
Vista is bringing about innovations in technology. Un- or under-documented file formats require application-specific innovations (and these include Registry entries, not just binary format).
See what I mean? It's kind of hard to put your finger on, even though it's there...just outside your direct line of vision, like trying to see someone at a distance, at night. On the one hand, cybercrime has a motivation to innovate...money. Innovations are made out of necessity. But what about other cases or issues, such as missing childern? Business innovations in technology and applications (MySpace, Xanga, IM applications, etc.) just naturally require innovations in the areas of understanding, investigations, and subsequently communications. Outside innovations in storage media have led to different (albiet, not new) means of committing information theft and fraud.
Thoughts?
Friday, October 06, 2006
d00d, you can do it on Windows, too!
Jesse Kornblum had a couple of interesting posts recently on his blog, both relating to ssdeep. Yes, Jesse, I found the ssdeep stuff to be more interesting than the cat stuff. Sorry! One post was about using ssdeep to discover code re-use by comparing files in directories, and the other one was about using ssdeep to tie a portion of a file to the original. Very cool stuff.
I've gotta say that ssdeep is one of the true innovations in incident response and computer forensics. This isn't a new/different implementation of something that's already there...this is truly something new.
I've gotta say that ssdeep is one of the true innovations in incident response and computer forensics. This isn't a new/different implementation of something that's already there...this is truly something new.
Thursday, October 05, 2006
VMWare Converter (beta)
I received an email this morning that mentioned the release of VMWare's Converter tool, which is still in beta. Clicking on the "Registry Now" button lets you register for the beta.
The Converter is a tool that allows you to convert between formats. From the web page:
The Converter is a tool that allows you to convert between formats. From the web page:
- Supports cloning a wide variety of Windows OS platforms including Windows XP, Windows Server 2003, Windows 2000, Windows NT 4 (SP4 +) and 64-bit Windows Support (Windows XP and Windows Server 2003).
- Supports conversion of standalone VMware virtual machine disk formats (VMware Player, VMware Workstation, VMware GSX Server and VMware Server) across all VMware virtual machine platforms (including ESX 3.0 server and VC 2.0 managed servers as target host).
- Supports conversion of 3rd party disk image formats such as Microsoft Virtual PC, Microsoft Virtual Server, Symantec Backup Exec System Recovery (formerly LiveState Recovery) and Norton Ghost9 (or higher) to VMware virtual machine disk format.
Tuesday, October 03, 2006
Rootkits revisted
I was browsing the F-Secure blog this morning and found something interesting...from last Friday, there was this post about reselling stolen information. Now, this is nothing new...this is just part of how organized online crime is becoming. Rather than one person doing everything, someone will purchase malware and use it to infect systems, then collect the data from Protected Storage, keystroke loggers, etc. This information is then sold to others for use...in fraud, identity theft, etc.
For a good example of this, take a look at Brian Krebs' story from 19 Feb 06.
What I thought was most interesting about the F-Secure blog entry was this:
These changing Haxdoor variants are generated with a toolkit known as "A-311 Death".
My post on Gromozon has some links to rootkit detection software.
Additional Resources:
AusCERT
McAfee Rootkits: The Growing Threat paper
Symantec C variant, D variant
For a good example of this, take a look at Brian Krebs' story from 19 Feb 06.
What I thought was most interesting about the F-Secure blog entry was this:
These changing Haxdoor variants are generated with a toolkit known as "A-311 Death".
The toolkit itself is sold on the Internet by its author, known as "Corpse" or "Korpsov".
Okay, this is nothing new, either. Selling malware toolkits or custom rootkits is nothing new, either. This toolkit is based on Haxdoor. I started taking a look around and I found some interesting links. One was from the nmap-dev list...it's a discussion of a service detection signature for rootkits produced from this toolkit.My post on Gromozon has some links to rootkit detection software.
Additional Resources:
AusCERT
McAfee Rootkits: The Growing Threat paper
Symantec C variant, D variant
FSP/FRU File Copy Client posted
I posted the File Copy Client (FCli) that was mentioned in Windows Forensics and Incident Recovery. After getting enough questions about it, I thought that it was about time that I uploaded it to the SourceForge site.
The FCli is a GUI client that the investigator can use to select files to be copied from the 'victim' system, over to the FSP server. Here's how you use it (I am going to create webinar/movie files for this stuff for the book)...download the archive from the SF site, and keep all of the files (EXE and associated DLLs) together in the same directory. For initial testing, you may want to have them separate from other tools and files. Launch FCli, and choose File -> Config...enter the IP address and port of the FSP server. Then choose File -> Open and use the dialog to select the files that you want to copy (web server log files, etc.). Once you've selected the files that you want, click OK to close the dialog and the file names will be added to the FCli ListView (you can go back and open the File -> Open dialog again, if you wish).
Once you have selected the files you want to copy, click "OK" in the main FCli window. The status bar on the bottom of the window will show you your progress...it may go fairly quickly. Once all the files are copied over, simply close the window.
What FCli does is first collect metadata about the file...size, MAC times, and MD5/SHA-1 hashes. This data is sent to the FSP server and archived. The file itself is then copied over to the server, at which point the server verifies the hashes. Here's an extract from the case log file:
Mon Oct 2 21:26:14 2006;DATA command received: bho2.dat
Mon Oct 2 21:26:14 2006;HASH bho2.dat:885f60ff031496a3fe37aa15454c6a46:bf402abbbe76e417105d18ad9193436315dd7343
Mon Oct 2 21:26:14 2006;FILE command received: bho2.pl
Mon Oct 2 21:26:14 2006;bho2.pl created and opened.
Mon Oct 2 21:26:14 2006;bho2.pl closed. Size 1522
Mon Oct 2 21:26:14 2006;MD5 hashes confirmed for bho2.pl.
Mon Oct 2 21:26:14 2006;SHA-1 hashes confirmed for bho2.pl.
First, the metadata is sent to the server and saved in a file with the .dat extension (next version needs to change this, in case of a conflict with a file with a .dat extension), and the hashes are pulled out of the file and logged. Then the file is copied over and the size of the file on the server, after it's been written, is logged (you can verify this later with the size recorded in the metadata). Then the file hashes are computed for the file that is now on the server, and confirmed against the metadata.
The archive you want from the SF site is fcli_20061003.zip. This archive contains the executable file and all supporting DLLs, as well as the Perl source code for the FCli.
Thanks, and enjoy!
Addendum: It seems that WinRAR-compressed files don't always play well with other compression utilities, so I updated the archive and uploaded it...look for fcli_20061003a.zip
The FCli is a GUI client that the investigator can use to select files to be copied from the 'victim' system, over to the FSP server. Here's how you use it (I am going to create webinar/movie files for this stuff for the book)...download the archive from the SF site, and keep all of the files (EXE and associated DLLs) together in the same directory. For initial testing, you may want to have them separate from other tools and files. Launch FCli, and choose File -> Config...enter the IP address and port of the FSP server. Then choose File -> Open and use the dialog to select the files that you want to copy (web server log files, etc.). Once you've selected the files that you want, click OK to close the dialog and the file names will be added to the FCli ListView (you can go back and open the File -> Open dialog again, if you wish).
Once you have selected the files you want to copy, click "OK" in the main FCli window. The status bar on the bottom of the window will show you your progress...it may go fairly quickly. Once all the files are copied over, simply close the window.
What FCli does is first collect metadata about the file...size, MAC times, and MD5/SHA-1 hashes. This data is sent to the FSP server and archived. The file itself is then copied over to the server, at which point the server verifies the hashes. Here's an extract from the case log file:
Mon Oct 2 21:26:14 2006;DATA command received: bho2.dat
Mon Oct 2 21:26:14 2006;HASH bho2.dat:885f60ff031496a3fe37aa15454c6a46:bf402abbbe76e417105d18ad9193436315dd7343
Mon Oct 2 21:26:14 2006;FILE command received: bho2.pl
Mon Oct 2 21:26:14 2006;bho2.pl created and opened.
Mon Oct 2 21:26:14 2006;bho2.pl closed. Size 1522
Mon Oct 2 21:26:14 2006;MD5 hashes confirmed for bho2.pl.
Mon Oct 2 21:26:14 2006;SHA-1 hashes confirmed for bho2.pl.
First, the metadata is sent to the server and saved in a file with the .dat extension (next version needs to change this, in case of a conflict with a file with a .dat extension), and the hashes are pulled out of the file and logged. Then the file is copied over and the size of the file on the server, after it's been written, is logged (you can verify this later with the size recorded in the metadata). Then the file hashes are computed for the file that is now on the server, and confirmed against the metadata.
The archive you want from the SF site is fcli_20061003.zip. This archive contains the executable file and all supporting DLLs, as well as the Perl source code for the FCli.
Thanks, and enjoy!
Addendum: It seems that WinRAR-compressed files don't always play well with other compression utilities, so I updated the archive and uploaded it...look for fcli_20061003a.zip
Monday, October 02, 2006
E-Evidence.info site updated
The E-Evidence site was updated earlier today...as always, lots of interesting stuff! Thanks, Christine!
When did a user's access change?
I saw a question today on the Windows Forensic Analysis group on Yahoo that I thought was definitely worth repeating here. One of the members said that he was investigation a situation in which a limited helpdesk account was found to have Administrator-level rights on a system; his question was, how could he go about determining when the access level had changed.
Well, he never mentioned the version of Windows he was faced with, but if he were working with Windows XP or above, he could make use of the System Restore Points to answer that question.
How? Well, I wrote a ProScript to use with ProDiscover that parses through the SAM file of the Registry to extract things such as user information, and group membership information. Andreas posted some really good info on the specifics of parsing the Registry values, so I won't repeat it here. So...the ProScript works with the regular Registry files, but what to do about the Registry files located in the Restore points? Well, that's where the Offline Registry Parser comes in. By adapting regp.pl (from the SourceForge site) to include some code from my ProScript, one can then go back and parse through each of the SAM files in the Restore Points, until you find a point where the helpdesk account is no longer included in the Administrators account. Note that this will only work for accounts local on the system.
Not sure about the scripting but have a need for a tool that does something like this? Regp.pl will parse through the SAM file, dumping it all out to ASCII text, but it currently does not translate the specific values, particularly those that are REG_BINARY or REG_NONE types. However, a modicum of modification is all that's necessary to dump a report of just the information you want from that file. If this is something you'd be interested in, let me know, and maybe we can discuss some custom Perl coding. Need an EXE instead of a script? I can help with that, too.
Well, he never mentioned the version of Windows he was faced with, but if he were working with Windows XP or above, he could make use of the System Restore Points to answer that question.
How? Well, I wrote a ProScript to use with ProDiscover that parses through the SAM file of the Registry to extract things such as user information, and group membership information. Andreas posted some really good info on the specifics of parsing the Registry values, so I won't repeat it here. So...the ProScript works with the regular Registry files, but what to do about the Registry files located in the Restore points? Well, that's where the Offline Registry Parser comes in. By adapting regp.pl (from the SourceForge site) to include some code from my ProScript, one can then go back and parse through each of the SAM files in the Restore Points, until you find a point where the helpdesk account is no longer included in the Administrators account. Note that this will only work for accounts local on the system.
Not sure about the scripting but have a need for a tool that does something like this? Regp.pl will parse through the SAM file, dumping it all out to ASCII text, but it currently does not translate the specific values, particularly those that are REG_BINARY or REG_NONE types. However, a modicum of modification is all that's necessary to dump a report of just the information you want from that file. If this is something you'd be interested in, let me know, and maybe we can discuss some custom Perl coding. Need an EXE instead of a script? I can help with that, too.