Interesting Links, and Some Thoughts

Often we run across interesting posts or articles on the Internet, and this leads us to other sites that interest us and may often be applicable to the work that we do.  As such, blogging provides better approach to presenting and sharing this information, and the thoughts that are generated, because we not only have the site itself (as with a bookmark), but we can also include why we found it interesting, or some additional, supporting commentary to make the information a bit more useful and relevant.

Registry Artifacts
Andreas Schuster recently stood up a Scoop.It site for DFIR topics, and from that, I found this post at Pragmatic Forensics.  The title of the post is somewhat off with respect to the actual content, but the content itself is interesting.  In short, an analyst created a timeline and ran across an IRL example of the use of the Image File Execution Options Registry key as a persistence mechanism.

This key is addressed starting on page 133 of Windows Registry Forensics, and the RegRipper imagefile.pl plugin.

Along the same lines, I recently read this Cheeky4n6Monkey blog post, which discusses using SIFT tools to perform a diff of Registry hives.  The example provided in the post is excellent, and can be easily translated for use in analyzing hives on a Windows 7 system, particularly when you want to know what changed following a VSC being created, or between VSCs.

Writing
Like many folks, I wasn't a big fan of writing.  I know that's hard to believe...but the fact is that I didn't like to write.  I wasn't good at it, and it was always a chore.  Even when I did put effort into what I was writing, the results were often not what I'd hoped.

Over time, however, I was in positions and situations where I had to write.  While I was in the military, there were JAG Manual investigations, fitreps, awards, log entries, etc.  I had to write during my graduate program.  When I got out of the military, and moved to private industry, I had analysis plans and reports to write.

Perhaps the most succinct description of why we (DFIR analysts) should write is  encapsulated in the 7 Real Ways Writing Increases Expertise blog post.  Take a look at the points mentioned...I think what's really powerful about this is that writing does allow us to clarify our thoughts, and you have to admit, you don't HAVE to hit the Send button until you're satisfied.

Self-Inflicted Artifacts
Over 6 years ago, I wrote a blog post regarding the MUICache key.  At the time, I was wondering why I was seeing a reference to malware creating this key in AV vendor write-ups.

This System Forensics blog post provides an excellent example of self-inflicted artifacts.  The post as a whole is an excellent resource for using Volatility in malware analysis, but very early on in the post, the author mentions a value being added to the MUICache key, as well as UserAssist subkey entries being created.  These are self-inflicted artifacts, and a result of how the malware was executed for testing (i.e., place it on the Desktop, and double-click).

Okay...so why does any of this matter?  I came across the following Registry key:

HKLM\SOFTWARE\Microsoft\RFC1156Agent\CurrentVersion\Parameters

"MiB".  Get it?

According to the timeline I'd created, the key had been modified during a specific time period that was potentially of interest.  When I checked the key, it had a single value named "TrapPollTimeMilliSecs".  I am familiar with SNMP, so I know about traps and MiBs (per RFC1156), but I ran a Google search for the value name, I got a number of hits associated with malware.  In fact, I found one AV write-up that indicated that this was the only artifact associated with the malware.  Ultimately, the analysis did not reveal indications of malware on the system (included scans with multiple AV scanners).

None of the sites I found could provide a clue as to how the value in question is used by malware.  Many of the write-ups I found stated that the value (and it's data) were created by the malware, and my timeline indicated that the key had been modified at a certain time, which could mean that the value was created...or it could mean something else.  And no, I don't have a sample of the malware to analyze.

Overall, I'm beginning to think that the value is a "self-inflicted" artifact, and that the same might be true for some other artifacts that I've observed.

Shoutz to Cory Altheide for using "self-inflicted" in a sentence, and allowing me to bogart the term.

Vulture Research
I was reading this news article recently (yes, I admit it, I'm a closet CSI fan), and it got me to thinking...how often do we, as analysts, misinterpret what we have in front of us?  How often do we draw conclusions based on the data that we have, given the possibility that the data is incomplete?

So...in case you didn't want to read the article I linked to, it's about research that was conducted with respect to scavenger predation of bodies, and how it can affect homicide investigations.  If you watch the crime shows (CSI, NCIS, Bones, etc.), you can probably recount episodes in which a skeleton was found in the open and the conclusion was drawn that the body had been there for months.  Well, this new research indicates that vultures can denude all flesh from a body in a couple of hours...and this can have a significant impact on the assumptions made about the timeline of the crime.

So, this got me to thinking...how often does this happen with what we do?  This "new" research with respect to the vultures is simply something that's been happening for a while, but investigators perhaps haven't considered it.  After all, these birds come down and feed for a few hours, you'd think that there'd be some sort of evidence of this...tracks, feathers, etc.  But what if these artifacts were not noted or simply ignored, or obscured by weather?

Now, consider digital analysis.  Who has received a Windows 7 system to analyze in the past year (or more) and their investigation involved tracking user activity?  When you examined the system, did you include Jump Lists in your analysis?  Registry artifacts?  If you had to track USB devices connected to the system, did you include the EMDMgmt Registry key in that analysis? 

Also, consider Corey Harrell's recent post on Jump Lists; even though he's worked backwards in our usual sequence (starting with a known task first...), he's shown what's possible on systems, and allows other analysts to connect the dots and fill in some gaps.  If you'd looked at a Windows 7 system recently and had to determine authorship of a document, did you consider something along the lines of what Corey pointed out?  Did you collect metadata from the document itself?

How often have we made and reported conclusions based on incomplete analysis, and how often have we used assumptions to fill in the gaps?

One of the ways to overcome this is to use checklists for certain types of data collection, particularly those that are complicated and repetitive.  Notice I don't say "analysis"...that's because data gets collected, and then someone analyzes it; a checklist provides the ability to duplicate the data collection phase, and provides that data for analysis.  The key to this is that a documented process can be updated and modified...you can't evaluate or replicate something that you don't have written down.  Examples of where you might use a checklist include (but are not limited to) USB device analysis, malware detection, authorship of or access to documents, etc.

As  a side note, I've taken some time recently update my malware detection checklist, offline, including some input from some of the recent and excellent malware analysis books that have been published.