Friday, August 28, 2015

Updates & Links

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

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

Sunday, August 16, 2015

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.

Sunday, July 26, 2015

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.

Monday, July 13, 2015

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.

Tuesday, June 23, 2015

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.

Monday, June 22, 2015

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?

Thursday, June 11, 2015

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?