Re: [PEN-TEST] Auditing for Malicious Tools

[H Carvey <keydet89 () YAHOO COM>]

I'd have to agree with Mark...trying to find malicious tools 
on a system can be a tough job, w/ so many places to look...

To follow along with what Mark said, one approach would be 
to use a little prevention ahead of time, in order to make 
your detection easier.  For the 'ounce of prevention', I'll 
use an article I wrote as an example:

http://patriot.net/~carvdawg/NTtrojan_article.html

If your policy is that users cannot install software, then 
you can easily back that up with technical controls; ie, 
ACLs on files, directories, and the Registry keys.  Do not 
allow users the right to create or write to Registry keys, 
or to write to certain directories.  

If you lock down the filesystem, for example, you can allow 
them to write to the Temp dir (some apps, like Word, will 
write files there), and then have a cleanup routine as part 
of their login.

Once you lock down the filesystem and enable auditing, you 
can remotely sweep through the EventLog, looking for EventID 
560 events.  

Any directories that the user can write to can be checked 
using remote tools...Perl is excellent for this.  I have a 
tool on my web site that will run through startup Registry 
keys (Run, RunOnce, etc) as well as the StartUp directory 
of all user profiles on a system...so it's fairly easy to 
do.  I'm working on a Tripwire-like tool called "FileSentry" 
that lets you run MD5 checksums remotely...plus a bunch of 
other goodies...

So again...I would use the defense in depth approach.  Don't 
try to rely on combing the entire filesystem, running 
checksums on all the files, etc.  Limit the directories that 
the user can write to, and then comb those...

Carv