Analysis of ADD Ref Image - Part 1

Two weeks ago at Shmoocon I showed the ADD anti-forensics tool with my SANS Memory Forensics (FOR526) co-author Alissa Torres.  Others have pointed out that memory artifact forgeries have previously been theorized about, but to my knowledge, no other publicly available code demonstrates the concept.  Sadly, forging these artifacts is way too easy to do so I'm glad to bring awareness to the subject with a proof of concept tool.

I was eventually going to get around to walking through analysis of the memory image, but Jack Crook beat me to it with this excellent blog post.  If you haven't read it, do that first.  As the author of the tool (and the "attacker" of the sample machine), I get a huge advantage that Jack didn't have in his analysis.

Like many attackers, I made (intentional) mistakes creating the image.  These leave some breadcrumbs for those who know what they are looking for.  It all comes down to knowing what "normal" looks like.



If you examine the output of a psscan, there are three abnormal processes.  There are a couple of things that should stand out:

1. The PDB (page directory base aka directory table base or DTB) is the same on all three anomalous processes.  I left this as a static signature in the released build  of ADD.  Any attacker could change this, but I'm betting that script kiddies won't.  In any case, each process should have a unique PDB and I removed the code for randomizing the PDB from the release build.  If you want to signature the default build of ADD, this is currently your best bet.  The PDB of 0x12345680 is very unlikely to be legitimate (and very likely to belong to ADD).
2. The creation times are wrong (probably).  Note that the three bad processes were all created before smss.exe.  That shouldn't happen.  The only way this is legit is if these processes were here from a previous boot (assuming the machine was never powered off).  But that's unlikely (and easily verified with log review).  Applying Occam's Razor here, I'd say the more likely scenario is that the attacker simply got the times wrong when faking the EPROCCESS structures.
3. The cmd.exe process (assuming this is a legit cmd.exe) is missing something.  In Windows 7, a cmd.exe process should have a corresponding conhost.exe process.  That's notably missing in this case.  The likely explanation is that the attacker screwed this up and forgot to forge a conhost.exe when creating this artifact. 

Are there other ways to detect these forgeries?  Oh yeah.  I'll cover some of those later.  But for now, I wanted to point out that just by knowing a little about what's normal in Windows we can start to unravel that these artifacts are forgeries.  To find the evil, you must first be able to identify the good.