Goin' huntin'

I ran across this write-up on W32.Brambul recently, and as I often do when I see this sort of thing, I thought about how one might go about trying to find this within an infrastructure, from an endpoint perspective.  After all, this is the perspective that most of the "threat intelligence" that we see tends to leave out.

The most obvious indicator would be failed login attempts within the Security Event Log of target systems, and possibly account lockouts.  You'd see this sort of indicator either via the SIEM you're using, or if you were proactively hunting within the domain.

As something of a side note, I mentioned Ryan's (of Tanium) presentation at the HTCIA2015 conference a bit ago, where he discussed "hunting in the dark".  I thought it was a really good presentation as he broke down how to get started.  Hunting in any infrastructure can be a bit overwhelming, but if you break your goal down into discrete, manageable steps, it can be easier to get started.  As Ryan recommends, starting small is key...you start eating the elephant one bite a time.  Looking at the enormity of an infrastructure can make things overwhelming, so start small.  Start with examining the contents of the Run key on systems, maybe starting with domain controllers and then once you've automated that, move to workstations.  Learn what's "normal" in your environment.  Then move on to the Windows Event Logs.  But the point is to not get overwhelmed by the apparent size and scope of the task, and to instead start working with what you have.

Okay.,.that said, we'll go back to the Brambul...

On the infected systems, looking in the Run key might be a place to start.  However, if the malware installs as a service, locating "Service Control Manager/7045" event records (there shouldn't be many) within the System Event Log would be the way to go.  If you're using a SIEM, and forwarding the right logs, you could search there, instead.  Or set a filter.  If you don't have a SIEM, you can use Powershell (MS has some good documentation available...) or WMI.

Something else that may occur on the infected systems is Security Auditing/4648 event records, indicating the use of explicit credentials.  This likely won't be definitive without further context, and to be honest, it's not surprising that malware write-ups aren't addressing this sort of indicator.

The key is that if you're going to "go huntin'" within your infrastructure, what do you look for?  Do you look for malware, when the write-ups you're seeing all talk about how the folks writing this stuff are using high-speed techniques to ensure that the malware avoids detection and is hard to analyze?  Do you search for file hashes on systems?  Do you search for IP addresses in your logs?  Or do you go looking for indicators of behavior?

So, how is looking beyond low-level technical indicators (hashes, IP addresses) valuable?  Remember the Moker write-up?  This 'new APT' reportedly includes anti-detection and anti-debugging techniques, allowing it to bypass detection.  Yet, it apparently persists via the Run key...so, if I just enumerate the values within this key and look for anything suspicious, such as a path that includes "C:\ProgramData".  If I did that, and then correlated that information with a new user account being created on the system, would I then be able to determine that the system was infected with something?  And that's not so much a low-level technical indicator as it is moving closer to a behavior, something that may be anomalous within your infrastructure and indicate that something needs to be looked at a bit closer.

Here's another bit of malware that, according to some write-ups, may be associated with Brambul.  you'll notice in the write-up that it states:

If it is successful in logging in, it will set the %System Root% as a network share named adnim. 

I added the emphasis, in order to draw your attention to the spelling of the share (I did a copy-paste and didn't try to retype that...).  If you were hunting in your environment, looking at the values beneath the LanmanServer/Shares key within the Registry might help you find this (or anything else that might be suspicious), particularly if you don't have auditing for Object Access/File Shares enabled.

Just for fun, I created a couple of shares using the "net share" command...one called "adnim" and one called "adnim$".  Both appeared as values beneath the LanmanServer/Shares key.  So rather than looking for file hashes on a system, we can start to correlate various indicators, based on time, and also develop context around what we're seeing.  The name of the share may change, but if the malware continues to create a share, we know what to look for when we're hunting.

Testing and Monitoring
If you're testing malware, doing dynamic analysis by running it in a VM (or on bare metal), something that I don't seen done very often is running it with monitoring tools such as SysMon or Carbon Black.

Why would anyone want to do this?  After all, who really cares what happens on the endpoint, right?  Not the malware RE and AV guys.  If you're protecting an infrastructure, or responding to a breach, you probably do care, because process creation monitoring is extremely valuable.

Here's an example...we've seen malware that persists via a particular key, and at one point that malware stopped using the API and instead used an embedded 'reg add' command to maintain persistence.  Okay, so now, we have not only the persistence location, but we also have a command we can monitor for in order to perform detection much closer to the time of infection.  Or...and bear with me here...if you don't use reg.exe in your infrastructure, you can take steps to prevent it from being used, even by an account running with System-level privileges.

The same holds true for other processes.  Consider the malware described above that creates a share...how does it do this?  Via the API, included as part of the code, or via an embedded "net share" command?

Monitoring for this sort of activity within the infrastructure can give us a great deal more visibility into what's going on.  For example, if someone archives files (via WinRAR) and encrypts the archive, the process runs and completes, and the memory used if freed up for use by other processes.  However, if we monitor for process creation, we can capture that command line (along with the password used).  Process creation monitoring provides a great deal of insight into what the bad guys are doing, or are trying to do, and will illustrate behaviors.

OSDFCon follow-up

I attended Basis Tech's OSDFCon recently...I've attended and presented at this conference in the past...and as has been the case in previous years, this turned out to be a great experience.

OSDFCon isn't so much a DFIR conference as it is a "tools and frameworks" conference, centered around the Autopsy toolkit.  However, the folks who attend this conference are, for the most part, developers and DFIR practitioners.  Many of the attendees are one or the other, while a number are both.  This makes for a very interesting time.

Brian asked me to come by and, along with several other folks, give an update to a previous presentation.  Last year, I talked about some updates I was considering/working on for RegRipper, and this time I gave a quick update on what I was looking at in the coming year.  Based on that, my hope for next year's conference is to have something available to give a presentation, along with a demo, of what I talked about.

I really liked hearing about the new stuff in Volatility 2.5, as well as seeing the plugins that came out of the contest...and congrats to the contest winners!

Something I like about this particular conference is the type of folks that it brings together.  Working on the types of cases I tend to work gives me a sort of myopic view of things, so it's good to meet up with others and hear about the kinds of cases they work, and the challenges they face.

Take-Aways
There are a lot of really smart people at this conference, and what I really like to see is frameworks and solutions to DFIR problems being created by DFIR practitioners, even if they are specific to those individual's needs.

Many of the solutions...whether it be Turbinia, or Autopsy, or Willi's tools, or whatever...provide an excellent means for data collection and presentation.  I think we still have a challenge to overcome...data interpretation.  Sure, we get now get data from an image or from across the enterprise much faster because we've put stuff in the cloud, or we've got a fast, multi-threaded design in our framework, and that's awesome.  But what happens if that data is misunderstood and misinterpreted?  This thought started to gel with me right after I registered for the conference and was talking to Christa about CyberTriage, and then during the conference, I made a comment to that effect to Cory...to which he responded, "Baby steps."  He's right.  But now that we can get to the data faster, the nex step is to make sure that we're getting the right data, and that it's being interpreted and understood correctly.  Maybe the data interpretation phase is beyond the scope of a conference that's about open source tools...although there may be space for an open source tool that incorporates threat intelligence.  Just sayin'...

Maybe I've just given myself the basis for a presentation next year.  ;-)

Finally, a huge thanks to Brian and his staff for continuing to put on an excellent conference, in both format and content.  In fact, I still believe that this is one of the better conferences available today.  The format is great, requiring speakers to focus on the guts of what they want to convey, and the breaks allow for interaction not only with speakers but with other attendees, as well.

Threat Intel and Threat Hunting Conferences in 2016

I'm looking for input from the community, with respect to conferences in 2016 that cover DFIR, threat intelligence, and threat hunting.

Members of the team I work with have some pretty significant content that we're looking to share, so I thought I'd reach to the community and see what conferences are out there that folks are looking to (for content) in 2016.

So, if you're looking at conferences in 2016 that cover digital forensics, incident response, as well as targeted threat hunting and response, I'd appreciate hearing about them.

Thanks.

Tools, Links - ESEDB, etc.

Tools
CapLoader - This looks like an interesting tool...and another one...for carving packets from memory dumps.  I'm not clear as to how this tool differs from the Volatility modules, in particular netscan and Jamaal's ethscan, but it does seem interesting.  If you were curious as to how to install Rekall on Windows systems, see this blog post.

SAMParser.py - I'm not entirely sure how this Python script differs from RegRipper's samparse.pl plugin, but it does offer an interesting alternative, if you're looking for one.  The output does appear similar to what samparse.pl produces.

MFT Parsers
Mari posted an excellent blog article based on her review of several MFT parsing tools.  One of the key factors to Mari's post is that she understands what it is she's looking at (MFT records), so she's able to evaluate the various tools for her own use, rather than simply running them and not questioning the output.

This is the sort of thing that the DFIR community would benefit from greatly, if more practitioners engaged in it, or if more practitioners responded to it.  Honestly evaluating tools can be of significant benefit to the community, particularly when they're evaluated in light of a particular practitioner's analysis process.  It's even more beneficial if that process is shared, so that others can determine the usefulness of the tools for themselves, and decide if those tools can/should be incorporated into their own analysis process.

Yara
Yara is a tool that's been available for some time, and is worth mentioning again.  A while back, Corey Harrell asked a question via social media regarding how to detect the presence of web shells on a system, using only the HTTP access logs.  Shortly thereafter, Aaron Shelmire posted this article to the ThreatStream blog.  In the article, Aaron mentions a couple of methods for detecting web shells using only the HTTP access logs, in accordance with Corey's question, and his suggestions are very valuable.  One method of detection he mentioned, as well, was using a change control and inventory process, or a file system monitoring tool, to detect new pages being added to web directories.  Aaron also mentions that searching for patterns within files can produce false positives, but if you use something like Yara, you can reduce those false positives.  Yara can be used by sysadmins who want to keep ahead of things or those who want to perform hunting, as well as by analysts and responders engaged in DFIR analysis.

An excellent resource for web shell rules can be found here.

ESEDB Databases
Windows systems utilize ESE format databases more and more, and as such, it's imperative that analysts be able to identify the databases, as well as extract data for incorporation into their analysis processes.

An example of an ESE format database includes the IE10+ WebCacheV01.dat web history database. Also, Brent Muir recently posted regarding Windows 10 Cortana Notification Center Forensics.

A note on Brent's post...I have a Windows 10 laptop that was upgraded from Win7; I opened the notification center as he described towards the end of the post.  Even after rebooting the system, the value containing the timestamp does not exist in my NTUSER.DAT.  However, I'm also not running Cortana, as this is an older laptop, so that may have an impact as to whether or not the value gets created.

There's also the Search Index database; reading through the post responses, you can see how the contents of this database can be useful to a forensic analyst.  One of the response lists tools that can be used to parse the database.

So, at this point, that's three databases that use the ESE format, all of which can provide significant value to a forensic analyst.

Parsing Tools
WoanWare ESEDBViewer - deprecated, but still a good visual tool.

libesedb - needs to be compiled for the Windows platform; most of the web sites that I've found that mention the tool don't provide a compiled copy

esentutl - native tool that lets you copy and/or recover an ESEDB file.  While one method of obtaining a copy of an ESEDB file for analysis might be to create a VSC and copy the file in question from the shadow copy, this option might not always be available.  As such, this native tool may be of significant use to an analyst.

pyesedbwebcache2.py - It looks as if Jon Glass has updated his Python script for parsing the WebCacheV01.dat file.

Addendum, 7 Oct: I found this post over at Sanderson Forensics this morning...if you're analyzing Windows systems, you want to be sure to read the post and include the tool in your toolkit...

Updates, Links, etc.

RegRipper Plugin Updates
I updated a plugin recently and provided a new one, and thought I'd share some information about those updates here...

The updated plugin is environment.pl, originally written in 2011; the update that I added to the code was to specifically look for and alert on the value described in this blog post.  So, four years later, I added a small bit of code to the plugin to look for something specific in the data.

I added the malware.pl plugin, which can be run against any hive; it has specific sections in its code that describe what's being looked for, in which hive, along with references as to the sources from which the keys, values or data in question were derived - why was I looking for them in the first place?  Essentially, these are all artifacts I find myself looking for time and again, and I figured I'd just keep them together in one plugin.  If you look at the plugin contents, you'll see that I copied the code from secrets.pl and included it.

There are a couple of other plugins I thought I'd mention, in case folks hadn't considered using them....

The sizes.pl plugin was written to address malware maintaining configuration information in a Registry value, as described in this Symantec post.  You can run this plugin against any hive.

The rlo.pl plugin is an interesting plugin, and the use of the plugin was illustrated in this Secureworks blog post.  As you can see in the figure to the left, there are two Registry keys that appear to have the same name.

In testing for this particular issue, I had specifically crafted two Registry key names, using the method outlined in the Secureworks blog post.  This allowed me to create some useful data that mimicked what we'd seen, and provided an opportunity for more comprehensive testing.

As you can see from the output of the plugin listed below, I had also crafted a Registry value name using the same method, to see if the plugin would detect that, as well.

C:\Perl\rr>rip -r d:\cases\local\ntuser.dat -p rlo
Launching rlo v.20130904
rlo v.20130904
(All) Parse hive, check key/value names for RLO character

RLO control char detected in key name: \Software\gpu.etadp  [gpupdate]
RLO control char detected in key name: \Software\.etadpupg  [gpupdate]
RLO control char detected in value name: \Software\.etadpupg :.etadpupg [gpupdate]

Now, when running the rlo.pl plugin, analysts need to keep in mind that it's looking for something very specific; in this case, indications of the RLO Unicode control character.  What's great about plugins like this is that you can include them in your process, run them every time you're conducting analysis, and they'll alert you when there's an issue.

Just as PSA, I have provided these plugins but I haven't updated any of the profiles...I leave that up to the users.  So, if you're downloading the plugins folder and refreshing it in place, do not expect to see the


Anti-Forensic Malware
I ran across this InfoSecurity Magazine article recently, and while the title caught my attention, I was more than a bit surprised at the lack of substance.

There are a couple of statements in the blog post that I wanted to address, and share my thoughts on...

Increasingly, bad actors are using techniques that leave little trace on physical disks. And unfortunately, the white hats aren’t keeping up: There’s a shortage of digital forensics practitioners able to investigate these types of offensives.

As to the first sentence, sometimes, yes.  Other times, not so much.

The second statement regarding "white hats" is somewhat ambiguous, don't you think?  Who are the "white hats"?  From my perspective, if "white hats" are the folks investigating these breaches, it's not so much that we aren't keeping up, as it is that the breaches themselves aren't being detected in a timely manner, due to a lack of instrumentation.  By the time the "white hats" get the call to investigate the breach, a great deal of the potential evidence has been obviated.

Finally, I don't know that I agree with the final statement, regarding the shortage of practitioners.  Sometimes, there's nothing to investigate.  As I described in a recent blog post, when putting together some recent presentations, I looked at the statistics in annual security trends reports.  One of the statistics I found interested was dwell time, or median time to detection.  The point I tried to make in the presentations was that when consultants go on-site to investigate a breach, they're able to see indicators that allow them to identify these numbers.  For example in the M-Trends 2015 report, there was an infrastructure that had been compromised 8 years before the compromise was detected.

I would suggest that it's not so much a shortage of practitioners able to investigate these breaches, it's a lack of management oversight that prevents the infrastructure from being instrumented in a manner that provides for timely detection of breaches.  By the time some breaches are detected (many through external, third party notification), the systems in question have likely been rebooted multiple times, potentially obviating memory analysis all together.

If a crime is committed and the perpetrator had to walk across a muddy field to commit that crime (leaving footprints), and that field is dug up and paved over with a parking lot before the crime is reported, you cannot then say that there aren't enough trained responders able to investigate the crime.

...seen a rise in file-less malware, which exists only in volatile memory and avoids installation on a target’s file system.

"File-less malware"?  Like Poweliks?  Here's a TrendMicro blog post regarding PhaseBot, which references a TrendMicro article on Poweliks.  Sure, there may not be a file on disk, but there's something pulled from the Registry, isn't there?

Malware comes from somewhere...it doesn't magically appear out of nowhere.  If you take a system off of the main network and reboot it, and find indications of malware persisting, then it's somewhere on the system.  Just because it is in memory, but there are no obvious indications of the malware within the file system doesn't mean that it can't be found.

Hunting
At the recent HTCIA 2015 Conference, I attended Ryan's presentation on "Hunting in the Dark", and I found it fascinating that at a sufficient level of abstraction, those of us who are doing "hunting" are doing very similar things; we may use different terms to describe it (what Ryan refers to as "harvesting and stacking", the folks I work with call it "using strategic rules")

Ryan's presentation was mostly directed to folks who work within one environment, and was intended to address the question of, "...how do I get started?"  Ryan had some very good advice for folks in that position...start small, take a small bite, and use it to get familiar with your infrastructure to learn what is "normal", and what might not be normal.

Along those lines, a friend of mine recently asked a question regarding detecting web shells in an environment using only web server logs.  Apparently in response to that question, ThreatStream posted an article explaining just how to do this.  So this is an example of how someone can start hunting within their own environment, with limited resources.  If you're hunting for web shells, there are number of other things I'd recommend looking at, but the original question was how to do so using only the web server logs.

The folks at ThreatStream also posted this article regarding "evasive maneuvers" used by a threat actor group.  If you read the article, you will quickly see that it is more about obfuscation techniques used in the malware and it's communications means, which can significantly effect network monitoring.  Reading the article, many folks will likely take a look at their own massive lists of C2 domain names and IP addresses, and append those listed in the article to that list.  So, like most of what's put forth as 'threat intelligence', articles such as this are really more a means for analysts to say, "hey, look how smart I am, because I figured this out...".  I'm sure that the discussion of assembly language code is interesting, and useful to other malware reverse engineers, but how does a CISO or IT staff utilize the contents of the third figure to protect and defend their infrastructure?

However, for anyone who's familiar with the Pyramid of Pain, you'll understand the efficacy of a bigger list of items that might...and do...change quickly.  Instead, if you're interested in hunting, I'd recommend looking for items such as the persistence mechanism listed in the article, as well as monitoring for the creation of new values (if you can).

Like I said, I agree with Ryan's approach to hunting, if you're new to it...start small, and learn what that set of artifacts looks like in your environment.  I did the same thing years ago, before the terms "APT" and "hunting" were in vogue...back then, I filed it under "doing my job".  Essentially, I wrote some small code that would give me a list of all systems visible to the domain controllers, and then reach out to each one and pull the values listed beneath the Run keys, for the system and the logged in user.  The first time I ran this, I had a pretty big list, and as I started seeing what was normal and verifying entries, they got whitelisted.  In a relatively short time, I could run this search during a meeting or while I was at lunch, and come back to about half a page of entries that had to be run down.

Tools
I ran across this post over at PostModernSecurity recently, and I think that it really illustrates somethings about the #DFIR community beyond just the fact that these tools are available for use.

The author starts his post with:

...I covet and hoard security tools. But I’m also frugal and impatient,..

Having written some open source tools, I generally don't appreciate it when someone "covets and hoards" what I've written, largely because in releasing the tools, I'd like to get some feedback as to if and how the tool fills a need.  I know that the tool meets my needs...after all, that's why I wrote it.  But in releasing it and sharing it with others, I've very often been disappointed when someone says that they've downloaded the tool, and the conversation ends right there, at that point...suddenly and in a very awkward manner.

Then there's the "frugal and impatient" part...I think that's probably true for a lot of us, isn't it?  At least, sometimes, that is.  However, there are a few caveats one needs to keep in mind when using tools like those the author has listed.  For instance, what is the veracity of the tools? How accurate are they?

More importantly, I saw the links to the free "malware analysis" sites...some referenced performing "behavioral analysis".  Okay, great...but more important than the information provided by these tools is how that information is interpreted by the analyst.  If the analyst is focused on free and easy, the question then becomes, how much effort have they put into understanding the issue, and are they able to correctly interpret the data returned by the tools?

For example, look at how often the ShimCache or AppCompatCache data from the Windows Registry is misinterpreted by analysts.  That misinterpretation then becomes the basis for findings that then become statements in reports to clients.

There are other examples, but the point is that if the analyst hasn't engaged in the academic rigor to understand something and they're just using a bunch of free tools, the question then becomes, is the analyst correctly interpreting the data that they're being provided by those tools?

Don't get me wrong...I think that the list of tools is a good one, and I can see myself using some of them at some point in the future.  But when I do so, I'll very likely be looking for certain things, and verifying the data that I get back from the tools.

Registry Analysis

I gave a presentation on Registry analysis at the recent HTCIA2015 Conference, and I thought that there were some things from the presentation that might be worth sharing.

What is Registry analysis?  
For the purposes of DFIR work, Registry analysis is the collection and interpretation of data and metadata from Registry keys and values.

The collection part is easy...it's the interpretation part of that definition that is extremely important.  In my experience, I see a lot of issues with interpretation of data collected from the Registry.  The two biggest ones are what the timestamps associated with ShimCache entries mean, and what persistence via a particular key path really means.

Many times, you'll see the timestamps embedded in the ShimCache data referred to as either the execution time, or "creation/modification" time.  Referring to this timestamp as the "execution time" can be very bad, particularly if you're using it to demonstrate the window of compromise during an incident, or the time between first infection and discovery.  If the file is placed on a system and timestomped prior to being added to the ShimCache, or the method for getting it on the system preserves the original last modification time, that could significantly skew your understanding of the event.  Analysts need to remember that for systems beyond 32-bit XP, the timestamp in the ShimCache data is the last modification time from the file system metadata; for NTFS, this means the $STANDARD_INFORMATION attribute within the MFT record.

Ryan's slides include some great information about the ShimCache data, as does the original white paper on the subject.

With respect to persistence, I see a lot of write-ups that state that malware creates persistence by creating a value beneath the Run key in the HKCU hive, and the write-up then states that that means that the malware will be started again the next time the system reboots.  That's not the case at all...because if the persistence exists in a user's hive, then the malware won't be reactivated following a reboot until that user logs in.  I completely understand how this is misinterpreted, particularly (although not exclusively) by malware analysts...MS says this a lot in their own malware write-ups.  While simple testing will demonstrate otherwise, the vast majority of the time, you'll see malware analysts repeating this statement.

The point is that not all of the persistence locations within the Registry allow applications and programs to start on system start.  Some require that a user log in first, and others require some other trigger or mechanism, such as an application being launched.  It's very easy...too easy...to simply make the statement that any Registry value used for persistence allows the application to start on system reboot, because there's very little in the way of accountability.  I've seen instances during incident response where malware was installed only when a particular user logged into the system; if the malware used a Registry value in that user's NTUSER.DAT hive for persistence, the system was rebooted, and the user account was not used to log in, then the malware would not be active.  Making an incorrect statement about the malware could significantly impact the client's decision-making process (regarding AV licenses), or the decisions made by regulatory or compliance bodies (i.e., fines, sanctions, etc.).

Both of these items, when misinterpreted, can significantly impact the overall analysis of the incident.

Why do we do it?
There is an incredible amount of value in Registry analysis, and even more so when we incorporate it with other types of analysis.  Registry analysis is rarely performed in isolation; rather, most often, it's used to augment other analysis processes, particularly timeline analysis, allowing analysts to develop a clearer, more focused picture of the incident.  Registry analysis can be a significant benefit, particularly when we don't have the instrumentation in place that we would like to have (i.e., process creation monitoring, logging, etc.), but analysts also need to realize that Registry analysis is NOT the be-all-end-all of analysis.

In the presentation, I mention several of the annual security trend reports that we see; for example, from TrustWave, or Mandiant.  My point of bringing these up is that the reports generally have statistics such as dwell time or median number of days to detection, statistics which are based on some sort of empirical evidence that provides analysts with artifacts/indicators of an adversary's earliest entry into the compromised infrastructure.  If you've ever done this sort of analysis work, you'll know that you may not always be able to determine the initial infection vector (IIV), tracking back to say, the original phishing email or original web link/SWC site.  Regardless, this is always based on some sort of hard indicator that an analyst can point to as the earliest artifact, and sometimes, this may be a Registry key or value.

Think about it...for an analyst to determine that the earliest data of compromise was...for example, in the M-Trends 2015 Threat Report, 8 yrs prior to the team being called in...there has to be something on the system, some artifact that acts as a digital muddy boot print on a white carpet.  The fact of the matter is that it's something that the analyst can point to and show to another analyst in order to get corroboration.  This isn't something where the analysts sit around rolling D&D dice...they have hard evidence, and that evidence may often be Registry keys, or value data.

HTCIA2015 Conference Follow up

I spoke at the HTCIA 2015 conference, held in Orlando, FL, on Mon, 31 Aug.  In fact, I gave two presentations...Registry analysis, and lateral movement.  You can see the video for the lateral movement presentation I gave at BSideCincy here...many thanks to the BSides Cincy guys and Adrian.

I haven't spoken at, or attended an HTCIA conference in quite a while.  I had no idea if I was going to make it to this one, between airline delays and tropical storms.  This one was held at the Rosen Shingle Creek Resort, a huge ("palatial" doesn't cover it) conference center..."huge", in the manner of Caesar's Palace.  In fact, there was an Avon conference going on at the same time as the HTCIA conference, and there very well could have been other conferences there, as well.  Given the humidity and volume of rain, having everything you'd need in one location was a very good thing.  In fact, the rain was so heavy on Monday afternoon, after the final presentation, that there were leaks in the room.

After presenting on Monday, I attended Mari's presentation, which I've seen before...however, this is one of those presentations that it pays to see again.  I think that many times when we're deeply engaged in forensic analysis, we don't often think about other artifacts that may be of use...either we aren't aware of them, due to lack of exposure, or we simply forgot.  However, if you're doing ANYTHING at all related to determining what the user may have done on the system, you've got to at least consider what Mari was talking about.  Why?  Well, we all know that browsers have an automatic cache clean-up mechanism; if the user is right at about 19 days since the last cache clean-up in IE, and they do something bad, it's likely that the artifacts of activity are going to be deleted...which doesn't make them impossible to find, just harder.  The cookies that Mari has researched AND provided a tool to collect can illustrate user activity long after the fact, either in specific activity, or simply illustrating the fact that the user was active on the system at a particular time.

Also, Mari is one of the very few denizens of the DFIR community who finds something, digs into it, researches it and runs it down, then writes it up and provides a tool to do the things she talked about in her write-up.  This is very rare and unique within the community, and extremely valuable.  Her presentation on Google Analytics cookies could very well provide coverage of a gap that many don't even know exist in their analysis.

I was also able to see Ryan's presentation on Tuesday morning.  This one wasn't as heavily attended as the presentations on Monday, which is (I guess) to be expected.  But I'll tell you...a lot of folks missed some very good information.  I attended for a couple of reasons...one was that Ryan is a competitor, as much as a compatriot, within the community.  We both do very similar work, so I wanted to see what he was sharing about what he does.  I'm generally not particularly interested in presentations that talk about "hunting", because my experience at big conferences has often been that the titles of presentations don't match up with the content, but Ryan's definitely did so.  Some of what I liked about his presentation was how he broke things down...rather than going whole hog with an enterprise roll-out of some commercial package, Ryan broke things down with, "...here are the big things I look for during an initial sweep...", and proceeded from there.  He also recommended means for folks who want to start hunting in their own organization, and that they start small.  Trying to do it all can be completely overwhelming, so a lot of folks don't even start.  But taking just one small piece, and then using it to get familiar with what things look like in your environment, what constitutes "noise" vs "signal"...that's the way to get started.

What's interesting is that what Ryan talked about is exactly what I do in my day job.  I either go in blind, with very little information, on an IR engagement, or I do a hunt, where a client will call and say, "hey, I don't have any specific information that tells me that I've been compromised, but I want a sanity check...", and so I do a "blind" hunt, pretty much exactly as Ryan described in his presentation.   So it was interesting for me to see that, at a certain level of abstraction, we are pretty much doing the same things.  Now, of course there are some differences...tools, exact steps in the process, and even the artifacts that we're looking for or at, may be a little different.  But the fact of the matter is that just like I mentioned in my presentation, when a bad guy "moves through" an environment such as the Windows OS, there are going to be artifacts.  Looking for a footprint here, an over-turned stone there, and maybe a broken branch or two will give you the picture of where the bad guy went and what they did.  For me, seeing what Ryan recommended looking at was validating...because what he was talking about is what I do while both hunting and performing DFIR work.  It was also good to see him recommending ways that folks could start doing these sorts of things in their own environments.  It doesn't take a big commercial suite, or any special skills...it simply takes the desire, and the rest of what's needed (i.e., how to collect the information, what to look for, etc.) is all available.

All in all, I had a good time, and learned a lot from the folks I was able to engage with.

Addendum: While not related to the conference, here are some other good slides that provide information about a similar topic as Ryan's...

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.

Indicators
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...

handler.pl - 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".

winrar2.pl - "randomaccess" made some updates to the winrar.pl 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 below...in 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

Updates

RegRipper Plugin Updates
I made some updates to a couple of plugins recently.  One was to the networklist.pl/networklist_tln.pl 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 nic2.pl 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.

jIIr
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.

BSidesCincy Follow up

I had the distinct honor of speaking at @BSidesCincy this past weekend, and I greatly appreciate the opportunity that Justin, Josh, and the entire crew provided for me to speak.

In my time, I've been to a number of conferences.  I started with Usenix back in '99, and that experience was a bit different for me, in that the vast majority of my public speaking to that point had been in the military (during training, and while providing training).  Over the years, I've attended (I prefer to speak at conferences in an attempt to keep costs to my employer down...) several conferences that left me wondering what the point was.  Sometimes, what the speaker actually spoke about had little or nothing to do with the advertised title of their talk, and in a few cases, with the conference theme itself.  With BSidesCincy, it was clear that folks from the same community, with similar experiences and concerns, were coming together to share and discuss those experiences and concerns., and IMHO, that's the real way to make forward progress in this community.

Unfortunately due to flights (or rather, the lack of direct flights), I had to depart the venue after scarfing down lunch.  I did get to see John Davidson's presentation, and I've got to say, it was pretty fascinating.  Even though I'm more of a DFIR guy, my day job does include hunting (albeit largely from a host-based perspective), so a lot of what John talked about made complete sense, as at one point or another, I had some similar thoughts.  John took those thoughts and then took them further.  From a 50,000 ft view, John's presentation was about "here's the issue I ran into and here's how I addressed it...", which resulted in a really good presentation.  Further, it addressed something that I've heard over the years throughout the community...that folks don't want to hear, "...this is what you need to do...", as much as they want to hear, "...this is the issue I faced, and here's what I did to address it...", illustrating their methodology and thought processes throughout.

Thanks to Adrian, here's a link to the video of my presentation.

Again, to Justin, Josh, Adrian, and everyone on the BSidesCincy crew...thanks so much for having me out and for giving me the opportunity to share a bit with everyone.  I had a really great time engaging with everyone I got to speak with and meet.  I hope that for you, it was worth it and that some folks came away with something that they could use.

Addendum, 30 July: I was asked recently via Twitter if I was going to post the slides somewhere, and to be honest, I really don't see the point.  First, I don't read off of my slides...most of what I talk about during a presentation isn't in the slides (on the screen or in the notes).  Second, if you're looking to use the slides as a reference, the information that is posted in the slides is already available in my blog, or someplace else.  Many of the event IDs mentioned in this presentation were taken from eventmap.txt.

Finally, slide 4 of the presentation is to the left.  I used this slide to illustrate a point I was trying to make...that is, the annual reports that we see from some security companies tell us that when these consultants respond to a breach, they're able to see something (some indicators, artifacts, etc.) that allow them to populate the "dwell time" statistics.  The thought that I shared was that if the consultants can find this, what's stopping the local IT security staff from finding these things earlier in the game?

I didn't get many comments on this thought at the time...am I on target, or am I way off and clearly making things up?  Does it make sense?  Does it generate any additional or follow-on thoughts?

So, what would be the point of releasing the slides?  I talk to this slide in the video, and so far, haven't heard any comments or feedback on the point, so why release the slides, just to get...well...still NOT get comments or thoughts?  So far, there have been a good number of RTs and "Favorites" for the original version of this post, but as of yet, no comments regarding the content of the video.

Ghost Busting

First, read Jack's post, Don't wait for an intrusion to find you.

Next, read this post (The Blue Team Myth).

Notice any similarities...not in content, but in the basic thought behind them?

Yeah, me, too.  Great minds, eh?  Okay, maybe not...but

So, you're probably wondering what this has to do with Ghostbusters...well, to many, an intruder within the infrastructure may seem like a ghost, moving between systems and through firewalls, apparently like an apparition.  One thing I've seen time and again during incident response is that an intruder is not encumbered by the artificialities of an infrastructure, where someone shouldn't be able to access systems, due either to policies and roles, or to local laws (European privacy laws, etc.). Yeah, that doesn't stop an adversary.

Jack's right about a number of things.  First, the old adage about an intruder needing to be right once, and a network defender needing to be right all the time is...well...wrong.  Consider this...prevention, by itself, is ineffective.  In defending a network, you need to include prevention, detection, and response in your security plan.  Given that, what is the adversary's definition of success?  What is their goal?  Once you arrive at what you believe to be the adversary's goal, you'll realize that there are plenty of opportunities for defenders and responders to "win", to get inside the adversary's OODA loop and disrupt/hamper/impede their activities.


Jack is exactly right...an intruder needs to accomplish five stages in order to succeed, and all five of those stages require one thing in common...execution of commands.  Something has to run on the systems.  Doesn't it then make sense to have some sort of process creation monitoring in place, such as Bit9's Carbon Black, or MS's Sysmon?

Here's another way to look at it...in the beginning of my blog post, I mention two annual security/threat reports, and describe what some of the statistics mean.  In short, one metric that the investigators report on is dwell time...how long (as far as they can tell based on the artifacts) a targeted actor was embedded within the infrastructure before being detected.  What this means is that when investigators look at the available data, they're able to determine (at least up to a point) the earliest indicators of the adversary's activities, be it early indicators (use of web shells), or the actual initial infection vector (IIV), such as a strategic web compromise, or an email with a link to a malicious site, or with a weaponized document attached.  The point is that the investigators are able to find indicators...Registry keys/values, Windows Event Log records, etc...of the adversaries activities.  And all of these are indicators that could have been used to detect the adversaries activities much sooner.

Finally, one other thought...Jack's steps 4 and 5 are cyclic.  Wait...what?  What I mean by that is that following credential theft and establishing persistence, the adversary needs to orient to where they are and begin taking steps to locate data.  What are they looking for, what are they interested in, and where is located?  Is the data that the adversary is interested in on a server someplace (file server, database server), or are there bits of the data that they're interested in located on workstations, in emails, reports, spreadsheets, etc.?  So, what you may see (assuming you have the instrumentation to observe it) is the adversary collecting data for analysis in order to assist them in targeting the specific information they're interested in; this might be directory listings, emails, etc.  You may see this data exfiltrated so that the adversary can determine what it is they want.

The Blue Team Myth

The 2015 M-Trends Report states that the median number of days that threat groups were present in a victim's network before detection was 205 days, which is down 24 days from 2013.  But that's the median number of days...the longest persistence was 2,982 days.  That's over 8 years.  The report also states that 69% of organizations were informed of the breach by an external entity.

The 2015 TrustWave Global Security Report indicates that 81% of companies did not detect breaches on their own, and that the median length of time it took to detect a breach was 86 days.

What do these numbers tell us?   They tell us that the organizations in question did not detect the breaches, but when they called in consultants to assist, those consultants found evidence of the breaches that allowed them to identify for how long (to a point, of course) that the intruders had persisted within the infrastructure.  I'm going to go out on a limb here and just say that I recognize that the consultants may not have been able to trace the breach information back to the initial infection vector (IIV) in every case, so the numbers in the report are likely just a little fuzzy.  

What the numbers tell us is that the consultants, based on their combined experience, knowledge, and methodologies, were able to find indicators and artifacts that others did not.  This means that the local IT staff either wasn't looking, or didn't have a complete understanding of what to look for.

The numbers in the reports are supported by my own experiences, as well as those of a myriad of other responders.  A while back, I worked on an engagement during which we were able to trace the adversary's activities back to the original phishing email and attached weaponized PDF.  The emails had been received 21 months before we had been called.  I've done analysis on breaches where indicators went back two years or more, and we were never able to track down the IIV.

The numbers also tell us that the adage that attackers need to be right 1 out of 100 times and defenders need to be right 100 out of 100 times doesn't hold, and that it's a myth.  What artifacts did the consultants who provided input to the reports find, and could administrators of the compromised infrastructure have found those artifacts, as well, if they'd been looking?  Based on my own personal experiences, I would say that the answer is a definite yes.

By now, we are all well aware that prevention doesn't work, that regardless of how many technical measures we put in place, that as long as people are involved in some way, at some point someone will make their way into an infrastructure.  So what we need to do is include detection and response; put our protection mechanisms in place, monitor them, look/hunt for issues throughout our infrastructure, and be ready to take some sort of action when issues are found.

In my previous blog post, I shared some thoughts on hunting, in short, describing, in general terms, what folks can look for within their environments.  One person commented (via Twitter) that I should spend less time talking about it, and more time listing those artifacts that hunters should look for.

So what should you look for? Check out this video of Lee's presentation...he shares a lot of great information.  Much like the information here, or in any of the HowTo blog posts from July, 2013.  That's a start.  Eventmap.txt has some interesting tips, as do many RegRipper plugins.  Want more?  Take a hard look at your threat intelligence...if you're getting it from a vendor, does it give you what you need?  How about the threat intel you're developing internally?  Similarly, does it meet your needs?  MD5 hashes and IP addresses aren't going to get you as far as TTPs, if you have the processes and methodologies to find those TTPs.

Hunting, and Knowing What To Hunt For

Like many others of my generation, when I was a kid I'd go and play outside for hours and hours.  Sometimes, while running through the woods, I'd see trash...but seeing it often, I wouldn't think much of it.  Sometimes it was a tire in the creek, and other times it might be bottles or cigarette butts in a small cluster.

When I went through my initial military training, we spent a lot of time in the outdoors, but during the first 6 months, there was no real "this is what to look for training".  It wasn't until a couple of years later, when I returned to be an instructor that the course was teaching new officers the difference between moving through the woods during the day and at night.

Much later, after my military service ended, I got engaged in horseback riding, particularly trail riding.  Anyone who's ever done this knows that you become more aware of your surroundings, for a variety of reasons, but most importantly, the safety of your horse, you, and those you may be riding with.  You develop an awareness of your surroundings; what's moving near you, and what's further away.  Are there runners or walks with dogs (or children in strollers) down the trail?  Sometimes you can be warned of the impending approach of others not so much visually, as by what you hear or smell (some riders like to smoke while they're riding).  You can tell what is or might be in the area by visual observation (scat, droppings, etc.), as well as listening, and even smell.  Why is this important?   There's a lot that can spook a horse...horses will smell a carcass well before a human will, and as you ride up, a gaggle of vultures might suddenly take flight.  Depending on your horse's temperament, a flock of turkey hens running through a field might spook them or just catch their attention.  

If it's recently rained in the area where I'm riding, I'll visually sweep the ground looking for footprints and signs of animals and people.  If I see what appear to be fresh impressions of running shoes with dog paw prints near by, I might be looking for a walker or runner with a dog.  Most runners have a sense of courtesy to slow down to a walk and may be even say something when approaching horses from the rear.  Most...not all.  And not everyone who walks a dog really thinks about whether their dog is habituated to horses, or even how the dog will reach when they see horses.  I'll also look for signs of deer, because they usually (albeit not always) move in groups.  More than once in the springtime, I've come across a fawn coiled up in the tall grass...deer teach their fawns to remain very still, regardless of the circumstances, while they go off to forage.  More than once I've seen the fawn well before the fawn has lost its nerve and suddenly bolted from its hiding place.

Now, because of this level of awareness, I had an interesting experience several years ago while hiking with friends at the base of Mount Rainier.  At the park entrance, there was a small lake with signs prohibiting fishing, and a sign telling hikers what to do if they spotted a bear.  We hiked about 3 1/2 miles to a small meadow with wild blueberries growing.  The entire way out and back, there were NO signs of animal life...no insects, no sounds of birds or squirrels.  No scat or markings of any kind.  The absence of any and all fauna was very extremely evident, and more than a bit odd.

So what?
Okay...so what's my point?  If you're familiar with the environment, and aware of your surroundings while performing DFIR work, and know what should be there, you know what to look for, as well as what data sources to go to if you're looking for suspicious activity.  It's all about knowing what to hunt for when you're hunting.  This is particularly true if you're performing hunting operations in your own environment; however, it can also be applied in cases where you're a consultant (like me), engaging with an unfamiliar infrastructure.

In a recent presentation  (BrightTalk, may require registration) at InfoSecurity Europe 2015, Lee Lawson discussed some of the indicators that are very likely available to you right now, particularly if you've done nothing to modify the default audit configuration on Windows systems.

Not long ago, the folks at Rapid7 shared this video, describing four indicators you could use to detect lateral movement within your infrastructure.  Unfortunately, two of them are not logged as a result of the default audit configuration of Windows systems, and the presenter doesn't mention alternate Windows Event Log source/ID pairs you can look for instead.

There are a lot of ways to hunt for indications of activity, such as lateral movement, but what needs to happen is that admins need to start looking, even if it means building their list of indicators (and hopefully automating as much of it as makes sense to do...) over time.  If you don't know what to look for, ask someone.

If someone were to ask me (this is my opinion, and should not be misconstrued as a statement of my employer's opinion or business model) what was the one thing they could do to increase their odds of detecting malicious behavior, I'd say, "install Sysmon", but that's predicated on someone actually looking at the logs.

Addendum: @Cyborg_DFIR over on Twitter read the original version of this post (prior to the addendum) and felt that I talked more about explaining what you meant instead of talking about it. Fair enough.  I don't dispute that.  But what I will say is that I, and others, have talked about what to look for.  A lot. Does that mean it should stop?  No, of course not.  Just because something's been talked about before doesn't mean that it doesn't bear repeating or being brought up again.

During July 2013, I wrote 12 articles whose titles started with "HowTo:" and went on to describe what to look for, if you were looking for specific things.  More recently, I addressed the topic of detecting lateral movement within the last month.

So, to @Cyborg_DFIR and others who have similar thoughts, questions or comments...I'm more than willing to share what I know, but it's so much easier if you can narrow it down a bit.  Is there something specific you're interested in hearing about...or better yet, discussing?

RegRipper plugin update

I just pushed out an update to the appcompatcache.pl plugin, and committed it to the Github archive.  The update was based on a request I'd received to make the output of the tool a bit more manageable, and that was right along the lines of something I'd been thinking about doing for some time, anyway.

In short, the update simply puts the output for each entry on a single line, with the app path and name first, then the date, then other data (that's specific to 32-bit XP, actually), and finally, the executed flag.  Each segment is separated by two spaces.

So, what does this mean?  Well, the format puts everything on one line, so if you redirect the output to a file and any searches you run will give you the entire line, not just the first line (as with the old format).

Another way to use this new format is the way I like to use it, to determine if there's anything in the ShimCache data that requires my attention:

rip.pl -r d:\cases\local\system -p appcompatcache | find "programdata" /i

Done.  That's it.  Using DOS commands, it's quick and easy to run through a data sample quickly to see if there's anything of interest.

What techniques do you use during Registry analysis?

Links

SANS DFIR Poster
If you haven't heard, the new SANS DFIR "Evidence of..." poster is available.  I can see looking at the second page of the poster that they've added some items of interest that have been talked about recently.  For example, under "Browser Usage", I see mention of Mari's Google Analytics Cookies, and under "Program Execution", I see a reference to the AmCache.hve and the RecentFileCache.bcf files.

What's New in Windows 10
Speaking of "evidence of...", one question I see quite often is, "..what's new in Windows {insert newest version number}?"  Some folks at Champlain College have written up a Windows 10 Forensics guide.

The Problem with RegRipper 
I was reading herrcore's blog post in which malware that persists via a user's shell extensions, and came across the following statement in the post:

The problem with the two tools I mentioned; RegRipper (shellext.pl plugin) and Autoruns is that they rely on the Shell Extension to be registered using the standard method with HKEY_CLASSES_ROOT.

This quote is taken from the first sentence under a header that says, "A Blind Spot in our Incident Response Tools".

Since I first released RegRipper, my intention was that it would be community-based. That is, that by providing a framework such as RegRipper, the strength of the tool would be not simply that it would be downloaded and blindly pointed at Registry hives, but rather that analysts would either write and contribute their own plugins, or request (providing sample data, as well) plugins be developed.  That's right.  I totally get that not everyone programs in Perl...which is why I provide Windows executable files for the framework.  This is also why if someone doesn't program in Perl but strongly believes that they have a good idea for a plugin, all they need to do is write up a concise description of what it is they'd like to see, and email it to me along with some sample data.  When this has happened, I've been able to turn around a functioning plugin pretty quickly...usually within 4 hrs, and often within 1 hr.

This sort of thing has happened before.  At the SANS DFIR Summit in 2012, I sat in a presentation, during which the speaker stated, "...RegRipper does not have a plugin for {insert functionality}...".  That speaker also stated that RegRipper "does not scale to the enterprise" (which is was NEVER designed to do); however, that speaker had never reached to me to say, "...here's a plugin I wrote...", nor did they ever ask me for such functionality in a plugin.  I did find out after the presentation that the presentation had been written several months prior, and that a plugin had been written...the speaker had simply not updated their materials.

I get that there are some roadblocks to having a community-based tool...I completely understand that not everyone programs (nor wants to learn), and that of those who do, not all program in Perl.  That's okay.  I also understand that a major roadblock for a lot of DFIR analysts is simply...communicating.  There are a lot of reasons for this, but the fact is that most DFIR analysts simply do not want to communicate with others within the community.

I would suggest that the real "blindspot" or "problem" isn't whether or not RegRipper (or any other tool) contains specific functionality, but rather, what are we, as analysts, are willing to do to communicate with each other.

That being said, I contacted herrcore, and as a result of an email exchange where he sent me some sample data.  I'm researching his findings a little bit more to see if I can modify a current plugin (inprocserver.pl, shellext.pl), or would it make sense to write a new one?

In the meantime, here are some links where I've discussed RegRipper in this blog:
Mar, 2011 - Using RegRipper
Jul, 2012 - Thoughts on RegRipper Support
Aug, 2012 - RegRipper Updates

Addendum, 8 June: This morning, I updated a plugin, and created two others, and committed them to the plugin repository.

inprocserver.pl - I updated this plugin by adding "programdata" to the @alerts list in the alertCheckPath() function, and ran it against the test data that herrcore provided.  The result was:

ALERT: inprocserver: programdata found in path: c:\programdata\{9a88e103-a20a-4e
a5-8636-c73b709a5bf8}\ieapfltr.dll

cached.pl - new plugin; run it against the NTUSER.DAT hive to get the values from the \Shell Extensions\Cached key.  Running it via rip.exe displays the time value, and the two available CLSID values; I added a simple lookup for the second one.  As such, the output appears as follows:

Tue May 26 05:31:59 2015  First Load: {BDFA381D-D8C6-441A-BA17-95EB7FEBEA81} (IDriveFolderExt)
Tue May 26 05:34:57 2015  First Load: {9C73F5E5-7AE7-4E32-A8E8-8D23B85255BF} (IShellFolder)
Tue May 26 05:34:57 2015  First Load: {7007ACC7-3202-11D1-AAD2-00805FC1270E} (IShellFolder)
Tue May 26 05:35:05 2015  First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A} (IDriveFolderExt)

Simple enough.  However, if you use your command line fu, you can do something like this:

rip.pl -r d:\cases\herrcore\ntusertest2.dat -p cached | find "F6BF"
Launching cached v.20150608
Tue May 26 05:35:05 2015  First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A} (IDriveFolderExt)

cached_tln.pl - new plugin; similar to cached.pl, except that this plugin's output can be added directly to a timeline.  Also, this plugin does not have the lookup that cached.pl has...below is an example of the output:

rip.pl -r d:\cases\herrcore\ntusertest2.dat -p cached_tln -u keydet89 | find "F6BF"
Launching cached_tln v.20150608
1432618505|REG||keydet89|Cached Shell Ext First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A}

So, there you have it.  Typical caveats apply...such as "..these are based on extremely limited test data..", etc.

 USRCLASS.DAT excerpt

Also, something I wanted to mention as a result of looking through the hives herrcore sent me was that there were other indicators added to the USRCLASS.DAT hive, as seen in the image to the left.  You can see that in addition to the CLSID\{GUID}\InprocServer32 key, another key was added with the path Drive\ShellEx\FolderExtensions\{GUID}.

Detecting Lateral Movement

Almost two years ago, I posted this article that addressed how to track lateral movement within an infrastructure.  At the time, I'd been using this information successfully during engagements, and I still use it today.

This morning, I saw this video from Rapid7, and I thought that Mike did a great job with the presentation.  Mike made some very good points during his presentation.  For example, "SMB" is native to a Windows infrastructure, and with the right credentials, an adversary can go just about anywhere they please.

There were some things missing in the presentation, some caveats that need to be mentioned; I do understand that they were likely left out for the sake of time.  However, they are important.  For example:

Security-Auditing/4698 events - Scheduled Task creation; under Advanced Security Audit Policy settings, for Object Access, you need to have Audit Other Object Access Events enabled for this event to appear in your Windows Event Logs.

Security-Auditing/4697 events - Service installation; similar to the previous events, systems are not configured to audit for system creation via the Security Event Log by default.

So, the take-away here is that in order for these (and other) events to be useful, what admins need to do is properly configure auditing on systems, as well as employ a SEIM with some sort of filtering capability.  Increasing auditing alone will not be useful...I've seen that time and time again when an incident is identified; auditing is ramped up suddenly, and the Security Event Logs start filling up and rolling over in a matter of a few hours, causing valuable information to be lost.  The best thing to do is to enable auditing that makes sense within your infrastructure ahead of time, employing the appropriate settings (what to audit, increasing the default size of the Windows Event Log files, etc.) before an incident occurs.

Also, consider the use of MS's Sysmon, sending the collected data to a SEIM (Splunk??).  Monitoring process creation (including the command line) is extremely valuable, and not just in incident response.  For IR, having the process creation information available (along with a means to monitor it in a timely manner) reduces IR engagements from days or weeks to hours or even minutes.  If setting up Sysmon, Splunk, and filters is too daunting a task, consider employing something like Carbon Black.

Thanks to Rapid7 for sharing the video...it's some great information.

Resources
Description of Security Events in Windows 7/Windows Server 2008 R2

Links and Stuff

Registry Goodness
I recently wrote a RegRipper plugin, based on this KB article; on 26 May, I committed it to the plugin repository.  I had tweeted to ask the DFIR community if this information was relevant to their investigations, and there was not a great deal of response on the topic...although there was apparently some confusion.  I hope that folks take the time to try it, and I hope it's of some use to the DFIR community.  I don't often (scratch that...in 15+ years of doing DFIR work, I've never...) need to determine the history of GPOs assigned to a system.

Speaking of RegRipper plugins, Dan posted recently about how he completed the SANS CEIC 2015 Challenge.  While he completed the challenge using Eric Zimmerman's Registry Explorer tool, he did state toward the end of the post that he could've used RegRipper to complete the challenge, as well.

From the recent CEIC Conference, you can see David Dym's slides for his Improving Windows External Device Investigations presentation.  I know that no matter how many times this subject is addressed and discussed, there will always be confusion as to what resources are available on Windows systems if you are conducting one of these investigations.  I think it's great that we've got others talking about this topic, particularly because there seems to be so much confusion in this area.  Cory Altheide and I published the initial research into this topic in 2005 (there's a link here), and as new versions of Windows have come out, more information has become available regarding not only which devices were connected to systems, but also which user may have accessed the device.

Speaking of the Registry, Eric Zimmerman recently released a command line tool for interacting with (including searching) a Registry hive file for specific items.  Be sure to get version 0.6 of the tool.  Eric's been doing a lot of work in creating freeware tools for accessing the Registry, so be sure to check out his other offerings.

AutoStart
Not related to Registry analysis, but TrendMicro recently had a blog post about what they seem to be presenting as a variation in autostarting malware.  More than anything else, the post left me more than a little confused...it says that the intruders found an application that was set to run when the system started, and then modified the application's import table by adding a reference to a malicious DLL.  It was the next sentence that left me confused:

It is almost impossible to find differences between the original version and the modified ones, as even their file sizes are almost identical.

The post then goes on to say that 4 of the 5 infected applications were discovered as the modified versions weren't signed.  However, there still seems to be more going on here, because adding a DLL to the import table of a .exe file, and then referencing the malicious function should make something of an impact on the size of the application, as well as other aspects of the system itself (MFT, USN change journal, etc.).

Processes
Speaking of stuff starting, Corey posted recently regarding some testing he'd done with an MSWord document that would launch an executable.

Something I really like about Corey's post is that there's enough detail in the way he presented the material to not only replicate what he did (if you can or want to get a copy of the file he used...).  Also, there's enough information in the post to create things like searches for the pattern after running LogParser against the Sysmon Event Log file, as well as to write Carbon Black watchlist queries.