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.