How CrowdStrike Prevents Fileless Attacks

How Falcon Prevents File-less Attacks in Your Organization

In this video we’ll demonstrate an attack that doesn’t drop malware or require any user interaction. We have identified a vulnerable webserver and passed a command that will drop a webshell and provide access to the system. We then gain access to the system and do some simple reconnaissance to illustrate the visibility that Falcon can provide your organization. We then attempt to run an encoded command that will only run in memory, again making sure to write nothing to disk, and steal credentials. Finally we illustrate how simple it is to contain this compromised server or change the configuration in Falcon to prevent these attacks.

Read Video Transcript

How Falcon Prevents Fileless Attacks in Your Organization

In targeted attacks, it is often easier for a hacker to exploit unpatched and vulnerable systems than it is for them to drop malware. In this example, we’ll exploit a vulnerable website that is SQL database driven and inject a command that will give us full system access to the web server.

From our attacker system, we’ve identified a vulnerable web server. And instead of filling out the field as indicated with a username or password, we’ll use this field to pass an argument that will drop a web shell, a tool hackers can use to manipulate a targeted system.

Once this is executed, we can open the Chopper Web Shell program and launch a virtual terminal from our new connection. A couple of quick commands, such as net stat, IP config, and who am I reveal that we are on the web server as NT Authority System. We pretty much own this machine at this point.

Web shells are a popular tool for hackers because no file is written to disk, and they often go undetected by traditional AV, whitelisting, or app control. As a hacker, I’m confident that I’ve gone undetected and can start reconnaissance and establish persistence in this organization.

Because the falcon sensor sits at the kernel and CrowdStrike focuses on malicious patterns or indicators of attack, this type of behavior is easily detected. Let’s open Falcon Host to see what this event logs like in the Falcon UI when we are only in detect mode.

Filtering out new events, we can quickly see the most recent detections. By clicking on the first alert, we can immediately see that our indicators of attack, or detection patterns, recognize that this series of events corresponds to a web shell exploit and specifically the patterns of the chopper web shell. We can also see the commands entered in the command prompt– who am I, IP config, and net stat– and under these circumstances, they are suspicious.

Now I’m going to run a command that is often missed by other security products. This is because the command will run mimikatz in memory, a popular credential-stealing tool. Going back to the Falcon UI and refreshing the browser adds the additional context to the attack, and we can clearly see the entire string passed via the terminal. We know exactly what’s happening on the web server and can take action in one of two ways. We can either network contain the server or enable prevention of these types of attacks.

To make these changes and prevent this from happening at all, navigate to the configuration app and select Prevention Policies. Either the default policy or a list of your organization’s policies will appear. In this scenario, the effective machine is the demo policy.

Selecting that policy will open the Configuration Settings page. And to prevent these types attacks in the future, I’m going to make sure my exploit behavior prevention IOAs is enabled, and I’m also going to enable prevention in the Machine Learning slider and then save the changes.

Back on the attacker system, we can relaunch Chopper Web Shell. And when we open a virtual terminal, access is denied. Falcon Host has stopped this attack.