I recently posted a little something on IOCs, and I wanted to take a moment to extend that, along the vein of what I was discussing, particularly the part where I said, "Engage with those with adjacent skill sets".  I think that this is a particularly important undertaking, particularly when we're talking about IOCs, because we can get better, more valuable IOCs when we engage with those with adjacent skill sets, and understand what their needs are.  This true for responders, DF analysts, malware analysts, and we can even include pen testers, as well.

First, a word on specialization.  Many of us in the infosec world recognize the need and importance of understanding a general body of knowledge, but at the same time, many of us also gravitate toward a particular specialization, such as digital forensic analysis of mobile devices or Windows systems, web app assessments/pen testing, etc.  Very often, we find this specialization to be extremely beneficial to us, not only in what we do, but in our careers, and often our hobbies, as well.  What happens when we try to do too much...say, IR, DF, and pen testing?  Well, we really don't become an expert at anything in particular, do we?  Several years ago, I sat on a panel at the SANS Forensic Summit, and the question was asked about who you'd want to show up to respond to an incident...my answer was someone who responded to incidents, not someone who was doing a pen test last week, and pulling cable the week before that.  Think about it...who do you want doing your brain surgery?  A trained, experienced neurosurgeon, or someone who, up until 6 months ago, was driving trucks?  My point is that due to how complex systems have become, who can really be an expert in everything? 

Okay, so to tie that together, while it's good to specialize in something, it's also a really good idea to engage with those with other, ancillary, adjacent specializations.  For example, as a digital forensic analyst, I've had some really outstanding successes when I've worked closely with an expert malware analyst (you know who you are, Sean!!).  By working together with the malware analyst, and providing what they need to do their job better (i.e., context, specific information such as paths, etc.), and getting detailed information back from them, we were able to develop a great deal more (and more valuable) information for our customer, in less time, than if we'd each worked separately on the case, and even more so than if we'd worked solo, without the benefit of the other's skills.

Part of that success had to do with sharing IOCs between us.  Well, we started by sharing the specific indicators associated with what was found...I had not found the indication of the infection until running the fourth AV scanner (a relatively obscure free AV scanner named 'a-squared').  From there, I referred to my timeline, and was able to determine why there seemed to be no Registry-based auto-start mechanisms for the malware.  From there, I provided the information I had available to the malware analyst, including information about the target platform, where the malware was found, a copy of the malware itself, etc.  After disabling WFP on his the analysis system, the malware guy got the infected files up and running, and pulled information out of memory that I was then able to use to further my analysis within the acquired image (i.e., domain name, etc.).  Using this information, I targeted specific artifacts...for example, the malware analysts shared that once the malware DLL was in memory, it was no longer obfuscated, so he was able to parse out the PE headers of the file, including the import table.  As the malware DLL imported functions from the WinInet API, it was reasonable to assume (and was verified through analysis) that the malware DLL itself was capable of off-system communications.  This made it clear not only that additional malware was not required, but also told us exactly where we should be looking for artifacts.  As such, in my analysis of the acquired image, I focused on the IE history for the user in question and the pagefile.  I ran strings across the pagefile, looking for indications of the domain name we had, and then wrote a Perl script that would go into the pagefile at that offset for each hit of interest, and grab 100 bytes on either side of the hit.  What we ended up getting was several web server responses to the malware's HTTP off-system communications, which included time stamps from the web server, as well as server directives telling the client to not cache anything.

Now, each of us focusing on our specialized areas of analysis, but treating each other like "customers", worked extremely well.  We each had a wealth of information available to us and worked closely to determine was the other needed, and what was most valuable.

Addendum: While driving home from work in traffic today, I thought of something that might reveal a bit more about this exchange...

At the early stage of my analysis, I had an acquired image from a system, from which I'd created a timeline, and against which I had run four AV scans.  The result of the last scan was where one file was identified as "malicious".  Looking at that file within in the image, via FTK Imager, I could see that the file was obfuscated (by the contents of the import table), although I didn't know how it was obfuscated (packed, encrypted, both, etc.).  And I only had the acquired image...I didn't have a memory dump.  So before I sent it to the malware guy, I had to figure out how this thing was launched...after all, I couldn't just send him the file and ask him, "what can you tell me about this file?", because his answer would be "not much", or not much that I couldn't already figure out for myself (MD5, strings, etc.).

So, I developed some context around the file, by figuring out how it had been launched on the system...which turned out to be that a regular system DLL had been modified to load the malicious DLL.  Ah, there's the context!  So I could send both files to the malware guy.  When I did, it turned out that the regular system DLL on the malware guy's analysis system was 'protected' by Windows File Protection (WFP), so he couldn't just copy the two files onto the system and reboot to get everything to work.  So I told him which Registry key to use to just disable WFP for the installation process, and everything worked.

I should point out that many of the EXE samples of malware are run through dynamic analysis by the analyst copying the EXE to the desktop and double-clicking it.  However, this was a DLL, so that wouldn't work.  Using rundll32.exe might not work, either...figuring out any needed arguments would just take up a lot of time.  So, by putting in a few more minutes (because that's all it really amounted to) of analysis, I was able to provide the malware guy with enough information to get the malware sample up and running on the test system.

Once the malware guy got things going on his end, he was able to provide me with information about Registry keys accessed by the malware (in this case, none), as well as more details regarding off-system communications.  Because he saw HTTP traffic leaving the test system, this gave us some information as to where to look with respect to how it was doing this, which was confirmed by checking the import table of the DLL once it had been loaded into memory.  The malware guy provided me with this information, which told me pretty much where to look for artifacts of the off-system communications.

Yes, 'strings' run against the now un-obfuscated DLL would have provided some information, but by parsing the import table, that information now had the benefit of additional context, which was further added to through the use of more detailed analysis of the malware.  For example, the data stolen by the malware was never written to disk...once it was captured in memory, it was sent off the system via the HTTP communications.  This was extremely valuable information, as it really narrowed down where we should expect to find artifacts of the data collected/collection process.

The point of all this is that rather than providing simply what was easiest, by collecting additional data/context about particular artifacts, we can provide useful information to someone else, which in turn increases the quality of the information (or intelligence) that we receive in turn, and very often, in a much quicker, more timely manner.  In short, I help you to help me...

Now, back to our regularly scheduled program, already in progress...

Okay...so what?  Consider this recent blog post...while it is very cool that 7Zip can be used to export the various sections of a PE file into different files, and you can then run 'strings' on those exported sections, one would think that parsing the PE headers would also be beneficial, and provide a modicum of context to the strings extracted from the .text section.  Why does that matter?  Well, consider this post...from my perspective as a host-based analyst, knowing that the string 'ClearEventLog' was found in the import table versus in the code section makes a huge difference in how I view and value that artifact.

Consider an email address that you found somewhere in an acquired image...wouldn't the relative value of that artifact depend on the context, such as whether or not the email address was associated with emails or not?  And if the address were found to be in an email, wouldn't it's context...whether it was found in the To or From block, or within the body of the email...potentially have a significant impact on your exam?

My point is that sometimes what we may find to be interesting from our perspective may not be entirely useful to someone else, particularly someone with an adjacent skill set.  Other times, something that we think is completely and totally trivial and not interesting at all may be enormously useful to someone else.  A malware analyst may not find that a particular bit of malware that uses the Run key as a persistence mechanism as very interesting, but as a Windows analyst, that piece of information is extremely valuable to me, not only with respect to that particular sample, but also when correlated with other samples, as well as other threats.

So, some thoughts regarding IOCs:
1.  Specific, targeted IOCs only really work well for specific samples of malware or specific incidents.  By themselves, they may have very limited value.  However, when combined/aggregated with other IOCs, they have much greater overall value, in that they will show trends from which more general IOCs can be derived.

2.  You don't always have to create a new IOC...sometimes, updating one you already have works much better.  Rather than having an IOC that looks for a specific file in a specific directory path (i.e., C:\Windows\ntshrui.dll), why not look for all files of a particular type in that directory, and potentially whitelist the good ones?

3.  Working together with analysts with adjacent skill sets, and understanding what artifacts or indicators are valuable to them, produces better overall IOCs.  A malware analyst may find an MD5 hash to be useful, but a DF analyst may find that the full path to the file itself, as well as PE headers from the file, are more useful.  An malware analyst may find the output of 'strings' to be useful, but a DF analyst may need some sort of context around or associated with those strings.

4.  No man, or analyst, is an island.  As smart as each of may be, we're not as smart as several of us working together.  Tired of the cliche's?  Good.  Working with other specialists...malware and memory analysts, host-based DF folks, network analysis folks...is a much better solution and produces a much better overall result than one guy trying to do it all himself.

Not long ago, I read Greg's blog post on using HBGary's DDNA to detect APT attackers in memory, and ran across an interesting statement near the end of the post, specifically, the first paragraph in the Using IOC’s effectively subsection (it's kind of long so I won't copy/paste it here...though I highly recommend that you take a look).  I have to say, I agree with Greg's statements...IOCs can be effective tools, but like any tool, they are only as effective as how they are used.  I think that IOCs have great potential in data reduction and providing an automated facility for removing the "low-hanging fruit" from analysis, thereby leaving the analyst to...you know...analyze.  But like Greg says, if your IOCs are just lists of file names and MD5 hashes, then they really aren't all that effective.

Back when I was performing PCI forensic exams, one of the most frustrating things was the lists of "IOCs" we got from one of the major card brands; we'd get these lists of mostly file names and MD5 hashes, two of the most mutable aspects of IOCs, and we were told that we had to include these ever-expanding lists in searches across all acquired images.  Okay, so let's say we found bp0.exe during an exam, but the hash was different from the one provided in the issued list...we noted that and sent it back in, and then the next list we saw would have the new hash added to it.  However, the lack of sharing any real intel was frustrating, as having a more comprehensive intel model would have allowed all analyst firms to move beyond the relatively simple, "yes, you were compromised" and more toward, "this is how you were compromised, this is your window of compromise, and this is what you can do to prevent it in the future."  For example, we'd get file names, but in most cases, not paths.  We'd get MD5 hashes, but not fuzzy hashes, and Chris Pogue would push for fuzzy hashes.  In most cases, we wouldn't even get things like Registry artifacts that would let us see when something had been installed and run, but then deleted.

So, per Greg's statements, one way to make IOCs more effective is to create them so that they're not just a simple blacklist.  Rather than looking for a specific Registry value used for persistence (because file names and Registry value names can be random and change...), have the IOC either dump all of the values in the key for manual review, or correlate multiple keys and values in order to narrow the focus a bit.  Again referring back to past PCI engagements, when looking for credit card numbers (CCNs) within an image, we had three checks...length, BIN, and Luhn check...that we would use, but we got a lot of false positives (such as MS GUIDs).  However, adding additional checks for track 1 and 2 data not only narrowed down our criteria, but increased our confidence that what we'd found was actual useful data and NOT false positives.  So, as Greg suggests, looking for more general things, or adding additional items to your IOCs, can be very effective.

The effectiveness of IOCs is increased though open source intel sharing, by having someone who discovers something develop an effective (and well-documented) IOC and sharing with their team.  These IOCs can be even more effective if they're shared openly (even if it's within a relatively closed community), because then they're not only subject to a more open review, but they can also be expanded further.

The effectiveness of IOCs is obviated and completely lost when the folks using IOCs do nothing but consume them; that is, download the latest IOCs and run them without any review or understanding.  Tools that use a plugin-based approach (Nessus comes to mind...) are only as effective as the effort put into the plugins, and what's actually reported.  A recent InformationWeek article describes eight lessons learned from the recent Nortel revelation...number 6 is "conduct a thorough forensic analysis".  If you suspect that you have something untoward going on in your infrastructure, and you run a list of IOCs and don't get anything definitive...maybe it's time to break out the toolkit and take things a step further.  You may find something entirely new...or you may simply get peace of mind.

Let's take a look at a couple of tandem blog posts that addressed some malware analysis recently.  I caught wind of this on Twitter...we all know how difficult it is to share anything on Twitter, because you have squeeze things down into 140 characters, or make multiple, abbreviated posts...and a lot gets lost that way.  First, we have Keith's post on the Digital4rensics blog, and then there's the Digitalsec4u post on the New Age Security blog.  Both address different components of the analysis of something that hit an infrastructure and was shared, in order to complete some analysis.  You have to look at both of these blog posts together to pull out the IOCs; read the Digitalsec4u post first to see what hit the infrastructure, and what it "looked like" when it came in, and get the Initial Infection Vector.  Then read Keith's post to begin getting a view of what happened once the original bit of malware was executed.

Now, I know from some perspectives, neither the malware that was analyzed nor the actual results are particularly "earth shattering", particularly from the perspective of these two gents who very graciously shared their analysis.  However, there is considerable value in the data that has been posted and shared.  For example, this malware came in as an email attachment, disguised to look like a plane ticket.  We can see hashes on the original payload, and we know that these artifacts are easily mutable.  We can also see that the malware is packed...that's something we can latch on to (IOC: search email attachment directories for packed executables).  Moving over to Keith's post, we begin to see what happens when the original malware is executed.  We can use this information to see if our IR (and DF) processes are sufficient to deal with this type of issue; assume that it wasn't detected and blocked by your in-place security mechanisms, how would you go about responding to this?  Or, better yet, if part of it was blocked, would your current response and analysis process be suitable to determine that the follow-on stages hadn't actually executed?  This is an extremely important question, and one that not a lot of responders and analysts have been trained to consider, or answer.

Some lessons from the two blog posts:
Engage with those with adjacent skill sets; the above two blog posts are great examples of malware analysts doing their thing, but there are a number of artifacts and other bits of information that would be extremely useful for responders and analysts.  Keith's blog has some request URLs that network analysts can search for in proxy and firewall logs, but there's a question as to how these requests are made - does the malware use the WinInet APIs?  If so, we would expect to see other artifacts on the system, wouldn't we?  So, it's not unusual for an analyst to highlight or share what makes sense to them, but they have the information right there in front of them that would be useful to someone else, perhaps someone with an adjacent skill set (responder, DF analyst, network analyst, etc.), so sharing that other information with them would reduce the amount of time looking for these things.

When sharing that information, specificity of language is important.  Does the malware create a Registry key...or does it add a value to an existing key?  If it adds a value to the Run key...which one?  The same is true for file and directory paths, as well as identifying the platform you're infecting during your analysis.

In short, being clear and concise in presenting your findings makes it much easier for someone to not only replicate your findings (taking variations in platform...WinXP vs Win7...into account), but to also use that information in an immediate response mode, and begin seeing if their systems are infected.

Okay, so why are these lessons important?  There's a bit more to this than was mentioned in the blog posts; Keith mentioned that one of the bits of malware was identified by Microsoft (via VirusTotal) as PWS:Win32/Sypak.A...which is not just a password stealer, but it's a keystroke logger.  This means that it just doesn't capture passwords...it can potentially capture everything, and this can be extremely detrimental to an organization.

DFIROnline Meetup
If you're interested purely in numbers, last night's DFIROnline meetup had, at one point, 97 attendees.  It might've helped that my presentation was addressing malware, and we ended up continuing Cory Altheide's drinking game from last year's OSDFC...every time I mispronounced the word as "mall wear", everyone had to take a drink.  I have to go back and review the tape, but my presentation may have ended up being more like a Ron White concert.  ;-)

My previous blog post includes a link to the slides I used, as well as the malware detection checklist that I mentioned in my presentation. 

There's an excellent write-up at the Digital Forensic Source blog regarding last night's meetup, if you're interested, and you can also search for the "#DFIROnline" hash tag on Twitter to see what comments folks made during the meetup.  I have to say, however, that most of the comments were made online, in chat window 3...

Again, a huge thanks to Mike for setting these up and making the resources available, and thanks to everyone who takes the time out of their evening (or day, depending on where you are) to attend and engage. 

Malware IOCs - Ramnit
Here's an excellent walk-through of creating an IOC for the Ramnit malware.  If you're interested in the OpenIOCs at all, or just want to see how someone would go about creating an IOC, take a look at the post...and be sure to read the first two parts, as well.

If you were on last night's DFIROnline presentation on malware detection within an acquired image, what would the malware characteristics be for Ramnit, based on the IOC?

Timelines
If you like case studies and discussions of practical analysis techniques, take a look at Rob's post on Digital Forensic SIFTing.  Rob provides some very good walk-thrus regarding how to use log2timeline effectively on several incident types, and this is well worth a look.

Tools
A bit ago I ran across something Yogesh had written on parsing IE RecoveryStore files.  As these files are based on the OLE format, and I've recently had some experience writing parsers for files that use this format (Jump Lists, StickyNotes), I thought I'd take a crack at this file, as well.  This is still something I'd like to do...I'm hoping Yogesh will release the specifics of parsing the various streams soon.

Along those lines, John Moan recently commented on a blog post and mentioned that he's written two tools, ParseRS and RipRS.  I haven't had a case yet that involves recovering information about a user's browser activity, but the approach he's taken is very interesting, and I'm sure that John would greatly appreciate it if folks would try the tools out and provide him with some valuable feedback.  I've added the tools to my FOSS Tools page, keeping them persistent in one place.

Case Studies
Speaking of case studies, this is one of the items of interest within the community.  I've known about it for a while...in fact, I've tried to write my books to include case studies, and I also tend to look for similar approaches in other books.  Writing about a tool or technique is dry enough as it is, and the way to engage the reader (using the vehicle of the written word) is to include a case study that describes how the tool or technique was used.

On a number of forums, I see requests for case studies.  Not long ago, a thread was started in a forum that included a request that analysts post case studies; this is nothing new, I've seen it before.  What I haven't seen is those folks then posting case studies themselves.  Now, there are a number of what could be considered case studies online.  In fact, if you go to the FOSS Tools page off of my blog, and scroll down to the "Sample Images" section, you'll see links to several sample images that you can download...several of them have actual scenarios associated with them, as well as solutions.  These can serve as some pretty good case studies.