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

No comments: