Security Incidents mailing list archives
Re: Incident investigation methodologies
From: Pho Man <ph0k1n () yahoo com>
Date: Wed, 2 Jun 2004 14:56:12 -0700 (PDT)
Hi Harlan et al, I very much agree with the philosophy of taking a scientific approach to understanding hacker methodology. I am definitely not the foremost expert on this stuff (not even close), but I have found that doing experimentation with hacker tools has helped me in my humble forensics efforts. FOr example, lately I have been working with WIndows rootkits (it's funny you should mention that). I used an old XP workstation (non-networked of course) installed a rootkit, and tried to detect it, and then remove it without reinstalling the OS. FWIW, I learned a lot through these methods. For example, the first rootkit I tried, HackerDefender, totally eluded all the forensic tools I had been using, so I had to start over, learn new techniques, find better tools, etc. Its humbling to know that you know nothing, and then it's good to learn from it. :) --Pho Man --- Harlan Carvey <keydet89 () yahoo com> wrote:
Stepping off from a now-dead thread, I'd like to open up the discussion for investigation methodologies. As mentioned earlier, it's very easy to sit back and say "a 'hacker' could...". Yes, that's true...but what that ultimately leads to is complete paralysis. At a certain point, there are so many things that an attacker *could* do that there's no sense in doing any sort of forensics on the system, live or otherwise. Folks within the security profession, and even those on the fringes, are doing themselves a huge disservice. Posting to a public list/discussion that something *could* happen serves no purpose, and greatly reduces the signal to noise level. Instead, what I'm suggesting is that we, as a professional community, look to repeatable experiments in those cases where we do not have actual data. By that, I mean we set up and document our experiments to a level that someone else can verify them...run them on the same (or similar) set up and get the same (or similar) results. How do we do this? Here's an example...instead of saying "...a rootkit could...", get a system and a rootkit, and install it. Find out what that particular rootkit does. Document your testing setup (ie, WinXPSP1, etc), what you did to test (ie, ran FileMon and RegMon) and what you found. While it's entirely possible that a rootkit *could* do something, why not base what we do in fact, rather than in speculation, rumor, and paranoia?
__________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/
Current thread:
- Re: NKADM rootkit - Something new?, (continued)
- Re: NKADM rootkit - Something new? Harlan Carvey (Jun 02)
- Dead Thread: Re: NKADM rootkit - Something new? Daniel Hanson (Jun 02)
- Incident investigation methodologies Harlan Carvey (Jun 02)
- Re: Incident investigation methodologies Gadi Evron (Jun 02)
- Re: Incident investigation methodologies Harlan Carvey (Jun 03)
- Re: Incident investigation methodologies Ansgar -59cobalt- Wiechers (Jun 04)
- Re: Incident investigation methodologies Paul Schmehl (Jun 04)
- Re: Incident investigation methodologies Jon Coller (Jun 04)
- Re: Incident investigation methodologies Valdis . Kletnieks (Jun 04)
- Re: Incident investigation methodologies Harlan Carvey (Jun 07)
- Re: Incident investigation methodologies Pho Man (Jun 04)
- RE: Incident investigation methodologies James C Slora Jr (Jun 07)
- RE: Incident investigation methodologies Harlan Carvey (Jun 08)
- Re: Incident investigation methodologies James C. Slora Jr. (Jun 08)