In this week’s chat, the malware research team looks at the recent spikes in fileless malware attacks and answers questions from IT pros who want to know how fileless attacks work and what they can do to stop them.
ryan: There’s been a lot of talk around fileless malware attacks lately….
Say hello to the super-stealthy malware that’s going mainstream https://t.co/pmtFZKtUZT— WIRED (@WIRED) February 10, 2017
Before we dive in, let’s step back and explain what “fileless malware" actually refers to. Rick, want to unpack what it means?
rick: By most definitions, it describes an attack that doesn't come from a portable executable (PE). Calling a lot of these attacks “fileless” is a bit of a misnomer, however, since many times the source can be tracked back to a file…
For example, a Word document can contain a payload that streams a PowerShell script to your system that does something malicious. This is considered fileless since the attack isn’t tracked back to a PE-EXE.
matt: In addition to fileless techniques for getting onto the system, there’s also fileless techniques for achieving persistence.
ryan: Right. Pedantically, “fileless" originates from malware gaining execution in memory and staying resident without leaving executables on disk. Many of the original forms were exploits delivered through exploit kits like Angler. You browse some nefarious website (or a legitimate one that’s compromised by malvertising), you’re vulnerable to some Flash-based exploit and boom — it’s off to the races without ever leaving crumbs on the disk.
But the definition has been taken over to refer to any non-executable based malware.
In general, “fileless" malware refers to malware that gains execution in memory and stays resident without leaving executables on disk.
rick: True, the general definition of fileless malware is a bit vague by industry standards. Kovter and Poweliks can also be considered fileless since they store persistence mechanisms in the registry, but the original payloads are executables.
Also, the rise of PowerShell-based attacks are also being lumped in to the fileless category as well.
ryan: Which makes it reasonable for folks to ask questions like this:
ryan: Great question, Colin. In some sense, “fileless malware” is a buzzword. But there’s a reason it’s become a buzzword… It's actually important to know the differences between fileless attacks and typical executable-based malware. If you don't then your current security may not be setup to handle them very well.
rick: Agreed. The “fileless" designation shouldn’t matter, but it does because a lot of legacy security tools have been heavily focused on executables (PE files). As a result, hackers are using different techniques to get in.
ryan: So in the interest of clearing things up — if we have a list of types of attacks being included in the fileless category, it’s really:
rick: Most of the fileless attacks I can think of can be lumped in either category. Lower-level malware like rootkits can also be considered fileless, but I haven’t seen a lot of rootkit activity in the past few years.
ryan: Let’s answer some more questions.
So tackling these one at a time.... How do these attacks commonly enter a network? How do they get executed and run if there's no executable?
matt: As mentioned earlier, it’s often delivered via an exploit kit. Ex: The original code gets executed inside your browser through a Flash vulnerability.
ryan: Phishing campaigns can either enable that by leading you to a waterhole or they can deliver malicious documents with embedded scripts (ex: a Word doc with macros that remotely stream commands).
rick: Phishing = biggest bang for the buck. Protect the email, protect the world.
ryan: IT administrators worse nightmare: should I not have clicked that?
#TellASadStoryIn3Words They enabled macros— Malware Unicorn (@malwareunicorn) February 22, 2017
rick: In terms of how fileless attacks execute, here's one example:
Late last year, a Barkly customer had a user who downloaded what appeared to be a legitimate Firefox update. Instead, it dropped a new variant of Kovter that was able to get past the user's AV because the attackers had a signed certificate for the fake Firefox update and the Kovter sample hadn't been blacklisted yet.
As it executed, Kovter wrote an embedded and encoded script in various locations in the Windows registry that would execute PowerShell.exe and use it to inject shellcode in the system. Once that happened, the original .exe could be deleted, cleaning up its tracks.
Luckily, since Barkly analyzes system processes and behaviors instead of just file attributes, we were able to see that attempt at process injection during runtime and stop it before any harm was done.
ryan: Ok, next up: "How does one detect this type of attack?" And I guess another question is, why can it be difficult to detect?
rick: So, one answer is use Barkly ;-)
matt: Without the file to point back to, a traditional scan of your file system won't have anything to find.
ryan: Exactly. Just looking at static files doesn’t help you recognize a program is behaving outside of normal operations. You have to be watching its behavior in runtime.
It’s like Harry Potter’s cloak of invisibility — even if you are looking right at something malicious, unless you see the wallet being stolen off the nightstand it's hard to recognize something bad is actually happening.
We are trained to recognize that the browser uses a lot of CPU, so the fact that an attacker is actually using it to do a remote network scan and steal data just gets added to the noise.
rick: Ultimately, detection isn't enough, anyhow. As we’ve seen in past research, malware like ransomware can cause damage incredibly fast.
Windows Event IDs are a good place to start. My favorite reference is eventid.net. Unfortunately, when you look at the logs it can sometimes be difficult to understand what each event is actually logging.
Besides, if you're waiting to respond till after the fact, at that point you’re really chasing a bank robber on a tricycle.
The old way of thinking about security was to minimize visibility gaps. After each incident, do a lessons learned and figure out what failed and how to close any visibility gaps. For example, PowerShell can be audited and there are some specific Windows IDs and logs to look at.
That's not enough anymore.
"If you're waiting to respond to fileless attacks till after the fact, at that point you’re really chasing a bank robber on a tricycle."
Understanding what a normal system baseline looks like does help a lot, though. I was thinking about writing a tool that looks for large binary blobs in the widnows registry...
ryan: Moving on to the last of Z-Ethan's questions: How do you clean up this type of infection? Does it require a "nuke from orbit" approach?
rick: Once a machine is infected, the only way to clean it is to nuke it. Many malware is bundled with other malware. Ransomware is increasingly becoming bundled with credential stealers or click fraud. Finding one malware artifact doesn’t guarantee the hacker didn't have another artifact on the machine.
Advising the user to change all their passwords is another remediation step that is rarely used. Turning on 2FA proactively on everything from your bank account to your email are great things to do, as well.
ryan: There is no easy "delete malware" button. That assumes you know what crumbs were left where, what processes where injected, etc. As @rick says, the problem lies in assuming you know what you don’t know, and that can be dangerous.
Now that's in general. If you know what the malware is, it has been well researched, and you know what it did do, then it cleaning it up more tactfully can be done... but that's a lot of if's.
If you like to gamble then surgical removal is an option. If you prefer to be safer, nuke it.
The bigger thing to think about is how you plan to deal with situations where, for business purposes, you don't currently have the option of nuking a particular system. If your risk profile highlights little tolerance for getting a more surgical removal wrong, then you may want to work on establishing a business protocal that makes nuking an option, after all.
The point is, you need to think through these things before the decision is already made for you.
ryan: Before we kick off this next portion, lets all take a quick trip back to 2008 via this article by Don Jones. Three paragraphs in:
"As Windows PowerShellTM becomes more popular, though— it has already been downloaded more than a million times — the odds increase that someone will use it to create a malicious script."
(from January 2008)
Hmmm... Really, if you haven’t read that article, you should.
rick: I have seen a few PowerShell attacks that bypass execution policy recently, along with this, "Detecting and Defending against PowerShell Shells."
ryan: It seems like every generation seems to forget the lessons learned from the past. And speaking of the past...
We’re seeing other techniques like scripts in .lnk files delivering Locky and Kovter, as well as Office Macros getting in the act by streaming commands to runtimes like Python and PowerPoint to execute fileless attacks.
The dissections of some of the recent PowerShell attacks are really interesting. For ex: PowerShell can arbitrarily download and execute a script from a URL. From an attacker’s perspective, that’s the coolest thing ever for so many reasons!!
matt: All you need is an Office document whose macro launches PowerShell with that (or similar) argument(s) and bang.
rick: And since it’s remotely hosted, the attacker has a much finer-grain control on the exploit. They can remove the payload once their target hits it, or randomly serve different things dyamically (e.g. hosting different ransomware or credential stealers).
ryan: So what's our advice from avoiding getting infected in all these nasty "fileless" ways?
rick: Turn on automatic updates and verify they are working to avoid exploit kits. Use Barkly to stop attacks at runtime (again, couldn't resist).
matt: Agree with Rick — browsers and PDF readers are prime targets for exploit kits, so keeping them up-to-date will help curb that delivery mechanism.
ryan: Yeah, if you haven’t disabled Flash in your browser yet, before you leave the office today disable Flash.
rick: That’s an excellent point. Many sites don’t use Flash anymore. Even YouTube has an HTML5 version. Although sometimes it’s hard to do, especially with legacy business critical applications written in Flash.
matt: But another big thing is user education. Keeping people off malicious sites or from opening attachments in emails as much as possible goes a long way.
With that, I want to thank everyone for hanging in there, but we have to go back to making world class endpoint security.
Get the latest security news, tips, and trends straight to your inbox.
Get the latest security news, tips, and trends straight to your inbox.