From the Trenches

I had an idea recently...there are a lot of really fascinating stories from the infosec industry that aren't being shared or documented in any way.  Most folks may not think of it this way, but these stories are sort of our "corporate history", they're what led to us being who and where we are today.

Some of my fondest memories from the military were sitting around with other folks, telling "war stories".  Whether it was at a bar after a long day (or week), or we were just sitting around a fire while we were still out in the field, it was a great way to bond and share a sort of "corporate history".  Even today, when I run into someone I knew "back in the day", the conversation invariably turns to one of us saying, "hey, do you remember when...?"  I see a lot of value in sharing this sort of thing within our community, as well.

While I was still on active duty, I applied for and was assigned to the graduate program at the Naval Postgraduate School.  I showed up in June, 1994, and spent most of my time in Spanagel Hall (bldg 17 on this map).  At the time, I had no idea that every day (for about a month), I was walking by Gary Kildall's office.  It was several years later that I was reading a book on some of the "history" behind MS/DOS and Silicon Valley that I read about Digital Research, and made the connection.  I've always found that kind thing fascinating...getting an inside view of things from the people who were there (or, in Gary's case, allegedly not there...), attending the meetings, etc.  Maybe that's why I find the "Live To Tell" show on the History Channel so fascinating.

As a bit of a side note, after taking a class where I learned about "Hamming distance" while I was at NPS, I took a class from Richard Hamming.  That's like reading Marvel Comics and then talking to Stan Lee about developing Marvel Comics characters.

So, my idea is to share experiences I've had within the industry since I started doing this sort (infosec consulting) of work, in hopes that others will do the same.  My intention here is not to embarrass anyone, nor to be negative...rather, to just present humorous things that I've seen or experienced, as a kind of "behind the scenes" sort of thing.  I'm not sure at this point if I'm going to make these posts their own separate standalone posts, or include shorter stories along with other posts...I'll start by doing both and see what works.

War Dialing
One of the first civilian jobs I had after leaving active duty was with SAIC.  I was working with a small team...myself, a retired Viet Nam-era Army Colonel, and two other analysts...that was trying to establish itself in performing assessment services.  If anyone's ever worked for a company like this, they were often described as "400 companies all competing with each other for the same work", and in our case, that was true.  We would sometimes loose work to another group within the company, and then be asked to assist them as their staffing requirements for the work grew.

This was back in 1998, when laptops generally came with a modem and a PCMCIA expansion slot, and your network interface card came in a small hard plastic case.  Also, most of the laptops had 3.5 disk drives built in still, although some came with an external unit that you connected to a port.

One particular engagement I was assigned to was to perform "war dialing" against a client located in one of the WTC towers.  So, we flew to New York, went to the main office and had our introductory meeting.  During the meeting, we went over our "concept of operations" (i.e., what we were planning to do) again, and again requested a separate area from where we could work, preferably something out of view of the employees, and away from the traffic patterns of the office (such as a conference room).  As is often the case, this wasn't something that had been set up for us ahead of time, so two of us ended up piling into an empty cubicle in the cube-farm..not ideal, but it would work for us.

At the time, the tools of choice for this work were Tone Loc and THC Scan.  I don't remember which one we were using at the time, but we kicked off our scan using a range of phone numbers, but without randomizing the list.  As such, two of us were hunkered down in this cubicle, with normal office traffic going on all around us.  We had turned the speakers on the laptop we were using (being in a cubicle rather than a conference room meant we only had access to one phone line...), and leaned in really close so we could hear what was going on over the modem.  It was a game for us to listen to what was going on and try to guess if the system on the other end was a fax machine, someone's desk phone or something else, assuming it picked up.

So, yeah...this was the early version of scanning for vulnerabilities.  This was only a few years after ISS had been formed, and the Internet Scanner product wasn't yet well known, nor heavily used.  While a scan was going on, there really wasn't a great deal to do, beyond monitoring the scan for problems, particularly something that might happen that we needed to tell the boss about; better that he hear it from us first, rather than from the client.

As we're listening to the modem, every now and then we know that we hit a desk phone (rather than a modem in a computer) because the phone would pick up and you'd hear someone saying "hello...hello..." on the other end.  After a while, we heard echos...the sequence of numbers being dialed was in an order that we could hear the person speaking via the laptop speakers, as well as above the din of the office noise.  We knew that the numbers were getting closer, so we threw jackets over the laptop in an attempt to muffle the noise...we were concerned that the person who picked up the phone in the cubicles on either side of us would hear themselves.

Because of the lack of space and phone lines available for the work, it took us another day to finish up the scan.  After we finished, we had a check-out meeting with our client point of contact, who shared a funny story about our scan with us.  It seems that there was a corporate policy to report unusual events; there posters all over the office, and apparently training for employees, telling them what an "unusual event" might look like, to whom to report it, etc.  So, after about a day and a half of the "war dialing", only one call had come in.  Our scan had apparently dialed two sequential numbers that terminated in the mainframe room, and the one person in the room felt that having to get up to answer one phone, then walk across the room to answer the other (both calls of which hung up) constituted an "unusual event"...that's how it was reported to the security staff.

About two years later, when I was working at another company, we used ISS's Internet Scanner, run from within the infrastructure, to perform vulnerability assessments.  This tool would tell us if the computer scanned had modems installed.  No more "war dialing" entire phone lists for me...it was deemed too disruptive or intrusive to the environment.

Updated samparse.pl plugin

I received an email from randomaccess last night, and got a look at it this morning.  In the email, he pointed out there there had been some changes to the SAM Registry hive as of Windows 8/8.1, apparently due to the ability to log into the system using an MSDN Live account.  Several new values seem to be added to the user RID key, specifically, GivenName, SurName, and InternetUserName.  He provided a sample SAM hive and an explanation of what he was looking for, and I was able to update the samparse.pl plugin, send him a copy, and update the GitHub repository, all in pretty short order.

This is a great example of what I've said time and again since I released RegRipper; if you need a plugin and don't feel that you can create or update one yourself, all you need to do is provide a concise description of what you're looking for, and some sample data.  It's that easy, and I've always been able to turn a new or updated plugin around pretty quickly.

Now, I know some folks are hesitant to share data/hive files with me, for fear of exposure.  I know people are afraid to share information for fear it will end up in my blog, and I have actually had someone tell me recently that they were hesitant to share something with me because they thought I would take the information and write a new book around it.  Folks, if you take a close look at the blog and books, I don't expose data in either one.  I've received hive files from two members of law enforcement, one of whom shared hive files from a Windows phone.  That's right...law enforcement.  And I haven't exposed, nor have I shared any of that data.  Just sayin'...

Interestingly enough, randomaccess also asked in his email if I'd "updated the samparse plugin for the latest book", which was kind of an interesting question.  The short answer is "no", I don't generally update plugins only when I'm releasing a new book.  If you've followed this blog, you're aware that plugins get created or updated all the time, without a new book being released.  The more extensive response is that I simply haven't seen a SAM hive myself that contains the information in question, nor has anyone provided a hive that I could used to update and test the plugin, until now.

And yes, the second edition of Windows Registry Forensics is due to hit the shelves in April, 2016.

The Need for Instrumentation

Almost everyone likes spies, right?  Jason Bourne, James Bond, that sort of thing?  One of things you don't see in the movies is the training these super spies go through, but you have to imagine that it's pretty extensive, if they can pop up in a city that they maybe haven't been to and transition seamlessly into the environment.

The same thing is true of targeted adversaries...they're able to seamlessly blend into your environment.  Like special operations forces, they learn how to use tools native to the environment in order to get the information that they're after, whether it's initial reconnaissance of the host or the infrastructure, locating items of interest, moving laterally within the infrastructure, or exfiltrating data.

I caught this post from JPCERT/CC that discusses Windows commands abused by attackers.  The author takes a different approach from previous posts and shares some of the command lines used, but also focuses on the frequency of use for each tool.  There's also a section in the post that recommends using GPOs to restrict the use of unnecessary commands.  An alternative approach might be to track attempts to use the tools, by creating a trigger to write a Windows Event Log record (discussed previously in this post).  When incorporated into an overall log management (SEIM, filtering, alerting, etc.) framework, this can be an extremely valuable detection mechanism.

If you're not familiar with some of the tools that you see listed in the JPCERT/CC blog post, try running them, starting by typing the command followed by "/?".

TradeCraft Tuesday - Episode #6 discusses how Powershell can be used and abused. The presenters (one of whom is Kyle Hanslovan) strongly encourage interaction (wow, does that sound familiar at all?) with the presentation via Twitter.  During the presentation, the guys talk about Powershell being used to push base64 encoded commands into the Registry for later use (often referred to as "fileless"), and it doesn't stop there.  Their discussion of the power of Powershell for post-exploitation activities really highlights the need for a suitable level of instrumentation in order to achieve visibility.

The use of native commands by an adversary or intruder is not new...it's been talked about before.  For example, the guys at SecureWorks talked about the same thing in the articles Linking Users to Systems and Living off the Land.  Rather than talking about what could be done, these articles show you data that illustrates what was actually done; not might or could, but did.

So, what do you do?  Well, I've posted previously about how you can go about monitoring for command line activity, which is usually manifest when access is achieved via RATs.

Not all abuse of native Windows commands and functionality is going to be as obvious as some of what's been discussed already.  Take this recent SecureWorks post for example...it illustrates how GPOs have been observed being abused by dedicated actors.  An intruder moving about your infrastructure via Terminal Services won't be as easy to detect using command line process creation monitoring, unless and until they resort to some form of non-GUI interaction.

Training

On the heels of my Skills Dilemma blog post, I wanted to share some thoughts on training.  Throughout my career, I've been on both sides of that fence...in the military and in private sector consulting, I've received, as well as developed and conducted training at various levels.  I've attended presentations, and developed and conducted presentations, at a number of levels and at a variety of venues.

Corey's also had some pretty interesting thoughts with respect to training in his blog.

Purpose
There are a lot of great training options out there.  When you're looking at the various options, are you looking to use up training funds, or are you looking for specific skills development?  What is the purpose of the training?  What's your intent in either attending the training, or sending someone, a staff member, to that training?

If you're just looking to use up training funds so that you'll get that money included in your budget next year, well, pretty much anything will do.  However, if you're looking for specific skills development, whether it's basic or advanced skills, you may want to look closely at what's being taught in the course.

What would really help with this is a Yelp-like system for reviewing training courses.  Wait...what?  You think someone should actually evaluate the services they pay for and receive?  What are you, out of your mind?

So, here's my thought...as a manager, you sit down with one of your staff and develop performance indicators and goals for the coming year, as well as a plan for achieving those goals.  The two of you decide that in order to meet those goals, one step is to attend a specific training course.  Your staff member attends, and then you both write a review.  You both write a review of the course based on what you agreed you wanted to achieve by attending the course; the staff member based on attending the course, and you (as the manager) based on your observation of your staff member's use of their new skills.

Accountability
I'll say it again...there are a lot of great training options out there, but in my experience, what's missing is accountability for that training.  What I mean by that is, if you're a manager and you send someone off to training (whether they obtain a certification or not), do you hold them accountable for that training once they return?

Here's an example...when I was on active duty and was stationed overseas, there was an NBC (nuclear, biological, chemical) response course being conducted, and being the junior guy, I was sent.  After I'd passed the course and received my certificate, I returned to my unit, and did absolutely NOTHING with respect to NBC.  Basically, I was simply away for a week.  I was sent off to the training for no other reason than I was the low guy on the totem pole, and when I returned, I was neither asked about, nor required to use or implement that training in any way.  There was no accountability.

Later in my tenure in the military, I found an opening for some advanced training for a Sgt who worked for me.  I felt strongly that this Sgt should be promoted and advance in his career, and one way to shore up his chances was to ensure that he advanced in his military occupational specialty.  I got him a seat in the training course, got his travel set up, and while he was gone, I found a position in another unit where he would put his new-found skills to good use.  When he returned, I informed him of his transfer (which had other benefits for him, as well).  His new role required him to teach junior Marines about the device he'd been trained on, as well as train the new officers attending the Basic Communication Officers Course on how to use and deploy the device, as well.  He was held accountable for the training he'd received.

How often do we do this?  Be honest.  I've seen an analyst that had attended some pretty extensive training, only to return and within the next couple of weeks, not know how to determine if a file had been time stomped or not.  I know that the basics of how to conduct that type of analysis were covered in the training they'd attended.

Generalist vs. Specialist
What kind of training are you interested in?  Basic skills development, or advanced training in a very specific skill set?  What specific skills are you looking for?  Are they skills specific to your environment?

There's a lot of good generalist training out there, training that provides a broad range of skills.  You may want to start there, and then develop an in-house training program ("brown bag" lunch presentations, half- or full-day training, mentoring, etc.) that reinforces and extends those basic skills into something that's specific to your environment.

Analysis

A bit ago, I posted about doing analysis, and that post didn't really seem to get much traction at all.  What was I trying for?  To start a conversation about how we _do_ analysis.  When we make statements to a client or to another analyst, on what are we basing those findings?  Somewhere between the raw data and our findings is where we _do_ analysis; I know what that looks like for me, and I've shared it (in this blog, in my books, etc.), and what I've wanted to do for some time is go beyond the passivity of sitting in a classroom, and start a conversation where analysts engage and discuss analysis.

I have to wonder...is this even possible?  Will analysts talk about what they do?  For me, I'm more than happy to.  But will this spark a conversation?

I thought I'd try a different tact this time around.  In a recent blog post, I mentioned that two Prefetch parsers had recently been released.  While it is interesting to see these tools being made available, I have to ask...how are analysts using these tools?  How are analysts using these tools to conduct analysis, and achieve the results that they're sharing with their clients?

Don't get me wrong...I think having tools is a wonderful idea.  We all have our favorite tools that we tend to gravitate toward or reach for under different circumstances.  Whether it's commercial or free/open source tools, it doesn't really matter.  Whether you're using a dongle or a Linux distro...it doesn't matter.  What does matter is, how are you using it, and how are you interpreting the data?

Someone told me recently, "...I know you have an issue with EnCase...", and to be honest, that's simply not the case.  I don't have an issue with EnCase at all, nor with FTK.  I do have an issue with how those tools are used by analysts, and the issue extends to any other tool that is run auto-magically and expected to spit out true results with little to no analysis.

What do the tools really do for us?  Well, basically, most tools parse data of some sort, and display it.  It's then up to us, as analysts, to analyze that data...interpret it, either within the context of that and other data, or by providing additional context, by incorporating either additional data from the same source, or data from external sources.

RegRipper is a great example.  The idea behind RegRipper (as well as the other tools I've written) is to parse and display data for analysis...that's it.  RegRipper started as a bunch of scripts I had sitting around...every time I'd work on a system and have to dig through the Registry to find something, I'd write a script to do the actual work for me.  In some cases, a script was simply to follow a key path (or several key paths) that I didn't want to have to memorize. In other cases, I'd write a script to handle ROT-13 decoding or binary parsing; I figured, rather than having to do all of that again, I'd write  a script to automate it.

For a while, that's all RegRipper did...parse and display data.  If you had key words you wanted to "pivot" on, you could do so with just about any text editor, but that's still a lot of data.  So then I started adding "alerts"; I'd have the script (or tool) do some basic searching to look for things that were known to be "bad", in particular, file paths in specific locations.  For example, an .exe file in the root of the user profile, or in the root of the Recycle Bin, is a very bad thing, so I wanted those to pop out and be put right in front of the analyst.  I found...and still find...this to be an incredibly useful functionality, but to date,

Here's an example of what I'm talking about with respect to analysis...I ran across this forensics challenge walk-through recently, and just for sh*ts and grins, I downloaded the Registry hive (NTUSER.DAT, Software, System) files.  I ran the appcompatcache.pl RegRipper plugin against the system hive, and found the following "interesting" entries within the AppCompatCache value:

C:\dllhot.exe  Tue Apr  3 18:08:50 2012 Z  Executed
C:\Windows\TEMP\a.exe  Tue Apr  3 23:54:46 2012 Z  Executed
c:\windows\system32\dllhost\svchost.exe  Tue Apr  3 22:40:25 2012 Z  Executed
C:\windows\system32\hydrakatz.exe  Wed Apr  4 01:00:45 2012 Z  Executed
C:\Windows\system32\icacls.exe  Tue Jul 14 01:14:21 2009 Z  Executed

Now, the question is, for each of those entries, what do they mean?  Do they mean that the .exe file was "executed" on the date and time listed?

No, that's not what the entries mean at all.  Check out Mandiant's white paper on the subject.  You can verify what they're saying in the whitepaper by creating a timeline from the shim cache data and file system metadata (just the $MFT will suffice); if the files that had been executed were not deleted from the system, you'll see that the time stamp included in the shim cache data is, in fact, the last modification time from the file system (specifically, the $STANDARD_INFORMATION attribute) metadata.

I use this as an example, simply because it's something that I see a great deal of; in fact, I recently experienced a "tale of two analysts", where I reviewed work that had previously been conducted, by two separate analysts.  The first analyst did not parse the Shim Cache data, and the second parsed it, but assumed that what the data meant was that the .exe files of interested had been executed at the time displayed alongside the entry.

Again, this is just an example, and not meant to focus the spotlight on anyone.  I've talked with a number of analysts, and in just about every conversation, they've either known someone who's made the same mistake misinterpreting the Shim Cache data, or they've admitted to misinterpreting it themselves.  I get it; no one's perfect, and we all make mistakes.  I chose this one as an example, because it's perhaps one of the most misinterpreted data sources.  A lot of analysts who have attended (or conducted) expensive training courses have made this mistake.

Pointing out mistakes isn't the point I'm trying to make...it's that we, as a community, need to engage in a community-wide conversation about analysis.  What resources do we have available now, and what do we need?  We can't all attend training courses, and when we do, what happens most often is that we learn something cool, and then don't see it again for 6 months or a year, and we forget the nuances of that particular analysis.  Dedicated resources are great, but they (forums, emails, documents) need to be searched.  What about just-in-time resources, like asking a question?  Would that help?

Resources, Link Mashup

Monitoring
MS's Sysmon was recently updated to version 3.2, with the addition of capturing opens for raw read access to disks and volumes.  If you're interested in monitoring your infrastructure and performing threat hunting at all, I'd highly recommend that you consider installing something like this on your systems.  While Sysmon is not nearly as fully-featured as something like Carbon Black, employing Sysmon along with centralized log collection and filtering will provide you with a level of visibility that you likely hadn't even imagined was possible previously.

This page talks about using Sysmon and NXLog.

The fine analysts of the Dell SecureWorks CTU-SO recently had an article posted  that describes what the bad guys like to do with Windows Event Logs, and both of the case studies could be "caught" with the right instrumentation in place.  You can also use process creation monitoring (via Sysmon, or some other means) to detect when an intruder is living off the land within your environment.

The key to effective monitoring and subsequent threat hunting is visibility, which is achieved through telemetry and instrumentation.  How are bad guys able to persist within an infrastructure for a year or more without being detected?  It's not that they aren't doing stuff, it's that they're doing stuff that isn't detected due to a lack of visibility.

MS KB article 3004375 outlines how to improve Windows command-line auditing, and this post from LogRhythm discusses how to enable Powershell command line logging (another post discussing the same thing is here).  The MS KB article gives you some basic information regarding process creation, and Sysmon provides much more insight.  Regardless of which option you choose, however, all are useless unless you're doing some sort of centralized log collection and filtering, so be sure to incorporate the necessary and appropriate logs into your SEIM, and get those filters written.

Windows Event Logs
Speaking of Windows Event Logs, sometimes it can be very difficult to find information regarding various event source/ID pairs.  Microsoft has a great deal of information available regarding Windows Event Log records, and I very often can easily find the pages with a quick Google search.  For example, I recently found this page on Firewall Rule Processing events, based on a question I saw in an online forum.

From Deus Ex Machina, you can look up a wide range of Windows Event Log records here or here.  I've found both to be very useful.  I've used this site more than once to get information about *.evtx records that I couldn't find any place else.

Another source of information about Windows Event Log records and how they can be used can often be one of the TechNet blogs.  For example, here's a really good blog post from Jessica Payne regarding tracking lateral movement...

With respect to the Windows Event Logs, I've been looking at ways to increase instrumentation on Windows systems, and something I would recommend is putting triggers in place for various activities, and writing a record to the Windows Event Log.  I found this blog post recently that discusses using PowerShell to write to the Windows Event Log, so whatever you trap or trigger on a system can launch the appropriate command or run a batch file the contains the command.  Of course, in a networked environment, I'd highly recommend a SEIM be set up, as well.

One thought regarding filtering and analyzing Windows Event Log records sent to a SEIM...when looking at various Windows Event Log records, we have to look at them in the context of the system, rather than in isolation, as what they actually refer to can be very different.  A suspicious record related to WMI, for example, when viewed in isolation may end up being part of known and documented activity when viewed in the context of the system.

Analysis
PoorBillionaire recently released a Windows Prefetch Parser, which is reportedly capable of handling *.pf files from XP systems all the way up through Windows 10 systems.  On 19 Jan, Eric Zimmerman did the same, making his own Prefetch parser available.

Having tools available is great, but what we really need to do is talk about how those tools can be used most effectively as part of our analysis.  There's no single correct way to use the tool, but the issue becomes, how do you correctly interpret the data once you have it?

I recently encountered a "tale of two analysts", where both had access to the same data.  One analyst did not parse the ShimCache data at all as part of their analysis, while the other did and misinterpreted the information that the tool (whichever one that was) displayed for them.

So, my point is that having tools to parse data is great, but if the focus is tools and parsing data, but not analyzing and correctly interpreting the data, what have the tools really gotten us?

Creating a Timeline
I was browsing around recently and ran across an older blog post (yeah, I know it's like 18 months old...), and in the very beginning of that post, something caught my eye.  Specifically, a couple of quotes from the blog post:

...my reasons for carrying this out after the filesystem timeline is purely down to the time it takes to process.

...and...

The problem with it though is the sheer amount of information it can contain! It is very important when working with a super timeline to have a pivot point to allow you to narrow down the time frame you are interested in.

The post also states that timeline analysis is an extremely powerful tool, and I agree, 100%.  What I would offer to analysts is a more deliberate approach to timeline analysis, based on what Chris Pogue coined as Sniper Forensics.

Speaking of analysis, the folks at RSA released a really good look at analyzing carrier files used during a phish.  The post provides a pretty thorough walk-through of the tool and techniques used to parse through an old (or should I say, "OLE") style MS Word document to identify and analyze embedded macros.

Powershell
Not long ago, I ran across an interesting artifact...a folder with the following name:

C:\Users\user\AppData\Local\Microsoft\Windows\PowerShell\CommandAnalysis\

The folder contained an index file, and a bunch of files with names that follow the format "PowerShell_AnalysisCacheEntry_GUID".  Doing some research into this, I ran across this BoyWonder blog post, which seems to indicate that this is a cache (yeah, okay, that's in the name, I get it...), and possibly used for functionality similar to auto-complete.  It doesn't appear to illustrate what was run, though.  For that, you might want to see the LogRhythm link earlier in this post.

As it turned out, the folder path I listed above was part of legitimate activity performed by an administrator.

More Registry Fun

Once, on a blog far, far away, there was this post that discussed the use of the Unicode RLO control character to "hide" malware in the Registry, particularly from GUI viewers that processed Unicode.

Recently, Jamie shared this Symantec article with me; figure 1 in the article illustrates an interesting aspect of the malware when it comes to persistence...it apparently prepends a null character to the beginning of the value name.  Interesting, some seem to think that this makes tools like RegEdit "brokken".

So, I wrote a RegRipper plugin called "null.pl" that runs through a hive file looking for key and value names that being with a null character.  Jamie also shared a couple of sample hives, so I got to test the plugin out.   The following image illustrates the plugin output when run against one of the hives:

Figure 1

All in all, the turn-around time was pretty quick.  I started this morning, and had the plugin written, tested, and uploaded to Github before lunch.

Later in the day, Eric Zimmerman followed up by testing the hive that Jamie graciously shared with me against the Registry Explorer.  I should also note that MiTeC WRR has no issues with the value names; it displays them as follows:

Figure 2

Addendum, 20 Jan: On a whim, I ran the fileless.pl plugin against the hive, and it detected the two values with the "fileless" data seen in figure 2.

The Skills Dilemma

Is there an issue of skills within information or "cyber" security?  Yes, without a doubt.  But it's not the way you think...the dilemma is not one of a lack of qualified and skilled practitioners, it's one of a lack of skilled managers.

Okay, caveat time...if you're a manager, you might want to stop reading.  If you get butt-hurt easily, you might not want to continue on beyond this point.  Just sayin'...

I read Scott Scanlon's The Hunt for Cyber Security Leadership Intensifies article recently, and I have to say, being in the industry for the past 19-some-odd years, I have different perspective on the issue.  The second sentence of Scott's article, referring to executive recruiters, says:

But they are finding a lack of qualified candidates just as companies put a greater emphasis and give a higher priority to corporate security.

It's not my intention to take anything away from Scott, nor am I suggesting that he's incorrect.  I'm simply saying that I have a different perspective.  In doing so, I'd like to take a look at that sentence; specifically, what constitutes a "qualified candidate", and who decides?  If you're "finding a lack of qualified candidates", how are you looking?

Let's look at the process of finding a "qualified candidate":

Job Posting
Who writes job postings or position descriptions?  Managers?  Are you a manager?  Write a description for a position you need to fill.  Now, ball it up and throw it away, because you're wrong.

Here's what I mean...I was engaged in a thread recently on LinkedIn, where an employee of a company had posted two position descriptions, one for a threat intel analyst.  When I read the position qualifications, one of the stated requirements was a familiarity with "EnCase or FTK".  I was curious, so I asked why that was a requirement, and the employee who shared the links didn't know.  Shortly, one of the C-level execs from the company responded, saying that it wasn't a requirement.

Then why say that it is?

Have you ever seen those position descriptions?  "The candidate MUST have a CISSP, EnCE, etc."  Really?

Running the Gauntlet
Position descriptions are passed from the manager to HR or a recruiting firm, who become the gate keepers.  Most of the recruiters I've encountered have no experience in the information security field themselves...they're recruiters.  So for them, the position description is a set-in-stone road map, and the words used by the hiring manager become the round holes in the board.

I once worked at a company where, after I was hired, one of the recruiters stated publicly that when they receive a resume from a candidate for a position in information security, they search the resume for the term "information security", and if they don't find it at least 4 times, they throw the resume out.  What about qualifications?  The hiring manager includes "CISSP" and "EnCE" as a "requirements", but doesn't tell the recruiter that they really aren't "requirements".  So, the recruiter looks at resumes, and if "CISSP" AND "EnCE" aren't listed, you don't pass GO and you don't collect $200.

So the question then becomes, how does someone who's qualified pass through that gauntlet and get an actual interview?  I "came up" in the industry before there were courses you could take, and a lot of what I know is self-taught.  I know enough about EnCase and FTK to know when they're suitable for use.  I'm not suggesting that I'm a "qualified candidate" but if I was, how would anyone know?

Interviewing a Candidate
I'll be 100% with you...most of the people I've encountered while interviewing don't know how to interview.  We all like to think that we're good at it, but the simple fact is that we don't know how to interview.

When I first got out of the military, I interviewed at a defense contractor, and had four hours of interviews with different departments scheduled.  At the beginning of the first interview of the day, the senior manager started off by telling me, very clearly, that he'd run all of my qualifications through a model that he'd developed, and he'd determined how much I would make in my first job.  This is before he even spoke to me or got to know me.  That's not how to conduct an interview...and I made considerably more than what his model showed in my first job.

A great way to loose a candidate is to take them around the office, and surprising members of your team by dropping the candidate off for a "spur of the moment" interview.

Look, I've been on both sides of the fence in 19 years.  When I was getting out of the military, I had to take classes in "how to interview".  What made it disheartening was that the people I wasn't interviewing with had NO training at all.  All the preparation in the world cannot stand up to the first question in an interview being, "so...why are you here?"

I've also been responsible for conducting interviews.  I've seen people lie on their resume, simply to make it past the "recruiter gauntlet" and get an interview.  I've had interviews go really well, and some that didn't go well.  I've also been in a position where someone was hired to support the work that I did, and I was not involved in the process, at any level.  In fact, in that case, I wasn't even aware of the vision or business decision for filling the position...all I know is that I heard a discussion in the hallway about offering this person a signing bonus.

The Reality of the Position
What is the reality of the position itself?  Yeah, I know what the job description says about the position and the company (words like "dynamic" are used), but all bullsh*t aside, what's the reality?

Is the actual work position in the heart of a major city?  As someone who lives outside of a major city (way outside), I know better than to try to drive into the city for the odd social event...and you want me to drive into the city everyday as part of the job?  I thought the position description said that your company "values quality of life"....

What about the actual work itself?  In my time, I've worked for a couple of contracting firms, "supporting" federal law enforcement.  In both cases, a lot of very positive things were said about the position.  When I supported a CSIRT, it took me 8 months to get my agency-specific clearance, and in that time, I found out that the "CSIRT" didn't actually respond to anything; if they happened to find out that something happened, they had to request that someone from network ops run a tool (just one) on the suspect system.  When I found out that the one tool was one that simply listed processes, I suggested that along with the process, we also get the path to the executable image (for context), and the person I suggested this to got offended.

In the other position, all of the case agents would take their work to one or two analysts, while the rest of us got really good at Solitaire.

If you're a contractor and having trouble finding "qualified candidates", then the issue may be one of the positions you're filling themselves.  I've spent time with contracting firms whose business model is to be a seat-filler, and to be honest, I can see why they're having trouble finding qualified candidates.

I'm not talking about being cynical about the position or the company...I'm talking about being honest about it, that's all.  After all, if you're not honest about the position, it's going to be revolving door of candidates.  As bad as it sounds, a worse outcome is having someone realize how it is, and stay.

So, my point is that there are, in fact, highly skilled individuals in the "cyber" arena.  Many of them have time in the industry, have learned a lot of the lessons I've described (and more), and have created for themselves an environment where they're happy.  Some of the highly qualified but relatively new individuals in the industry have gravitated to the more experienced folks, and are similarly very happy.

Rather than repeating the "lack of qualified candidates" mantra, take a good hard look at what you're doing to find those candidates.  Is it the process you're using?  Is it the business model that needs to be changed?  Or, consider "rolling your own"...use your current expertise to develop and grow new expertise.

Addendum, 19 Jan: I ran across this INC article today that gives 16 steps to help make your interview a success.  The problem I've always found is that there aren't articles like this for those on the other side of the table...those who have head count and a position to fill.  There are a lot of articles out there that talk about how to be an interviewee, but few that really prepare the interviewer.

Addendum, 25 Jan: Here's a Forbes article that discusses answers to the 5 dumbest interview questions; the point is that they're still being asked.

New RR Plugin: rdpnla.pl

I received a new RegRipper plugin from Chakib today, rdpnla.pl.  In short, the plugin checks the SecurityLayer value of the HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp key in order to determine if network level authentication is enabled or not.

So what?, you ask?  Well, for one, this is a way to help prevent the Sticky Keys attack from succeeding.  If you've found that a system had been subject to the attack and wanted to see if it would succeed, be sure to run this plugin.

This HowToGeek page has a graphical discussion of what some of the other settings look like for this key.

Thanks, Chakib!

Working with Shadow Volumes

I had an opportunity recently to do some interesting work with Volume Shadow Copies within an image acquired from a Windows 7 system.  In this instance, I got some great information from a specific VSC, and I wanted to go back and do some testing.  Through exchanges with David Cowen, I got access to some tools and decided to share my findings.

Goal
The goal of this analysis, after completing the analysis I originally intended to do with the image, was to see if the hibernation file (hiberfil.sys) existed as a "previous version" in a VSC.

My original analysis involved creating a timeline in order to develop a detailed understanding of a malware infection associated with a targeted threat group.  The system had been infected over a year ago, and at one point late this past summer, the AV had quarantined the malware and "cleaned" the persistence mechanisms.

VSCs in FTK Imager

During that initial analysis, I opened the image in FTK Imager, and at one point, I checked the "System Volume Information" folder and found that there were a number of difference files visible.  At that point, I knew that the image contained VSCs, and by examining the modification dates for the files in FTK Imager, I had a good idea of when each had been created.  I saw that there were one or two VSCs that had been created prior to the malware being quarantined, and I figured that I could extract specific data sources from that VSC in order to augment my timeline.

I accessed the VSC of interest using the VHD method outlined here (note: this blog post contains the commands used).  I still have a copy of vhdtool.exe (seems to no longer be available, possible replacement linked here), so I used the "convert" option to change the *.001 file to a VHD format; this operation essentially adds a footer to the image file.  In order to attach the VHD via the Disk Management utility on my Win10 analysis system, I had to change the file extension from "*.001" to "*.vhd"; the file still opens just fine in FTK Imager.

Everything went fine using the vssadmin and mklink commands to access the VSC of interest, and I then added the resulting folder as an evidence item to FTK Imager (choosing 'contents of a folder').  I was able to extract the files I wanted at the time, but I did not that this method did not provide me with the necessary access to extract files such as the $MFT, etc.  At the time, for the analysis I was doing, that was not an issue.

The issue came up later when I mentioned to Jamie Levy that I had Windows 7 system with VSCs available, and that the hibernation file within the image itself was not a useful source of information about the malware, because the malware had been quarantined about a month prior the hibernation file being created.  Jamie said she was curious to see through testing if the hibernation file was covered by VSCs; that is, could I go back to the VSC of interest and retrieve/extract a previous version of hiberfil.sys?

VSS
Jimmy Weg has a good number of blog posts that address VSS; Jimmy's done a lot of great work and shared it.  In fact, I initially used information from his 13 Jul 2012 blog post entitled Mounting Shadow Volumes to mount the VSC of interest as a RAM disk on my analysis system.  At the time that I did this, I was simply interested in collecting a copy of the $MFT, which is why I was pursing it...at the time, I wasn't interested in comparing hibernation files.

After attaching the VHD and running the vssadmin command to enumerate VSCs from the newly-attached volume, I used the following command:

D:\Tools>vss x: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy16

This resulted in a RAM disk being added to my analysis system.  I didn't see it in Explorer, nor in the Disk Management utility, but I could add it as a logical volume to FTK Imager.

Removing the drive was easy:

D:\Tools>vss x:

Drive X: removed

If you're interested in mounting multiple VSCs sequentially, take a look at Jimmy's blog posts and consider using Dan Mare's vss.exe.

Libvshadow
While chatting with David, he mentioned that the method used to access VSCs may have an effect on what I was seeing, or what I could access, and he suggested that I take a look at using libvshadow to access the VSCs.

Step 1: Get the tools..look for "...windows compiled version of libvshadow..."

Step 2: Install Dokan (I went with v.0.7.4, as David mentioned via chat that 0.7.something was the latest stable release)

Step 3: Run mmls to get the sector offset to the partition of interest

mmls -i raw -t dos z:\image.vhd

This gave me a sector offset of "0000002048" to the partition.

Step 4: Run vshadowinfo (not really necessary)

I'm including this step for completeness...vshadowinfo and vshadowmount require byte offsets, and 2048 x 512 = 1048576, so we will use 1048576 to designate the byte offset to the partition we're interested in:

vshadowinfo -o 1048576 z:\image.vhd

Step 5: Run vshadowmount

vshadowmount -o 1048576 -X allow_other z:\image.vhd x:

X:\ volume contents

The result of running this command is that I now had an X:\ volume on my system (i.e., X: is the mount point added via the vshadowmount command line), with the contents of the volume illustrated in the figure to the right.

Note: After hitting "enter" following the above command line, the command prompt did not return; this is normal.  Don't do anything...don't hit "ctrl-C" and do not close the command prompt.  You can minimize it, but do not forget that it's there.

Step 6: Access VSS1 using FTK Imager

I opened FTK Imager and added VSS1 as an image file.  It parsed and opened a little slower than a "normal" image would (the image itself is on a USB drive, and the VSC had to be parsed...).  However, I now have access to the VSC as a raw/dd image.  This VSC was created on 13 July 2015, and I can not only extract files that were quarantined on 13 Aug 2015, but I can also extract a previous version of the $MFT and other system files.  I can even mount the contents of the VSC by choosing "File->Image Mounting..." via FTK Imager.

If you left the command prompt up in the background, you'll see stuff scrolling by...when you're done doing what you want to do with the VSC and have closed FTK Imager, or just removed the evidence item, bring the command prompt into focus and hit "Ctrl-C"; the prompt will return, and you'll no longer have an X:\ volume on your system.

Testing
I opted to use libvshadow to access the VSC and extract hiberfil.sys.  I did that, and use Volatility to convert the file to a raw memory dump, and then ran the imageinfo command; even though the VSC that I'd "extracted" the file from had been created on 13 July 2015, the output of the imageinfo command said that the file had been created on 13 Sept 2015.  I then hashed both hiberfil.sys files and got the exact same hash.

As such, using this method it appears that the hibernation file is not "tracked" or affected by the Volume Shadow Service; that is, you don't get previous versions of the file.

Addendum: After publishing this post, David Cowen pointed me to this MSDN page that discusses files excluded from VSCs.  Checking the Registry key HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup on my analysis system, I see that the hibernation file is listed (as is the pagefile).

Addendum, 29 Dec: I had a chance recently to work with another Windows 7 image file, and found that it contained two difference files.  I then used Arsenal Image Mounter to mount the image read-only, and was able to enumerate VSCs using vssadmin.

If you perform your own testing and find something different, I'd greatly appreciate knowing the process and tools you used.

Other Take-Aways
The research, testing, and most importantly, interaction with other analysts really demonstrates that there a number of methods available for accessing historical information on Windows systems that do not require dongles, and do not require the purchase of commercial applications.  Also, you don't need to know Linux, or how to install and compile libraries.  Using native Windows tools, you can access the contents of a VSC as you would any other folder, but with a couple of freely available tools, you can get even deeper access, to the point of accessing the $MFT within the shadow volume.

During my initial analysis (prior to the testing outlined here), I extracted a couple of specific files from the VSC and created a mini-timeline in order to add context to my original timeline, and develop a clearer picture.  And it all took just a couple of minutes.

And it doesn't end there.  David Cowen's been producing a series of blog posts on automating DFIR work, and he has a blog post that walks you through accessing VSCs within an acquired image programmatically, via Python.  The final Python script that David makes available essentially accesses each VSC, searches across it for specific files, and collects information about those files.

Resources
VhdxTool - possible replacement to vhdtool (Note: I have not tried this tool)

New RR Plugin: Identities.pl

This past week, I read an interesting FireEye blog post that discussed malware that targets the volume boot record.  As I read through the post, I got to step 4 ("Component Installation") for the malware, and the Registry values listed caught my eye.  I know...go figure, right?

The blog post states that a number of values are created within a specific hive file, and that these values refer to the various components of the malware itself.  As such, I looked at these values as a great way to determine if a system was infected, through either digital forensic analysis, or even active hunting within the enterprise.

The key path for the values listed in the blog post is "HKCU\.Default".  Hhhmmm...okay, so...where is that hive on the system?  As you can see in the figure to the right, taken via RegEdit on my Windows 10 system, the path should be listed as "HKU", which stands for "HKEY_USERS", rather than "HKCU", which stands for "HKEY_CURRENT_USER" (which would be me).  Regardless, we see the ".Default" key in the figure.  This MSDN blog post lets us know that it's not what we think...no, not at all. That is, this key is not for the "Default User", from which the new user profiles are created, but instead for the Local System account.

The RegRipper profilelist.pl plugin will show us the paths to the NTUSER.DAT hives for various accounts on the system, including not only the users but the other SIDs, as well:

Path      : %systemroot%\system32\config\systemprofile
SID       : S-1-5-18
LastWrite : Tue Jul 14 04:53:25 2009 (UTC)

Path      : C:\Windows\ServiceProfiles\LocalService
SID       : S-1-5-19
LastWrite : Thu Dec 30 20:51:42 2010 (UTC)

Path      : C:\Windows\ServiceProfiles\NetworkService
SID       : S-1-5-20
LastWrite : Thu Dec 30 20:51:42 2010 (UTC)

As such, you can extract the NTUSER.DAT file from any of these profiles, and run the identities.pl plugin (uploaded to the GitHub repository today) against it.

Addendum, 13 Dec: I added a plugin to the repository this morning called latentbot.pl that parses the persistence location for LatentBot (as reported by FireEye), and attempts to determine the plugins, as well.  YMMV...extremely limited test suite.

WRF 2/e

As 2015 draws to a close, so does my work on "Windows Registry Forensics, 2/e".  My schedule has the manuscript completed just before the end of the year, and from what I've seen, the book itself is supposed to be available in April, 2016.  As it is, I got the final material in to the publisher yesterday, three weeks ahead of schedule.

Note: The OFFICIAL (re: ONLY) location of RegRipper is the GitHub repository.  Do not send me emails about the Google Code site, or about the Wordpress page. Please stop referring to the Wordpress site, and please stop referring others (i.e., your students) to the site.

Goals
What I hoped to do with this edition is spend much less time focused on the basics of the Registry (where the files are located) and how to extract data from the Registry, and spend more time on data interpretation.  I retained the basic material, as I think it's important to have that foundation before proceeding, but in chapters 3 and 4, I wanted to spend more real estate talking about how the available data needs to be interpreted correctly.

What it is
The second edition is a significant (albeit not complete) rewrite of the first edition.  Some of the material remains the same because quite frankly, it doesn't change.  There's some new stuff in there (new keys/values, AmCache.hve, etc.), and some stuff has been updated.

There is some discussion that includes new versions of Windows, and there are examples specific to Windows 8, 8.1, and 10.

In this edition, I separated various Registry artifacts by category, in hopes that it would be easier to follow, or visualize.  We'll see...

Throughout the book, as with my other books, I've used examples of how Registry analysis has had a significant impact on the analysis I've done.  Unfortunately, most of the stories are from analysis I've done.  Prior to starting the book, I held an online contest to see if folks from the community would be willing to send in little stories and vignettes about how Registry analysis had impacted their analysis; I offered a free copy of the book, once it was published, for any and all submissions that appeared in the book.  I got one submission.

There is more content in this book that discusses using RegRipper.  In fact, there's an entire chapter just on RegRipper.

There is discussion of "new" plugins that I've written and added to the GitHub repository.  In fact, here's a blog post that describes a couple of the ones I wrote and added to the repository; these plugins are meant to be run intentionally, and I did not add them to any of the profiles.

Speaking of new plugins, I'd like to ask that if you have a question about RegRipper, please do not post it to a forum first...because doing that makes it likely that you won't get an answer.  Here's an example of a blog post where someone decided that RegRipper didn't do something, and instead of asking about it, just announced it.  If there is something you'd like RegRipper to be capable of, please feel free to reach to me first...most times that results in RegRipper being able to do just that, usually within a few hours.

What it is NOT
This edition is NOT a complete compendium of all possible Registry keys and values that may be of interest to an analyst, in part because...quite simply...I don't know everything.  

I did not address all devices that contain Windows Registry hives, for the simple reason that I could not...I do not have access to Windows phones or other devices that include hives.  I do get those questions (i.e., "What about Registry files from ....?"), so I thought I'd just go ahead and answer them ahead of time.

As for the rest of the questions, like, "...did you cover this?", and "...did you talk about this?", you're SOL and missed your chance to get it included in the book, my friend...sorry.

What's next?
I've been thinking for some time now about a scanner, where I'd be able to point the tool at a mounted image or shadow volume, make a couple of simple choices, and have the tool spit out the data.  I like the idea of basing this on artifact categories and an analysis matrix.

Resources
InfoSecInstitute - Registry Forensics

Links

NTFS Tools
A while back, David and his cohorts released NTFS TriForce, a great tool that allowed you to correlate several NTFS data sources...the MFT, $LogFile, and the USN change journal, using various data elements as "pivot points" to join tables within the database.  The folks over at StrozFriedberg came out with their own version of a similar tool called NTFS-Linker.

Program Execution
Not 'new' (this one is from earlier this year), but Chad recommended that if you're looking for artifacts of program execution, you should consider taking a look at SuperFetch artifacts.  This is another artifact to add to the category, given information such as can be found here.

Registry
The folks over at CodeReversing have an interesting post on "Stealth Techniques: Hiding Files in the Registry".  This is not new...about 15 years ago, I developed a proof of concept tool that downloaded an executable file that had been renamed as a *.gif file, and parsed up the file into discrete sections, putting those sections in the Registry.  The second half of the PoC re-assembled the file in the Recycle Bin and launched the executable.

Don't get me wrong...just because something isn't new doesn't mean that it's not relevant.  I see that in pretty much ever targeted threat response engagement that I'm involved in, either directly or peripherally...the adversary or intruder uses some technique that are really very simple, so much so that it's overlooked; the Sleeper Agent blog post is a great example of that.

RegRipper
Reminder: The OFFICIAL (re: only) location of RegRipper is GitHub.  Do not send me emails about the Google Code site, or about the Wordpress page.

Plugins
I caught something in the archives for one of the mailing lists I access...someone had reached to the list about the auditpol.pl plugin, saying that it wasn't working for them.  Well, I hadn't touched that plugin since I wrote it, and it was intended for Windows XP and 2003 systems, due to the fact that those were the only systems on which I had documentation.

Well, someone responded with a link to a PDF document that illustrates how to parse the audit configuration for Vista+ systems.  I renamed the current plugin to auditpol_xp.pl, and updated the auditpol.pl plugin to work for Windows 7 and 10 systems ONLY, because I don't have data from other systems available for testing.

Again, the new auditpol.pl plugin has only been tested against Windows 7 and Windows 10 systems, and only one Security hive from each platform.  What it does is allow you to see the effective audit policy on the system, or the equivalent of running:

auditpol /get /category:*

Both plugins are in the Github repository; however, again, I do not maintain the RegRipper profiles, so as plugins are added to the repository, I am not updating the profiles to remain current based on the available plugins.

On Sharing
I'm a huge proponent for sharing; sharing information or intel, even just engaging and asking questions.  I recently came across this article on sharing that just sort of reinforced my thoughts on the subject.

Doing Analysis

I had an opportunity to perform some pretty fascinating analysis recently, and I thought some might appreciate it if I were to take a moment and describe what I did, and how I went about the analysis.

Situation
The situation was pretty straight-forward; a system (Win7SP1) had been identified as having been infected with malware at one point.  What had been determined from the initial analysis that had been conducted was that the system have been infected in Sept, 2014.  As it turned out, the malware in question had been deleted by an AV scan around mid-Aug, 2015, and the image had been acquired near the end of Sept, 2015.  Two user profiles had been identified as having been involved in the initial infection.

Goals
The goal of this analysis was pretty simple.  Essentially, the initial analysis work had already been done, and a report had been delivered to the client. My objective for this analysis was to gain greater insight into the infection process, and to see if I could develop threat intelligence from anything else that I found.

Tools
I performed all of my work using free and open-source tools.

• Timeline Tools
• RegRipper
• FTK Imager
• Volatility

I conducted my analysis using Notepad++.

Timeline
I created a timeline of system activity using:

• File system metadata
• Selected Windows Event Logs
• Registry hives (Software, System, Security)
• NTUSER.DAT and USRCLASS.DAT from the two profiles of interest
• User WebCacheV01.DAT IE browser history files

The process I used to create my timeline is pretty much exactly what's listed in Windows Forensic Analysis 4/e, in ch. 7.  The process took only a couple of minutes to put together a timeline and begin analyzing it.  From the time I opened the image in FTK Imager, I had a timeline in less than 30 min. Also, something I really like about it is that the process can be used in such a manner that only those files required are sent to another analyst to construct a timeline.

The system did have Prefetch files but given the time frame, there were no files of interest in the Prefetch folder.

Once I created the timeline, I was able to easily add context to what I was looking at using other tools.  For example, I parsed the user's WebCacheV01.dat files initially using esedbexport.exe, and then using ESEDatabaseView.  An important take-away from this is data interpretation...entries have several time stamps associated with each visited URL, and the incorrect identification and interpretation of those time stamps can significantly impact your findings.  For example, the visited URL has an expiry date time stamp; assuming that this is when the site was last accessed can have a significant (and perhaps detrimental) impact on your overall analysis.

I took a look at IE session recovery files using the Structured Storage Viewer; I got what I needed out of the particular streams of interest, and added notes to my timeline.

Mapping the user's TypedURLs values with the TypedURLsTime values was pretty fascinating, although all it really did was support findings that didn't pertain directly to the malware.  Still...it was pretty cool.

User shellbags proved to be very illuminating, and the UserAssist information added additional context to what I was seeing.  In the case of one user profile, the combination of those two artifacts illustrated intentional, purposeful activity...the user navigated to a specific subfolder, and double-clicked a specific .exe file, launching it.  File system and Registry events following this activity indicated the execution of the application.

Hibernation File
It turned out that the system was a laptop, and had a hibernation file.  I extracted the file, and used Volatility 2.5 to convert it to raw format.  The "imageinfo" command told me that the hibernation file had been created on 13 Sept 2015,  a bit before the image was acquired.  I didn't expect to find anything of value from the memory image, but I ran a couple of commands (pslist, psxview) anyway.  Doing so essentially validated my suspicions, but better to do it than not.  Besides, I wasn't stopping my other analysis...the command prompt where I ran the commands simply went to the background, and I examined the output files when the commands completed.

The previous analysis had indicated that strings/IOCs associated with the malware had been found in the hibernation file.  I used strings.exe, and then the Volatility 'strings' command, and found that those strings were in free space.

Working with VSCs
A quick check of the image indicated that there were volume shadow copies (VSCs) available, which was great.  Most corporate systems I've dealt with for the past couple of years have had VSCs disabled for some reason, and here was one that didn't.  I ran vhdtool.exe to "convert" the image, which essentially added a footer to the file.  As my analysis system is Windows 10, I renamed the file to have the ".vhd" file extension.  I opened the Disk Management utility and attached the newly-created VHD, and used the following command to list the available VSCs:

vssadmin list shadows /for=g:

Interestingly, I basically followed the process laid out in this blog post.  The output of the vssadmin command showed me that there was a VSC that had been created on 13 Jul 2015, which was about a month prior to the malware being detected and quarantined by AV.  I linked the VSC to a folder on my analysis system, and added the contents of the folder to FTK Imager; however, this didn't give me the level of access I wanted, as I wanted to get, among other things, a copy of the $MFT from the VSC.

That's where Jimmy's blog post on mounting shadow volumes can into play.  Using vss.exe, I added the VSC in question to my analysis system as X:\, which appeared as a RAM image.  I then added the logical volume to FTK Imager, and was able to extract the $MFT, as well as other files.   By creating a timeline using files extracted from the VSC, I was able to create a bit more context around the

Conclusion
Creating the timeline in the manner that I did allowed me to get started on my analysis in fairly short order, identify what needed a closer look, and then add context and notes to the timeline.  I didn't have to wait for an automated tool to complete, and then trudge through a lot of data that didn't pertain to what I was trying to determine.  I admit, I had a bit of a leg up because of the initial analysis that had been conducted, but the process I used would have led me to the initial indicators pretty quickly.  Specifically, the use of eventmap.txt in parsing Windows Event Logs allows for a number of event records to be auto-tagged, and then easily searched for in the timeline.  Searching the timeline for the "[MalDetect]" tag would've taken me to the "Symantec Endpoint Protection Client" event ID 51 record that identified what would be my initial pivot point.

As it turns out, there were a number of "Symantec Endpoint Protection Client/51" events in the timeline, so an easy fix to that would have been to do something like this:

type events.txt | find "[MalDetect]" > av_events.txt

The above command runs through the events file and locates all malware detection events, putting them into a separate file.  From there, I could have run:

parse -f av_events.txt > av_tln.txt

This would give me a nano-timeline of just AV detection events, giving me a much smaller set of data to analyze, and on which I could pivot.  This would also pick up all malware detection events, for any such events mapped in the eventmap.txt file.

Accessing the shadow volume allowed me to collect copies of files that were not otherwise accessible, as well as get a look at the state of the system prior to the malware being removed.  In this case, the malware employed two persistence mechanisms, which meant that two copies of the malware existed on the system.  My initial timeline provided an indication of this, as immediately prior to the AV writing it's detection and quarantine message to the Windows Event Log, there were changes to two locations within the file system, and to one Registry key.  Accessing the shadow volume from a time when the malware existed on the system allowed me to confirm what I had suspected.  It only took a few minutes, and to be honest, it was worth time to close the loop on the speculation.

I should note that I exported the hibernation file from the shadow volume, but once I converted it to raw format, the "imageinfo" command showed me that it had the same "image date and time" as the one from the image.  Running "pslist" and "psxview" gave me the exact same information as running those commands on the original hibernation file.  I need to look into this more, but it seems that the hibernation file is not tracked in shadow volumes, although the $MFT is.

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.