Monday, January 02, 2017

Links, Updates

I thought I'd make my first post of 2017 short and frills in this one...

Volatility 2.6 is available!

Matt Suiche recently tweeted that Hibr2Bin is back to open source!

Here's a very good article on hibernation and page file analysis, which discusses the use of strings and page_brute on the page file, as well as Volatility on the hibernation file.  Do not forget bulk_extractor; I've used this to great effect during several examinations.

Willi's EVTXtract has been updated; this is a great tool for when the Windows Event Log has been cleared, or someone took a live image of a system and one or more of the *.evtx files are being reported as 'corrupt' by your other tools.

FireEye recently published an article describing how they parse the WMI repository for indications of process execution...

Cyber Interviews
Douglas has kept the content coming, so be sure to check out the interviews he's got posted so far...

Web Shells
Web shells are still something very much in use by the bad guys.  We've seen web shells used very recently, and TrustWave also published an interesting article on the topic.

Tenable published their own article on hunting for web shells.

Sunday, December 18, 2016


What's New?
The question I hear perhaps most often, when a new book comes out, or if I'm presenting at a conference, is "what's new?" or "what's the latest and greatest in Windows version <insert upcoming release version>?"

In January, 2012, after attending a conference, I was at baggage claim at my home airport along with a fellow attendee (to the conference)...he asked me about a Windows NT4 system he was analyzing.  In November of 2016, I was involved in an engagement where I was analyzing about half a dozen Windows 2003 server systems.  On an online forum just last week, I saw a question regarding tracking users accessing MSOffice 2003 documents on Windows 2003 systems.

The lesson here is, don't throw out or dismiss the "old stuff", because sometimes all you're left with is the old stuff.  Knowing the process for analysis is much more important than memorizing tidbits and interesting facts that you may or may not ever actually use.

Keeping Up
Douglas Brush recently started recording podcast interviews with industry luminaries, beginning with himself (the array is indexed at zero), and then going to Chris Pogue and David Cowen.  I took the opportunity to listen to the interview with Chris not long ago; he and I had worked together for some time at IBM (I was part of the ISS purchase, Chris was brought over from the IBM team).

Something Chris said during the interview was very poignant; it was one of those things that incident responders know to be true, even if it's not something you've ever stated or specifically crystallized in your own thoughts.  Chris mentioned during the interview that when faced with a number of apparently complex options, non-technical folks will often tend toward those options with which they are most familiar.  This is true not just in information security (Chris mentioned firewalls, IDS, etc.), but also during incident response.  As a responder and consultant, I've seen time and again where it takes some time for the IT staff that I'm working with to understand that while, yes, there is malware on this system, it's there because someone specifically put it there so that they could control it (hands on keyboard) and move laterally within the infrastructure.

Chris's interview was fascinating, and I spent some time recently listening to David's interview, as well.  I had some great take-aways from a lot of the things David said.  For example, a good bit of David's work is clearly related to the courts, and he does a great job of dispelling some of what may be seen as myth, as well as addressing a few simple facts that should (I say "should" because it's not always the case) persist across all DFIR work, whether you're headed to court to testify or not.  David also has some great comments on the value of sharing information within the community.

So far, it's been fascinating to listen to the folks being interviewed, but to be honest, there a lot of women who've done exceptional work in the field, as well, and should not be overlooked.  Mari DeGrazia, Jamie Levy, Cindy Murphy, Sarah Edwards, to name just a few.  These ladies, as well as many others, have had a significant impact on, and continue to contribute to, the community.

I did listen to the Silver Bullet Podcast not long ago, specifically the episode where Lesley Carhart was interviewed.  It's good to get a different perspective on the industry, and I'm not just talking about from a female perspective.  Lesley comes from a background that is much different from mine, so I found listening to her interview very enlightening.

Friday, November 18, 2016

The Joy of Open Source

Not long ago, I was involved in an IR engagement where an intruder had exploited a web-based application on a Windows 2003 system, created a local user account, accessed the system via Terminal Services using that account, run tools, and then deleted the account that they'd created before continuing on using accounts and stolen credentials.

The first data I got to look at was the Event Logs from the system; using evtparse, I created a mini-timeline and got a pretty decent look at what had occurred on the system.  The client had enabled process tracking so I could see the Security/592 and ../593 events, but unfortunately, the additional Registry value had not been created, so we weren't getting full command lines in the event records.  From the mini-timeline, I could "see" the intruder creating the account, using it, and then deleting it, all based on the event record source/ID pairs.

For account creation:
Security/624 - user account created
Security/628 - user account password set
Security/632 - member added to global security group
Security/642 - user account changed

For account deletion:
Security/630 - user account deleted
Security/633 - member removed from global security group
Security/637 - member removed from local security group

Once I was able to access an image of the system, a visual review of the file system (via FTK Imager) confirmed that the user profile was not visible within the active file system.  Knowing that the account had been a local account, I extracted the SAM Registry hive, and ran regslack.exe against it...and could clearly see two keys (username and RID, respectively), and two values (the "F" and "V" values) that had been deleted and were currently "residing" within unallocated space in the hive file.  What was interesting was that the values still included their complete binary data.

I was also able to see one of the deleted keys via RegistryExplorer.

SAM hive open in RegistryExplorer

Not that I needed to confirm it, but I also ran the RegRipper plugin against the hive and ended up finding indications of two other deleted keys, in addition to the previously-observed information.

Output of RR plugin (Excerpt)

Not only that, but the plugin retrieves the full value data for the deleted values; as such, I was able to copy (via Notepad++) code for parsing the "F" and "V" value data out of the plugin and paste it into the plugin for temporary use, so that the binary data is parsed into something intelligible.

The plugin (output below) made it relatively simple to add the deleted key information to a timeline, so that additional context would be visible.

Output of RR plugin

If nothing else, this really illustrates one of the valuable aspects of open source software.  With relatively little effort and time, I was able to incorporate findings directly into my analysis, adding context and clarity to that analysis.  I've modified Perl and Python scripts to meet my own needs, and this is just another example of being able to make quick and easy changes to the available tools in order to meet immediate analysis needs.

Speaking of which, I've gone back and picked up something of a side project that I'd started a bit ago, based on a recent suggestion from a good friend. As I've started to dig into it a bit more, I've run into some challenges, particularly when it comes to "seeing" the data, and translating it into something readable.  Where I started with a hex editor and highlighting a DWORD value at a time, I've ended up writing and cobbling together bits of (open source) code to help me with this task. At first glance, it's like having a bunch of spare parts laying out on a workbench, but closer inspection reveals that it's all basically the same stuff, just being used in different ways.  What started a number of years ago with the header files from Peter Nordahl's ntchpwd utility became the first Registry parsing code that I wrote, which I'm still using to this day.

Some take-aways from this experience...

When a new version of Windows comes out, everyone wants to know what the new 'thing' is...what's the latest and greatest artifact?  But what about the stuff that always works?  What about the old stuff that gets used again and again, because it works?

Understanding the artifact cluster associated with certain actions on the various versions of Windows can help in recognizing those actions when you don't have all of the artifacts available.  Using just the event record source/ID pairs, we could see the creation and deletion of the user account, even if we didn't have process information to confirm it for us.  In addition, the account deletion occurred through a GUI tool (mmc.exe running compmgmt.msc) and all the process creation information would show us is that the tool was run, not which buttons were pushed.  Even without the Event Log record metadata, we still had the information we extracted from unallocated space within the SAM hive file.

Having access to open source tools means that things can be tweaked and modified to suit your needs.  Don't program?  No problem.  Know someone who does?  Are you willing to ask for help?  No one person can know everything, and sometimes it's helpful to go to someone and get a fresh point of view.

Saturday, October 29, 2016


I think that we can all agree, whether you've experienced it within your enterprise or not, ransomware is a problem.  It's one of those things that you hope never happens to you, that you hope you never have to deal with, and you give a sigh of relief when you hear that someone else got hit.

The problem with that is that hoping isn't preparing.

Wait...what?  Prepare for a ransomware attack?  How would someone go about doing that?  Well, consider the quote from the movie "Blade":

Once you understand the nature of a thing, you know what it's capable of.

This is true for ransomware, as well as Deacon Frost.  If you understand what ransomware does (encrypts files), and how it gets into an infrastructure, you can take some simple (relative to your infrastructure and culture, of course) to prepare for such an incident to occur.  Interestingly enough, many of these steps are the same that you'd use to prepare for any type of incident.

First, some interesting reading and quotes...such as from this article:

The organization paid, and then executives quickly realized a plan needed to be put in place in case this happened again. Most organizations are not prepared for events like this that will only get worse, and what we see is usually a reactive response instead of proactive thinking.


I witnessed a hospital in California be shut down because of ransomware. They paid $2 million in bitcoins to have their network back.

The take-aways are "not prepared" and "$2 million"...because it would very likely have cost much less than $2 million to prepare for such attacks.

The major take-aways from the more general ransomware discussion should be that:

1.  Ransomware encrypts files.  That's it.

2.  Like other malware, those writing and deploying ransomware work to keep their product from being detected.

3.  The business model of ransomware will continue to evolve as methods are changed and new methods are developed, while methods that continue to work will keep being used.

Wait...ransomware has a business model?  You bet it does!  Some ransomware (Locky, etc.) is spread either through malicious email attachments, or links that direct a user's browser to a web site.  Anyone who does process creation monitoring on an infrastructure likely sees this.  In a webcast I gave last spring (as well as in subsequent presentations), I included a slide that illustrated the process tree of a user opening an email attachment, and then choosing to "Enable Content", at which point the ransomware took off.

Other ransomware (Samas, Le Chiffre, CryptoLuck) is deployed through a more directed means, bypassing email all together.  An intruder infiltrates an infrastructure through a vulnerable perimeter system, RDP, TeamViewer, etc., and deploys the ransomware in a dedicated fashion.  In the case of Samas ransomware, the adversary appears to have spent time elevating privileges and mapping the infrastructure in order locate systems to which they'd deploy the ransomware.  We've seen this in the timeline where the adversary would on one day, simply blast out the ransomware to a large number of systems (most appeared to be servers).

The Ransomware Economy
There are a couple of other really good posts on Secureworks blog regarding the Samas ransomware (here, and here).  The second blog post, by Kevin Strickland, talks about the evolution of the Samas ransomware; not long ago, I ran across this tweet that let us know that the evolution that Kevin talked about hasn't stopped.  This clearly illustrates that developers are continuing to "provide a better (i.e., less detectable) product", as part of the economy of ransomware.  The business models that are implemented the ransomware economy will continue to evolve, simply because there is money to be had.

There is also a ransomware economy on the "blue" (defender) side, albeit one that is markedly different from the "red" (attacker) side.

The blue-side economy does not evolve nearly as fast as the red-side.  How many victims of ransomware have not reported their incident to anyone, or simply wiped the box and moved on?  How many of those with encrypted files have chosen to pay the ransom rather than pay to have the incident investigated?  By the way, that's part of the red-side economy...make it more cost effective to pay the ransom than the cost of an investigation.

As long as the desire to obtain money is stronger that the desire to prevent that from happening, the red-side ransomware economy will continue to outstrip that of the blue-side.

Preparation for a ransomware attack is, in many ways, no different from preparing for any other computer security incident.

The first step is user awareness.  If you see something, say something.  If you get an odd email with an attachment that asks you to "enable content", don't do it!  Instead, raise an alarm, say something.

The second step is to use technical means to protect yourself.  We all know that prevention works for only so long, because adversaries are much more dedicated to bypassing those prevention mechanisms than we are to paying to keep those protection mechanisms up to date.  As such, augmenting those prevention mechanisms with detection can be extremely effective, particularly when it comes to definitively nailing down the initial infection vector (IIV).  Why is this important?  Well, in the last couple of months, we've not only seen the deliver mechanism of familiar ransomware changing, but we've also seen entirely new ransomware variants infecting systems.  If you assume that the ransomware is getting in as an email attachment, then you're going to direct resources to something that isn't going to be at all effective.

Case in point...I recently examined a system infected with Odin Locky, and was told that the ransomware could not have gotten in via email, as a protection application had been purchased specifically for that purpose.  What I found was that the ransomware did, indeed, get on the system via email; however, the user had accessed their AOL email (bypassing the protection mechanism), and downloaded and executed the malicious attachment.

Tools such as Sysmon (or anything else that monitors process creation) can be extremely valuable when it comes to determining the IIV for ransomware.  Many variants will delete themselves after files are encrypted, (attempt to) delete VSCs, etc., and being able to track the process train back to it's origin can be extremely valuable in preventing such things in the future.  Again, it's about dedicating resources where they will be the most effective.  Why invest in email protections when the ransomware is getting on your systems as a result of a watering hole attack, or strategic web compromise?  Or what if it's neither of those?  What if the system had been compromised, a reverse shell (or some other access method, such as TeamViewer) installed and the system infected through that vector?

Ransomware will continue to be an issue, and new means for deploying are being developed all the time.  The difference between ransomware and, say, a targeted breach is that you know almost immediately when you've had files encrypted.  Further, during targeted breaches, the adversary will most often copy your critical files; with ransomware, the files are made unavailable to anyone.  In fact, if you can't decrypt/recover your files, there's really no difference between ransomware and secure deletion of your files.

We know that on the blue-side, prevention eventually fails.  As such, we need to incorporate detection into our security posture, so that if we can't prevent the infection or recover our files, we can determine the IIV for the ransomware and address that issue.

Addendum, 30 Oct: As a result of an exchange with (and thanks to) David Cowen, I think that I can encapsulate the ransomware business model to the following statement:

The red-side business model for ransomware converts a high number of low-value, blue-side assets into high-value attacker targets, with a corresponding high ROI (for the attacker).

What does mean?  I've asked a number of folks who are not particularly knowledgeable in infosec if there are any files on their individual systems without which they could simply not do their jobs, or without access to those files, their daily work would significantly suffer.  So far, 100% have said, "yes".  Considering this, it's abundantly clear that attackers have their own reciprocal Pyramid of Pain that they apply to defenders; that is, if you want to succeed (i.e., get paid), you need to impact your target in such a manner that it is more cost-effective (and less painful) to pay the ransom than it is perform any alternative.  In most cases, the alternative amounts to changing corporate culture.


I was working on an incident recently, and while extracting files from the image, I noticed that there was an AmCache.hve file.  Not knowing what I would find in the file, I extracted it to include in my analysis.  As I began my analysis, I found that the system I was examining was a Windows Server 2012 R2 Standard system.  This was just one system involved in the case, and I already had a couple of indicators.

As part of my analysis, I parsed the AppCompatCache value and found one of my indicators:

SYSVOL\downloads\malware.exe  Wed Oct 19 15:35:23 2016 Z

I was able to find a copy of the malware file in the file system, so I computed the MD5 hash, and pulled the PE compile time and interesting strings out of the file.  The compile time was  9 Jul 2016, 11:19:37 UTC.

I then parsed the AmCache.hve file and searched for the indicator, and found:

File Reference  : 28000017b6a
LastWrite          : Wed Oct 19 06:07:02 2016 Z
Path                   : C:\downloads\malware.exe
SHA-1               : 0000
Last Mod Time2: Wed Aug  3 13:36:53 2016 Z

File Reference   : 3300001e39f
LastWrite           : Wed Oct 19 15:36:07 2016 Z
Path                    : C:\downloads\malware.exe
SHA-1                : 0000
Last Mod Time2: Wed Oct 19 15:35:23 2016 Z

File Reference  : 2d000017b6a
LastWrite          : Wed Oct 19 06:14:30 2016 Z
Path                   : C:\Users\\Desktop\malware.exe
SHA-1               : 0000
Last Mod Time  : Wed Aug  3 13:36:54 2016 Z
Last Mod Time2: Wed Aug  3 13:36:53 2016 Z
Create Time       : Wed Oct 19 06:14:20 2016 Z
Compile Time    : Sat Jul  9 11:19:37 2016 Z

All of the SHA-1 hashes were identical across the three entries.  Do not ask for the hashes...I'm not going to provide them, as this is not the purpose of this post.

What this illustrates is the value of what what can be derived from the AmCache.hve file.  Had I not been able to retrieve a copy of the malware file from the file system, I would still have a great deal of information about the file, including (but not limited to) the fact that the same file was on the file system in three different locations.  In addition, I would also have the compile time of the executable file.

Sunday, October 16, 2016

Links and Updates

RegRipper Plugin
Not long ago, I read this blog post by Adapt Forward Cyber Security regarding an interesting persistence mechanism, and within 10 minutes, had RegRipper plugin written and tested against some existing data that I had available.

So why would I say this?  What's the point?  The point is that with something as simple as copy-paste, I extended the capabilities of the tool, and now have new functionality that will let me flag something that may be of interest, without having to memorize a checklist.  And as I pushed the new plugin out to the repository, everyone who downloads and uses the plugin now has that same capability, without having to have spent the time that the folks at Adapt Forward spent on this; through documentation and sharing, the DFIR community is able to extend the functionality of existing toolsets, as well as the reach of knowledge and experience.

Speaking of which, I was recently assisting with a case, and found some interesting artifacts in the Registry regarding LogMeIn logons; they didn't include the login source (there was more detail recovered from a Windows Event Log record), but they did include the user name and date/time.  This was the result of a creating a timeline that included Registry key LastWrite times, and led to investigating an unusual key/entry in the timeline.  I created a RegRipper plugin to extract the information (, and then created one to include the artifact in a timeline (  Shorty after creating them both, I pushed them up to Github.

Extending Tools, Extending Capabilities
Not long ago, I posted about parsing .pub files that were used to deliver malicious macros.  There didn't seem to be a great deal of interest from the community, but hey, what're you gonna do, right?  One comment that I did receive was, "yeah, so's a limited infection vector."  You know what?  You're right, it is.  But the point of the post wasn't, "hey, look here's a new thing..."; it was "hey, look, here's an old thing that's back, and here's how, if you understand the details of the file structure, you can use that information to extend your threat intel, and possibly even your understanding of the actors using it."

And, oh, by the way, if you think that OLE is an old format, you're right...but if you think that it's not used any longer, you're way not right.  The OLE file format is used with Sticky Notes, as well as automatic Jump Lists.

Live Imaging
Mari had an excellent post recently in which she addressed live imaging of Mac systems.  As she pointed out in her post, there are times when live imaging is not only a good option, but the only option.

The same can also be true for Windows systems, and not just when encryption is involved.  There are times when the only way to get an image of a server is to do so using a live imaging process.

Something that needs to be taken into consideration during the live imaging of Windows systems is the state of various files and artifacts while the system is live and running.  For example, Windows Event Logs may be "open", and it's well known that the AppCompatCache data is written at system shutdown.

Not long ago, I commented regarding my experiences using the AmCache.hve file during investigations; in short, I had not had the same sort of experiences as those described by Eric Z.

That's changed.

Not long ago, I was examining some data from a point-of-sale breach investigation, and had noticed in the data that there were references to a number of tools that the adversary had used that were no longer available on the system.  I'd also found that the installed AV product wasn't writing detection events to the Application Event Log (as many such applications tend to do...), so I ran 'strings' across the quarantine index files, and was able to get the original path to the quarantined files, as well as what the AV product had alerted on.  In one instance, I found that a file had been identified by the AV product as "W32.Bundle.Toolbar"...okay, not terribly descriptive.

I parsed the AmCache.hve file (the system I was examining was a Windows 7 SP1 system), and searched the output for several of the file names I had from other sources (ShimCache, UserAssist, etc.), and lo and behold, I found a reference to the file mentioned above.  Okay, the AmCache entry had the same path, so I pushed the SHA-1 hash for the file up to VT, and the response identified the file as CCleaner.  This fit into the context of the examination, as we'd observed the adversary "cleaning up", using either native tools (living off the land), or using tools they'd brought with them.

Windows Event Log Analysis
Something I see over and over again (on Twitter, mostly, but also in other venues) is analysts referring to Windows Event Log records solely by their event ID, and not including the source.

Event IDs are not unique.  There are a number of event IDs out there that have different sources, and as such, have a completely different context with respect to your investigation.  Searching Google, it's easy to see (for example) that events with ID 4000 have multiple sources; DNS, SMTPSvc, Diagnostics-Networking, etc.  And that doesn't include non-MS applications...that's just what I found in a couple of seconds of searching.  So, searching across all event logs (or even just one event log file) for all events with a specific ID could result in data that has no relevance to the investigation, or even obscure the context of the investigation. what?  Who cares?  Well, something that I've found that really helps me out with an examination is to use eventmap.txt to "tag" events of interest ("interest", as in, "found to be interesting from previous exams") while creating a timeline.  One of the first things I'll do after opening the TLN file is to search for "[maldetect]" and "[alert]", and get a sense of what I'm working with (i.e., develop a bit of situational awareness).  This works out really well because I use the event source and ID in combination to identify records of interest.

As many of us still run across Windows XP and 2003 systems, this link provides a good explanation (and a graphic) of how wrapping of event records works in the Event Logs on those systems.

Thursday, September 22, 2016

Size Matters

Yes, it does, and sometimes smaller is better.

Here's why...the other day I was "doing" some analysis, trying to develop some situational awareness from an image of a Windows 2008 SP2 system.  To do so, I extracted data from the listing of the partition via FTK Imager, Windows Event Logs, and Registry hive files.  I then used this data to create a micro-timeline (one based on limited data) so that I could just get a general "lay of the land", if you will.

One of the things I did was open the timeline in Notepad++, run the slider bar to the bottom of the file, and search (going "up" in the file) for "Security-Auditing/".  I did this to see where the oldest event from the Security Event Log would be located.  Again, I was doing this for situational awareness.

Just to keep track, from the point where I had the extracted data sources, I was now just under 15 min into my analysis.

The next thing I did was go all the way back to the top of the file, and I started searching for the tags included in eventmap.txt.  I started with "[maldetect]", and immediately found clusters of malware detections via the installed AV product.

Still under 18 min at this point.

Then I noticed something interesting...there was as section of the timeline that had just a bunch of failed login attempts (Microsoft-Windows-Security-Auditing/4625 events), all of them type 10 logins.  I knew that one of the things about this case was unauthorized logins via Terminal Services, and seeing the failed login attempts helped me narrow down some aspects of that; specifically, the failed login attempts originated from a limited number of IP addresses, but there were multiple attempts, many using user names that didn't exist on the system...someone was scanning and attempting to brute force a login.

I already knew from the pre-engagement conference calls that there were two user accounts that were of primary was a legit account the adversary had taken over, the other was one the adversary had reportedly created.  I searched for one of those and started to see "Microsoft-Windows-Security-Auditing/4778" (session reconnect) and /4779 (session disconnect) events.  I had my events file, so I typed the commands:

type events.txt | find "Microsoft-Windows-Security-Auditing/4778" > sec_events.txt
type events.txt | find "Microsoft-Windows-Security-Auditing/4779" >> sec_events.txt

From there, I wrote a quick script that ran through the sec_events.txt file and gave me a count of how many times various system names and IP addresses appeared together.  From the output of the script, I could see that for some system names, ones that were unique (i.e., "Hustler", etc., but NOT "Dell-PC") were all connecting from the same range of IP addresses.

From the time that I had the data available, to the point where I was looking at the output of the script was just under 45 min.  Some of that time included noodling over how best to present what I was looking for, so that I didn't have to go through things manually...make the code do alphabetical sorting rather than having to it myself, that sort of thing.

The point of all this is that sometimes, you don't need a full system timeline, using all of the available data, in order to make headway in your analysis.  Sometimes a micro-timeline is much better, as it doesn't include all the "noise" associated with a bunch of unrelated activity.  And there are times when a nano-timeline is a vastly superior resource.

As a side note, after all of this was done, I extracted the NTUSER.DAT files for the two user profiles of interest from the image, added the UserAssist information from each of them to the main events file, and recreated the original timeline with new time to do that was less than 10 min, and I was being lazy.  That one small action really crystallized the picture of activity on the system.

Addendum, 27 Sept:
Here's another useful command line that I used to get logon data:

type events.txt | find "Security-Auditing/4624" | find "admin123" | find ",10"

Monday, September 19, 2016


Malicious Office Documents
Okay, my last post really doesn't seem to have sparked too much interest; it went over like a sack of hammers.  Too bad.  Personally, I thought it was pretty fascinating, and can see the potential for additional work further on down the road.  I engaged in the work to help develop a clearer threat intel picture, and there has simply been no interest.  Oh, well.

Not long ago, I found this pretty comprehensive post regarding malicious Office documents, and it covers both pre- and post-2007 formats.

What's in your WPAD?
At one point in my career, I was a security admin in an FTE position within a company.  One of the things I was doing was mapping the infrastructure and determining ingress/egress points, and I ran across a system that actually had persistent routes enabled via the Registry.  As such, I've always tried to be cognizant of anything that would redirect a system to a route or location other than what was intended.  For example, when responding to an apparent drive-by downloader attack, I'd be sure to examine not only the web history but also the user Favorites or Bookmarks; there have been several times where doing this sort of analysis has added a slightly different shade to the investigation.

Other examples of this include things like modifications to the hosts file.  Windows uses the hosts file for name resolution, and I've used this in conjunction with a Scheduled Task, as a sort of "parental control", leaving the WiFi up after 10pm for a middle schooler, but redirecting some sites to localhost.  Using that knowledge over the years, I've also examined the hosts file for indicators of untoward activity; I even had a plugin for the Forensic Scanner that would automatically extract any entries in the hosts file what was other than the default.  Pretty slick.

Not new...this one is over four years old...but I ran across this post on the NetSec blog, and thought that it was worth mentioning.  Sometimes, you just have to know what you're looking for when performing incident response, and sometimes what you're looking for isn't in memory, or in a packet capture.

Speaking of checking things related to the browser, I saw something that @DanielleEveIR tweeted recently, specifically:

I thought this was pretty interesting, not something I'd seen or thought of before.  Unfortunately, many of the malware RE folks I know are focused more on the network than the host, so things such as modifications of Registry values tend to fall through the cracks.  However, if you're running Carbon Black, this might make a pretty good watchlist item, eh?

I did a search and found a malware sample described here that exhibits this behavior, and I found another description here.  Hopefully, that might provide some sort of idea as to how pervasive this artifact is.

@DanielleEveIR had another interesting tweet, stating that if your app makes a copy of itself and then launches the copy, it might be malware.  Okay, she's starting to sound like the Jeff Foxworthy of IR..."you might be malware if..."...but she has a very good point.  Our team recently saw the LaZagne credential theft tool being run in an infrastructure, and if you've ever seen or tested this, that's exactly what it does.  This would make a good watchlist item, as well...regardless of what the application name is, if the process name is the same as the parent process name, flag that puppy!  You can also include this in any script that you use that parses Security Event Logs (for event ID 4688) or Sysmon Event Logs.

Defender Bias
There've been a number of blog posts that have discussed analyst bias when it comes to DFIR, threat intel, and attribution.

Something that I haven't seen discussed much is blue team or defender bias.  Wait...what?  What is "defender bias"?  Let's look at some're sitting in a meeting, discussing an incident that your team is investigating, and you're fully aware that you don't have all the data at this point.  You're looking at a few indicators, maybe some files and Windows Event Log records, and then someone says, "...if I were the bad guy, I'd...".  Ever have that happen?  Being an incident responder for about 17 years, I've heard that phrase spoken.  A lot.  Sometimes by members of my team, sometimes by members of the client's team.

Another place that defender bias can be seen is when discussing "crown jewels".  One of the recommended exercises while developing a CSIRP is to determine where the critical data for the organization is located within the infrastructure, and then develop response plans around that data. The idea of this exercise is to accept that breaches are inevitable, and collapse the perimeter around the critical data that the organization relies on to function.

But what happens when you don't have the instrumentation and visibility to determine what the bad guy is actually doing?  You'll likely focus on protected that critical data while the bad guy is siphoning off what they came for.

The point is that what may be critical to you, to your business, may not be the "crown jewels" from the perspective of the adversary.  Going back as far as we can remember, reports from various consulting organizations have referred to the adversary as having a "shopping list", and while your organization may be on that list, the real question isn't just, "..where are your critical assets?", it's also "...what is the adversary actually doing?"

What if your "crown jewels" aren't what the adversary is after, and your infrastructure is a conduit to someone else's infrastructure?  What if your "crown jewels" are the latest and greatest tech that your company has on the drawing boards, and the adversary is instead after the older gen stuff, the tech shown to work and with a documented history and track record of reliability?   Or, what if your "crown jewels" are legal positions for clients, and the adversary is after your escrow account?

My point is that there is going to be a certain amount of defender bias in play, but it's critical for organizations to have situational awareness, and to also realize when there are gaps in that situational awareness.  What you decide are the "crown jewels", in complete isolation from any other input, may not be what the adversary is after.  You'll find yourself hunkered down in your Maginot Line bunkers, awaiting that final assault, only to be mystified when it never seems to come.