Friday, August 28, 2015

Updates & Links

HTCIA2015 Presentations
For those of you attending HTCIA2015 (or just interested), I printed my presentations to PDF format and uploaded them to my GitHub site.  Unfortunately, as you'll see, particularly with the Registry analysis presentation, there are slides that are just place holders, so you won't know what is said unless you're actually there.

I recently read this post at the SecurityIntelligence web site, and was more than just a little happy to see a malware write-up that contained host-based indicators that could be used by analysts to determine if a system had been affected by this malware.  The same could be extended to an image acquired from the system, or to the entire infrastructure.

However, something does concern me about the write-up, and is found in the section titled "Dyre's Run Key in Non-Admin Installations".  The write-up states:

Until a few weeks ago, these non-admin installations had Dyre register a run key in the Windows Registry, designed to have it automatically run as soon as the computer is rebooted by the user:

The write-up then goes on to list the user's Run key, located in the NTUSER.DAT hive file.  This goes back to what I've said before about specificity and clarity of language...the malware does not "register a run key"; it creates a value beneath the Run key.  When this occurs, the persistence only works to re-start the malware when the user logs in, not when the system is rebooted.

I know that this seems pedantic, but Registry keys and values have different structures and properties, and are therefore...well...different.  The commands to create or retrieve Registry keys via reg.exe are different from those for values.  If you approached a developer who had no DFIR background and asked them to create a tool to look for a specific Registry key on all systems within an infrastructure, when you really meant value, you'd get a piece of code that likely returned nothing, or incorrect information.

I understand that Registry analysis is one of the least understood areas of DFIR analysis work.  So many Registry indicators are misunderstood and misinterpreted, that I think that it's important that analysts from across the many fields in information security (malware RE, DFIR, etc.) accept a common structure and usage of terminology.

That same section does, however, include the command used to create the Scheduled Task, and what's listed in the write-up provides a great deal of information regarding how an analyst can detect this either on a system, within an acquired image, or across an enterprise.  It can also be used to detect the persistence mechanism being created, if you're using something like SysMon or Carbon Black.

I would say that I'm adding this one to my bag of tricks, but it's already there...the timeline analysis process that I use can already detect this "renovation".  I think that more than anything, I'm just glad to see this level of detail provided by someone doing malware analysis, as it's not often that you see such things.

Plugin Updates
I've recently written a RegRipper plugin that may prove to be helpful, and someone else has updated another plugin... - there is malware out there that modifies the "(Default)" value beneath the HKCR\Network\SharingHandler key, which essentially removes the hand icon from shared resources. I wrote this plugin recently in order to help analysts determine if the value had been modified.  In the hives that I have available, the value simply points to "ntshrui.dll". - "randomaccess" made some updates to the plugin, and shared them, so I'm including the plugin in the distribution.  Thanks to "randomaccess" for providing the plugin...I hope that folks will find the information it provides valuable.

Windows 10
It's likely that many of you may have recently updated your Win7 to Win10, via the free upgrade...I did.

I know that when I present at conferences, one of the questions I get asked quite often is, "...what's the new hotness in Windows 10?"  Well, I'm providing some links part because my thoughts are that if you don't understand the old hotness (i.e., Registry analysis, ADSs, Jump Lists, etc.), what good is the new hotness?

Some Win10 Forensics Resources
Brent Muir's slides on SlideShare
PDF Document from Champlain
Zena Forensics - Win10 Prefetch files

Sunday, August 16, 2015


RegRipper Plugin Updates
I made some updates to a couple of plugins recently.  One was to the plugins; the update was to add collecting subkey names and LastWrite times from beneath the Nla\Cache\Intranet key.  At this point, I'm not 100% clear on what the dates refer to, but I'm hoping that will come as the data is observed and added to timelines.

I also updated the plugin based on input from Yogesh Khatri.  Specifically, he found that in some cases, there's a string (REG_SZ) value named "DhcpNetworkHint" that, if you reverse the individual nibbles of the string, will spell out the SSID.

This is an interesting finding in a couple of ways.  First, Yogesh found that by reading the string in hex and reversing the nibbles, you'd get the SSID.  That in itself is pretty cool.  However, what this also says is that if you'd doing a keyword search for the SSID, that search will not return this value.

Corey's most recent blog post, Go Against The Grain, is a pretty interesting read.  It is an interesting thought.  As a consultant, I'm not usually "in" an infrastructure long enough to try to effect change in this manner, but it would be very interesting to hear how others may have utilized this approach.

"New" Tools
Eric Zimmerman recently released a tool for parsing the AmCache.hve file, which is a "new" file on Windows systems that follows the Registry hive file format.  So, the file follows the same format as the more "traditional" Registry hive files, but it's not part of the Registry that we see when we open RegEdit on a live system.

Yogesh Khatri blogged about the AmCache.hve file back in 2013 (here, and then again here).

While Eric's blog post focuses on Windows 10, it's important to point out that the AmCache. hve file was first seen on Windows 8 systems, and I started seeing them in images of Windows 7 systems since about the beginning of 2015.  Volatility has a parser for AmCache.hve files found in memory, and RegRipper has had a plugin to parse the AmCache.hve file since Dec, 2013.

I applaud Eric for adding a winnowing capability to his tool; in an age where threat hunting is a popular topic for discussion, data reduction (or, "how do I find the needle in the haystack with no prior knowledge or experience?") is extremely important.  I've tried doing something similar with my own tools (including, to some extent, some RegRipper plugins) by including an alerting capability based on file paths found in various data sources (i.e., Prefetch file metadata, Registry value data, etc.).  The thought behind adding this capability was that items that would likely be of interest to the analyst would be pulled out.  However, to date, the one comment I've received about this capability has been, "...if it says 'temp was found in the path', what does that mean?"

Again, Eric's addition of the data reduction technique to his tool is really very interesting, and is very likely to be extremely valuable.

Shell Items
I had an interesting chat with David Cowen recently regarding stuff he'd found in LNK files; specifically, Windows shortcut/LNK files can contain shell item ID lists, which can contain extremely valuable information, depending upon the type of examination you're performing.  Specifically, some shell item ID lists (think shellbags) comprise paths to files, such as those found on network shares and USB devices.  In many cases, the individual shell items contain not only the name of a folder in the path, but also timestamp information.  Many of the shell items also contain the MFT reference number (record number and sequence number combined) for the folder.  Using this information, you can build a historical picture of what some portion of the file system looked like, at a point in the past.

Conference Presentations And Questions
Many times when I present at a conference and open up for questions, one question I hear many times is, "What's new in Windows (insert next version number)?"  Many times, I'm sort of mystified by questions like this, as I don't tend to see the "newest hotness" as something that requires immediate attention if analysts aren't familiar with "old hotness", such as ADSs, Registry analysis, etc.

As an example, I saw this tweet not long ago, which led to this SANS ISC Handler's Diary post.  Jump Lists are not necessarily "new hotness", and have been part of Windows systems since Windows 7.  As far as resources go, the ForensicsWiki Jump Lists page was originally created on 23 Aug 2011.  I get that the tweet was likely bringing attention back to something of value, rather than pointing out something that is "new".

As a bit of a side note, I tend to use my own tools for parsing files like Jump Lists, because the allow me to incorporate the data in to the timelines I create, if that's something I need to do.