Defense Evasion and Phishing Emails

Our faithful readers are no doubt quite familiar with various threats associated with attachments to emails. After all, we’ve all seen malicious PDFs, Microsoft Office files, binaries, compressed archives, and even the occasional oddity such as a Java archive (JAR), Visual Basic Script (VBS), or JavaScript directly attached to emails. It is even one of the top MITRE ATT&CK Techniques we see:  Spearphishing Attachment.

Many organizations are prepared for these—and have defenses in place to prevent or block such attachments. But what do you do when the adversary anticipates and evades those defenses?  What do you do when they use an ISO disc image file to introduce a malicious binary into your environment?

The fact of the matter is that it is impossible to prepare for every threat vector, but that doesn’t mean you can’t have detection in place (cue prior blog posts about broad detector approaches). Now let’s dive in and get the details on this activity!

I See Your ISO

This threat was interesting primarily because of the way it used an ISO file. As it turns out, the adversary sent out a malicious binary inside of an ISO file, which made it past defenses to reach users. Here we see that ISO file being written to disk by Outlook.

Great, but this isn’t a simple zip archive or something that’s easy for the user to deal with, right?  Well, since Windows 8, Microsoft has built in the ability to mount ISO files using Explorer by default; this will work with a simple double-click. Magic!

And the binary within—from the user’s perspective—just looks like a PDF. They of course would not see the hash value, nor anything else to indicate that it was actually an executable, provided that the default Windows settings (which hide file extensions) were in place.

Looks like the variation on a common phishing theme worked perfectly, since next up we see the execution. You’ll note that Explorer has mounted the ISO file as “cdrom0” and launched the binary.

Rather than having this malicious binary make a network connection, the adversary has it spawn the privileged and signed Microsoft .NET Assembly Registration Utility (regasm.exe), which is trusted by default in Windows. RegAsm then does the following:

• Writes a file named run.dat under the user profile
• Writes a renamed copy of itself under the user profile
• Creates a network connection to an external IP address over a nonstandard port

Advanced Threat, but is it Persistent?

Obviously, these adversaries are mixing it up, changing the playbook; this means that they’re “Advanced” without a doubt, right?  And if they’ve gotten a binary past defenses by using an ISO file, they’re definitely a “Threat.” But without “Persistence” we’re only dealing with an “AT.” Fortunately (for them), at.exe can help with “Persistence”—but who uses at.exe any more?

Enough joking about “APT”

Alright, so the threat is on the box, and it’s running. But that mounted ISO will not survive a reboot, or even a logoff event. It’s technically possible to create a persistence mechanism that would mount the ISO and execute the binary again, but why recreate the wheel? Going with a “tried and true” approach works just fine. So the original malware wrote a renamed copy of itself to the user profile and created a scheduled task to launch that new binary every minute.

Now we have persistence, give me an “A … P … T!!!”  Okay, okay, I’m kidding with all the “APT” stuff—by all indications, this is just commodity malware with a twist. From this point forward with the infection it was a lot of “lather, rinse, repeat” with that scheduled task kicking off, writing a new binary copy, deleting the old one, and launching the new scheduled task. Every. Single. Minute.

Fortunately, our customer responded quickly, leveraging automation to help contain the immediate threat and initiate mitigation action.

Sowing the Seeds of a Better Future

Look: adversaries adapt and change their tactics. In this case, they employed some creativity and leveraged an ISO file to evade defenses and get their binary into the environment. So if our only method of detecting activity relied on attachment types, we would miss this. As defenders, how can we prepare for the unexpected (like ISO files)?  You’ve heard it before, but I’ll say it again anyway—defense in depth. In this context, I really mean building out coverage for various types of activity that may improve visibility, regardless of the specific approach an adversary takes.

In this scenario, we didn’t have a red flag from the common phishing attachment (MS Office maldoc) where the chain of execution goes Outlook -> Word -> CMD -> PowerShell. Thank you, ISO!  But we still have multiple ways to raise the activity, and can easily map these to MITRE ATT&CK Techniques if we’re so inclined:

• Outlook writing ISO file to disk: T1193 and T1027 (Spearphishing Attachment and Obfuscated Files or Information)
• RegAsm creating an external network connection: T1121 (Regsvcs/Regasm)
• Creation of a scheduled task by an untrusted/unknown binary (in this case, malware):T1053 (Scheduled Task)
• Creation of a scheduled task in an unusual location (in this case, the user profile): T1053

It’s also possible to build in some additional protections against these types of attacks. For example:

• Configuring email policies to block unusual attachments (such as ISO files!)
• Removing the default file handler for ISO files in the registry so that users are prompted on how to take action
• Enabling file extensions so that an executable sporting a PDF logo stands out more
• And last but not least, educating users and encouraging them to report suspicious emails (and following up on those reports!)

Thank you for joining me on today’s “Threaty Threat Post”—I enjoyed working on this one, as the activity we observed was just a bit outside the norm for phishing emails. The approach showed an understanding of Windows internals in an unusual area, and a creative way to evade defenses. A nice break!