Tuesday, September 26, 2017


It's been some time since I've had an opportunity to talk about NTFS alternate data streams (ADS), but the folks at Red Canary recently published an article where ADSs take center stage.  NTFS alternate data streams go back a long way, all the way to the first versions of NTFS, and were a 'feature' included to support resource forks in the HFS file system.  I'm sure that will all of the other possible artifacts on Windows systems today, ADSs are not something that is talked about at great length, but it is interesting how applications on Windows systems make use of ADSs.  What this means to examiners is that they really need to understand the context of those ADSs...for example, what happens if you find an ADS named "ZoneIdentifier" attached to an MS Word document or to a PNG file, and it is much larger than 26 bytes?

Some thoughts on Equifax...

According to the Equifax announcement, the breach was discovered on 29 July 2017.  Having performed incident response activities for close to 20 years, it's no surprise to me at all that it took until 7 Sept for the announcement to be made.  Seriously.  This stuff takes time to work out.  Something that does concern me is the following statement:

The company has found no evidence of unauthorized activity on Equifax's core consumer or commercial credit reporting databases.

Like I said, I've been responding to incidents for some time, and I've used that very same language when reporting findings to clients.  However, most often that's followed by a statement along the lines of, "...due to a lack of instrumentation and visibility."  And that's the troubling part of this incident to me...here's an organization that collects vast amounts of extremely sensitive data in one place, and they have a breach that went undetected for 3 months.

Unfortunately, I'm afraid that this incident won't serve as an object lesson to other organizations, simply because of the breaches we've seen over the past couple of years...and more importantly, just the past couple of months...that similarly haven't served that purpose.  For a while now, I've used the analogy of a boxing ring, with a line of guys mounting the stairs one at a time to step into the ring.  As you're standing in line, you see that these guys are all getting into the ring, and they apparently have no conditioning or training, nor have they practiced...and each one that steps into the ring gets pounded by the professional opponent.  And yet, even seeing this, no one thinks about defending themselves, through conditioning, training, or practice, to survive beyond the first punch.  You can see it happening in front of you, with 10 or 20 guys in line ahead of you, and yet no one does anything but stand there in the line with their arms at their sides, apparently oblivious to their fate.

Threat Intelligence
Sergio/@cnoanalysis recently tweeted something that struck me as profound...that threat intelligence needs to be treated as a consumer product.

He's right...take this bit of threat intelligence, for example.  This is solely an example, and not at all intended to say that anyone's doing anything wrong, but it is a good example of what Sergio was referring to in his short but elegant tweet.  While some valuable and useful/usable threat intelligence can be extracted from the article, as is the case with articles from other organizations that are shared as "threat intelligence", this comes across more as a research project than a consumer product.  After all, how does someone who owns and manages an IT infrastructure make use of the information in the various figures?  How do illustrations of assembly language code help someone determine if this group has compromised their network?

Web Shells
Bart Blaze created a nice repository of PHP backdoors, which also includes links to other web shell resources.  This is a great resource for DFIR folks who have encountered such things.

Be sure to update your Yara rules!

Sharing is Caring
Speaking of Yara rules, the folks at NViso posted a Yara rule for detecting CCleaner 5.33, which is the version of the popular anti-forensics tool that was compromised to include a backdoor.

Going a step beyond the Yara rule, the folks at Talos indicate in their analysis of the compromised CCleaner that the malware payload is maintained in the Registry, in the path:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\WbemPerf\001 - 004

Unfortunately, the Talos write-up doesn't specify if 001 is a key or value...yes, I know that for many this seems pedantic, but it makes a difference.  A pretty big difference.  With respect to automated tools for live examination of systems (Powershell, etc.), as well as post-mortem examinations (RegRipper, etc.), the differences in coding the applications to look for a key vs. a value could mean the difference between detection and not.

The Carbon Black folks had a couple of interesting blog posts on the topic of ransomware recently, one about earning quick money,  and the other about predictions regarding the evolution of ransomware.  From the second Cb post, prediction #3 was interesting to me, in part because this is a question I saw clients ask starting in 2016.  More recently, just a couple of months ago, I was on a client call set up by corporate counsel, when one of the IT staff interrupted the kick off of the call and wanted to know if sensitive data had been exfiltrated; rather than seeing this as a disruption of the call, this illustrated to me the paramount concern behind the question.  However, the simple fact is that even in 2017, organizations that are hit with these breaches (evidently some regulatory bodies are considering a ransomware infection to be a "breach") are neither prepared for a ransomware infection, nor are they instrumented to answer the question themselves. 

I suspect that a great many organizations are relying on their consulting staffs to tell them if the variant of ransomware has demonstrated an ability to exfiltrate data during testing, but that assumption is fraught with issues, as well.  For example, to assume that someone else has seen and tested that variant of ransomware, particularly when you're (as the "victim") are unable to provide a copy of the ransomware executable.  Further, what if the testing environment did not include any data or files that the variant would have wanted to, or was programmed to, exfil from the environment?

Looking at the Cb predictions, I'm not concerned with tracking them to see if they come true or not...my concern is, how will I, as an incident responder, address questions from clients who are not at all instrumented to detect the predicted evolution of ransomware?

On the subject of ransomware, Kaspersky identified a variant dubbed "nRansom", named as such because instead of demanding bitcoin, the bad guys demand nude photographs of the victim.

Attack of the Features
It turns out the MS Word has another feature that the bad guys have found and exploited, once again leaving the good folk using the application to catch up.

From the blog post:
The experts highlighted that there is no description for Microsoft Office documentation provides basically no description of the INCLUDEPICTURE field.



Matt Martin said...

"CCleaner 5.33, which is the version of the popular anti-forensics tool" Do people actually look at CCleaner as an ati-forensc tool? That surprises me. Thanks for the blog!

Harlan Carvey said...


Yes, quite a bit, actually. See...