Slashdot Mirror
Windows Forensics and Incident Recovery
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.
I can just see the "sharing violation" and "file in use" message boxes flying everywhere.
-- Mike Keryeski
http://freemp3players.fasturl.us
FYI, Amazon is also selling the book here. You save more than $10!
How do you keep a windoze box running long enough to do any forensic work on it?
They whose government reduces their essential liberties for temporary security, receive neither liberty nor security.
From article:
" Sample topics include file attributes, alternate data streams, OLE and stenography"
Should that be Steganography?
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. . .:)
You are not the customer.
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!
A Multiplayer Strategy Game for Mac OS X, Windows, and Linux
I actualy think this one:
The Koran
and this one:
Bible
is much better when it comes to windows revovery and security
A computer forensics guy came to talk to my computer crime class last year. He showed us this windows tool they use to look at confiscated drives. Pretty much first they make a bit for bit copy of a drive onto a drive of equal or greater size using a hardware device. Then they put the original drive away in the evidence box without touching it again. Then they use this software tool, which I forget the name of, which is the only tool that holds water in a court of law. It examines the whole drive one piece at a time to recreate every file on all partitions and filesystems even if the files are "deleted". His example was how he caught a bunch of kiddy porn perverts. Well that's great for catching those guys, but against someone using out of the ordinary stuff this guy is screwed. I've got serial ATA drives and reiser4 and xfs file systems. I'm willing to bet that he doesn't have a hardware drive copier that supports SATA. And his software doesn't recognize reiser4 or xfs. He would either need a different tool or he would have to send the drive someone higher up to be examined. And if the case is too small they wont bother. The real problem is that the average nerds and the hackers are so far ahead of the forensics guys in terms of knowledge about modern technology and software that they can't keep up. Hackers will always have bleeding edge tools, and police budgets can't
For some reason after every investigation the only culprit to blame in all windows problems is Bill Gates... Film at Eleven....
Cool, I love arcane knowledge *hugs his falconry for dummies book*
"It's too bad she won't live, but then again who does?" - Gaff
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.
Trolling is a art,
"Yet I cannot help remember one enigma. A hybrid, elusive destroyer. This is the only mystery I have not solved. The only element unaccounted for."
not stenography... Stenography is 'short hand'.
My God! It's full of Voids!
Mr Garrison, in the library, with the baseball bat!
(Seems puppet-boy's developed a taste for necrophilia!)
"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, 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...)
I see this and want to kill the slashdot window in my browser.
Windows Forensics
crack whore at the gynecologists
----
It should go to the Science Fiction book review category.
Go grab those torrents.
He is just spamming with his amazon account.
Come on Timothy - let's start proofing those articles:
/. - we don't proof the articles. :-)
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 - (you mean STEGANOGRAPHY?). This is an excellent chapter with many examples; I found myself stopping after each subject to try out each of the discussed techniques.
Oh wait, this is
yeah, I wish I had mod points myself.
Or maybe you need to type really fast to be able to analyse the system before the evidence is deleted.
Love of two is BSD culminated in it will be among (7000+1400+700)*4 the wind appeared are A few good That should be the next round of of all legitimate
Not surprising for a brain-dead OS
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.
YOU DON'T KNOW WHAT PAIN IS!
...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 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.
Is that postmortem available online?
Bleh!
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 polymorphic virus code which encrypts the decode key in the virus startup code.
fact is, after a complete format everything is lost.
Don't create urban myths.
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.
No, I'm New Here
I know, I know, it was a typo... still funny.
This book is danger first rule of a breach bring system down and backup from a indepentant source. Just in case the program or person who breached has installed a del all program that could be working in background nice way to clean your tracks embed delete all in explorer.(yes there is at least one person out there who has done this)
Knoppix and other linux disks are great for this.
If you dont have a backup server it is your own fault for building networks too cheep there is a min cost of a network built correctly.
Also the backup provide provable evidence if you go to court. This is what the machine look like at day x. G4u is one of the best tools for this even nortons ghost if you can afford it is great too. Requried tools are free to do everything correctly. Note a G4u backup will let someone less have a look at the drive after Forensics who might have better skills. Note bring system down even if it is a in memory thing will stop the data leak now. Active firewall loging of connections in the linux firewall box is a good move if you think that it is in memory as it will provide the required tracking info.
Ie Microsoft Office and Internet Explorer stop using them you will be suprised how stable the system becomes.
Ie FireFox pre version 1(have not tested version1 yet)has memory leaks it eats more resources over time then kills self leaving system intack A beta program allways has problems FireFox is no different.
Please note stoping using Microsoft Office is alot harder than what is sounds a lot of things load up at startup without you knowing.
Unstable with this "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."
No way in hell try running a full install of linux with only 128 megs of ram on a Pent2 based motherboard with a pent 3 333mhz cel on it with 5 ltsp machines hanging of it and 2 2g drive raid together with software. This is lock up central it lives everyone has to take the lockups sometimes 2 and 3 mins at a time. 256 megs of ram helped a little but processor is way to small ie all programs from 6 users run on the same chip it kinda hurts. Love to see someone do this with windows.
This is just not true. Otherwise we would have infinite-storage drives.
And the reason they destroy drives is because they don't trust people to reliably wipe them. People forget, use the wrong software, skip a step, etc. If you were 100% sure employees would wipe drives properly, then you could wipe them and allow reuse knowing that no one could recover any useful info from the drives. But people aren't reliable: they're lazy, forgetful and sometimes downright malicious. It's cheaper to destroy the drives.
Well, if you're viewing kiddy porn then I'm probably not feeling sorry for you if you're nailed anyhow - however there are other factors. I think the easiest place to get nailed is cache. Either your browser cache or whatever. Unless you're pointing *that* to an encrypted FS (or the whole thing is encrypted, which is super-high overhead) you'll probably have something in there.
The big problem I see is that you can have such things in your cache without being a pedo. How many pr0n sites advertise lolita pics, and there are fuzzy banners etc. I've had a few times where my normal pr0n-browsing misadventures have ended up with all sort of interesting popups (moz helps this, mind, but not always)... anything from animals to underage and other types of filth. Even if I haven't viewed it, the bazillion popups it spawns have probably nicely laced my browser caching will also sorts of incriminating crud.
I've always wondered if those things would be used against you, but it probably depends on how bad they want to nail you or if they just don't like you. Hopefully I'll never have to find out, and lately moz has been doing a good job of blocking the popups.
"[...]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?
0 9/ 202220&tid=192&tid=172&tid=6
http://books.slashdot.org/article.pl?sid=04/11/
RandomAndInteresting.comdefending the world from stupidity since 1979