Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Books Media Security Book Reviews

Windows Forensics and Incident Recovery 142

Posted by timothy from the windows-is-a-big-pain dept.
dba599 (Mark McKinnon) submits this review of Harlan Carvey's Windows Forensics and Incident Recovery, writing "This book takes an unusual approach to computer forensics in that it deals only with live analysis of the system: the compromised computer is left powered on and everything is running. (Compare to a dead analysis, for which the computer is powered off and the hard drive's contents are then analyzed.)" Read on for the rest of McKinnon's review.
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.
This discussion has been archived. No new comments can be posted.

Windows Forensics and Incident Recovery More

Windows Forensics and Incident Recovery

Comments Filter:
  • I can just see the "sharing violation" and "file in use" message boxes flying everywhere.

    • Not only that, how do you mitigate the risk of losing deleted information to the creation of other files? I've analyzed HDD images up to 40GB and they're no party. It can take quite a bit of time to do a thorough analysis of the disk. It seems to me that you'd run the risk of losing important filesystem information or the contents of unlinked files. If some idiot runs degrag or something you could lose a good bit of critical fs data before it's stopped. Hell, everytime you launch an Office document it seems

    • Re:Your typical sharing violations (Score:3, Informative)

      by Anonymous Coward
      I can just see the "sharing violation" and "file in use" message boxes flying everywhere.

      The solution to this is to go beneath the file system. Read raw sectors from the disk and interpret FAT or NTFS yourself. You run the risk of corrupt data if a file changes while you're reading it, but it's about the only way to snag registry files and the like while the system is up and running.

      AccessData [accessdata.com] FTK Imager is capable of doing just that, and it was used for this purpose in Operation Firewall [slashdot.org]. It was als

  • what? (Score:3, Funny)

    by zmollusc ( 763634 ) on Tuesday November 09, 2004 @04:28PM (#10769795)
    How do you keep a windoze box running long enough to do any forensic work on it?

    • Re:what? (Score:1, Funny)

      by Anonymous Coward

      The secret is leaving it at the BIOS screen for weeks on end. It's not very useful but the machine gets wicked uptime before running MS code.

    • Re:what? (Score:4, Informative)

      by baadfood ( 690464 ) on Tuesday November 09, 2004 @04:51PM (#10770075)
      While that is intended no doubt to be amusing, I use a Win2K pro system to develop.

      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.
      • Dual Pentium 4 ? Who makes such a mobo ???

      • Re:what? (Score:3, Interesting)

        by Loki_1929 ( 550940 )
        Indeed. I use Win2k Pro at home, myself, and I must say that ECC memory has really completed the system in terms of stability. The last time it went down was about a month ago when my Antec TruePower 550 crapped out. (ugh, almost brand new!) The last time it had been rebooted prior to that was back in May when I took some hard drives out of it for use in another machine that I was putting together just for storage, and put in that damned Truepower PSU. Before that, I couldn't tell you the last time it went

        • Re:what? (Score:2)

          by ghjm ( 8918 )
          Then you aren't running current patches, and are vulnerable to various exploits. In order not to be vulnerable, you'll have to run Windows Update, which will require you to reboot for several of the current critical updates.

          • Re:what? (Score:3, Insightful)

            by Loki_1929 ( 550940 )
            I run patches when I do hardware maintenance. If that means I run a few months behind the latest and 'greatest' Microsoft patches, so be it. I run a router with a stateful packet filter, an application-level software firewall, an IDS, and multiple anti-virus/anti-trojan scanners. If someone manages to get into my system and stay there, they deserve it.

        • "Indeed. I use Win2k Pro at home, myself, and I must say that ECC memory has really completed the system in terms of stability."

          2K's pretty cool, iddn't it? I've been running Lightwave plus After Effects for several weeks straight now. Time == money is very much a fact in my line of business. I'd be the first to go running to Linux (Actually, OSX is a more likely candidate...) if Windows behaved like the anti-MS bunch imagines. Yet, rehashed BSOD jokes still get +5 funnys...
    • The serious side to this is that if the system is running then is what you find a result of what you are doing or what the person being investigated did. In Britain we *HAVE* to analyse dead systems as this is the only way to say we are looking at what someone else did when the system was live. You have to image the system and work with the images as it is important not to taint the evidence in any way. Any mistake will result in a lost case. One of the stupidities of Windows is that even if you mount a

  • Hiding Data (Score:4, Informative)

    by darth_MALL ( 657218 ) on Tuesday November 09, 2004 @04:32PM (#10769846)
    From article:
    " Sample topics include file attributes, alternate data streams, OLE and stenography"
    Should that be Steganography? [wikipedia.org]

    • Re:Hiding Data (Score:4, Funny)

      by micromoog ( 206608 ) on Tuesday November 09, 2004 @04:39PM (#10769923)
      You know, stenography. As in, typing the files on paper instead of in the computer. Makes them really hard to find later.

    • stenography (Score:1, Redundant)

      by temojen ( 678985 )
      Or maybe you need to type really fast to be able to analyse the system before the evidence is deleted.
    • "Load the first image, apply the logical and operation with the number 3 to the image, and make the image 85 times brighter, and you get the second image."

      Has anyone tried the example in the link? I'm not sure what is meant by the bolded statement in the quote from the Wikipedia article.
      • I loaded it up into IDL, and sure enough, the damn thing works. Creepy. For those of you out there with a copy of IDL handy, try the following commands:

        image = READ_PNG(Dialog_Pickfile(Filter="*.png"))
        TV, (image AND 3)*85

  • Non-software solutions? (Score:5, Interesting)

    by Limburgher ( 523006 ) on Tuesday November 09, 2004 @04:32PM (#10769847) Homepage Journal
    Does the book offer any comprehensive ideas beyond tools you can download and hwo to use them? I'm really more interested in knowing where an attacker's footprints are likely to be evident, not in using some sort of footprint detector. Tools are nice, but one should have basics to fall back on when tools are unavailable or untrusted. That said, the best Windows security tool is Nero. It's great for burning Debian .isos. . .:)

  • Here's my method (Score:3, Funny)

    by BortQ ( 468164 ) on Tuesday November 09, 2004 @04:32PM (#10769850) Homepage Journal
    Granted I have been called crazy, but here's my computer forensics method:

    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)

    by Baron von Blapp ( 767958 ) on Tuesday November 09, 2004 @04:37PM (#10769893) Homepage
    I love books that only dish out arcane knowledge that .02% of the windows sys admin or windows security [sic] community will use once in a life time.

    Cool, I love arcane knowledge *hugs his falconry for dummies book*

  • Live analysis. (Score:5, Interesting)

    by grub ( 11606 ) <slashdot@grub.net> on Tuesday November 09, 2004 @04:37PM (#10769894) Homepage Journal

    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.

  • not stenography... Stenography is 'short hand'.

  • Live "Forensics" (Score:5, Interesting)

    by stew1 ( 40578 ) on Tuesday November 09, 2004 @04:48PM (#10770028) Homepage Journal
    "Forensics" on a live system is a misnomer. For incident response, collecting live data on open ports, running processes, logged on users, and mounted devices is useful and sometimes necessary. Investigators should be sure to check -- gingerly -- whether any encrypted volumes are mounted.

    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)

      by pbranes ( 565105 ) on Tuesday November 09, 2004 @05:05PM (#10770244)
      I see your point, but the extreme difficuly comes when a sysadmin should determine that something needs to be handled by the information security officer and not by himself. Here's an example:

      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.

      • Re:Live "Forensics" (Score:3, Insightful)

        by stew1 ( 40578 )
        And that kind of an IT response (problem? reboot!) is fine, because you've got work to do after all.

        However, at the point that you discover that there's been an incident, you should note what's running (ps), what's open (netstat), who's logged on, and what drives are mounted. Document everything that you do (date/time, action, reason for action), pull the plug, and call your lawyer.

        Incident response is difficult as the scale of the "response" can vary so widely. Sometimes it's enough to run a virus scanne
    • Jon,

      I find that second paragraph interesting - doesn't that directly contradict the purpose of your Encase Enterprise Edition product? (of which my security team happens to be a happy customer, btw.?) Also, isn't there a new Live Analysis feature?

      For the uninitiated, Encase is quite possibly the industry standard tool for Forensic analysis. The latest interation, Encase Enterprise Edition, allows for forensic acquisition over a live network with the installation of a 100k agent on the target machine. Idea
      • Hi Jack -

        The EEE "servlet" will not write anything to the filesystem directly. Acquisitions are made on a low-level sector-by-sector basis.

        However, running *any* program on a targetted system necessarily changes it. The operating system has to allocate memory and CPU time for the process, and on any modern system that can invoke a write to the pagefile/swap area. This is just the way life is, and for corporate investigations -- which almost never go criminal -- this is more than good enough.

        Whether an in
        • Thanks for the response - I agree with you in that running a program does indeed change the system, but I guess the key question is whether it is better to guarantee no changes whatsoever or risk losing volatile data (which could also be very valuable in the case on an investigation into an ongoing matter, like a hack).

          We do have a forensic group on-site or near-site (quick response available). I seem to recall also that PriceWaterhouse is working with Guidance in piloting EEE as a "valid" tool for crimina
    • "Forensics" on a live system is a misnomer. For incident response, collecting live data on open ports, running processes, logged on users, and mounted devices is useful and sometimes necessary. Investigators should be sure to check -- gingerly -- whether any encrypted volumes are mounted.

      Why a "misnomer"? Forensics, in the usage of the phrase "computer forensics", is an extension of our usage of forensics to refer to the presentation of evidence in court. The word initially means "methods pertaining to
      • Commenting on the pulling the plug...

        this is generally suggested for law enforcement who respond to a crime scene for which there is a standalone running machine and a qualified computer forensic examiner is not readily available. In the "bag and tag" process, the responding cops are then told to pull the plug (literally...not from the wall, but from the machine itself) and then bag and tag the machine. This might seem odd at first, and yes things can be lost, but the key is obtaining "forensically sound
      • Can you imagine how badly you would screw up investigations if you went around pulling plugs on a bunch of Linux machines, and losing the entire contents of their /tmp directories in the process? That's liable to get you in the doghouse, that's for sure

        You know, all the time that I was reading the previous comments, when people talked about 'plugging the plug', I assumed that they meant the network connection, it didn't occur to me that they meant the power. Unless the process is stomping all over your f

      • Re:Live "Forensics" (Score:2, Insightful)

        by stew1 ( 40578 )
        Windows-centric? The title of the book is *Windows* Forensics and Incident Response. I guess this is Slashdot so I should expect to be flamed for being on-topic...

        My top post isn't about EnCase.

        As others note here, standard forensic practice -- especially when you don't know what you're doing -- is to pull the plug. That's what the DOJ says, at least.

        In the example that you give, of the OpenSSH vulnerability, it's very likely that the intruder will leave filesystem artifacts. sync() runs every few second

  • Analogy (Score:1, Funny)

    by barcodez ( 580516 )
    Windows Forensics
    crack whore at the gynecologists

  • OS integrated DRM and Steath "hiding" technique (Score:5, Interesting)

    by NZheretic ( 23872 ) on Tuesday November 09, 2004 @05:10PM (#10770296) Homepage Journal
    Microsoft's planned Digital Right Management systems are based on the principle of locking the owner of the computer out of the ability to access sections of memory and disk space used by the DRM mediaplayer systems.

    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.

    • Crackers and hackers always find ways to exploit the code to access or share protected content... 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.

      Make up your mind. Which is it? Can the code *always* be exploited to "access or share protected content", or can malware hide itself "from any forensic analysis"?
      • I think what he is trying to say is that malware authors can use DRM "features" to make the investigator and sysadmin's job harder.
      • 1) The Digital Millennium Copyright Act of 1998 severely restricts the release of any tool which could be used to circumvent DRM technology.

        2) Cracking the DRM code is not the same as cracking the key used to encrypt each item of encrypted content. If the key is not accessable then the content cannot be decrypted without major difficulty . If the virus/malware retains the decrypt key only in DRM OS protected resident memory, then the key is not accessable to the user. Also it is possible to construct polym [cknow.com]

    • There is not a DRM system that has not been cracked within months of widespread release.

      Somebody cracked the DRM system for DVD-Audio? I'd love to know where that utility is.

      Or does DVD-Audio's encryption system not count as true DRM?

      Serious question. Last time I checked (and I search every couple of months), nobody had cracked it yet.

      • Your not looking hard enough [google.com].

        The point is that you have a lot of very clever people trying to reverse engineer the code, which exposes code which has often undergone very little peer review. Most of the times this also exposes vulnerabilities in the decoding software, some of which are remotely or locally exploitable.

    • Any clue how I can unDRM wmv files so that I can play them on a mac? (The ones that need WMP10, but that anyone should be able to view)

  • I have the book (Score:4, Informative)

    by jkitchel ( 615599 ) <jacob_kitchel&hotmail,com> on Tuesday November 09, 2004 @05:29PM (#10770555)

    ...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.
  • I know, I know, it was a typo... still funny.
  • "[...]Sample topics include file attributes, alternate data streams, OLE and stenography.[...]"

    People always confuse these two words,
    stenography - typing fast on a weird machine,
    steganography - information hiding techniques.
  • Wasn't this posted on Tuesday?

    http://books.slashdot.org/article.pl?sid=04/11/0 9/ 202220&tid=192&tid=172&tid=6

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (1) Gee, I wish we hadn't backed down on 'noalias'.

Close