Looking at Abused File Extensions

This is my first new post using Medium as a content platform; I’m trying to get away from hosting my own blog, and I like Medium a lot. Please provide any feedback via Twitter or email if you have any thoughts on me using this platform.

This evening, I wanted to take a few minutes and discuss abused file extensions. There’s two main reasons behind this:

  1. This shit is working, it’s causing some very good people a lot of unnecessary grief, and we could all use a hand. This post was a long time coming, but I’ll say with certainty this weekend is the straw that went all Bane on the camel’s back.
  2. A recent tweet from @da_667:

Tony’s tweet on this issue was in response to a successful ransomware infection that spawned out of an unknowing user executing a WSF file. I’m going to do my best not to repeat his tweets, and those from others, but instead offer my own insight.

What Extensions Are You Talking About?

Short answer: Go look here. Howtogeek provides a great list of file extensions to be concerned about, and I won’t spend time repeating them all. If you’re a blue teamer, that entire list of files needs to be on your radar. Hopefully most of them already are.

If you’re a red teamer, most of them probably already are. More on this later.

Why This is a Problem

Attackers know that most organizations aren’t handling a majority of these types of files. As if right on cue, look at this recent post from Kaspersky Lab:

Fabio Assolini’s post on a Brasilian banking Trojan dropped via PIF files

A banking Trojan initially dropped by a malicious PIF file. The malware goes on to utilize Powershell, however the initial vector is what I find interesting. If you aren’t aware of PIF files, here’s why they should scare the shit out of you (and be #1 on your next GPO): The PIF format does not have the magic MZ header, but is still handled the same way EXEs are handled. WTF.

If you think it stops at PIFs, don’t worry: there’s more. Look at a recent WSF success story (albeit, short-lived success):

Look at this freakin’ code! This is a mess:

Snippet of the malicious WSF file posted by InfoSec Taylor Swift at http://pastebin.com/XfKS8zaA.

Detection mechanisms can be tough to write for files like that.

Yet another example: Look at @HackingDave talk about HTA file success rates at this year’s NolaCon:

Dave Kennedy at NolaCon 2016. Skip to 26:58 to get right to HTA use.

Dave claims mid-90% success rate, and rightfully so. If PIFs didn’t scare you, HTA’s will. HTAs, or HTML Applications, are run by mshta.exe (read: outside of the browser), and are not constrained by browser sandboxing. Summary: They run as trusted applications, signed by Microsoft itself.

Why We Should Care

I think there’s a few reasons to care about these file types:

  1. Again, this shit is working. Red teamers, malware authors, ransomware, banking Trojans, you name it. They are abusing the fact that many organizations don’t have their hands around these files.
  2. Your users are not going to become aware of these file types. Infosec teams can preach all they want about Office Macros; attackers will just start using another file type. Preach about WSFs, attackers will switch again. Ever wonder why some attack vectors are way more popular than others? Because they work, but don’t get fooled. The $top_5_entry_vectors are not the extent of the arsenal.
  3. A lot of these problems you can solve yourself. There are some who will go on and go about phishing training and claim that if you train your users, these files will never run. Good luck with that initiative; call me to do your incident response. I’d prefer a technology approach. Why? Yes, it can be evaded. But your goal is to make a best effort to stop as much as you feasibly can.

Look at InfoSec Taylor Swift’s response to the malware:

Pushing Group Policy to reroute file extensions to open in something innocuous is a method blue teams should consider. Two reasons: First, it will help stop some scripts from running automatically. Second, it will popup a notepad screen with some funky text inside that the user will most likely not recognize. This can be a good place to say “if you see this, call Security”.

Many other file types can simply be prevented from execution. Sometimes Microsoft updates can re-associate file extensions, so other options must be considered. Take a look at using the registry to restrict certain file extensions to only certain groups of users. Limit scripts to the accounts who will need them. Of course, this will rest on the domain being setup appropriately, but can help prevent users from running some malicious scripts because they are interested in tracking their unexpected package.

Whatever your prevention/detection strategy may be, one important takeaway is that many defense teams can implement some measures using the tools they already have on hand. Use Windows’ inherent features to help you defend.

One Final Thought

When someone publicly announces a gap in security that was subsequently exploited, I find there are two ways to respond:

  1. Flame the person, pretend you’re the living answer to all of Earth’s problems, bitch about the current state of ${whatever}, or,
  2. Provide data points to help that person and other people in the same situation. Even if the original poster doesn’t need help, these types of problems are not unique. Someone, somewhere, will always benefit from your knowledge.

I’m happy to say this post, and those that inspired it, fall within the latter. Thank you.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.