Slashdot Log In
Windows Forensics and Incident Recovery
from the windows-is-a-big-pain dept.
| Windows Forensics and Incident Recovery | |
| author | Harlan Carvey |
| pages | 460 |
| publisher | Addison Wesley |
| rating | 9 |
| reviewer | Mark McKinnon |
| ISBN | 0321200985 |
| summary | Forensic analysis and incident recovery on a live Microsoft Windows is explained for the system administrator, security administrator and knowledgeable home user. |
The intended audience, according to the author, is "anyone with an interest in Windows security, which includes Windows system and security administrators, consultants, incident response team members, students and even home users." The author assumes the reader is familiar with basic networking (including TCP/IP) and has some Windows administration skills. Some programming ability, though not actually required, will help out greatly with reading and understanding the many examples provided, and will let you make your own modifications (this is encouraged by the author throughout the book).
The chapter on data hiding was a real eye-opener -- it's amazing the things Microsoft has implemented as part of the operating system (and included applications) that can be used to hide things. Discovering the hidden information is talked about, as well how it is hidden. Sample topics include file attributes, alternate data streams, OLE and stenography. This is an excellent chapter with many examples; I found myself stopping after each subject to try out each of the discussed techniques.
The next chapter delves into incident preparation. Carvey addresses some of the things that administrators can do to harden their systems. He goes over the application of security policies in general, as well as intelligent assignment of file permissions. He then covers Windows File Protection and how it is implemented, and includes a perl script to implement your own file watcher. He touches briefly on patch management and anti-virus programs, then moves into monitoring. He provides quite a few scripts, and discusses other means by which you can monitor your system.
The next chapter describes tools that can be used in incident response. This chapter has quite a lot of information and took me the longest to get through, because of all the tools mentioned that I had to download and check while I was reading the book. Carvey uses a mixture of his own perl scripts and programs that can be downloaded from places like Sysinternals, Foundstone, DiamondCS and others. All of the tools used are open source (or are at least freely available). That equips the reader with a low-cost toolkit, especially important to the home user or small business owner who cannot afford to buy the commercial equivalent. Carvey does acknowledge, though, that there are quite a few commercial tools with great functionality out there.
The first part of the incident-response tools chapter deals with the collection of volatile information (processes, services, etc.); this is a vital part of live analysis. The second part deals with the collection of non-volatile information (the content of the Windows registry, file MAC times and hashes, etc.) and tools for analyzing files. Carvey also shows how some of the tools complement each other, and that there is not one almighty tool that will find all the data you need. (This is also proven by example in a later chapter when he talks about rootkits.)
The next chapter deals with developing a security methodology, and it's handled differently than in most books: the author presents the material as a series of dreams that a Windows system administrator has, showing how an individual can come up with and fine tune a methodology as incidents happen. Carvey has used this approach before in a series of articles entitled "No Stone Unturned" for SecurityFocus.com, and the creative approach appeals to me. As he moves from dream to dream, you can relate to the admin's circumstances (and mistakes), and how be and becomes better at responding to different incidents.
The next chapter talks about what to usefully look for with the tools the book has introduced. It discusses infection vectors, types of malware and rootkits, and demonstrates tools and techniques for detecting them. This is where the author makes a clear point of why you would need to run several different tools, even if some overlap. His example uses an installed rootkit; running a particular program from a previous chapter, he shows that it fails to find that anything untoward is running -- it takes another program from the same chapter to actually reveal the rootkit's presence. By cross referencing the output for both programs, you can see why you should run more then one type of analysis tool for certain areas to make sure you are not missing anything.
Finally, the author dedicates an entire chapter to his own Forensic Server Project, a two-pronged approach to live forensic analysis which uses two machines simultaneously. The first piece, the Forensic Server Module, is the listener software; this runs on a clean PC where the data will be sent from the compromised system. The other piece, called the First Responder Utility, runs several of the programs and scripts from the incident tools chapter on the compromised system . After installing everything needed for both parts of this system, I followed the author's instructions on how to run it. What a slick tool! I ran it from a couple of PCs on my home network and was able to get a lot of the information that was described in the book as well as hash values for each log file that was produced, and a general log of everything the First Responder Unit did. The whole principle of this is that when you have an incident there will be very little interaction with the compromised system, since everything is scripted to begin with.
The framework that this software constitutes is very flexible. I was able to add two new features to the Forensic Server Module and the First Responder Utility with very little code. The first addition I made was to mark all the logs as read-only on the file system after they were written from the Forensic Server module. The next addition I made was to add a perl script to scan the c:\ drive of the PC that the First Responder Utility was running on. After I made both additions, I tested everything out, and it worked great. I had my extra log files and they were all read-only. My hat goes off to the author for coming up with and including this in the book, a really nice piece of software.
You can purchase Windows Forensics and Incident Recovery from bn.com. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page.
Your typical sharing violations (Score:2, Interesting)
(http://www.imonhold.com/)
what? (Score:3, Funny)
Re:what? (Score:4, Informative)
At times I have Diablo II running in a window, DevStudiodebuggins ome app. A couple of multi megabyte spreadsheets open in OpenOffice, And of course FireFox.
To ensure that the hardware is as unstable as possible, this runs on a dual P4, with a Matrox and an nVidia card, both dual head for a total of 4 displays - all with a mere 512Mb of RAM.
Ironically, FireFox is the real system resource hog.
I have to close it down every two weeks to free up some system memory. It does get restarted about once a month when my domain passwords expire - its the only damned way to ensure that some cached credentials dont lock me out of everything.
Hiding Data (Score:4, Informative)
" Sample topics include file attributes, alternate data streams, OLE and stenography"
Should that be Steganography? [wikipedia.org]
Re:Hiding Data (Score:4, Funny)
Non-software solutions? (Score:5, Interesting)
(http://fedoraproject.org/wiki/JonCiesla | Last Journal: Thursday December 05 2002, @02:46PM)
Here's my method (Score:3, Funny)
(http://sillysoft.net/ | Last Journal: Wednesday November 24 2004, @02:50AM)
Bring the computer to my office.
Administer a morphine injection.
Ask the computer about his feelings (particularly towards his parenting fab)
Administer another morphine injection (to myself this time).
Play some Diablo 2 on the computer.
Upgrade computer's video card.
Play some more Diablo 2.
Charge computer's owner some big money.
One last morphine injection for the road.
Lather, rinse, repeat and you've got one hell of a business!
Good read? (Score:5, Funny)
(http://www.debian.org/)
Cool, I love arcane knowledge *hugs his falconry for dummies book*
Live analysis. (Score:5, Interesting)
(http://www.grub.net/blog/index.html | Last Journal: Wednesday June 27, @08:48AM)
We had an SGI IRIX system rooted a while ago. One of those obscure machines that sat in a corner running for years, rarely updated or touched. When it was discovered that the machine was taken over the person that admin'd the machine left it exactly as is but firewalled and VLAN'd the machine from touching anything outside of a test VLAN he set up.
In February he gave us (network guys visiting his branch) a look at the machine and what he found. The machine, the root kit and the IRC bot were all left intact and running. It was pretty neat, he wrote up a lengthy port-mortem of the event.
It's Steganography (Score:1)
(http://tony.awtrey.com/)
Live "Forensics" (Score:5, Interesting)
(http://www.alacpp.org/ | Last Journal: Wednesday April 03 2002, @10:12AM)
Generally, however, if there's any chance that the investigation could wind up in court, it's best to pull the plug (literally) and conduct a static analysis of the hard drive. You lose access to running processes and some live registry keys, but otherwise just about everything exists on the hard drive and is accessible through standard forensic tools.
As a forensic programmer/consultant, one of the biggest problems I run into is when J. Random Sysadmin is tasked with conducting an initial investigation and ends up rampaging through the hard drive like a bull in a china shop. If you ever find yourself in this situation, stop and get the facts. There's no better way for a sysadmin to wind up in the doghouse than to ruin a legal investigation.
Jon
(Disclaimer: I work at Guidance Software [guidancesoftware.com], makers of EnCase, which is the all-in-one tool that can do all of the things mentioned in the review. But not for free...)
Re:Live "Forensics" (Score:4, Insightful)
You have an older server that has a relatively small hard drive. You get a complaint from somebody saying they can't do so and so on the server. You look on it and find that the hard drive is full. You think, oh great, somebody printed a 200mb print job again and filled up the hard drive. Well, time to reboot the server. You have just lost an enormous amount of evidence and you may never know where the pirated games, movies, and music came from.
I am a windows/linux sysadmin and when something goes isn't working right, my first thought is not *I'VE BEEN HACKED*, no its "stupid {some software}, {some company} can't program to save their life. time to restart the service or reboot". I will agree that discovering a problem at this point is too late - you're already 0wN3d. Instead of focusing on forensics, we need to focus on proactive measures - use group policies to enforce better security policies; use ntop, nmap, snort, gfi languard, and ms baseline security analyzer to check your systems; dump your linux and windows boxes to a syslog server that notifies on any irregularities; use SUS, SMS or something similar to patch all systems quickly and efficiently. If we are more proactive, then forensics will be less of an issue.
Analogy (Score:1, Funny)
crack whore at the gynecologists
OS integrated DRM and Steath "hiding" technique (Score:5, Interesting)
(http://itheresies.blogspot.com/ | Last Journal: Wednesday April 28 2004, @12:06AM)
Crackers and hackers always find ways to exploit the code to access or share protected content. There is not a DRM system that has not been cracked within months of widespread release.
A stealth virus is one that, while active, hides the modifications it has made to files or boot records. It usually achieves this by monitoring the system functions used to read files or sectors from storage media and forging the results of calls to such functions. This means that programs that try to read infected files or sectors see the original, uninfected form instead of the actual, infected form. Thus the virus's modifications may go undetected by antivirus programs.
OS based DRM systems can still successfully lock a user, and any program, even if is running under localsystem/root privilege, out of areas of diskspace and memory. Microsoft's Mediaplayer , Active-X ( used with some DRM protection ), Real's realplayer, and even Microsoft's and Sun's Java JVMs, have in the past had remotely exploitable vulnerabilities. Such enviable offers the malware creator the ability to hide the virus from any antivirus tool or live forensic analysis.
The DRM encryption offers the ability for the malware to store content, and without the keys to decode the content, it is hidden from any forensic analysis.
I have the book (Score:4, Informative)
...and I'd have to say that the review was pretty thorough. I couldn't put the book down when I first got it (which would probably be true for any other self described nerd on here). Here's the link [awprofessional.com] to the book's web site if you want to read anything about it. There is a sample chapter there as I'm sure there probably is on amazon or bn.com.
Fear stenography as data hiding method... (Score:1)
(http://slashdot.org/ | Last Journal: Wednesday December 15 2004, @08:38PM)
It's always the same (Score:1)
(http://science.slashdot.org/4hire.pl)
People always confuse these two words,
stenography - typing fast on a weird machine,
steganography - information hiding techniques.
Dupe? (Score:2)
(http://nicholasbernstein.com/)
http://books.slashdot.org/article.pl?sid=04/11/
Re:FYI (Score:1, Informative)
Re:A much better book! (Score:1)
(http://www.debian.org/)
Re:Who needs books!? (Score:2)
(http://www.schmerg.com/)
Really ?? How much are you willing to bet [storageheaven.com] on that ??
Hmmm, I wonder if Google will predict roulette numbers for me too
Re:Who needs books!? (Score:2)
(http://www.petitiono...wtr650/petition.html)
Re:Who needs books!? (Score:2)
(http://www.smashcat.org/personal/)
The only way you've any chance of hiding your Pr0n is by using an encrypted filesystem like CryptFS [sunysb.edu], an encrypted loopback or whatever...
Re:Who needs books!? (Score:2)
Re:Who needs books!? (Score:2, Informative)
(Last Journal: Sunday November 11, @09:31AM)
I'm willing to bet you're wrong. A SATA-PATA converter is 20 bucks, if thats what it takes. And even if you don't recreate the files, you can still search bit for bit for tags like "JFIF" which denote the start of a jpeg file, and then just grab the data to see what the jpeg file is of.
Believe me, linux is not beyond the long arm of the law. When the FBI raids the big warez sites, do you think those are all windows machines? They manage to get convictions.
Re:Who needs books!? (Score:2, Informative)
Re:Who needs books!? (Score:5, Informative)
If you're going to repost other people's posts, at least preserve the formatting, you lazy turd.
Re:Who needs books!? (Score:5, Informative)
2) Most dedicated computer forensic tools, especially those for examining hard drive images, can work with any filesystem from FAT12 to xfs on a RAID 5 set. Again, the burden falls on the examiner to know the proper tools/methods for examining these file structures.
3) SATA drives can be copied with any dedicated hardware copier (such as Logicube's MD5 or Solitaire), but dd combined with an SATA interface will work just fine. Any memory image (RAM, IDE, SCSI, SATA, etc.) can be imaged with just dd, even over a network.
4) "Average nerds and hackers are so far ahread of the forensics guys"...what nonsense. Computer forensic analysts are without a doubt some of the most talented people in IT period. Computer forensics is multi-discipline and analysts typically have backgrounds in engineering, programming, criminology, and languages. And why are you assuming that most computer forensics experts are in law enforcement? The best analysts are in the private sector, military, and government intelligence.
Re:FYI (Score:3, Informative)
(http://www.gh-sts.com/HOWTO | Last Journal: Tuesday November 01 2005, @09:39PM)
Or here [amazon.com] if you'd rather not use an affiliate link and pay someone who didn't do anything more than type a few words into a search box.
Re:Who needs books!? (Score:2)
(http://slashdot.org/)
There are data recovery shops that probably do have the necessary equipment...though I don't see a problem with taking the drive, booting off of a CD and doing a bit copy to another drive using dd.
In either case, I think your confidence level is a bit too high. The forensics software I've used has checksum ID strings for known files and uses that as the basis for finding the known parts. These checksum databases are available for Unix-like systems, not just Windows. Once accounted for, the remaining file space can be investigated for other data.
The average hacker vs. the average cop, no doubt you are correct. The average hacker vs. a professional data forensics expert...it all depends on how much time the forensics expert has to do the investigation.
Re:Who needs books!? (Score:2)
(Last Journal: Wednesday November 21, @10:04AM)
As is always the case, the degree of security you need depends on how much effort anyone is going to put into compromising it. If you're a low-level pot dealer, you're probably right that your obscurity provides adequate secuity. On the other hand, if you're Osama bin Laden, I'm thinking they'll get your drive to someone who can read reiser partitions.
MOD PARENT DOWN (Score:3, Informative)
Re:Who needs books!? (Score:2)
No.
It's the only tool they know how to use.
Re:Who needs books!? (Score:1, Informative)
Re:FYI (Score:2)
Re:Who needs books!? (Score:2, Informative)
(Last Journal: Monday November 08 2004, @08:30PM)
The local Computer Investigation B. has some prety sofisticated stuff, all there software is used much the same way you described in court.
There was a case a few years back here where a guy had some files on his linux box that were incriminating. He set a script to do 10 DOD wipes. That's writing 1's and 0's 7 times over the HD, X 10.
The lab was able to 1:1 the drive, then recreate every file that was saved to the HD since the purchase date.
My friend runs this lab, he said his record is 15 reformats, and still recovered data. He recently had his first SATA case, he was able to dup the drive, and, since the guy had never reformated, and was on his first linux install, he had no problems!
Remember, the NSA can ALWAYS do it, most of the time before hackers can! They in turn hand down the info (as needed) to the FBI, CIB, and finally in the form of books, like this guy did.
It wouldn't suprise me if SATA has been cracked from day 1 release to the public. And xfs, the same.
My 2cents worth, take it for face value, it's all I got.
Re:FYI (Score:2, Funny)
Re:Who needs books!? (Score:2, Informative)
(http://www.alacpp.org/ | Last Journal: Wednesday April 03 2002, @10:12AM)
EnCase [guidancesoftware.com] supports Reiser3. I don't know whether Reiser4 is so radically different from Reiser3 that we can't decode the filesystem currently, but I'm sure we could roll it out the door quickly if there was a large need. We've done it for our customers before.
We can't yet do XFS, but we could still recover quite a bit of data from unallocated. As others have noted, all you need to get an image is good old dd.
In many respects, savvy forensics investigators are far ahead of most criminals. Police forces band together to create high tech task forces, and they tend to have plenty of budget (e.g. they have their own clean rooms for manufacturing damaged hard drive parts). With all the ways that Windows and most applications leak information, it requires an extreme amount of discipline to avoid littering your hard drive with evidentiary artifacts.
It sounds like you do need a book.
cheers,
Jon
Re:Who needs books!? (Score:2, Informative)
Re:Who needs books!? (Score:2)
(http://http//www.freeiPods.com/?r=14230492)
Man, you just the exact situation I had happen last year. My Linux email server was compromised do to a vulnerabilty in squirrelmail/UW Imap. They didn't do any damage that I could find, so I just took the email server off line, and buitlt a brand new one and hardened it. Unfortunatelly, my boss had to find out, because email was down for 1 day. Since she found out, she wanted me to report it to the Feds. I relunctantly did so. 3 Feds showed up. I handed them the drive, and they made an image of it with the device that you have mentioned. They then tried to use their SW to examine it. Guess what, it only works on WINBLOWS FORMATTED DRIVES. They couldn't see any of the data. They have since stopped investigating the case.
Re:Who needs books!? (Score:2)
(Last Journal: Friday November 16, @11:29PM)
This is partially true in that most crimes are taken on a "Big fish versus Small fish" basis. This is no different from traditional crime. In the case that a hacker hit a small business with very little effect, it is generally more practical for an incident response team to find out what happened, restore from a trusted backup, and then go about fixing the problem so it doesn't happen again.
However, if you're trading kiddie porn or decide to peruse your local financial institution or any other institution regulated and required by law to report hacking incidents, I will guarantee that you become a "Big Fish" fairly quickly.
And the range of forensic tools available to a good forensics analyst is likely to cover most anything you throw at it. You are correct in that local PD cyber crime units are often started by guys who have very little computer expertise and do not initially know how to get forensically-sound evidence. However, free software like iLook and expanded forensics education programs are changing that. And, if you do become a "Big Fish," you can almost bet that the guy assigned to your case knows what he is doing.