Not too long ago, I blogged about ADSs and the Prefetch directory...and so far, I've only been able to replicate this behaviour on XP Pro. I've tried XP Home and 2003, with no luck.
Is anyone else seeing this behaviour, or have you been able to replicate this on XP Home/2003?
Thursday, March 31, 2005
Tuesday, March 29, 2005
How good is your Reg-foo?
Yes, I'm still working on the Registry Analysis HOWTO, subtitled "Your Reg-foo is very good..." (remember the old, poorly-dubbed "BlackBelt Theatre"??). I'm using what I've got so far as a stepping off point for a presentation at work, then a similar presentation at a conference in June.
I've got some interesting tidbits so far...detecting deleted user accounts, mapping USB-connected storage devices, etc.
I was wondering that things you guys look for (or want to know more about) in the Registry.
Before you comment or email me...malware stuff is pretty passe. It's well known. We all know about the ubiquitous 'Run' key. So keeping that in mind, send in your tips...
I've got some interesting tidbits so far...detecting deleted user accounts, mapping USB-connected storage devices, etc.
I was wondering that things you guys look for (or want to know more about) in the Registry.
Before you comment or email me...malware stuff is pretty passe. It's well known. We all know about the ubiquitous 'Run' key. So keeping that in mind, send in your tips...
How good is your Reg-foo?
Yes, I'm still working on the Registry Analysis HOWTO, subtitled "Your Reg-foo is very good..." (remember the old, poorly-dubbed "BlackBelt Theatre"??). I'm using what I've got so far as a stepping off point for a presentation at work, then a similar presentation at a conference in June.
I've got some interesting tidbits so far...detecting deleted user accounts, mapping USB-connected storage devices, etc.
I was wondering that things you guys look for (or want to know more about) in the Registry.
Before you comment or email me...malware stuff is pretty passe. It's well known. We all know about the ubiquitous 'Run' key. So keeping that in mind, send in your tips...
I've got some interesting tidbits so far...detecting deleted user accounts, mapping USB-connected storage devices, etc.
I was wondering that things you guys look for (or want to know more about) in the Registry.
Before you comment or email me...malware stuff is pretty passe. It's well known. We all know about the ubiquitous 'Run' key. So keeping that in mind, send in your tips...
Parsing the Prefetch directory
One comment from the previous blog entry asked for a program that would parse through the Prefetch directory and list all files, as well as the date/time that the application was last run. I've got that done...didn't take long at all...and will post the code over on the Windows-IR.com web site...check the Tools page. I'll try to get it posted tonight.
I've also written a Perl script that will parse the layout.ini file and for each executable (based on file extension....exe, .dll, and .sys) listed, will located the file and parse out available file version information. I'll post that script along with it's standalone .exe file to the Windows-IR.com site, as well.
Both programs will make an interesting addition to the FRU...perhaps even adding some code to the above programs to perform data reduction would provide more interesting results. However, I would definitely consider correlating the last access times of the .pf files from the Prefetch directory with things such as the uptime of the system, and any logon/logoff information you can get from the Security Event Log (in a pinch, last access times to the user directories may be useful if the appropriate auditing is not enabled).
I've also written a Perl script that will parse the layout.ini file and for each executable (based on file extension....exe, .dll, and .sys) listed, will located the file and parse out available file version information. I'll post that script along with it's standalone .exe file to the Windows-IR.com site, as well.
Both programs will make an interesting addition to the FRU...perhaps even adding some code to the above programs to perform data reduction would provide more interesting results. However, I would definitely consider correlating the last access times of the .pf files from the Prefetch directory with things such as the uptime of the system, and any logon/logoff information you can get from the Security Event Log (in a pinch, last access times to the user directories may be useful if the appropriate auditing is not enabled).
Friday, March 25, 2005
More about the Prefetcher
So far, there hasn't been much of a response to my previous Prefetch blog post...though I have heard that some folks have been thinking along those lines. I wanted to add a couple of things I've stumbled across...
First, XP prefetches for the boot process and application launch, by default, while 2003 only prefetches for the boot process. As a system hardening recommendation, I'd suggest modifying the 2003 Registry value to prefetch for application launches, as well. The Prefetch directory shouldn't take up a great deal of space...for servers, pretty much the same applications will be launched over and over, so the predominant changes to the directory will be updates to file access times. However, if any unusual applications are launched, a record (ie, a '.pf' file) will be created in the Prefetch directory.
Second, I thought I mention something about the layout.ini file that you see in the Prefetch directory. This file is used by the system defrag tool to optimize system performance, by placing all of the files and directories listed in the layout.ini file in the same contiguous space. Having all of these files and directories close together in the same place makes the access of those objects more efficient.
So...what I did today was write a Perl script that parses the layout.ini file for executable files (based on .exe, .dll, and .sys file extensions) and then extract file version information from each of these. This script can easily be modified to flag files that aren't Microsoft (or Adobe or Symantec) files, or on files that don't have file version information. I should probably add extracting MAC times, as well, prior to grabbing file version info.
Here's an excerpt from the output of the script:
C:\WINDOWS\SYSTEM32\USERINIT.EXE
File Version : 5.1.2600.2180
Product Version : 5.1.2600.2180
OS : NT/Win32
Type : Application
CompanyName : Microsoft Corporation
FileDescription : Userinit Logon Application
FileVersion : 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
InternalName : userinit
Copyright : © Microsoft Corporation. All rights reserved.
Trademarks :
OrigFileName : USERINIT.EXE
ProductName : Microsoft® Windows® Operating System
ProductVersion : 5.1.2600.2180
PrivateBuild :
SpecialBuild :
This sort of thing is extremely useful, allowing for quicker searches of "suspicious" files. The key is in understanding how the Prefetch directory and the layout.ini file are populated, and then determining how they can be used (exploited??) by a forensic analyst.
First, XP prefetches for the boot process and application launch, by default, while 2003 only prefetches for the boot process. As a system hardening recommendation, I'd suggest modifying the 2003 Registry value to prefetch for application launches, as well. The Prefetch directory shouldn't take up a great deal of space...for servers, pretty much the same applications will be launched over and over, so the predominant changes to the directory will be updates to file access times. However, if any unusual applications are launched, a record (ie, a '.pf' file) will be created in the Prefetch directory.
Second, I thought I mention something about the layout.ini file that you see in the Prefetch directory. This file is used by the system defrag tool to optimize system performance, by placing all of the files and directories listed in the layout.ini file in the same contiguous space. Having all of these files and directories close together in the same place makes the access of those objects more efficient.
So...what I did today was write a Perl script that parses the layout.ini file for executable files (based on .exe, .dll, and .sys file extensions) and then extract file version information from each of these. This script can easily be modified to flag files that aren't Microsoft (or Adobe or Symantec) files, or on files that don't have file version information. I should probably add extracting MAC times, as well, prior to grabbing file version info.
Here's an excerpt from the output of the script:
C:\WINDOWS\SYSTEM32\USERINIT.EXE
File Version : 5.1.2600.2180
Product Version : 5.1.2600.2180
OS : NT/Win32
Type : Application
CompanyName : Microsoft Corporation
FileDescription : Userinit Logon Application
FileVersion : 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
InternalName : userinit
Copyright : © Microsoft Corporation. All rights reserved.
Trademarks :
OrigFileName : USERINIT.EXE
ProductName : Microsoft® Windows® Operating System
ProductVersion : 5.1.2600.2180
PrivateBuild :
SpecialBuild :
This sort of thing is extremely useful, allowing for quicker searches of "suspicious" files. The key is in understanding how the Prefetch directory and the layout.ini file are populated, and then determining how they can be used (exploited??) by a forensic analyst.
Wednesday, March 23, 2005
What is the Prefetcher?
Ever wondered what the Prefetcher is? As of Windows XP, MS added a prefetcher to improve boot and application launch time. Like many other things on Windows systems, this functionality is controlled by a Registry key.
Basically what happens is that when an application is launched, via pretty much any means (there are some methods I haven't tested yet...but even launching an app via a Scheduled Task works...), the system figures that you may want to launch it again at some point, so it creates a file in the %SYSTEMROOT%\Prefetch directory, with a ".pf" extension. This file contains some binary data, as well as some other information in Unicode (more on this in a minute).
The file that is created is given a name based on the following elements:
Basically what happens is that when an application is launched, via pretty much any means (there are some methods I haven't tested yet...but even launching an app via a Scheduled Task works...), the system figures that you may want to launch it again at some point, so it creates a file in the %SYSTEMROOT%\Prefetch directory, with a ".pf" extension. This file contains some binary data, as well as some other information in Unicode (more on this in a minute).
The file that is created is given a name based on the following elements:
- The name of the application
- A dash
- A value representing a hash of the path to the application
- The '.pf' extension
As the hash in the filename is based on the absolute path to the executable image file, if you run the same application after copying it to a different location, you'll get a different hash value, hence a different '.pf' file will be created in the Prefetch directory.
Back to the topic of Unicode data within the '.pf' file...if you open the file, near the end you'll see several paths. Most of these are paths to modules used by the application...but the path to the executable image file can also be seen here.
Combining this path with the MAC times on the file itself can provide valuable information to a forensics analyst.
I've test this by running apps from the command prompt, as a Scheduled Task, via Start->Run, etc. Nothing of note happened until I ran an application from within an NTFS alternate data stream. I created the ADS using the following command:
C:\>type c:\windows\notepad.exe > mytest.txt:np.exe
After running this command, I launched the application using the following command:
C:\>start .\mytest.txt:np.exe
Notepad ran just fine (as expected), and when I listed the contents of the Prefetch directory, I found this entry:
... 0 MYTEST.TXT
Hhhmmm...no '.pf' file. Or...is there? I ran LADS.EXE version 4.0 against the Prefetch directory, and found this:
Scanning directory c:\windows\prefetch
size ADS in file
---------- ---------------------------------
7960 c:\windows\prefetch\MYTEST.TXT:NP.EXE-0870E38D.pf
Nice! Very interesting!
So...what's my point? Let's say you want to determine if a user had run an application on a system. Well, there are locations in the Registry that record when a user launches an application in a certain way...via Start->Run, for example (search the Registry for "RunMRU"). While I haven't been able to determine whether or not there's any difference between Prefetch file names based on the user account, you should find a Prefetch file for the application (assuming, of course, the user doesn't know about prefetching and hasn't deleted the contents of the directory).
A forensic analyst can combine the MAC times of the file with the path found within the '.pf' file itself (yes, the absolute path to the ADS is in the '.pf' created in the ADS example I used), and add that to a timeline of system activity.
As I have an opportunity to try other things, I'll post them here. But don't be afraid to try your own things instead of asking me, "what happens if you..."
Registry HOWTO format
I've been working out some ideas regarding a HOWTO for the Registry and wanted to post what I'd come up with so far, and solicit thoughts and ideas on the format. So far what I've got is:
- A description of the Registry (gotta get us all on the same page)
- What is stored in the Registry?
- What to look for in the Registry when dealing with specific issues/cases (ie, CP, malware, intrusion, etc.)
What else would be of value?
Oddly enough, I haven't received a single comment to my "The Registry as a log file" blog entry. I thought that perhaps that one would be controversial enough so that someone would at least tell me that I'm out of my mind. So...either I'm completely on target, or I'm so far off base with that one, no one wants to even acknowledge it. ;-)
Tuesday, March 22, 2005
The popular media does it again.
I received a link to an eWEEK article this morning, entitled "Hacking Tools Can Strengthen Security", by Cameron Sturdevant. This article makes reference to rootkits on Windows as "new"...and at this point I'm grimacing, mumbling, "Please, not another one..." under my breath.
Embedded in that article is a link to another eWEEK article by Mr. Sturdevant, entitled "Anatomy of a Root-kit Attack". The article makes several references to this "rootkit" before finally naming it..."SpartaDoor". Symantec has several references to "Sparta", including the .B and .C versions...yet none of the write-ups makes reference to any rootkit-like capabilities. Googling for this bit of malware (admittedly, by name...), I found references to it being a backdoor, and IRC bot, and even a RAT...but nothing I found gave any indication that this malware has rootkit capabilities. Now, I'll admit upfront that I don't read French, so something may have been written up in one of the pages I found that I missed.
So...the author is way off base here. Regardless of what he wants this malware to be, for whatever reason, it looks as if it isn't a rootkit at all. You've fallen victim to the recent media hysteria, Mr. S, and jumped squarely on the bandwagon.
One thing that is interesting though is, even given the fact that the second article is, at best, sparse WRT actual information, it does seem to support my previous post, about IT folks being unprepared and ill-equipped.
Embedded in that article is a link to another eWEEK article by Mr. Sturdevant, entitled "Anatomy of a Root-kit Attack". The article makes several references to this "rootkit" before finally naming it..."SpartaDoor". Symantec has several references to "Sparta", including the .B and .C versions...yet none of the write-ups makes reference to any rootkit-like capabilities. Googling for this bit of malware (admittedly, by name...), I found references to it being a backdoor, and IRC bot, and even a RAT...but nothing I found gave any indication that this malware has rootkit capabilities. Now, I'll admit upfront that I don't read French, so something may have been written up in one of the pages I found that I missed.
So...the author is way off base here. Regardless of what he wants this malware to be, for whatever reason, it looks as if it isn't a rootkit at all. You've fallen victim to the recent media hysteria, Mr. S, and jumped squarely on the bandwagon.
One thing that is interesting though is, even given the fact that the second article is, at best, sparse WRT actual information, it does seem to support my previous post, about IT folks being unprepared and ill-equipped.
CNN News
I picked up something pretty interesting on CNN this morning, specifically this quote from a story:
"...new research suggests many companies are still unaware of -- and ill-equipped to deal with -- the threat from cyber-criminals or malicious hackers."
It turns out that this "new research" was a survey conducted by WebSense of 500 IT managers in Europe. The survey also had some other interesting "statistics", but I'll leave it up to the reader to take away what they will.
Also, be sure to take a look at their Trend Report from the second half of 2004.
I think what I find most interesting is the quote itself. This holds true for some of the companies I've worked for in FTE as well as consulting positions, and I'm sure that just about anyone in this industry is going to have stories on both sides of the fence. Another source of information for this is any of a number of public mailing lists/listservs, as many administrators post from their work addresses.
When you add this to the drop-off in conference and training attendance over the past year or so, one has to wonder if we're on the right track here...
"...new research suggests many companies are still unaware of -- and ill-equipped to deal with -- the threat from cyber-criminals or malicious hackers."
It turns out that this "new research" was a survey conducted by WebSense of 500 IT managers in Europe. The survey also had some other interesting "statistics", but I'll leave it up to the reader to take away what they will.
Also, be sure to take a look at their Trend Report from the second half of 2004.
I think what I find most interesting is the quote itself. This holds true for some of the companies I've worked for in FTE as well as consulting positions, and I'm sure that just about anyone in this industry is going to have stories on both sides of the fence. Another source of information for this is any of a number of public mailing lists/listservs, as many administrators post from their work addresses.
When you add this to the drop-off in conference and training attendance over the past year or so, one has to wonder if we're on the right track here...
Latest goings on
Have you been keeping abreast of the happenings in the world of Windows incident response? My first thought is that it shouldn't be hard, because its likely a pretty small world. But the fact remains that its also a scattered world. Part of the problem seems to be that with regards to blogs, many of the entries I'm coming across are simply links or trackbacks, with no opinion, commentary, or analysis. This has the effect of making the community look a bit larger than it really is...
Anyway, on with the show!
Dana Epp had a really interesting post recently about how to use the Image File Execution Options Registry key to launch one file instead of another. In his example, he shows how to have the command prompt run instead of Notepad, whenever someone tries to launch Notepad. Interesting, but Dana also points out that Administrator privileges are required. On my XP Pro system (the only one I have to look at right now), the permissions on the Image File Execution Options key (under HKLM\Software\Microsoft\CurrentVersion\Windows NT\) give users read access, and only Administrators and System have full access to the key. So the usefulness of this attack vector may be somewhat limited...in order for it to work, the attacker has to have Administrator level access to the system. Once he or she does, are they going to go messing with this sort of vector, or are they going to go with something else? This vector does have potential, though, as it is less well known than, say, the ubiquitous "Run" key. Oops, did I say "potential"? Wow...Trend Micro calls this on "Worms_Jean.A", and Symantec calls it "W32.Zellome".
Interestingly enough, a quick search on MSDN reveals quite a bit about this key. Microsoft provides a great deal of documentation regarding how to debug services (go here, here, or here).
This topic was also mentioned before on greggm's blog, but Junfeng Zhang's blog entry provides more detailed information. A quick glance through these and other information about the key seems to indicate that Dana was one of the first to point out a potential malicious use for this key. Also, if you use the Process Explorer tool from SysInternals, you can choose "Replace Task Manager" from the Options menu item, and the procexp.exe image will be entered into the Debugger key for taskmgr.exe. To see this, open RegEdit and navigate to the Image File Execution Options key. Leave this open, and make the menu choice in Process Explorer, then go back to RegEdit and hit F5 to refresh the view. Then go back to the shell and launch Task Manager via your favorite means.
Note the "Discovery Date" on the Symantec write-up, and then compare that to the MSDN and blog entries...
This isn't the first time this has happened, nor will it be the last. Combine the tools provided by MS for Administrators and developers to have access to more detailed information on the system with weak security by those same individuals (i.e., weak passwords, lack of auditing/monitoring, etc.), and you've got a recipe for disaster...or a really cool hack, anyway.
I have to say, though, that this one ranks right up there with some other ones (WRT Registry keys) I've seen. For example, there's HKLMHKCU\Software\Microsoft\Command Processor\Autorun. This key also requires Administrator privileges for full access, but it definitely looks like a good place to autostart something...like a batch file or even malware. Yet another interesting place for malware to hide is the HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\TaskMan key, which is included in the list of keys checked by AutoRuns 7.0.
Speaking of tools for Administrators, I dropped by the SysInternals site this morning and found some updates to tools on the site. First, RootkitRevealer is now in version 1.30...the update is in response to attackers setting up the HackerDefender configuration file to look for RootkitRevealer. This version of the tool allows the process to run with a randomly chosen name. Also, SigCheck has been updated, and a version of WhoIs has been released.
Anyway, on with the show!
Dana Epp had a really interesting post recently about how to use the Image File Execution Options Registry key to launch one file instead of another. In his example, he shows how to have the command prompt run instead of Notepad, whenever someone tries to launch Notepad. Interesting, but Dana also points out that Administrator privileges are required. On my XP Pro system (the only one I have to look at right now), the permissions on the Image File Execution Options key (under HKLM\Software\Microsoft\CurrentVersion\Windows NT\) give users read access, and only Administrators and System have full access to the key. So the usefulness of this attack vector may be somewhat limited...in order for it to work, the attacker has to have Administrator level access to the system. Once he or she does, are they going to go messing with this sort of vector, or are they going to go with something else? This vector does have potential, though, as it is less well known than, say, the ubiquitous "Run" key. Oops, did I say "potential"? Wow...Trend Micro calls this on "Worms_Jean.A", and Symantec calls it "W32.Zellome".
Interestingly enough, a quick search on MSDN reveals quite a bit about this key. Microsoft provides a great deal of documentation regarding how to debug services (go here, here, or here).
This topic was also mentioned before on greggm's blog, but Junfeng Zhang's blog entry provides more detailed information. A quick glance through these and other information about the key seems to indicate that Dana was one of the first to point out a potential malicious use for this key. Also, if you use the Process Explorer tool from SysInternals, you can choose "Replace Task Manager" from the Options menu item, and the procexp.exe image will be entered into the Debugger key for taskmgr.exe. To see this, open RegEdit and navigate to the Image File Execution Options key. Leave this open, and make the menu choice in Process Explorer, then go back to RegEdit and hit F5 to refresh the view. Then go back to the shell and launch Task Manager via your favorite means.
Note the "Discovery Date" on the Symantec write-up, and then compare that to the MSDN and blog entries...
This isn't the first time this has happened, nor will it be the last. Combine the tools provided by MS for Administrators and developers to have access to more detailed information on the system with weak security by those same individuals (i.e., weak passwords, lack of auditing/monitoring, etc.), and you've got a recipe for disaster...or a really cool hack, anyway.
I have to say, though, that this one ranks right up there with some other ones (WRT Registry keys) I've seen. For example, there's HKLMHKCU\Software\Microsoft\Command Processor\Autorun. This key also requires Administrator privileges for full access, but it definitely looks like a good place to autostart something...like a batch file or even malware. Yet another interesting place for malware to hide is the HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon\TaskMan key, which is included in the list of keys checked by AutoRuns 7.0.
Speaking of tools for Administrators, I dropped by the SysInternals site this morning and found some updates to tools on the site. First, RootkitRevealer is now in version 1.30...the update is in response to attackers setting up the HackerDefender configuration file to look for RootkitRevealer. This version of the tool allows the process to run with a randomly chosen name. Also, SigCheck has been updated, and a version of WhoIs has been released.
Wednesday, March 16, 2005
Lions and tigers and rootkits...oh, my!
As each day passes, I run across more and more fallout from MS's mention of rootkits at the RSA conference.
I've found mention of this at Adam's Mindspace, Bruce Schneier mentioned it, and others have mentioned it, as well.
A quote from Adam's blog:
The message was basically that, as there is currently no defacto way of detecting these rootkits, you either need to go to extreme measures to detect their presence on a potentially infected system or start from scratch.
I've got to say that I completely disagree. The fact remains that one doesn't need a rootkit to hide activity on a system. Simply changing the file name works just fine...it seems to fool a great number of people. Hiding the network activity has been demonstrated time and again...one way is to use IE as a COM server and have it do your bidding.
My point is that many user-mode rootkits are actually easily detected...just pick up a copy of my book and take a look at what I wrote about AFX Rootkit 2003.
Now, will these methods of detection always work? Probably not. But they work for now. The real danger isn't that rootkits are undetectable...it's that people think MS is saying that they are. Once the media grabs hold of this, now more people suddenly know about rootkits on Windows systems, but they don't know the real deal...all they know is the media hype.
What's missing in this whole media maelstrom is real, in-depth analysis. Most of the blog entries I've seen are simply links..."look, this guy said this about that!"...without much more than opinion from the blogger, if anything at all. Robert Hensing's blog is the noteable exception.
I've found mention of this at Adam's Mindspace, Bruce Schneier mentioned it, and others have mentioned it, as well.
A quote from Adam's blog:
The message was basically that, as there is currently no defacto way of detecting these rootkits, you either need to go to extreme measures to detect their presence on a potentially infected system or start from scratch.
I've got to say that I completely disagree. The fact remains that one doesn't need a rootkit to hide activity on a system. Simply changing the file name works just fine...it seems to fool a great number of people. Hiding the network activity has been demonstrated time and again...one way is to use IE as a COM server and have it do your bidding.
My point is that many user-mode rootkits are actually easily detected...just pick up a copy of my book and take a look at what I wrote about AFX Rootkit 2003.
Now, will these methods of detection always work? Probably not. But they work for now. The real danger isn't that rootkits are undetectable...it's that people think MS is saying that they are. Once the media grabs hold of this, now more people suddenly know about rootkits on Windows systems, but they don't know the real deal...all they know is the media hype.
What's missing in this whole media maelstrom is real, in-depth analysis. Most of the blog entries I've seen are simply links..."look, this guy said this about that!"...without much more than opinion from the blogger, if anything at all. Robert Hensing's blog is the noteable exception.
HOW TOs, part deux
Well, about the only thing I've gotten back with regards to the HOW TOs is stuff about the Registry. That works out well, as I'm already working on stuff for a presentation I'll be giving in June.
Anything else? If you have an idea, please be specific.
Also, there's nothing wrong with sending me a link to one you've written. ;-)
Anything else? If you have an idea, please be specific.
Also, there's nothing wrong with sending me a link to one you've written. ;-)
What is this thing called, love?
Okay, the title of this entry is an obscure reference to Benny Hill, but fans of the show may remember it...
I see it all the time, and I saw it again last night..."I found a strange program on my computer, with a reference in the Registry, and I don't know what it is...does anyone know anything about this program called enter name here?"
I've got to have a hotkey for the response to this, because it's encyclopedic, and getting tiresome to write it over and over again.
First off, files on Windows systems can be named anything, so posting just the name of the file can be pretty useless. Sometimes if you Google for it, you may get a hit, but you have to be very careful...if you Google on the name of a file you found and that's the same name as was used by a bit of malware a couple of years ago, you'll get erroneous information. So, go ahead and Google, but check what you find very carefully.
Next, saying that you ran anti-spyware and -virus tools doesn't say much, unless they're current versions and up-to-date. So, if you're going to run these tools, make sure they're updated just prior to running them. Also, if you're posting to the public lists, it might help to specify the tools and versions you're using.
Now, let's say that you find this unusual program, and it's actually running as a process. If this is the case, and you really want to know what that program is doing, try collecting information about the process. One thing you'll want to know is the command line used to launch the process...something you can't get from Task Manager. Tools I've recommended in the past include tlist.exe (free, part of the MS Debugging Tools), cmdline.exe, or WMI (using the Win32_Process class). The command line will give you the location of the executable image within the file system, as well as any command line arguments used...which can be important.
Now, let's get some info about the process itself. Tools I'd recommend running include handle.exe, listdlls.exe, and openports.exe (I prefer openports over fport, as it doesn't require an Admin account to run). If you're on XP SP2, run 'netstat -anob', as well. Another good tool for process-to-port mapping is PortQry v2.0. Then, dump the memory used by the process with pmdump.exe...this can create quite a large file, so you may want to zip it up.
You'll also want to check to see where the file is referenced in the Registry, if at all. One of the best tools for doing so that I've found is AutoRuns. Another good tool is SilentRunner.
Another important tidbit of information is how long the process has been running...something you can get with pslist.exe. Compare this to the uptime of the system (from psinfo.exe) and you will be able to ballpark about when the process was launched on the system. You may also want to get the LastWrite time of any Registry keys that reference the executable image...this may assist you in pinpointing when the program was installed.
If you're going to ask people about this file, use the tools I've listed to collect information about the file and process, piping the output to files. I recommend the use of command line tools, as they are easy to script. Archive this information, and make it available. Maks sure that you include a copy of the file itself.
If you want to look at the file yourself, I'd recommend pulling file version information (I use Perl and the Win32::File::VersionInfo module), as well as running strings, Dependency Walker, and any other tools you can think of against the file. If you're good with a debugger, try that.
So...posting the name of a file and nothing else is pretty pointless these days. If you're interested in knowing what a process is up to, or what file does, either collect some information about it and submit that information for analysis, or analyze it yourself. But keep in mind that determining how it got on your system is an entirely different matter...
I see it all the time, and I saw it again last night..."I found a strange program on my computer, with a reference in the Registry, and I don't know what it is...does anyone know anything about this program called enter name here?"
I've got to have a hotkey for the response to this, because it's encyclopedic, and getting tiresome to write it over and over again.
First off, files on Windows systems can be named anything, so posting just the name of the file can be pretty useless. Sometimes if you Google for it, you may get a hit, but you have to be very careful...if you Google on the name of a file you found and that's the same name as was used by a bit of malware a couple of years ago, you'll get erroneous information. So, go ahead and Google, but check what you find very carefully.
Next, saying that you ran anti-spyware and -virus tools doesn't say much, unless they're current versions and up-to-date. So, if you're going to run these tools, make sure they're updated just prior to running them. Also, if you're posting to the public lists, it might help to specify the tools and versions you're using.
Now, let's say that you find this unusual program, and it's actually running as a process. If this is the case, and you really want to know what that program is doing, try collecting information about the process. One thing you'll want to know is the command line used to launch the process...something you can't get from Task Manager. Tools I've recommended in the past include tlist.exe (free, part of the MS Debugging Tools), cmdline.exe, or WMI (using the Win32_Process class). The command line will give you the location of the executable image within the file system, as well as any command line arguments used...which can be important.
Now, let's get some info about the process itself. Tools I'd recommend running include handle.exe, listdlls.exe, and openports.exe (I prefer openports over fport, as it doesn't require an Admin account to run). If you're on XP SP2, run 'netstat -anob', as well. Another good tool for process-to-port mapping is PortQry v2.0. Then, dump the memory used by the process with pmdump.exe...this can create quite a large file, so you may want to zip it up.
You'll also want to check to see where the file is referenced in the Registry, if at all. One of the best tools for doing so that I've found is AutoRuns. Another good tool is SilentRunner.
Another important tidbit of information is how long the process has been running...something you can get with pslist.exe. Compare this to the uptime of the system (from psinfo.exe) and you will be able to ballpark about when the process was launched on the system. You may also want to get the LastWrite time of any Registry keys that reference the executable image...this may assist you in pinpointing when the program was installed.
If you're going to ask people about this file, use the tools I've listed to collect information about the file and process, piping the output to files. I recommend the use of command line tools, as they are easy to script. Archive this information, and make it available. Maks sure that you include a copy of the file itself.
If you want to look at the file yourself, I'd recommend pulling file version information (I use Perl and the Win32::File::VersionInfo module), as well as running strings, Dependency Walker, and any other tools you can think of against the file. If you're good with a debugger, try that.
So...posting the name of a file and nothing else is pretty pointless these days. If you're interested in knowing what a process is up to, or what file does, either collect some information about it and submit that information for analysis, or analyze it yourself. But keep in mind that determining how it got on your system is an entirely different matter...
Tuesday, March 15, 2005
HOW TOs
Here's a question to the reader...with regards to incident response on Windows systems, what kind of "HOW TO" guides would you like to see? What are some topics that you feel need to be covered? I've got my own ideas, but I also have a different perspective...so I'd like to hear what you have to say...
Imaging physical memory
I got a message from a buddy of mine last night asking me about imaging physical memory (RAM) on Windows systems. The "how" of this is pretty simple...just jump on over to George Garner's site and grab a copy of dd.exe. The command you use to image RAM is even listed on George's site.
Okay, so you have a copy of RAM...what next? This is the kicker, IMHO. Say you have 512MB of RAM...you'll get an image file around that size. So what do you do with it? Well, you could run strings on it, but what would that give you? How would you associate information you find with tools such as strings, with specific processes? Consider that the memory used by processes is fragmented across both RAM and the swap file...so imaging RAM is only going to give you a partial view of what's going on on the system.
In the absence of adequate tools to parse an image of RAM, another approach is to use tools such as pmdump.exe to dump the contents of process memory, both RAM and swap file. At least in this manner, you can associate anything you find with a specific process, even though more comprehensive tools for parsing this information don't seem to be available.
Thoughts?
Okay, so you have a copy of RAM...what next? This is the kicker, IMHO. Say you have 512MB of RAM...you'll get an image file around that size. So what do you do with it? Well, you could run strings on it, but what would that give you? How would you associate information you find with tools such as strings, with specific processes? Consider that the memory used by processes is fragmented across both RAM and the swap file...so imaging RAM is only going to give you a partial view of what's going on on the system.
In the absence of adequate tools to parse an image of RAM, another approach is to use tools such as pmdump.exe to dump the contents of process memory, both RAM and swap file. At least in this manner, you can associate anything you find with a specific process, even though more comprehensive tools for parsing this information don't seem to be available.
Thoughts?
Comments from a previous blog entry...
In my previous "rootkit saga continues..." blog entry, there were some comments that I...uh...wanted to comment on...
Geez, can you get any more circular than that?
"...one thing I understand is that it is more difficult to MONITOR a windows box..."
Hhhmmm...I can't say that I really agree with that, Bob (Note: oblique reference to "Office Space"). Sure, Windows does not maintain a log of all of the activity that occurs on the system, but Windows systems can be monitored. It simply comes down to intelligent design and engineering...knowing what you want to do, whether it makes sense, and then doing it. For example, some folks shut off auditing and logging all together because it either creates too much information and they can't review it, or they just don't understand what they're seeing...or both. A better option would be to enable logging based on the purpose of the box, then develop a centralized analysis repository for the logs. The truth is out there, Scully.
"So IMHO, Windows is substantially easier to "DRIVE", but substantially more difficult to analyse in general. But this can even be to a lack of documentation..."
Yeah, I'd have to agree with that. I think that most folks "grow up" in the security industry, hearing about Linux or *nix or *BSD systems being "more secure", so they migrate to that area. However, from a consulting perspective, Windows is much more ubiquitous on the desktop...and there's much less expertise out there, with regards to incident response analysis for these systems. I'm sure that part of this is due to the fact that this sort of skill set, though useful in other areas, is seen as a unique specialization.
I also believe that this documentation comes in two forms...documentation of the internals of Windows, and perhaps the more necessary "HOW-TO"-type guides. The Windows internals stuff is something the bad guys seem to know, and to be honest, is probably a lot more than most administrators and first responders have time to digest. I do agree that there needs to be much more in the way of "HOW-TO" guides, even with the ones that are already out there. Just as important, however, is that these guides and this sort of information needs to be credible...it should be based on experimentation, with verifiable and reproduceable results.
Geez, can you get any more circular than that?
"...one thing I understand is that it is more difficult to MONITOR a windows box..."
Hhhmmm...I can't say that I really agree with that, Bob (Note: oblique reference to "Office Space"). Sure, Windows does not maintain a log of all of the activity that occurs on the system, but Windows systems can be monitored. It simply comes down to intelligent design and engineering...knowing what you want to do, whether it makes sense, and then doing it. For example, some folks shut off auditing and logging all together because it either creates too much information and they can't review it, or they just don't understand what they're seeing...or both. A better option would be to enable logging based on the purpose of the box, then develop a centralized analysis repository for the logs. The truth is out there, Scully.
"So IMHO, Windows is substantially easier to "DRIVE", but substantially more difficult to analyse in general. But this can even be to a lack of documentation..."
Yeah, I'd have to agree with that. I think that most folks "grow up" in the security industry, hearing about Linux or *nix or *BSD systems being "more secure", so they migrate to that area. However, from a consulting perspective, Windows is much more ubiquitous on the desktop...and there's much less expertise out there, with regards to incident response analysis for these systems. I'm sure that part of this is due to the fact that this sort of skill set, though useful in other areas, is seen as a unique specialization.
I also believe that this documentation comes in two forms...documentation of the internals of Windows, and perhaps the more necessary "HOW-TO"-type guides. The Windows internals stuff is something the bad guys seem to know, and to be honest, is probably a lot more than most administrators and first responders have time to digest. I do agree that there needs to be much more in the way of "HOW-TO" guides, even with the ones that are already out there. Just as important, however, is that these guides and this sort of information needs to be credible...it should be based on experimentation, with verifiable and reproduceable results.
The Rootkit Saga continues...
Robert seems to be busy keeping the rootkit saga going over on his blog, with some interesting tidbits about how RootkitRevealer interacts with HackerDefender. Evidently, the bad guys are including the RootkitRevealer process name in the HackerDefender config file, and the result is that RootkitRevealer isn't reporting the existance of the rootkit. In a nutshell, this is because the RootkitRevealer process runs as a root process, and the rootkit files themselves aren't hidden.
In order to combat this, Robert suggests changing the name of the RootkitRevealer file to something different, possibly a random name. This would work, and the ensuing discussion via the comments on his blog entry lead into various ways the bad guys could counteract this tactic.
This reminds me of the old arms race/escalation issue in the military. For example, man invents tanks. Then some other guy invents a way to disable a tank. These two guys go back and forth, one guy producing heavier armour, the other guy coming up with advanced tactics. Finally, some guy invents the TOW Missile. So the tank guys come up with reactive armour. So then the missile guys improve their missiles with a probe, giving the missile standoff...the probe sets off the reactive armour, leaving a space for the missile to continue on through.
See how that works? In Robert's blog the comments go to changing the name of the RootkitRevealer executable, to the bad guys hashing the executable images, to the good guys padding the executable, etc. The next logical step would be the bad guys using some sort of anti-virus-type technique to identify the RootkitRevealer process.
However, the key is that all of these steps are purely reactive in nature. The good guys could get around this by (a) improving their prevention mechanisms, and (b) changing their detection tactics. Sound prevention mechanisms have been around for a while...perhaps they just aren't being used, or used employed in an effective manner. The other option is to change detection tactics, and one possibility is to use techniques I talked about in my book. If you don't have the book, I found a copy of the rootkit detection script (ie, rkd.pl), online. I'm being redundant, I know, having posted this before, but I thought it deserved another look.
A tool that may be of use with kernel-mode rootkits on Windows systems is KProcCheck. According to the web site, this proof-of-concept tool directly accesses the kernel structures and enumerates through the process and thread lists, looking for disparities. KProcCheck may definitely be something worth checking out...the latest beta version supports XP.
As a side note, I wanted to comment briefly on one of the comments that appeared on Robert's blog entry...the comment was "SysInternals could generate a random name as well I suppose, at the cost of convenience to the user. If they did so and generated a rootkitrevealer.lnk shortcut from which to launch it would that be traceable by hxdef?"
Don't get me wrong...I'm not going to be high-and-mighty here, nor am I going to be preachy. However, I see this kind of thing all the time at conferences and in courses. People just throw questions out without really reasoning through things themselves first. With regards to the above comment...first, why should SysInternals generate the random name for the file? Second, when a process is running, there isn't anything associated with the process that indicates how it was started...did the user open the "Run..." box, or double-click a desktop shortcut, or was the process launched via the ubiquitous HKLM\..\Run key in the Registry? So, then, how would any other process determine this based on information that does not exist?
Thoughts? Comments?
In order to combat this, Robert suggests changing the name of the RootkitRevealer file to something different, possibly a random name. This would work, and the ensuing discussion via the comments on his blog entry lead into various ways the bad guys could counteract this tactic.
This reminds me of the old arms race/escalation issue in the military. For example, man invents tanks. Then some other guy invents a way to disable a tank. These two guys go back and forth, one guy producing heavier armour, the other guy coming up with advanced tactics. Finally, some guy invents the TOW Missile. So the tank guys come up with reactive armour. So then the missile guys improve their missiles with a probe, giving the missile standoff...the probe sets off the reactive armour, leaving a space for the missile to continue on through.
See how that works? In Robert's blog the comments go to changing the name of the RootkitRevealer executable, to the bad guys hashing the executable images, to the good guys padding the executable, etc. The next logical step would be the bad guys using some sort of anti-virus-type technique to identify the RootkitRevealer process.
However, the key is that all of these steps are purely reactive in nature. The good guys could get around this by (a) improving their prevention mechanisms, and (b) changing their detection tactics. Sound prevention mechanisms have been around for a while...perhaps they just aren't being used, or used employed in an effective manner. The other option is to change detection tactics, and one possibility is to use techniques I talked about in my book. If you don't have the book, I found a copy of the rootkit detection script (ie, rkd.pl), online. I'm being redundant, I know, having posted this before, but I thought it deserved another look.
A tool that may be of use with kernel-mode rootkits on Windows systems is KProcCheck. According to the web site, this proof-of-concept tool directly accesses the kernel structures and enumerates through the process and thread lists, looking for disparities. KProcCheck may definitely be something worth checking out...the latest beta version supports XP.
As a side note, I wanted to comment briefly on one of the comments that appeared on Robert's blog entry...the comment was "SysInternals could generate a random name as well I suppose, at the cost of convenience to the user. If they did so and generated a rootkitrevealer.lnk shortcut from which to launch it would that be traceable by hxdef?"
Don't get me wrong...I'm not going to be high-and-mighty here, nor am I going to be preachy. However, I see this kind of thing all the time at conferences and in courses. People just throw questions out without really reasoning through things themselves first. With regards to the above comment...first, why should SysInternals generate the random name for the file? Second, when a process is running, there isn't anything associated with the process that indicates how it was started...did the user open the "Run..." box, or double-click a desktop shortcut, or was the process launched via the ubiquitous HKLM\..\Run key in the Registry? So, then, how would any other process determine this based on information that does not exist?
Thoughts? Comments?
Thursday, March 10, 2005
Blogging...
I haven't had many new ideas for blogging lately...so I thought I'd pose a question to the readers...
There are sites that offer up forensic or hacker challenges. Two of the most noteable are the HoneyNet Project, and Ed Skoudis' site, CounterHack. Both of these sites offer some really well thought out, well organized challenges. The results also offer quite an education...it's interesting to read through several of the results, looking at both the commonalities, and the differences in approaches.
And then there are sites like Robert Hensing's blog, and "A Day in the life of an Information Security Investigator", that present a more tutorial-style approach...this is what we saw, this is what we did, and this is what we found out...walking through the entire scenario, start to finish.
From my own personal standpoint, I prefer the things I can work on myself, as I learn more that way. Sometimes the tutorial-style approaches don't have enough information for my tastes, and I don't get to manipulate things, try other things, to see what happens.
So, my question to you, the reader, is...which style do you prefer? Is there another style, one which you find more beneficial? What are some sites that you go to for these sorts of things?
There are sites that offer up forensic or hacker challenges. Two of the most noteable are the HoneyNet Project, and Ed Skoudis' site, CounterHack. Both of these sites offer some really well thought out, well organized challenges. The results also offer quite an education...it's interesting to read through several of the results, looking at both the commonalities, and the differences in approaches.
And then there are sites like Robert Hensing's blog, and "A Day in the life of an Information Security Investigator", that present a more tutorial-style approach...this is what we saw, this is what we did, and this is what we found out...walking through the entire scenario, start to finish.
From my own personal standpoint, I prefer the things I can work on myself, as I learn more that way. Sometimes the tutorial-style approaches don't have enough information for my tastes, and I don't get to manipulate things, try other things, to see what happens.
So, my question to you, the reader, is...which style do you prefer? Is there another style, one which you find more beneficial? What are some sites that you go to for these sorts of things?
Thursday, March 03, 2005
The Registry as a log file
You're probably looking at the title of this entry and wondering..."what is this guy on??!! And where can I get some??!" Well, at least I hope you are...because that means that you're reading this blog entry...
So...what do I mean? Well, a lot of activity is recorded in the Registry...things like what you type into the "Run" box, documents you access, URLs you type into IE, etc. When this information is written to the appropriate Registry key, the LastWrite time associated with that key is updated accordingly. With some keys, it's relatively simple to narrow down which, with some level of certainty, what action occurred and resulted in the update to the key. With others, it's not so easy.
The LastWrite time is maintained in a FILETIME structure, and is processed in much the same way as file MAC times. This means that you can pull the data out and represent it as a system time, or translate it to a local time, taking the time zone and daylight savings settings into account.
Tying this information into the timeline you develop based on log entries, file MAC times, and other sources, you can sort of begin to see how the Registry can be considered to be a log file, of sorts. In some ways, it's as easy or as hard to read (or understand) as the Event Log, but it definitely should not be discounted as a source of valuable information.
More regarding the Registry to come...
So...what do I mean? Well, a lot of activity is recorded in the Registry...things like what you type into the "Run" box, documents you access, URLs you type into IE, etc. When this information is written to the appropriate Registry key, the LastWrite time associated with that key is updated accordingly. With some keys, it's relatively simple to narrow down which, with some level of certainty, what action occurred and resulted in the update to the key. With others, it's not so easy.
The LastWrite time is maintained in a FILETIME structure, and is processed in much the same way as file MAC times. This means that you can pull the data out and represent it as a system time, or translate it to a local time, taking the time zone and daylight savings settings into account.
Tying this information into the timeline you develop based on log entries, file MAC times, and other sources, you can sort of begin to see how the Registry can be considered to be a log file, of sorts. In some ways, it's as easy or as hard to read (or understand) as the Event Log, but it definitely should not be discounted as a source of valuable information.
More regarding the Registry to come...
Wednesday, March 02, 2005
Using WMI
Over the past couple of days, I've been working on updating some of the WMI code I keep on hand...updating what I have, and adding to it.
Yesterday after work, I tweaked my version of promqury.exe, which uses WMI to detect sniffers on managed Windows systems. I wanted to make sure that not only did it work correctly, but I also wanted to comment it a bit so that the code was easier to understand and follow. Basically, the code uses WMI/WDM to access the OID_GEN_CURRENT_PACKET_FILTER structure, and checks for NDIS_PACKET_TYPE_PROMISCUOUS, which, per ndis.h, equals 0x00000020. As this is hex, if we translate it to binary, it means that bit 6 (from the right) is set (equal to 1). So I took the return value for the current packet filter, translated it to a 32-character string of 1's and 0's, and checked the value of the 27th bit (from the left).
In addition, I got a version of one of the triangulation thing I mentioned before.
Let's see...what else? Oh, yeah, I wrote a process monitor tool that watches for the creation of new processes on Windows systems. The core of this is the WQL query:
"SELECT * FROM __instancecreationevent WITHIN 2 WHERE targetinstance ISA 'Win32_Process'"
I think I need to decrease the value of WITHIN, but according the warnings issued by the Perl interpreter, the WITHIN is required. I tried to do the same thing with CIM_DataFile and CIM_LogicalFile, but got warnings about quota violations...evidently the query is too large. I guess for a file monitor (for when I'm testing rootkits and such) I'll have to go back to FileMon, or use the now defunct Win32::AdvNotify module (I still have a copy around, and some code...).
I've got another script I'm working on that ties threads to their associated processes. I'm hoping that the Win32_Thread class in WMI really does look at threads, instead of enumerating processes first, and then their threads.
Interestingly enough, I was able to do what I did with the process monitor and make it watch for new threads being created, but the basic information you get from the Win32_Thread class is a bit limited.
I hope you, the reader, can see how useful something like this would be in incident response. I'd tweak these tools up a bit during a testing process, create standalone EXEs of them and burn them to CD...very useful stuff.
Yesterday after work, I tweaked my version of promqury.exe, which uses WMI to detect sniffers on managed Windows systems. I wanted to make sure that not only did it work correctly, but I also wanted to comment it a bit so that the code was easier to understand and follow. Basically, the code uses WMI/WDM to access the OID_GEN_CURRENT_PACKET_FILTER structure, and checks for NDIS_PACKET_TYPE_PROMISCUOUS, which, per ndis.h, equals 0x00000020. As this is hex, if we translate it to binary, it means that bit 6 (from the right) is set (equal to 1). So I took the return value for the current packet filter, translated it to a 32-character string of 1's and 0's, and checked the value of the 27th bit (from the left).
In addition, I got a version of one of the triangulation thing I mentioned before.
Let's see...what else? Oh, yeah, I wrote a process monitor tool that watches for the creation of new processes on Windows systems. The core of this is the WQL query:
"SELECT * FROM __instancecreationevent WITHIN 2 WHERE targetinstance ISA 'Win32_Process'"
I think I need to decrease the value of WITHIN, but according the warnings issued by the Perl interpreter, the WITHIN is required. I tried to do the same thing with CIM_DataFile and CIM_LogicalFile, but got warnings about quota violations...evidently the query is too large. I guess for a file monitor (for when I'm testing rootkits and such) I'll have to go back to FileMon, or use the now defunct Win32::AdvNotify module (I still have a copy around, and some code...).
I've got another script I'm working on that ties threads to their associated processes. I'm hoping that the Win32_Thread class in WMI really does look at threads, instead of enumerating processes first, and then their threads.
Interestingly enough, I was able to do what I did with the process monitor and make it watch for new threads being created, but the basic information you get from the Win32_Thread class is a bit limited.
I hope you, the reader, can see how useful something like this would be in incident response. I'd tweak these tools up a bit during a testing process, create standalone EXEs of them and burn them to CD...very useful stuff.
The rootkit saga continues...
Rootkits really seem to be in focus these days, all thanks to Microsoft bringing them to everyone's attention at the RSA Conference. I was reading a piece by Larry Seltzer this morning entitled "Rootkits: Invasion of the Windows Snatchers" (okay, I know...it's been out for over two weeks already...), and had to drop Larry an email and thank him for the breath of fresh air. Larry's article injected a dose of common sense into the issue.
Now, the geek in me comes out...in the early '60s, Arthur C. Clarke wrote in his essay, "Profiles of the Future" that "Any sufficiently advanced technology is indistinguishable from magic." Applying this to rootkits in use on Windows systems, and the concept holds true over 40 years later.
"Not detected by anti-spyware and anti-virus software" != rootkit (not always, anyway)
My point is simply this...too often, an incident isn't fully investigated and what is first suspected to be a rootkit turns out to be something else entirely. I believe that this is due largely to the Windows GUI (which I still believe is meant only to protect the user or admin from himself...). What I mean by that comment is that the majority of the security training for Windows involves interaction through the GUI...click here, check this box, click "OK". However, the GUI tools provided with a native Windows installation are simply insufficient to perform incident response. Therefore, what we end up seeing is that administrators and first responders become limited by their interaction with the GUI, and have no concept of what's going on "under the hood". For example, most folks have very little idea how much the Windows system interacts with the Registry, and where evidence of activity can be found...but I'll leave that for another blog entry.
So that's where education comes in. But the question becomes...how do you educate the folks who need it? Write books? Offer courses? I'm not sure if this works...and I say this because one doesn't see a lot of discussion on such topics.
Why is this education important? Well, while MS's Strider Ghostbuster approach is a good one, there are a great number of machines that may (please note the heavy emphasis on the previous word) be compromised in some way, but can't be taken down for examination. Production machines in ecommerce infrastructures, file servers, or the CxO's workstation...such systems can't necessarily be taken offline. Usually, one needs justification to do so, and one needs facts in order to develop a justification. The education part comes in by teaching administrators and first responders where to look, what to look for, what to watch out for, and how to interpret the data they collect.
Is the concept of rootkits and rootkit detection important? Yes, most definitely so. I did quick search this morning and found the following bits of malware with rootkit capabilities:
With regards to rootkit detection, Joanna Rutkowska released flister earlier this year. Joanna's done some pretty interesting work in the past, and I'm definitely going to be adding flister to my rootkit testing infrastructure.
One final thought...I have to get a publicist or something. Sheesh! SysInternals releases RootkitRevealer and is almost immediately /.'d. Others have done work that doesn't seem to be making it into the public (or even the community) view. For example, in my book, I described and provided an initial implementation of tool for performing rootkit detection on live Windows systems, using a behaviour-based approach. I've actually found the code listed online, too (i.e., rkd.pl). Why do I bring this up? Well, how else do you pierce FUD like this?
Now, the geek in me comes out...in the early '60s, Arthur C. Clarke wrote in his essay, "Profiles of the Future" that "Any sufficiently advanced technology is indistinguishable from magic." Applying this to rootkits in use on Windows systems, and the concept holds true over 40 years later.
"Not detected by anti-spyware and anti-virus software" != rootkit (not always, anyway)
My point is simply this...too often, an incident isn't fully investigated and what is first suspected to be a rootkit turns out to be something else entirely. I believe that this is due largely to the Windows GUI (which I still believe is meant only to protect the user or admin from himself...). What I mean by that comment is that the majority of the security training for Windows involves interaction through the GUI...click here, check this box, click "OK". However, the GUI tools provided with a native Windows installation are simply insufficient to perform incident response. Therefore, what we end up seeing is that administrators and first responders become limited by their interaction with the GUI, and have no concept of what's going on "under the hood". For example, most folks have very little idea how much the Windows system interacts with the Registry, and where evidence of activity can be found...but I'll leave that for another blog entry.
So that's where education comes in. But the question becomes...how do you educate the folks who need it? Write books? Offer courses? I'm not sure if this works...and I say this because one doesn't see a lot of discussion on such topics.
Why is this education important? Well, while MS's Strider Ghostbuster approach is a good one, there are a great number of machines that may (please note the heavy emphasis on the previous word) be compromised in some way, but can't be taken down for examination. Production machines in ecommerce infrastructures, file servers, or the CxO's workstation...such systems can't necessarily be taken offline. Usually, one needs justification to do so, and one needs facts in order to develop a justification. The education part comes in by teaching administrators and first responders where to look, what to look for, what to watch out for, and how to interpret the data they collect.
Is the concept of rootkits and rootkit detection important? Yes, most definitely so. I did quick search this morning and found the following bits of malware with rootkit capabilities:
- BKDR_BERBEW.Y (8 Feb 05)
- SPYW_PEEP.A (15 Feb 05)
- Trojan.Blubber (15 Jan 05)
- Trojan.Comxt.B (2 Feb 05) ADS + Rootkit
- Win32.Malsan.A (7 Dec 04 - .C, 9 Dec 04)
With regards to rootkit detection, Joanna Rutkowska released flister earlier this year. Joanna's done some pretty interesting work in the past, and I'm definitely going to be adding flister to my rootkit testing infrastructure.
One final thought...I have to get a publicist or something. Sheesh! SysInternals releases RootkitRevealer and is almost immediately /.'d. Others have done work that doesn't seem to be making it into the public (or even the community) view. For example, in my book, I described and provided an initial implementation of tool for performing rootkit detection on live Windows systems, using a behaviour-based approach. I've actually found the code listed online, too (i.e., rkd.pl). Why do I bring this up? Well, how else do you pierce FUD like this?
Subscribe to:
Posts (Atom)