A Little Something on IOCs...

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.