Lenny Zeltser has an excellent presentation on his web site that discusses how to respond to the unexpected. This presentation is well worth the time it takes to read it...and I mean that not only for C-suite executives, but also IT staff and responders, as well. Take a few minutes to read through the presentation...it speaks a lot of truth.
When discussing topics like this, in the past, I've thought it would be a good idea to split the presentation, discussing responding as (a) a consultant and (b) as a full-time employee (FTE) staff member. My reasoning was that as a consultant, you're walking into a completely new environment, and as a member of FTE staff, you've been working in that environment for weeks, months, or even years, and would tend to be very familiar with the environment. However, as a consultant/responder, my experience has been that most response staff isn't familiar with the incident response aspect of their...well...incident response. FTE response staff is largely ad-hoc, as well as under-trained, in response...so while they may be very familiar with the day-to-day management of systems, most times they are not familiar with how to respond to incidents in a manner that's consistent with senior management's goals. If there are any. After all, if they were, folks like me wouldn't need to be there, right?
So, the reason I mention this at all is that when an incident occurs, the very first decisions made and actions that occur have a profound effect on how the incident plays out. If (not when) an incident is detected, what happens? Many times, an admin pulls the system, wipes the drive, and then reloads the OS and data, and puts the system back into service. While this is the most direct route to recovery, it does absolutely nothing to determine the root cause, or prevent the incident from happening again in the future.
The general attitude seems to be that the needs of infosec in general, and IR activities in particular, run counter to the needs of the business. IR is something of a "new" concept to most folks, and very often, the primary business goal is to keep systems running and functionality available, whereas IR generally wants to take systems offline. In short, security breaks stuff.
Well, this can be true, IF you go about your security and IR blindly. However, if you look at incident response specifically, and infosec in general, as a business process, and incorporate it along with your other business processes (i.e., marketing, sales, collections, payroll, etc.), then you can not only maintain your usability and productivity, but you're going to save yourself a LOT of money and headaches. You're not only going to be in compliance (name your legislative or regulatory body/ies of choice with that one...) and avoid costly audits, re-audits and fines, but you're also likely going to save yourself when (notice the use of the word when, rather than if...) an incident happens.
I wanted to present a couple of scenarios based on culminations my own experience performing incident response in various environments for over 10 years. I think these scenarios are important, because like other famous events in history, they can show us what we've done right or wrong.
Scenario 1: An incident, a malware infection, is detected and the local IT staff reacts quickly and efficiently, determining that the malware was on 12 different systems in the infrastructure and eradicating each instance. During the course of response, someone found a string, and without any indication that it applied directly to the incident, Googled the string and added a relationship with a keystroke logger to the incident notes. A week later at a director's meeting, the IT director described the incident and applauded his staff's reactions. Legal counsel, also responsible for compliance, took issue with the incident description, due to the possibility of and the lack of information regarding data exfiltration. Due to the location and use of the "cleaned" systems within the infrastructure, regulatory and compliance issues are raised, due in part to the malware association with a keystroke logger, but questions cannot be answered, as the actual malware itself was never completely identified nor was a sample saved. Per legislative and regulatory requirements, the organization must now assume that any sensitive data that could have been exfiltrated was, in fact, compromised.
Scenario 2: An incident is detected involving several e-commerce servers. The local IT staff is not trained, nor has any practical knowledge of IR, and while their manager reports potential issues to his management, a couple of admins begin poking around on the servers, installing and running AV (nothing found), deleting some files, etc. Management decides to wait to see if the "problem" settles down. Two days later, one of the admins decides to connect a sniffer to the outbound portion of the network, and sees several files being moved off of the systems. Locating those files on the systems, the admin determines that the files contain PCI data; however, the servers themselves cannot be shut down. The admin reports this, but it takes 96 hrs to locate IR consultants, get them on-site, and have the IT staff familiarize the consultants with the environment. It takes longer due to the fact that the one IT admin who knows how the systems interact and where they're actually located in the data center is on vacation.
Scenario 3: A company that provided remote shell-based access for their employees was in the process of transitioning to two-factor authentication when a regular log review detected that particular user credentials were being used to log in from a different location. IT immediately shut down all remote access, and changed all admin-level passwords. Examination of logs indicated that the intruder had accessed the infrastructure with one set of credentials, used those to transition to another set, but maintained shell-based access. The second account was immediately disabled, but not deleted. While IR consultants were on their way on-site, the local IT staff identified systems the intruder had accessed. A definitive list of files known to contain 'sensitive data' (already compiled) was provided to the consultants, who determined through several means that there were no indications that those files had been accessed by the intruder. The company was able to report this with confidence to regulatory oversight bodies, and while a small fine was imposed, a much larger fine, as well as notification and disclosure costs, followed by other costs (i.e., cost to change credit/debit cards, pay for credit monitoring, civil suits, etc.) were avoided.
Remember, we're not talking about a small, single-owner storefront here...we're talking about companies that store and process data about you and me...PII, PHI, PCI/credit card data, etc. Massive amounts of data that someone wants because it means massive amounts of money to them.
So, in your next visit from an auditor, when they ask "Got IR?" what are you going to say?
Showing posts with label live response. Show all posts
Showing posts with label live response. Show all posts
Friday, March 26, 2010
Saturday, August 08, 2009
Thoughts on using a "trusted shell"
Recently I've seen the topic of using a "trusted shell", especially when performing live response on Windows systems, brought up in a couple of forums.
The idea of a "trusted shell" comes from the use of statically-compiled binaries on *nix systems, where the actual executable file carries with it it's own libraries and does not rely on libraries on the "victim" system. The idea is that if the actual shell binary or any of the dependent libraries have been compromised, the responder can still get accurate information due to the fact that she's using a "trusted shell". And, of course, there's always the concern about "rootkits", but whenever I see a post or email that includes a reference to rootkits, my FUD radar goes off; in most cases, I don't think that folks understand rootkits, per se. For example, why say that you're only going to use a "trusted" cmd.exe because the cmd.exe on the system may have been subverted by a rootkit, when your "trusted" cmd.exe is going to use the same DLLs as the native one? I mean, most rootkits hook or subvert API functions, not executables.
Mapping this to the world of Windows incident response, one has to ask, how do you statically compile an executable for Windows? Can you even do this? At some point, you're going to have to rely on an MS-provided DLL, and its all a matter of how deeply the system has been compromised. After all, if the intruder is able to compromise extremely low-level APIs to the point of tricking the kernel, it's game over!
Even using SxS manifests will very likely present their own unique set of problems, particularly since most currently available tools and applications don't use manifests and would need to be rewritten.
Finally when running cmd.exe, there are a number of ways to subvert the use of just that executable without ever touching or modifying the EXE or any of its dependent DLLs. One is through the use of the Command Processor\AutoRun Registry entry (HKLM or HKCU), one is through the exefile Registry entries, and another is through the Image File Execution Options Registry key.
So that leaves me with the question of, why are folks stressing so much about "trusted" shells, when we can't even figure out what that is?
Another way to look at this is that if we've done our IR planning, maybe we want the operating system to lie to us. Think about it...if we're using some form of differential analysis, wouldn't we want to run "netstat -ano" on a system, and then compare that output to a packet capture, firewall logs, or even an nmap scan? Or how about using tools that use disparate API calls, such as perhaps pslist.exe and handle.exe, to get similar information (ie, process listing)? Wouldn't we get some benefit from quick, automatic parsing of the data that would highlight disparities in the output? Let's say you're seeing a steady stream of data flowing from a system, and you have firewall and IDS logs, as well as a packet capture, and the output of netstat shows in indication of the use of the port? Wouldn't this sort of analysis provide us with something useful, and obviate the need for speculation and assumption?
What are your thoughts?
The idea of a "trusted shell" comes from the use of statically-compiled binaries on *nix systems, where the actual executable file carries with it it's own libraries and does not rely on libraries on the "victim" system. The idea is that if the actual shell binary or any of the dependent libraries have been compromised, the responder can still get accurate information due to the fact that she's using a "trusted shell". And, of course, there's always the concern about "rootkits", but whenever I see a post or email that includes a reference to rootkits, my FUD radar goes off; in most cases, I don't think that folks understand rootkits, per se. For example, why say that you're only going to use a "trusted" cmd.exe because the cmd.exe on the system may have been subverted by a rootkit, when your "trusted" cmd.exe is going to use the same DLLs as the native one? I mean, most rootkits hook or subvert API functions, not executables.
Mapping this to the world of Windows incident response, one has to ask, how do you statically compile an executable for Windows? Can you even do this? At some point, you're going to have to rely on an MS-provided DLL, and its all a matter of how deeply the system has been compromised. After all, if the intruder is able to compromise extremely low-level APIs to the point of tricking the kernel, it's game over!
Even using SxS manifests will very likely present their own unique set of problems, particularly since most currently available tools and applications don't use manifests and would need to be rewritten.
Finally when running cmd.exe, there are a number of ways to subvert the use of just that executable without ever touching or modifying the EXE or any of its dependent DLLs. One is through the use of the Command Processor\AutoRun Registry entry (HKLM or HKCU), one is through the exefile Registry entries, and another is through the Image File Execution Options Registry key.
So that leaves me with the question of, why are folks stressing so much about "trusted" shells, when we can't even figure out what that is?
Another way to look at this is that if we've done our IR planning, maybe we want the operating system to lie to us. Think about it...if we're using some form of differential analysis, wouldn't we want to run "netstat -ano" on a system, and then compare that output to a packet capture, firewall logs, or even an nmap scan? Or how about using tools that use disparate API calls, such as perhaps pslist.exe and handle.exe, to get similar information (ie, process listing)? Wouldn't we get some benefit from quick, automatic parsing of the data that would highlight disparities in the output? Let's say you're seeing a steady stream of data flowing from a system, and you have firewall and IDS logs, as well as a packet capture, and the output of netstat shows in indication of the use of the port? Wouldn't this sort of analysis provide us with something useful, and obviate the need for speculation and assumption?
What are your thoughts?
Wednesday, April 01, 2009
Extending Your Reach
As a consultant, one of the things I have always struggled with is an enterprise capability. Often, I'll go on-site for an organization, and the systems that are in-scope for the incident may potentially be the entire infrastructure, ranging from several hundred systems in a data center to several thousand systems across a city, state, or country.
In such instances, tools such as F-Response EE are lifesavers!
However, a full forensic capability isn't always what's necessary. Take the CommandLine Kungfu blog for example...episode 16 has the infamous Ed Skoudis showing us an excellent example of how to use tools inherent to Windows systems to check to see if the patch for MS08-067 has been installed. Ed's WMIC command line is:
C:\>wmic qfe where hotfixid="KB958644" list full
Run that on your own system and see what you get. WMIC makes use of the WMI classes, in this case, the QuickFixEngineering class.
As a sidenote, if you're a Perl freak (like me), or if you just want to add some error checking or nice formating to the output you get from the WMI class query, be sure to look at the MS Script Center repository of sample Perl code. This is a great place to start...for the most part, getting the code working is simply a matter of cut-and-paste. Also, there's a good deal of code on the Windows Forensic Analysis DVD that uses WMI, so you've got another resource available.
I ran a search for the KB958644 patch on my XP system via RegEdit and found it referenced in several locations, including:
HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB958644
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Management\ARPCache\KB958644
...and...
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
Another very cool thing is that RegRipper includes a plugin for the Uninstall key...which means that not only can you check for the patch while examining an acquired image, but you can also check live systems via F-Response EE and RegRipper!
Okay...but so what? Well, these approaches (WMIC, Perl, F-Response, RegRipper) give you (as a consultant or as an admin) an enterprise reach, and at a fraction of the cost (in dollars) of some of the big commercial products. Sometimes you don't need a commercial product to reach out and, say, check critical systems in your domain to see if they've been infected with Conficker...
In such instances, tools such as F-Response EE are lifesavers!
However, a full forensic capability isn't always what's necessary. Take the CommandLine Kungfu blog for example...episode 16 has the infamous Ed Skoudis showing us an excellent example of how to use tools inherent to Windows systems to check to see if the patch for MS08-067 has been installed. Ed's WMIC command line is:
C:\>wmic qfe where hotfixid="KB958644" list full
Run that on your own system and see what you get. WMIC makes use of the WMI classes, in this case, the QuickFixEngineering class.
As a sidenote, if you're a Perl freak (like me), or if you just want to add some error checking or nice formating to the output you get from the WMI class query, be sure to look at the MS Script Center repository of sample Perl code. This is a great place to start...for the most part, getting the code working is simply a matter of cut-and-paste. Also, there's a good deal of code on the Windows Forensic Analysis DVD that uses WMI, so you've got another resource available.
I ran a search for the KB958644 patch on my XP system via RegEdit and found it referenced in several locations, including:
HKLM\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB958644
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Management\ARPCache\KB958644
...and...
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
Another very cool thing is that RegRipper includes a plugin for the Uninstall key...which means that not only can you check for the patch while examining an acquired image, but you can also check live systems via F-Response EE and RegRipper!
Okay...but so what? Well, these approaches (WMIC, Perl, F-Response, RegRipper) give you (as a consultant or as an admin) an enterprise reach, and at a fraction of the cost (in dollars) of some of the big commercial products. Sometimes you don't need a commercial product to reach out and, say, check critical systems in your domain to see if they've been infected with Conficker...
Tuesday, September 30, 2008
Rootkit Detection
I received a comment to an older post from James (thanks, James!) yesterday who pointed me toward a very interesting article on Rootkit.com by Diablo. Diablo's article describes using the Windows CSRSS process as a built-in rootkit detection facility, and even provides some proof-of-concept code.
This is definitely worth a look, at least to get an understanding of the technique that Diablo is proposing. I've used RootkitRevealer and GMER as my primary tools for attempting to detect the use of rootkits on live systems, usually following some forensic analysis of the acquired image (feel free to ask me about this technique - but don't be afraid to share yours, as well).
Resources
How many csrss.exe process should be running in vista?
MS07-021
Default Processes in Windows 2000
This is definitely worth a look, at least to get an understanding of the technique that Diablo is proposing. I've used RootkitRevealer and GMER as my primary tools for attempting to detect the use of rootkits on live systems, usually following some forensic analysis of the acquired image (feel free to ask me about this technique - but don't be afraid to share yours, as well).
Resources
How many csrss.exe process should be running in vista?
MS07-021
Default Processes in Windows 2000
Friday, February 15, 2008
New Docs at SWGDE
The Scientific Working Group on Digital Evidence (SWGDE) has released some new documents, the most notable of which are the Vista Technical Notes, and the document on "Live Capture".
The document on Live Capture was very interesting! At only 5 pages in length (the first page is formal disclaimer stuff...), there isn't a whole lot of detail, and the timeliness of the document may be questionable, but the point is that the document does reference the benefits of performing "live capture"...a term which encompasses three different activities. The document spends only a small paragraph discussing RAM dumps, and in that paragraph refers to "DD" as a software tool that can be used for collecting the contents of memory...on Windows systems, this is no longer the case (unless you have an old copy of the version of dd.exe sitting around). Further, this article in the Forensic Magazine mentions the use of dcfldd (version 1.3.4 was reportedly used when writing the article) to dump RAM from a Windows system...however, the command line listed in the article no longer seems to work (although for some odd reason, on a Windows XP SP2 system, replacing "\\.\PhysicalMemory" with "/dev/mem" seems to get something). Oddly enough, the document doesn't mention ProDiscover (which had the ability to collect RAM and volatile data before EnCase), nor does it mention Nigilant32.
The section of the document that addresses live acquisition is also extremely short and bereft of any real content...I'd love to know what "careful planning" they are referring to, just as I'm sure others reading the document who've never done a live acquisition must be wondering.
But hey...don't get me wrong...I think it's a great thing that the document is out. The more these techniques and methodologies are discussed and presented, the more likely they are to be used and then become part of standard procedures.
The document on Live Capture was very interesting! At only 5 pages in length (the first page is formal disclaimer stuff...), there isn't a whole lot of detail, and the timeliness of the document may be questionable, but the point is that the document does reference the benefits of performing "live capture"...a term which encompasses three different activities. The document spends only a small paragraph discussing RAM dumps, and in that paragraph refers to "DD" as a software tool that can be used for collecting the contents of memory...on Windows systems, this is no longer the case (unless you have an old copy of the version of dd.exe sitting around). Further, this article in the Forensic Magazine mentions the use of dcfldd (version 1.3.4 was reportedly used when writing the article) to dump RAM from a Windows system...however, the command line listed in the article no longer seems to work (although for some odd reason, on a Windows XP SP2 system, replacing "\\.\PhysicalMemory" with "/dev/mem" seems to get something). Oddly enough, the document doesn't mention ProDiscover (which had the ability to collect RAM and volatile data before EnCase), nor does it mention Nigilant32.
The section of the document that addresses live acquisition is also extremely short and bereft of any real content...I'd love to know what "careful planning" they are referring to, just as I'm sure others reading the document who've never done a live acquisition must be wondering.
But hey...don't get me wrong...I think it's a great thing that the document is out. The more these techniques and methodologies are discussed and presented, the more likely they are to be used and then become part of standard procedures.
Sunday, November 11, 2007
Pimp my...live acquisition
Whenever you perform a live acquisition, what do you do? Document the system, write down things like the system model (ie., Dell PowerEdge 2960, etc), maybe write down any specific identifiers (such as the Dell service tag) and then acquire the system. But is this enough data? Are we missing things by not including the collection of other data in our live acquisition process?
What about collecting volatile data? I've had to perform live acquisitions of systems that had been rebooted multiple times since the incident was discovered, as well as systems that could not be acquired without booting them (SAS/SATA drives, etc.). Under those circumstances, maybe I wouldn't need to collect volatile data...after all, what data of interest would it contain...but maybe we should do so anyway.
How about collecting non-volatile data? Like the system name and IP address? Or the disk configuration? One of the tools available on the DVD that comes with my book lets you see the following information about hard drives attached to the system:
DeviceID : \\.\PHYSICALDRIVE0
Model : ST910021AS
Interface : IDE
Media : Fixed hard disk media
Capabilities :
Random Access
Supports Writing
Signature : 0x41ab2316
Serial No : 3MH0B9G3
DeviceID : \\.\PHYSICALDRIVE1
Model : WDC WD12 00UE-00KVT0 USB Device
Interface : USB
Media : Fixed hard disk media
Capabilities :
Random Access
Supports Writing
Signature : 0x96244465
Serial No :
Another tool lets you see the following:
Drive Type File System Path Free Space
----- ----- ----------- ----- ----------
C:\ Fixed NTFS 17.96 GB
D:\ Fixed NTFS 38.51 GB
E:\ CD-ROM 0.00
G:\ Fixed NTFS 42.24 GB
In the above output, notice that there are no network drives attached to the test system...no shares mapped. Had there been any, the "Type" would have been listed as "Network", and the path would have been displayed.
Does it make sense to acquire this sort of information when performing a live acquisition? If so, is this information sufficient...or, what other information, at a minimum, should be collected?
Are there conditions under which I would acquire certain info, but not others? For example, if the system had not been rebooted, would I dump the contents of physical memory (I'd say "yes" to that one)...however, if the system had been accessed by admins, scanned with AV, and rebooted several times, would it do me any good at that point to dump RAM or should I simply document the fact that I didn't, and why?
Would this information be collected prior to the live acquisition, or immediately following?
What are your thoughts...and why?
PS: If you can think of a pseudonym I can use...think of it as a "hacker handle" (that thing that Joey from Hackers kept whining about), but REALLY cool, like "Xzibit", let me know. Oh, yeah...Ovie Carroll needs one, too. ;-)
What about collecting volatile data? I've had to perform live acquisitions of systems that had been rebooted multiple times since the incident was discovered, as well as systems that could not be acquired without booting them (SAS/SATA drives, etc.). Under those circumstances, maybe I wouldn't need to collect volatile data...after all, what data of interest would it contain...but maybe we should do so anyway.
How about collecting non-volatile data? Like the system name and IP address? Or the disk configuration? One of the tools available on the DVD that comes with my book lets you see the following information about hard drives attached to the system:
DeviceID : \\.\PHYSICALDRIVE0
Model : ST910021AS
Interface : IDE
Media : Fixed hard disk media
Capabilities :
Random Access
Supports Writing
Signature : 0x41ab2316
Serial No : 3MH0B9G3
DeviceID : \\.\PHYSICALDRIVE1
Model : WDC WD12 00UE-00KVT0 USB Device
Interface : USB
Media : Fixed hard disk media
Capabilities :
Random Access
Supports Writing
Signature : 0x96244465
Serial No :
Another tool lets you see the following:
Drive Type File System Path Free Space
----- ----- ----------- ----- ----------
C:\ Fixed NTFS 17.96 GB
D:\ Fixed NTFS 38.51 GB
E:\ CD-ROM 0.00
G:\ Fixed NTFS 42.24 GB
In the above output, notice that there are no network drives attached to the test system...no shares mapped. Had there been any, the "Type" would have been listed as "Network", and the path would have been displayed.
Does it make sense to acquire this sort of information when performing a live acquisition? If so, is this information sufficient...or, what other information, at a minimum, should be collected?
Are there conditions under which I would acquire certain info, but not others? For example, if the system had not been rebooted, would I dump the contents of physical memory (I'd say "yes" to that one)...however, if the system had been accessed by admins, scanned with AV, and rebooted several times, would it do me any good at that point to dump RAM or should I simply document the fact that I didn't, and why?
Would this information be collected prior to the live acquisition, or immediately following?
What are your thoughts...and why?
PS: If you can think of a pseudonym I can use...think of it as a "hacker handle" (that thing that Joey from Hackers kept whining about), but REALLY cool, like "Xzibit", let me know. Oh, yeah...Ovie Carroll needs one, too. ;-)
Saturday, June 02, 2007
Thoughts on Live Acquisition
Recently, I've been doing some thinking about issues surrounding live acquisitions - specifically, acquiring an image from a system that is running, as opposed to either booting the system to an alternate OS, or removing the hard drive and hooking it up to a write-blocker.
There are several methods for performing a live acquisition, but most involve running an agent or application of some kind on the system itself. You can do this using ProDiscover (install or run the PDServer agent from a CD or thumb drive), FTK Imager (run from a CD or thumb drive, and write the image files to an external drive or an already-mapped share), or with good ol' dd and netcat running from a CD. Regardless of how you choose to do this, there is an additional process running on the system...so think Heisenberg's Uncertainty Principle, but in the digital realm.
So in acquiring an image from a live system, we need to introduce a process into a system of already running processes. While our intention is to take care and disturb the 'scene' as little as possible, it is simply a fact that we're going to leave some artifacts of our activities on the system...memory is consumed by our process, as are buffers, perhaps other processes have pages written out to the pagefile, etc. However, we address this issue with thorough documentation of our procedures and methodologies.
Now, in his book Computer Evidence: Collection & Preservation, Chris Brown describes the result of a live acquisition as a "smear", as from a temporal perspective, that's what we've got. Remember, it takes time to acquire an image from a hard drive, and if the system is still live and running when you acquire that image, then there is the distinct possibility that some sectors may change after you acquire them. Rather than having a sharp, distinct snapshot in time as when you acquire an image from a hard drive that has been removed from a system, you get a "smudge" or a "smear" instead. Also, as Greg Kelly pointed out in another forum recently, some of what we would normally consider stagnant data (Registry, files, etc.) can actually be considered volatile, and subject to change during the course of our acquisition...think log files, Event Log entries, the pagefile, etc.
Now, would it be possible to minimize this effect, by limiting what's running on the system during the acquisition? I believe that the answer to this is "yes". To do this, we'd need to take a couple of things into consideration. We'd should first ask ourselves, is this necessary? Hhhhmmm...if you're imaging the system over the network, and that system is still connected to the network, what is it doing on the network while you're acquiring your image? Is it serving up web pages, processing email, etc?
Before we continue, remember, we're talking about a live acquisition here, getting an image of the hard drive, NOT collecting the contents of memory.
Okay, that being said...if you're imaging over the network, is the system still providing services (shares via the Server service, etc.) that may have a significant effect on what you walk away with? We have to consider this in the face of what effect our actions will have on the system itself when we, say, disable a service. First, we have to see what processes are running, and to do that, we need to load some software and run another process (unless you're using the ProDiscover PDServer, as the agent provides this functionality, as well). Then we have to weigh the benefits of disabling the process or service against the "costs" of the effect that our actions have on the contents of the hard drive. Is that process really processing anything? We know that it may have file handles open, etc. But is there enough of an effect on the contents of the drive that it would make a significant difference within the time it takes to acquire the image? Also, if I disable that process/service, what happens? Any log files may be closed, perhaps the operating system itself will write an entry into the System or Application Event Log, etc.
Some of the processes or services I might consider shutting down include:
So, before doing any of this, we need to put some thought into it. What, if anything, am I going to disable or shut down? Do I even need to? In some cases, live acquistions I've done have been of systems that had already been taken off of the network (not by me) and shut down, and then rebooted so they could be acquired (acquisition via write-blocker was not possible). With no network connections, I'm not overly concerned about major changes to the system during the acquisition process...the NTP service may log a complaint with the Event Log, but little else may happen. However, this isn't always the case...we're seeing a greater need for live response, both in acquiring the contents of memory, as well as performing live acquisitions of major systems that cannot be brought down or offline. If this is the case, document it. On your acquisition worksheet or in your case notes, clearly state "these services could not be halted or disabled due to...".
This is just a first blush...getting my thoughts down, thinking through things, determining if there is even a strong enough need for something like this...perhaps a matrix of services and processes, and when its a good idea to shut them down, how to do so, etc. Is this necessary?
Also, because I know the question is going to come up...addressing this same issue in the face of acquiring the contents of physical memory is an entirely separate post. Stay tuned!
There are several methods for performing a live acquisition, but most involve running an agent or application of some kind on the system itself. You can do this using ProDiscover (install or run the PDServer agent from a CD or thumb drive), FTK Imager (run from a CD or thumb drive, and write the image files to an external drive or an already-mapped share), or with good ol' dd and netcat running from a CD. Regardless of how you choose to do this, there is an additional process running on the system...so think Heisenberg's Uncertainty Principle, but in the digital realm.
So in acquiring an image from a live system, we need to introduce a process into a system of already running processes. While our intention is to take care and disturb the 'scene' as little as possible, it is simply a fact that we're going to leave some artifacts of our activities on the system...memory is consumed by our process, as are buffers, perhaps other processes have pages written out to the pagefile, etc. However, we address this issue with thorough documentation of our procedures and methodologies.
Now, in his book Computer Evidence: Collection & Preservation, Chris Brown describes the result of a live acquisition as a "smear", as from a temporal perspective, that's what we've got. Remember, it takes time to acquire an image from a hard drive, and if the system is still live and running when you acquire that image, then there is the distinct possibility that some sectors may change after you acquire them. Rather than having a sharp, distinct snapshot in time as when you acquire an image from a hard drive that has been removed from a system, you get a "smudge" or a "smear" instead. Also, as Greg Kelly pointed out in another forum recently, some of what we would normally consider stagnant data (Registry, files, etc.) can actually be considered volatile, and subject to change during the course of our acquisition...think log files, Event Log entries, the pagefile, etc.
Now, would it be possible to minimize this effect, by limiting what's running on the system during the acquisition? I believe that the answer to this is "yes". To do this, we'd need to take a couple of things into consideration. We'd should first ask ourselves, is this necessary? Hhhhmmm...if you're imaging the system over the network, and that system is still connected to the network, what is it doing on the network while you're acquiring your image? Is it serving up web pages, processing email, etc?
Before we continue, remember, we're talking about a live acquisition here, getting an image of the hard drive, NOT collecting the contents of memory.
Okay, that being said...if you're imaging over the network, is the system still providing services (shares via the Server service, etc.) that may have a significant effect on what you walk away with? We have to consider this in the face of what effect our actions will have on the system itself when we, say, disable a service. First, we have to see what processes are running, and to do that, we need to load some software and run another process (unless you're using the ProDiscover PDServer, as the agent provides this functionality, as well). Then we have to weigh the benefits of disabling the process or service against the "costs" of the effect that our actions have on the contents of the hard drive. Is that process really processing anything? We know that it may have file handles open, etc. But is there enough of an effect on the contents of the drive that it would make a significant difference within the time it takes to acquire the image? Also, if I disable that process/service, what happens? Any log files may be closed, perhaps the operating system itself will write an entry into the System or Application Event Log, etc.
Some of the processes or services I might consider shutting down include:
- AntiVirus products - these things reach out on their own and update themselves, or run scans automatically
- Task Scheduler - check to see if there are any jobs scheduled to run...this can get in the way of your acquisition (also, see the "Notes from the Underground..." sidebar on pp 215-216 of my book for an interesting tidbit on hiding scheduled tasks)
- Windows Firewall - depending upon how it's configured (we'd want to check, of course) there may be some significant issues. I included a sample pfirewall.log file on the DVD with my book...I'd turned up logging on the firewall and hit it with nmap. ;-)
- Exchange/IIS - if the system is still connected to the network do you want it processing email and web pages during the acquisition? Think the same thing for the FTP and SMTP services that sometimes get installed along with IIS.
So, before doing any of this, we need to put some thought into it. What, if anything, am I going to disable or shut down? Do I even need to? In some cases, live acquistions I've done have been of systems that had already been taken off of the network (not by me) and shut down, and then rebooted so they could be acquired (acquisition via write-blocker was not possible). With no network connections, I'm not overly concerned about major changes to the system during the acquisition process...the NTP service may log a complaint with the Event Log, but little else may happen. However, this isn't always the case...we're seeing a greater need for live response, both in acquiring the contents of memory, as well as performing live acquisitions of major systems that cannot be brought down or offline. If this is the case, document it. On your acquisition worksheet or in your case notes, clearly state "these services could not be halted or disabled due to...".
This is just a first blush...getting my thoughts down, thinking through things, determining if there is even a strong enough need for something like this...perhaps a matrix of services and processes, and when its a good idea to shut them down, how to do so, etc. Is this necessary?
Also, because I know the question is going to come up...addressing this same issue in the face of acquiring the contents of physical memory is an entirely separate post. Stay tuned!
Saturday, May 19, 2007
Litchfield on Oracle Live Response
Thanks to Richard Bejtlich, I learned this morning that David Litchfield, famed security researcher with NGSSoftware, has released a paper entitled Oracle Forensics Part 4: Live Response. In that paper, David starts off by discussing live response in general, which I found to be very interesting, as he addresses some of the questions that we all face when performing live response, particularly those regarding trust and assurance...trusting the operating system, trusting what the tools are telling use, etc.
David's paper highlights some of the aspects of live response that every responder needs to be aware of...in particular, when the first responder arrives on-scene and wants to collect volatile data, she will usually start by assessing the situation, and then when she's ready to collect that volatile data, insert a CD full of tools into the CD-ROM drive. From David's paper:
When they insert the CD and run one of the tools, due to the way Windows launches new processes, the tool will have key system dynamic link libraries in its address space, i.e. the memory the tool uses.
Great point...but keep in mind that at this point in time, during live response, there really isn't any way to avoid this situation. It happens, and it has to happen. The key to live response isn't how to keep it from happening...rather, it's to have a thoroughly documented process that lets you address the situation head on.
One of the main concerns about live response is often, if we do live response and have to take the information to court, how do we prove that our investigation did not modify the "scene" in any way, and that everything is pristine? The fact is...we can't. Nor should we try. Instead, we need to have a thorough, documented process, and be able to show that while our actions did modify the "scene" (via the application of Locard's Exchange Principle or Heisenberg's Uncertainty Principle...) just as an EMT's actions will modify a real-world crime scene, as investigators we should be looking at the totality of the information or evidence that we're able to collect and examine.
So, in a nutshell, while it is possible that the tools we loaded and ran on the system to collect volatile data were themselves compromised by a patched version of ntdll.dll in memory, what does the totality of the information tell us?
One thing I would suggest is that when you're reading David's excellent paper, and you get to the General Steps of Live Response section, refer back to the Order of Volatility. Dave is correct in that the application-specific information (about Oracle in this case) should be collected last but IMHO, the first thing that should be collected, as soon as possible, is a complete snapshot of physical memory (check out the sample chapter for my book, Windows Forensic Analysis). The reason I would suggest collecting the contents of physical memory first have to do with David's description of process creation...when a process is created, an EPROCESS block and all of the other structures necessary (at least one ETHREAD block) are created, consuming memory. This means that as processes are created, the pages used by other processes will be swapped out to the pagefile. Knowing this, we should collect as much of the contents of RAM as possible before moving on and collecting specific items, such as running processes, or the memory contents (RAM + pagefile) of those processes, etc.
Okay, enough about live response for now...this is a topic that deserves it's own space.
I found David's paper to be particularly interesting, as some of the work I've been involved with (and likely will continue to be involved with) has had to do with databases; was the database compromised, and if so, was sensitive information extracted from the database. I'm not a database guy (ie, a DBA) but I do need to know some things about databases; per David's suggestion, it's often best for an incident responder to work shoulder-to-shoulder with an experienced DBA, bringing the forensics mindset (and requirements) to the table.
If you're interested in database security in general, check out David's databasesecurity.com site for more information and books related to database security. For additional information about other database topics, I picked up a link at Andrew Hay's blog, pointing to the Comprehensive SQL Injection Cheat Sheet (well, the cheat sheet is actually here). This resource is invaluable to anyone performing forensic analysis of a potentially compromised system, particularly if it either has a web server installed, or acted as a database back-end for a web-based system. Hint: any reference in web server logs to SQL stored procedures is worth looking at!
David's paper highlights some of the aspects of live response that every responder needs to be aware of...in particular, when the first responder arrives on-scene and wants to collect volatile data, she will usually start by assessing the situation, and then when she's ready to collect that volatile data, insert a CD full of tools into the CD-ROM drive. From David's paper:
When they insert the CD and run one of the tools, due to the way Windows launches new processes, the tool will have key system dynamic link libraries in its address space, i.e. the memory the tool uses.
Great point...but keep in mind that at this point in time, during live response, there really isn't any way to avoid this situation. It happens, and it has to happen. The key to live response isn't how to keep it from happening...rather, it's to have a thoroughly documented process that lets you address the situation head on.
One of the main concerns about live response is often, if we do live response and have to take the information to court, how do we prove that our investigation did not modify the "scene" in any way, and that everything is pristine? The fact is...we can't. Nor should we try. Instead, we need to have a thorough, documented process, and be able to show that while our actions did modify the "scene" (via the application of Locard's Exchange Principle or Heisenberg's Uncertainty Principle...) just as an EMT's actions will modify a real-world crime scene, as investigators we should be looking at the totality of the information or evidence that we're able to collect and examine.
So, in a nutshell, while it is possible that the tools we loaded and ran on the system to collect volatile data were themselves compromised by a patched version of ntdll.dll in memory, what does the totality of the information tell us?
One thing I would suggest is that when you're reading David's excellent paper, and you get to the General Steps of Live Response section, refer back to the Order of Volatility. Dave is correct in that the application-specific information (about Oracle in this case) should be collected last but IMHO, the first thing that should be collected, as soon as possible, is a complete snapshot of physical memory (check out the sample chapter for my book, Windows Forensic Analysis). The reason I would suggest collecting the contents of physical memory first have to do with David's description of process creation...when a process is created, an EPROCESS block and all of the other structures necessary (at least one ETHREAD block) are created, consuming memory. This means that as processes are created, the pages used by other processes will be swapped out to the pagefile. Knowing this, we should collect as much of the contents of RAM as possible before moving on and collecting specific items, such as running processes, or the memory contents (RAM + pagefile) of those processes, etc.
Okay, enough about live response for now...this is a topic that deserves it's own space.
I found David's paper to be particularly interesting, as some of the work I've been involved with (and likely will continue to be involved with) has had to do with databases; was the database compromised, and if so, was sensitive information extracted from the database. I'm not a database guy (ie, a DBA) but I do need to know some things about databases; per David's suggestion, it's often best for an incident responder to work shoulder-to-shoulder with an experienced DBA, bringing the forensics mindset (and requirements) to the table.
If you're interested in database security in general, check out David's databasesecurity.com site for more information and books related to database security. For additional information about other database topics, I picked up a link at Andrew Hay's blog, pointing to the Comprehensive SQL Injection Cheat Sheet (well, the cheat sheet is actually here). This resource is invaluable to anyone performing forensic analysis of a potentially compromised system, particularly if it either has a web server installed, or acted as a database back-end for a web-based system. Hint: any reference in web server logs to SQL stored procedures is worth looking at!
Sunday, April 15, 2007
Drive Encryption
One of the challenges posed by Vista to traditional forensic analysis is the use of BitLocker to encrypt data on the hard drive. However, this really isn't any different from other similar technologies such as PGP, etc., that already allow encryption of files, partitions, or drives.
The response to encountering active drive encryption, particularly when dealing with an uncooperative suspect, should be to acquire a live image of the system hard drive, as in many cases, powering off the system and removing the hard drive may result in encrypted data being imaged, and until we get some kind of instantaneous image translation technology, that would be a "Bad Thing" for analysts.
So, when approaching a system, how does one tell whether or not there's any drive encryption in use? Well, Hogfly wrote an excellent WMI VBS script for detecting BitLocker. Using Perl, you could implement this script and then "compile" it into a standalone EXE and run it from a CD prior to imaging.
At this point, all we'd need to do is come up with other "signatures" for drive encryption that we can look for. Using a checklist of visible references to look for on the screen, and combining that with a small applet that would be run from a CD and tell the responder (ie, LEO, etc.) if drive encryption was active and in-use, would likely be the best approach.
Thoughts?
The response to encountering active drive encryption, particularly when dealing with an uncooperative suspect, should be to acquire a live image of the system hard drive, as in many cases, powering off the system and removing the hard drive may result in encrypted data being imaged, and until we get some kind of instantaneous image translation technology, that would be a "Bad Thing" for analysts.
So, when approaching a system, how does one tell whether or not there's any drive encryption in use? Well, Hogfly wrote an excellent WMI VBS script for detecting BitLocker. Using Perl, you could implement this script and then "compile" it into a standalone EXE and run it from a CD prior to imaging.
At this point, all we'd need to do is come up with other "signatures" for drive encryption that we can look for. Using a checklist of visible references to look for on the screen, and combining that with a small applet that would be run from a CD and tell the responder (ie, LEO, etc.) if drive encryption was active and in-use, would likely be the best approach.
Thoughts?
Monday, April 09, 2007
Great news for IR and live response!
There was some great news recently for IR and live response!
Over the past couple of years, when discussing the viability and usefulness of live response, particularly as a source of evidence to be used in court, I have very often heard folks say, "I won't perform live response until there is case law to support its use."
Is it just me, or does sound like a chicken-or-the-egg thing? How can something be accepted in court if you're not willing to do the work and bring it into court in the first place? After all, look at everything that is used in court as evidence now, but at one time wasn't...fingerprints, DNA, even computer forensic evidence.
I was reading the TaoSecurity blog post regarding the Heckencamp case, and came across something interesting...that the court accepted a sysadmin's actions of logging into Heckencamp's computer to definitively determine that it was, in fact, the system being used to attack a mail server.
The Wired story mentions things like "counter-crack" and "counter-hacking", and I shudder at the use of both terms. The court's ruling includes a lot of discussion about expectation of privacy, but also includes such things as the fact that the sysadmin wasn't acting as an agent of law enforcement, but instead was acting to preserve the integrity of the mail server that was under attack. Basically, from what I can see in the opinion, the sysadmin confirmed that the system was used to attack the mail server by examining "network logs" and "after approximately 15 minutes of looking only in the temporary directory, without deleting, modifying, or destroying any files, Savoy [the sysadmin] logged off of the computer."
Okay, if anyone believes that nothing was modified in 15 minutes...well, that's a discussion for another time. After all, in order to access "network logs", a file would have had to have been accessed, modifying the last access time of the file...logging into the system itself would have modified logs, the contents of memory, etc...but I digress.
The Wired article ends in a monologue about vigilantism and student privacy, but that's not what I'm seeing here or interested in at all. Sure, the sysadmin used a username and password from a previous portion of his "investigation" to access Heckencamp's system, and the ethics of this can be argued until the cows come home. However, what I'm seeing is that live response may be starting to gain acceptance in court. If a sysadmin can log into a system and muck about for 15 minutes, why can't someone with a detailed process access a live system, collect necessary evidence as part of a thoroughly documented methodology, and then use that evidence in court?
Over the past couple of years, when discussing the viability and usefulness of live response, particularly as a source of evidence to be used in court, I have very often heard folks say, "I won't perform live response until there is case law to support its use."
Is it just me, or does sound like a chicken-or-the-egg thing? How can something be accepted in court if you're not willing to do the work and bring it into court in the first place? After all, look at everything that is used in court as evidence now, but at one time wasn't...fingerprints, DNA, even computer forensic evidence.
I was reading the TaoSecurity blog post regarding the Heckencamp case, and came across something interesting...that the court accepted a sysadmin's actions of logging into Heckencamp's computer to definitively determine that it was, in fact, the system being used to attack a mail server.
The Wired story mentions things like "counter-crack" and "counter-hacking", and I shudder at the use of both terms. The court's ruling includes a lot of discussion about expectation of privacy, but also includes such things as the fact that the sysadmin wasn't acting as an agent of law enforcement, but instead was acting to preserve the integrity of the mail server that was under attack. Basically, from what I can see in the opinion, the sysadmin confirmed that the system was used to attack the mail server by examining "network logs" and "after approximately 15 minutes of looking only in the temporary directory, without deleting, modifying, or destroying any files, Savoy [the sysadmin] logged off of the computer."
Okay, if anyone believes that nothing was modified in 15 minutes...well, that's a discussion for another time. After all, in order to access "network logs", a file would have had to have been accessed, modifying the last access time of the file...logging into the system itself would have modified logs, the contents of memory, etc...but I digress.
The Wired article ends in a monologue about vigilantism and student privacy, but that's not what I'm seeing here or interested in at all. Sure, the sysadmin used a username and password from a previous portion of his "investigation" to access Heckencamp's system, and the ethics of this can be argued until the cows come home. However, what I'm seeing is that live response may be starting to gain acceptance in court. If a sysadmin can log into a system and muck about for 15 minutes, why can't someone with a detailed process access a live system, collect necessary evidence as part of a thoroughly documented methodology, and then use that evidence in court?
Thursday, March 01, 2007
Book & Attending BlackHat DC
Recently, Troy Larson (bio and picture) graciously offered to review/tech edit my upcoming book, so to start, I asked the editor to send him two chapters; the one that covers volatile data collection and the one that covers Registry analysis. Here's a quote that I received from Troy regarding the Registry analysis chapter:
Speaking of the book, I found it on Amazon this morning, available for pre-order.
I spent most of yesterday at BlackHat DC and caught the first three presentations in the Forensics track...well most of them. I caught all of Kevin Mandia's presentation, as well as part of the presentation that followed on web app forensics, and then after lunch, I went to Nick Petroni and AAron Walter's presentation on VolaTools. Unfortunately, I didn't get to stay for the entire presentation.
Kevin's presentation was very interesting, addressing the need for live response. There were several comments that Kevin made, stating the need for "fast and light" response.
IMHO, there is a need for a greater understanding of live response...not just the technical aspects of it, but how those technical aspects can be applied to and affect the business infrastructure of an organization.
Following the presentation, I took a few minutes to jot down some notes and thoughts...I started by attempting to classify incidents (think of "Agent Smith" in The Matrix, classifying humans as a "virus") in terms of the speed of response required for each. I started by defining speed of response in general terms at first ("ASAP", etc.) and then attempting to become more specific but not to the point of minutes and seconds. Regardless of the angle I approached the problem from, the one thing that kept coming to mind were business requirements...what are the needs of the business? Sure, we've got all these great technical things we can do, and as Kevin pointed out (as did Nick and AAron), a lot of folks that he's talked to have said, "we've already got all this data (file system data, etc.) to analyze...we don't do live response because the last thing we need is more data!"
I guess the question this point is, is the data that you're currently collecting for analysis meeting your business needs? If you're backlogged 6 months in your analysis...probably not. Depending upon the nature (or class) of the incident and your business environment, it may/most likely will be useful to rapidly collect and analyze a specific subset of volatile data during live response so that you can get a better picture of the issue, and progress through your analysis more accurately and efficiently.
One of the things Kevin pointed out is that malware (can anyone verify that Kevin only said "malware" 6 times...I wasn't keeping track) is including the capability of modifying the MAC times of files written to the system. This is an anti-forensic technique that severely hampers those using the current "Nintendo forensics" approach to analysis.
I think that some people are beginning to recognize the need for live response and how it can be useful in an investigation. However, I think that the issue now is one of education...how do those currently doing response of any kind (live or otherwise) break out of their current mindset, and shift gears? By shifting to a more holistic approach and using live response where applicable, and in the appropriate manner, those people will begin to actually see how useful this activity can be.
The presentation I found to be the most interesting was Nick and AAron's "VolaTools" presentation. Once Nick finished with the overview (presenting some great information on why you'd want to use tools like this), AAron kicked off into the how portion of the talk. I think their approach is an excellent one, in that they've identified a major stumbling block for this kind of analysis...the tools that are available are not included with EnCase and are not "push the Find-All-Evidence button" kinds of tools, and people aren't using them because the tools themselves are too different. In a nutshell, there's a confidence factor that needs to be addressed. While Nick and AAron's tools are written in Python, they do provide a command-line interface in the Basic version of their tools that allow the user to extract information from a RAM dump in nearly the same manner as you would on a live system...to list the modules used, you would use a "dlllist" command (as opposed to listdlls.exe), and to list handles, you'd use "handles".
I can't wait to download and look at their tools...these two guys are really bright and have just moved the issue of Windows memory analysis forward a couple of huge leaps. And thanks to guys like Jesse Kornblum for things such as his Buffalo paper, because we can then use AAron and Nick's work as a basis for incorporating the pagefile into the memory analysis, as well.
Oh, and while I did meet both Ovie and Bret, unfortunately Ovie wasn't wearing his CyberSpeak t-shirt, so I guess I don't get to have a beer with Bret! ;-(
One final thing about BlackHat DC...seeing Jesse do his impression of a sardine was worth the price of admission! Speaking of Jesse, it looks like he's been busy on the ForensicWiki...
I really liked the registry chapter. It is worth the price of the book alone.Sweet! In the same email, Troy also mentioned that there wasn't as much info on Vista as there was on the other versions of Windows covered (2000, XP, 2003), but also said that this is largely due to the fact that there just isn't that much information available yet. secondedition
Speaking of the book, I found it on Amazon this morning, available for pre-order.
I spent most of yesterday at BlackHat DC and caught the first three presentations in the Forensics track...well most of them. I caught all of Kevin Mandia's presentation, as well as part of the presentation that followed on web app forensics, and then after lunch, I went to Nick Petroni and AAron Walter's presentation on VolaTools. Unfortunately, I didn't get to stay for the entire presentation.
Kevin's presentation was very interesting, addressing the need for live response. There were several comments that Kevin made, stating the need for "fast and light" response.
IMHO, there is a need for a greater understanding of live response...not just the technical aspects of it, but how those technical aspects can be applied to and affect the business infrastructure of an organization.
Following the presentation, I took a few minutes to jot down some notes and thoughts...I started by attempting to classify incidents (think of "Agent Smith" in The Matrix, classifying humans as a "virus") in terms of the speed of response required for each. I started by defining speed of response in general terms at first ("ASAP", etc.) and then attempting to become more specific but not to the point of minutes and seconds. Regardless of the angle I approached the problem from, the one thing that kept coming to mind were business requirements...what are the needs of the business? Sure, we've got all these great technical things we can do, and as Kevin pointed out (as did Nick and AAron), a lot of folks that he's talked to have said, "we've already got all this data (file system data, etc.) to analyze...we don't do live response because the last thing we need is more data!"
I guess the question this point is, is the data that you're currently collecting for analysis meeting your business needs? If you're backlogged 6 months in your analysis...probably not. Depending upon the nature (or class) of the incident and your business environment, it may/most likely will be useful to rapidly collect and analyze a specific subset of volatile data during live response so that you can get a better picture of the issue, and progress through your analysis more accurately and efficiently.
One of the things Kevin pointed out is that malware (can anyone verify that Kevin only said "malware" 6 times...I wasn't keeping track) is including the capability of modifying the MAC times of files written to the system. This is an anti-forensic technique that severely hampers those using the current "Nintendo forensics" approach to analysis.
I think that some people are beginning to recognize the need for live response and how it can be useful in an investigation. However, I think that the issue now is one of education...how do those currently doing response of any kind (live or otherwise) break out of their current mindset, and shift gears? By shifting to a more holistic approach and using live response where applicable, and in the appropriate manner, those people will begin to actually see how useful this activity can be.
The presentation I found to be the most interesting was Nick and AAron's "VolaTools" presentation. Once Nick finished with the overview (presenting some great information on why you'd want to use tools like this), AAron kicked off into the how portion of the talk. I think their approach is an excellent one, in that they've identified a major stumbling block for this kind of analysis...the tools that are available are not included with EnCase and are not "push the Find-All-Evidence button" kinds of tools, and people aren't using them because the tools themselves are too different. In a nutshell, there's a confidence factor that needs to be addressed. While Nick and AAron's tools are written in Python, they do provide a command-line interface in the Basic version of their tools that allow the user to extract information from a RAM dump in nearly the same manner as you would on a live system...to list the modules used, you would use a "dlllist" command (as opposed to listdlls.exe), and to list handles, you'd use "handles".
I can't wait to download and look at their tools...these two guys are really bright and have just moved the issue of Windows memory analysis forward a couple of huge leaps. And thanks to guys like Jesse Kornblum for things such as his Buffalo paper, because we can then use AAron and Nick's work as a basis for incorporating the pagefile into the memory analysis, as well.
Oh, and while I did meet both Ovie and Bret, unfortunately Ovie wasn't wearing his CyberSpeak t-shirt, so I guess I don't get to have a beer with Bret! ;-(
One final thing about BlackHat DC...seeing Jesse do his impression of a sardine was worth the price of admission! Speaking of Jesse, it looks like he's been busy on the ForensicWiki...
Subscribe to:
Posts (Atom)