In this document, we will see how to prevent malware-free attacks with CrowdStrike Falcon. Malware-free attacks are attacks that do not use malware.
Falcon uses multiple methods to prevent and detect those types of attacks and this unique combination allows Falcon to protect against even the most advanced attacks. This document will focus on Falcon’s exploit blocking and Indicators of Attack (IOAs) protection features.
“How to Detect and Prevent Malware Free Attacks with CrowdStrike Falcon”
Policy Configuration Steps
Navigate to the Configuration Policy. You can configure prevention features in the Configuration App. Once in the App, chose Prevention Policies. Please note that you need Admin privileges to configure the prevention features on the Prevention App settings page. Chose to edit an existing policy by clicking the icon on the right.
Enable Behavioral Exploit Mitigation
One of the challenges with attacks that do not use malware is that they can inject commands can directly into memory. Those attacks take advantage of vulnerabilities and make use of exploit kits. This is why Falcon provides an exploit blocking function. To turn an exploit mitigation on or off, just slide the toggle for the exploit mitigation you want to change. In our example we are going to turn on Force ASLR mitigation.
Let’s slide the toggle to the right, click “Save” and confirm the change.
If you want to disable the prevention for that exploit, slide the toggle to the left, click “save”, and confirm that you want to disable.
Here is an example of exploit blocking detection in the Falcon User Interface.
Prevention with Indicators of Attack
Exploit blocking provides another layer of protection but may not be sufficient at times. Some file-less malware do not use exploit kits, but rely on a user’s mistake to successfully compromise a system. Ransomware, for example, has some infamous examples of file-less ransomware that do not use exploits. Targeted attacks also fall into that category.
This is why Falcon also uses Indicators of Attacks (IOAs) to protect systems. IOAs look across both legitimate activity and suspicious activities to detect stealthy chains of events that indicate malware infection attempts. IOAs that prevent attacks which do not use malware are enabled by default. For attacks such as adware and ransomware, specific IOAs can be configured.
You can enable or disable them in the current window by sliding the toggles below similar to exploit blocking.
Below is an example of a ransomware prevented event based on an Indicator of Attack.
There are also policy options to configure behavioral detections around exploit behaviors, lateral movement and credential access.
CrowdStrike provides advanced prevention capabilities to help organizations protect their endpoints from more sophisticated, fileless attacks through simple configuration options.
- 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 Detect and Prevent Malware Free Attacks with CrowdStrike Falcon Host
In our example, we have set up a simple web page here on the left side of the screen with an input field that is connected to an improperly configured web server on the back end. And in the input field, you’ll pass a command instead of the required field. In this example, we’ll use the vulnerability to drop a web shell, or program which will give us full access to the web server, located here on the right side of the screen. Had the server been properly configured, these arguments would be invalid, and this attack would not have worked. Also notice that after inputting the command in the input field, the URL also contains the command. This means that we could have just passed the argument through the URL and not relied on a field in the web page.
On the right hand side is the web server. And as we execute the command, you’ll see the web shell appear in the file directory. This is essentially the back door from our attacker system to the target system that bypasses the traditional AB application whitelisting and other traditional network defenses. Once this web shell is on the target system, we can open an application on our computer and run some reconnaissance commands, like who am I, system info, and then determine the domain controller. In a traditional environment, this system would have been owned and used to establish persistence in the organization. But let’s look at the event in the Falcon console. Here we see a new event. Opening the full detection details gives us an easy to understand diagram of the events and commands in the attack. Clicking on any of the nodes, such as the command.exe node, opens the details pane on the right. Here we get details like the command line argument that was passed.
Back in the web shell, let’s see what other information we can get from this host. We’ll download and run that’s the popular credential stealing tool. Inspecting the output, we eventually see a username and password in clear text. Refreshing our browser in the UI, we see a new branch on our process tree. And selecting it gives us the additional detail in the right, where we can clearly see that the behavior is credential theft, and even the exact PowerShell command use. Additionally, we can see the GitHub DNS request and the subsequent network traffic created by this command.
Next, the attacker would like to establish persistence by creating a log in bypass. This command will change the registry so that when the onscreen keyboard is accessed from the login screen, instead of a keyboard, a command prompt will open. Again, refreshing the UI produces a new alerter, where there is a suspicious activity due to registry entry. In the details pane, we can see the command line argument used to change the registry and create a backdoor. On the attacker system, we’ll leverage this backdoor just created and use the Remote Desktop program. To get to the on screen keyboard hit the accessibility button, and select the on screen keyboard. When this is selected, a keyboard should appear, but instead, a command prompt. And we can quickly see that we are logged in as anti-authority system. At this point, we have the keys to the kingdom, and we’re going to use net use to connect to the domain controller and grab all the user accounts in the Active Directory. And we’ll also grab the system volume information and copy it to our own web server.
From here, we can use our chopper web shell program to get access directly to the enclosed folder, and copy its contents to our local system. Back in the Falcon UI, we refresh the pages here ever growing process tree. We can see the command used to change the registry for the on screen keyboard hack. When looking at the root process, we can also see all the disk activity on the right hand side that was created when we copied the files from the domain controller onto our local machine. Visibilities into these events are valuable, but more important than visibility is the ability to just prevent them all together. In our configuration app, we will move to the prevention policy page. And in our exploit behavior prevention IOA section towards the bottom, we’ll enable detection for Chopper web shell, and then save the changes. Let’s try to run this attack again. Here we can see that access is denied and the attack has been prevented.