Remember that old tag line from the '80's? It's right up there with "where's the beef!" However, my question is directed more toward forensic analysis, including anything collected during live response.
Where do you go for thoughts, input or validation regarding your live response process? Do you just grab a copy of Helix and run the WFT tools? Or are you concerned about doing that blindly (believe me, there are folks out there who aren't...), and want some kind of validation? (I'm not saying that WFT and toolkits like are bad...in fact, that's not the case at all. What I am saying is that running the tools without an understanding of what they're doing is a bad thing.)
What about analysis of an image? Do you ever reach out and ask someone for insight into your analysis, just to see if you've got all of your bases covered? If so, where do you go? Is it a tight group of folks you know, and you only contact them via email, or do you reach out to a listserv like CFID, or go on lists like ForensicFocus?
Another good example is the Linux Documentation Project and the list of HowTo documents. These are great sources of information...albeit not specific to forensic analysis...and something I've used myself.
NIST provides Special Publications in PDF format, and Security Horizon is distributed in PDF. CyberSpeak is a podcast. IronGeek posts videos, mostly due to hacking. I included a couple of desktop video captures on the DVD with my book, showing how to use some of the tools.
While agree that we don't need yet another resource to pile up on our desks and go unread, I do wonder at times why there isn't something out there specific to forensic analysis.
Saturday, December 29, 2007
Friday, December 28, 2007
Deleted Apps
Another question I've received, as well as seen in online forums, has to do with locating deleted applications.
As Windows performs some modicum of tracking of user activities, you may find references to applications that were launched in the UserAssist keys in the user's NTUSER.DAT file. Not only would you find references to launching the application or program itself, but I've seen where the user has clicked on the "Uninstall" shortcut that gets added to the Program menu of the Start Menu. I've also seen in the UserAssist keys where a user has launched an installation program, run the installed application, and then clicked on the Uninstall shortcut for the application.
You may also find references to the user launching the "Add/Remove Programs" Control Panel applet.
If you're dealing with an XP system you may find that if the application was originally installed via an MSI package, a Restore Point was created when the application was installed...and one may have been created when the application was removed, as well. So, be sure to parse those rp.log files in the Restore Points.
An MFT entry that has been marked as deleted is great for showing that a file, or even several files, had been deleted. Analysis of the Recycle Bin/INFO2 file may show you something useful. But there are other ways to find more data, to include showing that at one time, the application had been used...such as by parsing the .pf files in the XP Prefetch directory, and performing Registry analysis.
Other Resources:
Intentional Erasure
As Windows performs some modicum of tracking of user activities, you may find references to applications that were launched in the UserAssist keys in the user's NTUSER.DAT file. Not only would you find references to launching the application or program itself, but I've seen where the user has clicked on the "Uninstall" shortcut that gets added to the Program menu of the Start Menu. I've also seen in the UserAssist keys where a user has launched an installation program, run the installed application, and then clicked on the Uninstall shortcut for the application.
You may also find references to the user launching the "Add/Remove Programs" Control Panel applet.
If you're dealing with an XP system you may find that if the application was originally installed via an MSI package, a Restore Point was created when the application was installed...and one may have been created when the application was removed, as well. So, be sure to parse those rp.log files in the Restore Points.
An MFT entry that has been marked as deleted is great for showing that a file, or even several files, had been deleted. Analysis of the Recycle Bin/INFO2 file may show you something useful. But there are other ways to find more data, to include showing that at one time, the application had been used...such as by parsing the .pf files in the XP Prefetch directory, and performing Registry analysis.
Other Resources:
Intentional Erasure
The MAC Daddy
I received a question in my inbox today regarding locating a system's MAC address within an image of a system, and I thought I'd share the response I provided...
"The path to the key that tells you which NICs are/were in use on the system is:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards
Beneath this key, you will see a set of subkeys, each with different numbers;
on my system, I see "10", "12", and "2". Each of these keys contains values;
Description and ServiceName. The ServiceName value contains the GUID
for the interface.
Using the GUIDs, go to:
HKLM\SYSTEM\ControlSet00x\Services\Tcpip\Parameters
\Interfaces
*Be sure to use the ControlSet marked as "Current".
Beneath this key, you'll see subkeys with names that are GUIDs. You're
interested in the GUIDs you found beneath the previous key. Within each key,
you will find the values associated with that interface.
By default, Windows does not retain the MAC address in the Registry. I'm
aware that there are sites out there that say that it does, but they are incorrect...
at least, with regards to this key. If you *do* find an entry within the "Interfaces"
key above that contains a value such as "NetworkAddress", it is either specific
to the NIC/vendor, or it's being used to spoof the MAC address (this is a known
method).
Also check the following key for subkeys that contain a "NetworkAddress" value:
HKLM\SYSTEM\ControlSet001\Control\Class
\{4D36E972-E325-11CE-BFC1-08002bE10318}
Other places you can look for the MAC address:
*Sometimes* (not in all cases) if you find the following key, you may find a value
named "MAC", as well:
HKLM\SOFTWARE\Microsoft\Windows Genuine Advantage
Another place to look is Windows shortcut (*.lnk) files...Windows File Analyzer
is a GUI tool that parses directories worth of *.lnk files and one of the fields that
may be populated is the MAC address of the system."
I thought others might find this helpful as well...
Sunday, December 23, 2007
Perl Scripting Book
It looks like my Perl Scripting book made it out just in time for Christmas!Oddly enough, it only seems to be available on Amazon...I can't seem to locate it on the Syngress site, but I did find it on the Elsevier site (Elsevier owns Syngress).
Perl Scripting for IT Security is not a follow-on or companion to my previous book, Windows Forensic Analysis. Rather, it goes more into showing what can be done, and how it can be done, in the world of Incident Response and Computer Forensics Analysis using an open-source solution such as Perl. The book, in part, shows that with a little bit of knowledge and skill, we are no longer limited to viewing only what our commercial forensic analysis tools show us.
Addendum, 28 Dec: A box showed up on my doorstep today, with several copies of the book! Woot!
Sunday, December 02, 2007
Windows Shortcut (LNK) files
I saw a question in a forum recently regarding Windows Shortcut Files, and thought I would post something that included my findings from a quick test.
The question had to do with the file MAC times found embedded in the .lnk file, with respect to those found on the file system (FAT32 in this case). The question itself got me curious, so I ran a quick test of my own.
I located a .lnk file in my profile's (on my own system) Recent folder (NTFS partition) and ran the lslnk.pl script from my book against it, extracting (in part) the embedded file times:
MAC Times:
Creation Time = Fri Nov 16 20:33:21 2007 (UTC)
Modification Time = Fri Nov 16 22:47:50 2007 (UTC)
Access Time = Fri Nov 16 20:33:21 2007 (UTC)
I then double-clicked the Shortcut file itself (from within Windows Explorer), launching the .pdf file. I closed the .pdf file and used "dir /ta" to verify that the last access time on the shortcut file and on the .pdf file itself had been updated to the current time (in this case, 7:29am EST). I re-ran the lslnk.pl script against the original shortcut file, and extracted the same MAC times as seen above.
BTW...the creation date on the .pdf file in question is 11/16/2007 03:33 PM...which is identical to the creation date embedded in the shortcut file, with the time zone taken into account.
Based on extremely limited testing, it would appear that the MAC times in the shortcut file do not change following the initial creation of the shortcut file.
Can anyone confirm/verify this, on NTFS as well as FAT32?
The question had to do with the file MAC times found embedded in the .lnk file, with respect to those found on the file system (FAT32 in this case). The question itself got me curious, so I ran a quick test of my own.
I located a .lnk file in my profile's (on my own system) Recent folder (NTFS partition) and ran the lslnk.pl script from my book against it, extracting (in part) the embedded file times:
MAC Times:
Creation Time = Fri Nov 16 20:33:21 2007 (UTC)
Modification Time = Fri Nov 16 22:47:50 2007 (UTC)
Access Time = Fri Nov 16 20:33:21 2007 (UTC)
I then double-clicked the Shortcut file itself (from within Windows Explorer), launching the .pdf file. I closed the .pdf file and used "dir /ta" to verify that the last access time on the shortcut file and on the .pdf file itself had been updated to the current time (in this case, 7:29am EST). I re-ran the lslnk.pl script against the original shortcut file, and extracted the same MAC times as seen above.
BTW...the creation date on the .pdf file in question is 11/16/2007 03:33 PM...which is identical to the creation date embedded in the shortcut file, with the time zone taken into account.
Based on extremely limited testing, it would appear that the MAC times in the shortcut file do not change following the initial creation of the shortcut file.
Can anyone confirm/verify this, on NTFS as well as FAT32?
Saturday, December 01, 2007
Forensic Analysis
Often (well, often enough) we run into instances where it becomes evident that someone has an unrealistic expectation of what answers forensic analysis can provide.
I know that right now, most of you are thinking, "dude...no way!" But I say, truly, it is so. There's even a term for it...it's called the CSI Effect. There are even articles written about it (here, and here).
Let's look at an example of what I mean. Our hero, the forensic analyst and incident responder Dude Diligence gets a call from a company, and the caller says that they've been "hacked" ("hacked" is the new "smurfed", by the way...a verb with many nuances and flavors...). Dude gets on site to find that even before he was called, a considerable amount of remediation was going on...systems were being accessed and "cleaned" (another one of those verbs with many nuances and flavors...) by administrators, with no real focus as to who was doing what, when, or why?
I'm sure that by now, some of you who are consultants like our hero are now weeping into your beers, sobbing, "dude..." under your breath...but our story continues.
Dude does the best he can to get the story of what happened, and what systems were affected. In the end, he acquires images of about half a dozen systems and returned to the Dude Lab to do analysis. Before leaving, however, he made sure that he had a solid understanding of what questions needed to be answered for the customer...specifically, was this a targeted attack, and was sensitive data (could be credit card numbers, could be PII, PHI, etc.) compromised.
To make a long story short, ultimately what Dude finds is that...he can't find anything. Systems had not been configured for any sort of viable logging (the system, as well as applications), and what logs that were there had been removed from the system. Systems had been scanned with AV applications, etc., etc. Traces of the intruder's activity (if there was one) had been completely obliterated by the actions of those who "responded" to the incident. Even if Dude had determined that sensitive information was, in fact, on the system, he isn't able to provide a definitive response to the question of, does that information now, as a result of the intrusion/compromise, exist somewhere it shouldn't? Was it exposed?
Even under the best of circumstances, there are just some questions that forensic analysis cannot answer. One question that comes up time and time again, particularly in some of the online forensic forums, is, from an imaged system, can you tell what files were copied off of the system? Dude has found artifacts of files being uploaded to web-based email systems such as GMail, and found other artifacts, but what computer forensic artifacts are there if someone opens a Word or PDF document on their screen and copies information out of it onto a piece of paper, using a pen? How about if someone connects a removable storage device to the system and copies the files off onto to that device? Sure, there are artifacts of the device being connected to the system (particularly on Windows systems), but without actually imaging and analyzing that removable storage device, how would Dude determine what files were copied from the system to the device?
I've talked about alternative analysis techniques before, and the solutions I'm looking toward include, for example, how you may be able to show names of files that someone viewed, and possibly the dates, even if the user deleted and overwrote the files themselves, or viewed them from removable media, etc. There are lots of ways to get additional information through analysis of the Registry, Event Logs, and even of the contents of RAM captured from the system...but there are just some questions that computer forensics can not answer.
That being said, how does our hero Dude Diligence go about his dude-ly analysis? Well, to begin with, Dude is part-sysadmin. This means that he understands, or knows that he needs to understand, the interrelation between the different components of a system...be that the interrelation between the external router, firewall, and the compromised system within the network infrastructure, or the interrelation between the network, the apparently compromised host (i.e., the operating system), and the applications running on the host.
When it comes to analyzing intrusions, Dude doesn't have to be a pen-tester or "ethical hacker"...although it may help. Instead, Dude needs to shift his focus a bit and not so much concentrate on breaking into or compromising a system, but instead concentrate "around" it...what artifacts are left, and where, by various actions, such as binding a reverse shell to the system through the buffer overflow of an application or service? For example, when someone logs into a system (over the network via NetBIOS or ssh or some other application, or at the console), where would Dude expect to see artifacts? What does it mean to Dude if the artifacts are there? What if they're not there?
Remember Harlan's Corollary to Jesse's First Law of Computer Forensics?
This leads us back to the first statement in this post...there are some actions for which the artifacts are not available to forensic analysts like Dude when he's performing a post-mortem analysis, and there are some questions that simply cannot be answered by that analysis. There are some questions that can be answered, if Dude pursues the appropriate areas in his analysis...
I know that right now, most of you are thinking, "dude...no way!" But I say, truly, it is so. There's even a term for it...it's called the CSI Effect. There are even articles written about it (here, and here).
Let's look at an example of what I mean. Our hero, the forensic analyst and incident responder Dude Diligence gets a call from a company, and the caller says that they've been "hacked" ("hacked" is the new "smurfed", by the way...a verb with many nuances and flavors...). Dude gets on site to find that even before he was called, a considerable amount of remediation was going on...systems were being accessed and "cleaned" (another one of those verbs with many nuances and flavors...) by administrators, with no real focus as to who was doing what, when, or why?
I'm sure that by now, some of you who are consultants like our hero are now weeping into your beers, sobbing, "dude..." under your breath...but our story continues.
Dude does the best he can to get the story of what happened, and what systems were affected. In the end, he acquires images of about half a dozen systems and returned to the Dude Lab to do analysis. Before leaving, however, he made sure that he had a solid understanding of what questions needed to be answered for the customer...specifically, was this a targeted attack, and was sensitive data (could be credit card numbers, could be PII, PHI, etc.) compromised.
To make a long story short, ultimately what Dude finds is that...he can't find anything. Systems had not been configured for any sort of viable logging (the system, as well as applications), and what logs that were there had been removed from the system. Systems had been scanned with AV applications, etc., etc. Traces of the intruder's activity (if there was one) had been completely obliterated by the actions of those who "responded" to the incident. Even if Dude had determined that sensitive information was, in fact, on the system, he isn't able to provide a definitive response to the question of, does that information now, as a result of the intrusion/compromise, exist somewhere it shouldn't? Was it exposed?
Even under the best of circumstances, there are just some questions that forensic analysis cannot answer. One question that comes up time and time again, particularly in some of the online forensic forums, is, from an imaged system, can you tell what files were copied off of the system? Dude has found artifacts of files being uploaded to web-based email systems such as GMail, and found other artifacts, but what computer forensic artifacts are there if someone opens a Word or PDF document on their screen and copies information out of it onto a piece of paper, using a pen? How about if someone connects a removable storage device to the system and copies the files off onto to that device? Sure, there are artifacts of the device being connected to the system (particularly on Windows systems), but without actually imaging and analyzing that removable storage device, how would Dude determine what files were copied from the system to the device?
I've talked about alternative analysis techniques before, and the solutions I'm looking toward include, for example, how you may be able to show names of files that someone viewed, and possibly the dates, even if the user deleted and overwrote the files themselves, or viewed them from removable media, etc. There are lots of ways to get additional information through analysis of the Registry, Event Logs, and even of the contents of RAM captured from the system...but there are just some questions that computer forensics can not answer.
That being said, how does our hero Dude Diligence go about his dude-ly analysis? Well, to begin with, Dude is part-sysadmin. This means that he understands, or knows that he needs to understand, the interrelation between the different components of a system...be that the interrelation between the external router, firewall, and the compromised system within the network infrastructure, or the interrelation between the network, the apparently compromised host (i.e., the operating system), and the applications running on the host.
When it comes to analyzing intrusions, Dude doesn't have to be a pen-tester or "ethical hacker"...although it may help. Instead, Dude needs to shift his focus a bit and not so much concentrate on breaking into or compromising a system, but instead concentrate "around" it...what artifacts are left, and where, by various actions, such as binding a reverse shell to the system through the buffer overflow of an application or service? For example, when someone logs into a system (over the network via NetBIOS or ssh or some other application, or at the console), where would Dude expect to see artifacts? What does it mean to Dude if the artifacts are there? What if they're not there?
Remember Harlan's Corollary to Jesse's First Law of Computer Forensics?
This leads us back to the first statement in this post...there are some actions for which the artifacts are not available to forensic analysts like Dude when he's performing a post-mortem analysis, and there are some questions that simply cannot be answered by that analysis. There are some questions that can be answered, if Dude pursues the appropriate areas in his analysis...