This article is part of the series "Fileless Malware". Check out the rest:
- Adventures in Fileless Malware, Part I
- Adventures in Fileless Malware, Part II: Sneaky VBA Scripts
- Adventures in Fileless Malware, Part III: Obfuscated VBA Scripts for Fun and Profit
- Adventures in Fileless Malware, Part IV: DDE and Word Fields
- Adventures in Fileless Malware, Part V: More DDE and COM Scriplets
- Adventures in Fileless Malware: Closing Thoughts
When I first started looking into the topic of hackers living off the land by using available tools and software on the victim’s computer, little did I suspect that it would become a major attack trend. It’s now the subject of scary tech headlines, and security pros are saying it’s on the rise. It seems like a good time for a multi-part IOS blog series on this subject.
Known also as fileless or zero-footprint attacks, malware-free hacking typically uses PowerShell on Windows systems to stealthily run commands to search and exfiltrate valuable content. To IT security team monitoring for hacker activities, file-less attack are very difficult to spot, often evading virus scanners and other signature-based detection systems.
In short, legacy defense can’t really deal with this style of attack. Of course there is, ahem, security software that will spot the malware activity on file systems.
Anyway, I’ve written about some of these ideas before in my PowerShell obfuscation series, but more from a theoretical view. Then I discovered the Hybrid Analysis site, where you can find uploaded samples of malware captured in the wild.
I thought it would be a great place to look for some file-less malware specimens. I wasn’t disappointed. By the way, if you want to go on your own malware hunting expedition, you’ll have to be vetted by the Hybrid Analysis folks so they know you’re doing white hat work. As a blogger who writes about security, I passed with flying colors. I’m sure you will too.
Besides having samples, they also provide great insights into what the malware is doing. Hybrid Analysis runs the submitted malware in their own sandbox, and monitors for system calls, processes launched, and Internet activity, as well as pulling out suspicious text strings.
For binaries and other executables in particular, where you can’t even look at the actual high-level code, this container technique allows HA to decide whether the malware is evil or merely suspicious based on its run-time activity. And then they’ll rate the sample.
If you’ve read my obfuscation posts, you’ll know that the -e parameter indicates that what follows is base64 encoded. By the way Hybrid Analysis helpfully provides the decoded PowerShell as well. If you want to try decoding base64 PS on your own, you can run this command to do the work:
$DecodedText = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($EncodedText))
Getting in Deeper
I decoded the script using this technique, and you can see the resulting plaintext PowerShell malware below.
I was feeling a little nervous handling this live malware on my own laptop. Attention Varonis IT Security: please note that I worked with an on-line PowerShell console and also my own separate AWS environment. Got that, IT?
Anyway, we’ve seen this particular attack style before — in the PS obfuscation series — wherein the base64 encoded PS is itself pulling more of the malware from another site, creating a .Net Framework WebClient object to do the heavy lifting.
Why this approach?
For security software that’s scanning the Windows event log, the base64 encoding prevents text-based pattern matching from doing some easy detection – matching on say the string “WebClient”. And since the real evil part of the malware is then downloaded and injected into the PS app itself, this approach completely evades detection. Or so I thought.
It turns out with more advanced Windows PowerShell logging enabled – see my post — you can effectively see the downloaded string in the event log. I commend Microsoft (as did others!) for this added level of logging.
However, hackers then responded by base64 encoding the downloaded PowerShell from the remote site, so it would then show up in the Windows event log like the encoded sample above. Makes sense, right?
Adding More Scripting Sauce
The real-world samples in Hybrid Analysis then take this idea a step further. Hackers cleverly hide this PowerShell attack in Microsoft Office macros written in Visual Basic and in other scripts. The idea is that the victim receives a phish mail from say, FedEx, with a Word doc described as an invoice. She then clicks on the doc that then launches a macro that then eventually launches the actual PowerShell.
Often times, the Visual Basic script itself is obfuscated so that it evades virus and malware scanners.
Yes, it’s complicated and evil. And I’m only doing a very shallow dive.
There is one technique I borrowed from “in the wild” samples: the use of Wscript.Shell to launch the actual encoded PowerShell. It’s the way you get out of the script environment to interact with the rest of the system.
Not very evil.
Of course, real hackers are interested in gaining access to a laptop or server, say, through a shell..
In the next post, I’ll show how to do this by using PowerShell Empire, which I wrote about once upon a time.
We probably dove a little too deep for an introductory post, so I’ll let you catch your breath and cover some of this again next time. And then we can start grokking real-world malware-free attacks with the preliminaries out of the way.