Keylogers

[Robert J. Hansen]

On Wed, 27 Apr 2011 12:56:19 -0400, Mike Acker <Mike_Acker at charter.net>
wrote:

> This is why we need the Software Audit Tool I've discussed at times on
> various boards.  The Software Audit Tool will need to be on a separate,
> read-only, bootable media such as a DVD.  On boot-up it would mount the
> C: drive of the target system and then pull a software inventory. When
> complete this inventory would be audited, checking the data-time stamp
> and CRC of every executable software in the inventory.  This would be
> checked against OEM specifications and system owner's noted.  System
> Owners Notes should specify: what packages are supposed to be on this
> system.

Already exists: a copy of md5deep and the forensics signature database
will do it for you.

Unfortunately, as people have learned, this technique doesn't actually
work -- at least, not reliably.  False positives abound all over the place.
The problem is the signature db: it simply cannot work the way people
think it should.  Some system patches use data from the host system as part
of the patch.  (As an example, your processor ID might be used as a unique
identifier somewhere within the code.)  This means the updated executables
will not have a reproducible hash: each machine will report a slightly
different one.

You can get around this somewhat with fuzzy hashing, but in the main this
is an unresolved problem in computer forensics.  You can easily tell when a
file is known-good, but just because a file isn't on the known-good list
doesn't mean it's bad -- and telling the bad apart from the good is a
Herculean task.

My next door neighbor (okay, so he lives a block away) is pretty big in
the digital forensics community: if you like, I'd be happy to ask him about
the latest research in this the next time we go out for beers (probably
Monday, to celebrate his Sunday marathon).