Hogfly,
Thanks for the post…
> Binary analysis of unknown exe's and submittal(virustotal,norman,jotti).
I have an entire chapter on this in my book. If you get a copy, I'd appreciate your thoughts…
> Internet History analysis(Yes, I've seen attackers load up Internet
> Explorer and use it to download programs)
Ah, yes…I've got some great information in the book on this, too.
> Look at mapped drives and MRU keys to determine if other systems are
> in play
I'm considering a forensic preprocessor for extracting this sort of information automatically. There are a number of Registry extraction tools on the DVD with the book, in both Perl source and EXE format.
> Check the SAM for new accounts
The DVD includes a complete copy of SAMparse (see my blog)
http//
Another thought is to parse similar entries out of the SAM files located in Restore Points.
> If a specific account was compromised and used, I'll analyze the .dat file
> for that account to determine activity.
There is a tool on the DVD for parsing out the UserAssist entries, which will be added to the preprocessor.
Thanks, this is great stuff…
Harlan
re plugins
disclaimer I'm not in forensics (but hope to be one day)
I agree that in some cases, people just don't use the plugin features, but there are plenty of cases which do; obviously firefox, but that has a massive community, but also smaller software like paint.NET (
If you package it as a framework, and include all the actual forensics functionality you were going to write into in anyway as pre-written plugins, I think that would be a better approach than adding plugins as a side-thought; people will be able to see how it works. I'm a(n amateur/semi-pro) software developer so I have lots of ideas about where it could go (eg having everything go through an API would make logging what's been done and when a lot easier)
I don't think you should write off plugins because you think no-one would use them. You can offer incentives, such as that you could review 3rd party plugins and offer some kind of seal of approval, or the possibility of being included as standard, with credit, in a future release. All it takes is one enthusiastic user, and you've suddenly got 15 new plugins, increasing the value of the product tenfold; not only does it now offer 15 new features, but it has "an active developer community", thus attracting more developers and so the cycle repeats.
Alternatively, you could offer a DLL that CF software authors could use to link into the meta-feaures of the software, such as logging, without their software being fully integrated into the package as a whole.
"How many EnCase users know how to write EnScripts?"
I don't know EnCase, but the name EnScript suggests that they've developed their own pseudo-language, which is imo a big mistake; developers now need to learn a new language in order to add funtionality, and there's no way they're going to be doing enough coding in EnScript to make themselves proficient in it. Have it done via a loadable DLL that can be imported into C, VB… whatever, and you're increasing your target market; write something bespoke and you're starting with no market, trying to create one from scratch.
"How many Nessus users write their own plugins?"
sorry to be a smartass, but "There are 14181 plugins" - http//
)
anyway, you weren't asking about this specifically, and as I said, I'm not in CF, so I'll shush now, but it's worth bearing in mind )
Don't know if this is the sort of thing you were looking for, but If it's a live system, I find the following command reveals interesting things
ipconfig /displaydns
I'm probably teaching grandmas to suck eggs though )
User24,
Personally, I'm always glad to hear from folks, even if they're not actually in the industry.
> …people just don't use the plugin features…
It's not about using the features…it's about understanding what they do. I used to support a CSIRT where the team manager made blanket (and patently false) statements about what various Nessus plugins did…he'd never bothered to even look at a plugin.
With regards to writing plugins…how many folks already do that sort of thing? I'm on the ProDiscover forum as well as the EnCase User forum, and based on what I'm seeing, folks would rather just push a button.
> …people will be able to see how it works.
okay, devil's advocate…how many people want to see how EnCase works? The framework I'm referring to will be written in Perl, so anyone can "see how it works".
> sorry to be a smartass, but "There are 14181 plugins"
True, but that doesn't answer the question…"How many Nessus users write their own plugins?"
> Don't know if this is the sort of thing you were looking for…
From my original post
"When performing a post-mortem exam of an acquired image from a Windows system…"
Again, thanks for your input.
H
Harlan,
>I have an entire chapter on this in my book. If you get a copy, I'd appreciate your thoughts…
I'm definitely buying the book, and I'm hoping (expecting actually since your first book was awesome) your book is better than some of the ones I've purchased recently 😉
>I'm considering a forensic preprocessor for extracting this sort of
>information automatically. There are a number of Registry extraction
>tools on the DVD with the book, in both Perl source and EXE format.
I'm looking forward to this. I'm beginning to work on Vista and a little perl-fu(using WMI) to detect bitlocker *before* the system is shut down. If possible, I'd try to fit it in to your framework once you make it available.
>The DVD includes a complete copy of SAMparse (see my blog)
>http//
Have you done anything with Vista regarding this and the SAM changes?
> I'm hoping…your book is better than some of the ones I've purchased recently
Hey, no pressure there! 😉 Being biased, I want to say that it is…but it's hard to tell, because there's no other book like this available.
> I'm looking forward to this.
The preprocessor I'm referring to is a post-mortem thing…something to cull through the image (mounted as a drive letter…see that thread on FF) extracting data automatically.
> I'm beginning to work on Vista and a little perl-fu(using WMI) to detect
> bitlocker *before* the system is shut down.
Very cool. I wrote some WMI stuff for the book that looks at Restore Points, as well as a cool script that dumps Security Center info.
> Have you done anything with Vista regarding this and the SAM changes?
Nope, sorry. There's been no stimulus yet to focus resources in this area.
Hogfly,
Nice blog, btw. I caught up on Richard's "thoughts on IR" posting and followed your link over to your blog.
H
Harlan,
Much thanks and thanks for the link off your blog.
No problem…it looks like you've got something good started there…