In this document, you will see how to prevent malware with CrowdStrike Falcon. Falcon uses multiple methods to prevent and detect malware. These methods include machine learning, exploit blocking, blacklisting, and Indicators of Attack (IOA). This unified combination of methods protects you against known malware, unknown malware and file-less attacks. This document and attached video will focus on exploit blocking.
Preventing file-less malware with exploit blocking
The Falcon machine learning engine is great at blocking known and unknown malware, but malware does not always come in the form of a file that can be analyzed by machine learning. Malware can be deployed directly into memory using exploit kits. This is why Falcon also includes an exploit blocking function. Each of the exploit protections can be turned on or off in the same window as the machine learning configuration. To turn an exploit mitigation on or off, just slide the toggle for the exploit mitigation you want to change.
First navigate to the “Configuration” app, then select “Prevention Policy”.
On the Prevention Policy page, scroll down to the “Exploit Mitigation” section
Next, let’s slide the toggle to the right by clicking on it. A dialogue window will open asking to confirm the changes.
The toggle is changed to green and enabled. Explore the rest of the exploit settings and adjust accordingly.
If you want to disable the prevention for that exploit, slide to toggle to the left and confirm that you’d like to disable.
Here is an example of a detection in the Falcon User Interface as a result of enabling exploit blocking.
CrowdStrike Falcon uses an array of methods to protect you against exploits, known malware, unknown malware and file-less malware. Those methods include:
- Machine Learning
- Exploit Blocking
- Indicators of attack
- Blacklisting and whitelisting
Falcon uniquely combines these powerful methods into an integrated approach that protects endpoints more effectively against both malware and breaches.
- CrowdStrike 15-Day Free Trial
- CrowdStrike Tech Center
- Sign up for a weekly Falcon demo
- Request a 1:1 Demo
- Guide to AV Replacement
- CrowdStrike Products
- Falcon OverWatch
How to Block Zero Day and Known Exploits with CrowdStrike Falcon Host
Thank you for joining us today. Today we’re going to show you how CrowdsStrike’s Falcon Host focuses on prevention of non-malware based attacks. We’re going to walk through a typical scenario of how a real attacker, a real adversary, might take control of an end user’s machine through the concept of phishing. On the left hand side we have a victim machine, and on the right hand side we have an attacker machine.
A typical attempt to trick the user, using a phishing e-mail that says your PayPal account has been locked, please click on this link so you can enter your credentials and unlock your account. But as you see, if the end user scrolls over the link, it’s not really Paypal. There’s a number 1 in there instead of an l.
The end user clicks on the link. A browser is opened, and in this case, McAfee Anti- Virus is running on this machine. It shows that an exploit attempt was launched, and it was deleted. But the reality is something different has occurred. The end user goes ahead and closes their McAfee Anti-Virus window and goes about their business thinking everything is OK, that their Anti-Virus has stopped the attack.
On the right hand side, we see that the attacker machine has had some interesting commands executed. In this case, the attacker is launching an exploit against Internet Explorer. If we focus on the bottom, we see that some kind of session was established to our attacker tool, in this case, Metasploit. Then we have a migration of a process. Let’s see what’s actually going on.
We see that we have some kind of session established back to the attack command and control server. Let’s go ahead and connect to it. Let’s open up a shell command. Now we see a full blown command prompt back to the victim’s machine. And the victim is none the wiser.
From here, an attacker would launch typical commands to learn more about his victim. Let’s learn more about this machine. We see that there are some interesting documents on the desktop, maybe a new marketing campaign, maybe some salary information. We can go ahead and download and encrypt that data and copy it over to our command and control server within seconds. Maybe we see what other machines or what storage shares this machine is connected to.
Let’s also learn about the IP address of the machine. Let’s also ping our command and control server and make sure that we have a good connection back to it. We could also do a trace route back to the command and control server to figure out how far away we are from the command and control server.
Essentially, we have full access to this machine. And the goal is to stay stealthy, and not use malware. Because we have essentially bypassed the anti-malware solution loaded on the victim’s machine. At this point, the goal is to use native tools found in the Windows operating system to stay stealthy and quiet so we can go undetectable.
A common technique all attackers use once they are able to get on a victim machine, the number one goal is to get better credentials. In this case, I’m going to use a tool called Mimikatz, which is able to break caches of all passwords found on the local workstation. I’m going to use the internet to download that tool called Mimikatz and PowerShell, to ultimately run it in memory on this machine. Here is the exact command I’m executing on Michelle’s desktop.
The command takes a few seconds to run. And as you can see here, we were able to dump Michelle’s password right onto the attacker machine. Now we have a good password to slowly attempt to move around laterally inside of the network. This is again, one of the most targeted things that an attacker wants.
Finally, since I now have better credentials, my next step is to establish persistence on Michelle’s machine. I don’t want to do that using malware or traditional methods. Instead, I’m going to use a technique called the Sticky Keys Attack. The Sticky Keys Attack simply merges one single registry value into Michelle’s registry, which turns her on screen keyboard into a debugger mode. All it requires is one value. I go ahead and hit Enter, and the value has been changed in Michelle’s registry.
Now the original attack that I launched that ran purely in memory and used no malware, is currently running on Michelle’s machine inside of the process, the real process, known as notepad.exe. If Michelle were to destroy or end this process, my attack would no longer be running in memory. This would happen, of course, with a reboot, or in this case, I’m going to manually end the process.
I go ahead and hit End. Observe on the attacker machine what happens. You can see that our session is closed, because Michelle has essentially killed my process running in memory. So now that my session has been destroyed, how do I get back onto Michelle’s machine without having to relaunch my original exploit? I’m going to attempt to use remote desktop.
And because I know Michelle’s IP address, of course. I was on her machine and able to grab everything I wanted, I’m going to launch a remote desktop onto her machine. And I’m going to use the ease of access key right here. I will click on it and turn on the onscreen keyboard. The second I hit OK, instead of getting an onscreen keyboard, I get a full command shell.
I’m inside of system 32, and I am no longer running as Michelle. I am now running as system. I could do everything I was able to do before without ever fully logging into her machine. So now I’m able to come back to Michelle’s machine whenever I need to. But most importantly, I have her credentials, so I can slowly move around the environment over the next several days, weeks, or months, finding what it is I’m looking for. I can slowly move around the network looking like Michelle, and never be getting caught.
Now let’s take a look at this attack if we had Falcon Host turned on on this machine. In this case, our attack was successful, because Falcon Host had prevention turned off. As you can see here, these are all our prevention settings for Falcon Host. I had four major preventions turned off. I’m going to go ahead and turn them on right now, and only give the client a few seconds to enable them. Again, these preventions are focused on exploit blocking and memory protection.
If we go back to the original email and go ahead and click on that same link, and look on the right hand side, we will see that there is no success in migration to a process. In this case, Internet Explorer crashes, but the exploit is not successful. McAfee pops up as usual, but more importantly, Falcon Host was able to stop the attack by protecting memory on the client.
Let’s go ahead and open it one more time. Again, on the right hand side, we don’t see success, and we don’t see a migration to a process as we did before. Let’s go ahead and look at this attack inside of Falcon Host’s UI.
So let’s take a closer look at our detection. As you can see here, our detection is made up of multiple patterns. There’s a hit on intelligence, suspicious activity, blocked exploit, web exploit, and others. Now what does that attack actually look like? Let’s go ahead and minimize this just a little bit and take a deeper dive.
Again, the goal here is to show you a full recording of the activity. As you can see on the left hand side, we have what’s known as our process tree. Initially, we have Internet Explorer being launched, and we see Metasploit’s Meterpreter, the attacker tool that I used, was injected into Internet Explorer. From there, I migrated it into Notepad.
Now one thing I want you to notice, we call it malware, but the reality is it wasn’t malware. And no files were dropped. There was zero AV detections. Metasploit itself is not malware. And it was loaded into memory.
Then we migrated it into Notepad, and this was injected via browser from a shell code. And then again, zero AV detections, even though it says malware, it’s really a web exploit. No files were dropped whatsoever.
Then we see what happens after that. We see some kind of command line was processed or launched. So if you recall, I launched a command shell. Then I started running interesting commands as an attacker. What kind of commands were they? Right here, every single command is captured in detail, including all switches and associated commands.
Ping, if you recall, I pinged my command and control server right here. And then I did a trace route. And then I went on to exploit the machine using PowerShell, where I ran Mimikatz and dumped the credentials of Michelle and all other users. Here is the exact URL I went to. Again, no guessing, and we can clearly see that Mimikatz was running. And credentials were being dumped using PowerShell.
From there, we see more suspicious activity where the registry key replaced the onscreen keyboard, turning on the debugger mode. We also see everything associated with that merging in the registry key, and we see persistence was indeed established using this key and this registry data. Now let’s jump back and take a look at my ping.
Well, here it is. Why did I choose that address? Because I know it belongs to a known command and control server of an actor, or adversary, that we track. In this case, it’s Stone Panda, as you can see where my mouse is on the bottom. I’m going to go ahead and click on Stone Panda and see where that takes me.
Notice we instantly jump to our actor’s page. One of the most important things about our solution is we power everything with our intelligence team. This shows you everything we know about Stone Panda. Stone Panda, nice executive summary, where they’re from, who they target, their target countries, and their primary motivations. So the power of this is I can click on my actor’s page as well and see all the other adversaries that we track.
We have interesting characters for them, or villains. And there’s a taxonomy for each one of them. Pandas are from China. Bears are from Russia. Kittens are from Iran. Tigers are from India, on and on. And we can drill down into any one of them to learn a little bit more.
In addition, you can filter on the actor’s page and maybe choose your specific target industry, such as technology. So that way, you could see all actors that target technology organizations or target countries, or motivations. Jumping back to our detections, now that we showed you the process tree on the left, down here I want you notice instead of a red shield like so, where something is only detected, we turned on our prevention.
Notice here, we launched that link three more times. And instead of a triangle, we have a blue shield. Here the exploit was completely blocked, and ultimately, the attack never succeeded. And this occurred three times. So whenever we see that blue shield, that means the attack was blocked, and our prevention was able to block the attack.