Interesting Links, and Some Thoughts

Often we run across interesting posts or articles on the Internet, and this leads us to other sites that interest us and may often be applicable to the work that we do.  As such, blogging provides better approach to presenting and sharing this information, and the thoughts that are generated, because we not only have the site itself (as with a bookmark), but we can also include why we found it interesting, or some additional, supporting commentary to make the information a bit more useful and relevant.

Registry Artifacts
Andreas Schuster recently stood up a Scoop.It site for DFIR topics, and from that, I found this post at Pragmatic Forensics.  The title of the post is somewhat off with respect to the actual content, but the content itself is interesting.  In short, an analyst created a timeline and ran across an IRL example of the use of the Image File Execution Options Registry key as a persistence mechanism.

This key is addressed starting on page 133 of Windows Registry Forensics, and the RegRipper imagefile.pl plugin.

Along the same lines, I recently read this Cheeky4n6Monkey blog post, which discusses using SIFT tools to perform a diff of Registry hives.  The example provided in the post is excellent, and can be easily translated for use in analyzing hives on a Windows 7 system, particularly when you want to know what changed following a VSC being created, or between VSCs.

Writing
Like many folks, I wasn't a big fan of writing.  I know that's hard to believe...but the fact is that I didn't like to write.  I wasn't good at it, and it was always a chore.  Even when I did put effort into what I was writing, the results were often not what I'd hoped.

Over time, however, I was in positions and situations where I had to write.  While I was in the military, there were JAG Manual investigations, fitreps, awards, log entries, etc.  I had to write during my graduate program.  When I got out of the military, and moved to private industry, I had analysis plans and reports to write.

Perhaps the most succinct description of why we (DFIR analysts) should write is  encapsulated in the 7 Real Ways Writing Increases Expertise blog post.  Take a look at the points mentioned...I think what's really powerful about this is that writing does allow us to clarify our thoughts, and you have to admit, you don't HAVE to hit the Send button until you're satisfied.

Self-Inflicted Artifacts
Over 6 years ago, I wrote a blog post regarding the MUICache key.  At the time, I was wondering why I was seeing a reference to malware creating this key in AV vendor write-ups.

This System Forensics blog post provides an excellent example of self-inflicted artifacts.  The post as a whole is an excellent resource for using Volatility in malware analysis, but very early on in the post, the author mentions a value being added to the MUICache key, as well as UserAssist subkey entries being created.  These are self-inflicted artifacts, and a result of how the malware was executed for testing (i.e., place it on the Desktop, and double-click).

Okay...so why does any of this matter?  I came across the following Registry key:

HKLM\SOFTWARE\Microsoft\RFC1156Agent\CurrentVersion\Parameters

"MiB".  Get it?

According to the timeline I'd created, the key had been modified during a specific time period that was potentially of interest.  When I checked the key, it had a single value named "TrapPollTimeMilliSecs".  I am familiar with SNMP, so I know about traps and MiBs (per RFC1156), but I ran a Google search for the value name, I got a number of hits associated with malware.  In fact, I found one AV write-up that indicated that this was the only artifact associated with the malware.  Ultimately, the analysis did not reveal indications of malware on the system (included scans with multiple AV scanners).

None of the sites I found could provide a clue as to how the value in question is used by malware.  Many of the write-ups I found stated that the value (and it's data) were created by the malware, and my timeline indicated that the key had been modified at a certain time, which could mean that the value was created...or it could mean something else.  And no, I don't have a sample of the malware to analyze.

Overall, I'm beginning to think that the value is a "self-inflicted" artifact, and that the same might be true for some other artifacts that I've observed.

Shoutz to Cory Altheide for using "self-inflicted" in a sentence, and allowing me to bogart the term.

Vulture Research
I was reading this news article recently (yes, I admit it, I'm a closet CSI fan), and it got me to thinking...how often do we, as analysts, misinterpret what we have in front of us?  How often do we draw conclusions based on the data that we have, given the possibility that the data is incomplete?

So...in case you didn't want to read the article I linked to, it's about research that was conducted with respect to scavenger predation of bodies, and how it can affect homicide investigations.  If you watch the crime shows (CSI, NCIS, Bones, etc.), you can probably recount episodes in which a skeleton was found in the open and the conclusion was drawn that the body had been there for months.  Well, this new research indicates that vultures can denude all flesh from a body in a couple of hours...and this can have a significant impact on the assumptions made about the timeline of the crime.

So, this got me to thinking...how often does this happen with what we do?  This "new" research with respect to the vultures is simply something that's been happening for a while, but investigators perhaps haven't considered it.  After all, these birds come down and feed for a few hours, you'd think that there'd be some sort of evidence of this...tracks, feathers, etc.  But what if these artifacts were not noted or simply ignored, or obscured by weather?

Now, consider digital analysis.  Who has received a Windows 7 system to analyze in the past year (or more) and their investigation involved tracking user activity?  When you examined the system, did you include Jump Lists in your analysis?  Registry artifacts?  If you had to track USB devices connected to the system, did you include the EMDMgmt Registry key in that analysis? 

Also, consider Corey Harrell's recent post on Jump Lists; even though he's worked backwards in our usual sequence (starting with a known task first...), he's shown what's possible on systems, and allows other analysts to connect the dots and fill in some gaps.  If you'd looked at a Windows 7 system recently and had to determine authorship of a document, did you consider something along the lines of what Corey pointed out?  Did you collect metadata from the document itself?

How often have we made and reported conclusions based on incomplete analysis, and how often have we used assumptions to fill in the gaps?

One of the ways to overcome this is to use checklists for certain types of data collection, particularly those that are complicated and repetitive.  Notice I don't say "analysis"...that's because data gets collected, and then someone analyzes it; a checklist provides the ability to duplicate the data collection phase, and provides that data for analysis.  The key to this is that a documented process can be updated and modified...you can't evaluate or replicate something that you don't have written down.  Examples of where you might use a checklist include (but are not limited to) USB device analysis, malware detection, authorship of or access to documents, etc.

As  a side note, I've taken some time recently update my malware detection checklist, offline, including some input from some of the recent and excellent malware analysis books that have been published.

Links, Updates, and WhatNot

Malware
Evild3ad has an excellent writeup of the Federal (aka, R2D2) Trojan via memory analysis using Volatility.  The blog post gives a detailed walk-through of the analysis conducted, as well as the findings.  Overall, my three big take-aways:

1.  An excellent example of how to use Volatility to conduct memory analysis.
2.  An excellent example of case notes.
3.  Detailed information that can be used to create a plugin for either RegRipper, or a forensic scanner.

There is also a link to a Rar archive containing the memory image at the site, so you can download it and try running the commands listed in the blog post against the same data.

M-Trends
The Mandiant M-Trends 2011 report is available...I received a copy yesterday and started looking through it.  Very interesting information in the report...as a host-based analysis guy, I found some of the information on persistence mechanisms (starting on pg 11 of the report) to be very interesting.  Some may look at the use of Windows Services and the ubiquitous Run key as passe, but the fact is that these persistence mechanisms work.  After all, when the threat actors compromise an infrastructure, they are not trying to remain hidden from knowledgeable and experienced incident responders.

Interestingly, the report includes a side note that the authors expect to see more DLL Search Order Hijacking used as a persistence mechanism in the future.  I tend to agree with the statement in the report, given that (again, as stated in the report) that this is an effective technique that is difficult to detect.

Another interesting persistence mechanism described in the report was services.exe being modified (without changing the size of the binary) to point to an additional (and malicious) DLL.  This technique has been seen being used with other binaries, including other DLLs. 

A major section (section III) of the report discusses visibility across the enterprise; I think that this is an extremely important issue.  As I've performed incident response over the years, a common factor across most (if not all) of the incidents I've responded to has been a lack of any infrastructure visibility whatsoever.  This has been true not only for initial visibility into what goes on on the network and hosts, but it has also affected response capabilities.  Network- and host-based visibility of some kind needs to be achieved by all organizations, regardless of size, etc.  I mean, think about it...any organization that produces something has some sort of visibility into processes that are critical to the business, right?  A company that manufactures widgets has controls in place to ensure that the widgets are produced correctly, and that they're shipped...right?  I mean, wouldn't someone notice if trucks weren't leaving the loading docks?  So why not have some sort of visibility into the medium where your critical information assets are stored and processed?

Looking at the information provided in the M-Trends report (as well as other reports available from other organizations), I can see the beginning an argument for incident preparation being built up; that is to say that while the report may not specifically highlight this (the M-Trends report mentions the need for "...developing effective threat detection and response capabilities..."), it's clear that the need for incident preparation has existed for some time, and will continue to be an issue.

Addendum: Pg 13 of the M-Trends report mentions some "interesting" persistence mechanisms being used, one of which is "use of COM objects"; however, the rest of the report doesn't provide much of a description of this mechanism.  Well, I ran across this post on the ACROS Security Blog that provides some very good insight into using COM objects for persistence.  Both attacks described are something of a combination of the use of COM objects and the DLL Search Order hijacking, and very interesting.  As such, there needs to be tools, processes, and education of analysts in these techniques so that they can be recognized or at least discovered through analysis.  I would suggest that these techniques have been used for some time...it's simply that most of us may not have known to (or "how to") look for them.

Resources
Verizon DBIR
TrustWave GSR

Incident Preparation
I recently gave a talk on incident preparation at ETCSS, and overall, I think it was well received.  I used a couple of examples to get my point across...boxing, fires in homes...and as the gears have continued to turn, I've thought of another, although it may not be as immediately applicable or understandable for a great many folks out there.

Having been a Marine, and knowing a number of manager- and director-types that come from prior military experience, I thought that the USS Cole would be a great example of incident preparation.  The USS Cole was subject to a bombing attack on 12 October 2000, and there were 56 casualties, 17 of which were fatalities.  The ship was stuck by a bomb amidships, and a massive hole was torn in her side, part of which was below the waterline.  However, the ship did not sink.

By contrast, consider the RMS Titanic.  On 15 April 1912, the Titanic struck an iceberg and shortly thereafter, sank.  According to some sources, a total of six compartments were opened to the sea; however, the design of the Titanic was for the ship to remain afloat with only the first four compartments opened to the sea.  As the weight of the water pulled the ship down, more water was allowed to flood the ship, which quickly led to her sinking.

So, what does this have to do with incident preparation and response?  Both ships were designed with incidents in mind; i.e., it was clear that the designers were aware that incidents, of some kind, would occur.  The USS Cole had some advantages; better design due to a better understanding of threats and risk, a better damage control team, etc.  We can apply this thinking to our current approach to infrastructure design and assessments.

How would the USS Cole have fared had, at the time of the bombing, they not had damage control teams and sailors trained in medical response and ship protection?  What would have happened, do you think, if they'd instead done nothing, and gone searching for someone to call for help?

My point in all this goes right back to my presentation; who is better prepared to respond to an incident - the current IT staff on-site, who live and work in that environment every day, or a consultant who has no idea what your infrastructure looks like?

Determining Quality
Not long ago, I discussed competitive advantage and how it could be achieved, and that got me to thinking...when a deliverable is sent to a customer of DFIR services, how do they (the customer) judge or determine the quality of the work performed?

Over the years, I've had those engagements where a customer says, "this system is infected", but when asked for specifics regarding why they think it was infected, or what led them to think it was infected, most often don't have anything concrete to point to.  I'll go through, perform the work based on a malware detection checklist and very often come up with nothing.  I submit a report detailing my work activity and findings, which leads to my conclusions of "no malware found", and I simply don't hear back.

Consulting is a bit different from the work done in LE circles...many times, the work you do is going to be reviewed by someone.  The prosecution may review it, looking for information that can be used to support their argument, and the defense may review it, possibly to shoot holes in your work.  This doesn't mean that there's any reason to do the work or reporting any differently...it's simply a difference in the environments.

So, how does a customer (of consulting work) determine the quality of the work, particularly when they've just spent considerable money, only to get an answer that contradicts their original supposition?  When they receive a report, how do they know that their money has been well-spent, or that the results are valid?  For example, I use a checklist with a number of steps, but when I provide a report that states that I found no indication of malware on the system, what's the difference between that and another analyst who simply mounted the image as a volume and scanned it with an AV product?

Attacks
If you haven't yet, you should really consider checking out Corey's Linkz about Attacks post, as it provides some very good information regarding how some attacks are conducted.  Corey also provides summaries of some of the information, specifically pointing out artifacts of attacks.  Most of them are Java-based, similar to Corey's exploit artifact posts.

This post dovetails off of a comment that Corey left on one of my posts...

I've seen and hear comments from others about how it's difficult (if not impossible) and time consuming to determine how malware ended up on the system.

Very often, this seems to be the case.  The attack or initial infection vector is not determined, as it is deemed too difficult or time consuming to do so.  There are times when determining the initial infection vector may be extremely difficult, such as when the incident is months old and steps have been taken (either by the attacker or local IT admins) to clean up the indicators of compromise (IoCs).  However, I think that the work Corey has been doing (and providing the results of publicly) will go a long way toward helping analysts narrow down the initial infection vector, particular those who create detailed timelines of system activity.

Consulting
Hal Pomeranz has an excellent series of posts regarding consulting and issues that you're likely to run into and have to address if you go out on your own.  Take a look at part 1, 2, 3, and 4.  Hal's provided a lot of great insight, all of which comes from experience...which is the best teacher!  He also gives you an opportunity to learn from his mistakes, rather than your own...so if you're thinking about going this route, take a look at his posts.

Thoughts and Comments

Exploit Artifacts
There was an interesting blog post on the MMPC site recently, regarding an increase in attacks against the Help and Support Center vulnerability. While the post talks about an increase in attacks through the use of signatures, one thing I'm not seeing is any discussion of the artifacts of the exploit. I'm not talking about a secondary or tertiary download...those can change, and I don't want people to think, "hey, if you're infected with this malware, you were hit with the hcp:// exploit...". Look at it from a compartmentalized perspective...exploit A succeeds and leads to malware B being downloaded onto the system. If malware B can be anything...how do we go about determining the Initial Infection Vector? After all, isn't that what customers ask us? Okay, raise your hand if your typical answer is something like, "...we were unable to determine that...".

I spoke briefly to Troy Larson at the recent SANS Forensic Summit about this, and he expressed some interest in developing some kind of...something...to address this issue. I tend to think that there's a great benefit to this sort of thing, and that a number of folks would benefit from this, including LE.

Awards
The Forensic 4Cast Awards were...uh...awarded during the recent SANS Forensic Summit, and it appears that WFA 2/e received the award for "Best Forensics Book". Thanks to everyone who voted for the book...I greatly appreciate it!

Summit Follow-up
Chris and Richard posted their thoughts on the recent SANS Forensic Summit. In his blog post, Richard said:

I heard Harlan Carvey say something like "we need to provide fewer Lego pieces and more buildings." Correct me if I misheard Harlan. I think his point was this: there is a tendency for speakers, especially technical thought and practice leaders like Harlan, to present material and expect the audience to take the next few logical steps to apply the lessons in practice. It's like "I found this in the registry! Q.E.D." I think as more people become involved in forensics and IR, we forever depart the realm of experts and enter more of a mass-market environment where more hand-holding is required?

Yes, Richard, you heard right...but please indulge me while I explain my thinking here...

In the space of a little more than a month, I attended four events...the TSK/Open Source conference, the FIRST conference, a seminar that I presented, and the SANS Summit. In each of these cases, while someone was speaking (myself included) I noticed a lot of blank stares. In fact, at the Summit, Carole Newell stated at one point during Troy Larson's presentation that she had no idea what he was talking about. I think that we all need to get a bit better at sharing information and making it easier for the right folks to get (understand) what's going on.

First, I don't think for an instant that, from a business perspective, the field of incident responders and analysts is saturated. There will always be more victims (i.e., folks needing help) than there are folks or organizations qualified and able to really assist them.

Second, one of the biggest issues I've seen during my time as a responder is that regardless of how many "experts" speak at conferences or directly to organizations, those organizations that do get hit/compromised are woefully unprepared. Hey, in addition to having smoke alarms, I keep fire extinguishers in specific areas of my house because I see the need to immediate, emergency response. I'm not going to wait for the fire department to arrive, because even with their immediate response, I can do something to contain the damage and losses. My point is that if we can get the folks who are on-site on-board, maybe we'll have fewer intrusions and data breaches that are (a) third-party notification weeks after the fact, and (b) actually have some preserved data available when we (responders) show up.

If we, as "experts", were to do a better job of bringing this stuff home and making it understandable, achievable and useful to others, maybe we'd see the needle move just a little bit in the good guy's favor when it comes to investigating intrusions and targeted malware. I think we'd get better responsiveness from the folks already on-site (the real _first_ responders) and ultimately be able to do a better job of addressing incidents and breaches overall.

Tools
As part of a recent forensic challenge, Wesley McGrew created pcapline.py to help answer the questions of the challenge. Rather than focusing on the tool itself, what I found interesting was that Wesley was faced with a problem/challenge, and chose to create something to help him solve it. And then provide it to others. This is a great example of the I have a problem and created something to solve it...and others might see the same problem as well approach to analysis.

Speaking of tools, Jesse is looking to update md5deep, and has posted some comments about the new design of the tool. More than anything else, I got a lot out of just reading the post and thinking about what he was saying. Admittedly, I haven't had to do much hashing in a while, but when I was doing PCI forensic assessments, this was a requirement. I remember looking at the list and thinking to myself that there had to be a better way to do this stuff...we'd get lists of file names, and lists of hashes...many times, separate lists. "Here, search for this hash..."...but nothing else. No file name, path or size, and no context whatsoever. Why does this matter? Well, there were also time constraints on how long you had before you had to get your report in, so anything that would intelligently speed up the "analysis" without sacrificing accuracy would be helpful.

I also think that Jesse is one of the few real innovators in the community, and has some pretty strong arguments (whether he's aware of it or not) for moving to the new format he mentioned as the default output for md5deep. It's much faster to check the size of the file first...like he says, if the file size is different, you're gonna get a different hash. As disk sizes increase, and our databases of hashes increase, we're going to have to find smart ways to conduct our searches and analysis, and I think that Jesse's got a couple listed right there in his post.

New Attack?
Many times when I've been working an engagement, the customer wants to know if they were specifically targeted...did the intruder specifically target them based on data and/or resources, or was the malware specifically designed for their infrastructure? When you think about it, these are valid concerns. Brian Krebs posted recently on an issue where that's already been determined to be the case...evidently, there's an issue with how Explorer on Windows 7 processes shortcut files, and the malware in question apparently targets specific SCADA systems.

At this point, I don't which is more concerning...that someone knows enough about Seimens systems to write malware for them, or that they know that SCADA systems are now running Windows 7...or both?

When I read about this issue, my first thoughts went back to the Exploit Artifacts section above...what does this "look like" to a forensic examiner?

Hidden Files
Not new at all, but here's a good post from the AggressiveVirusDefense blog that provides a number of techniques that you can use to look for "hidden" files. Sometimes "hidden" really isn't...it's just a matter of perception.

DLL Search Order as a Persistence Mechanism
During the SANS Forensic Summit, Nick Harbour mentioned the use of MS's DLL Search Order as a persistence mechanism. Now he's got a very good post up on the M-unition blog...I won't bother trying to summarize it, as it won't do the post justice. Just check it out. It's an excellent read.