Traditionally, attackers sought ways to install malicious files onto your devices, which were easily detected. But there’s a new type of stealth attack that’s fileless and often evades detection. Here, we’ll guide you through how you can identify and protect yourself from these attacks with Carbon Black Cloud.
As part of our vRadiate 2 series, we’re helping you push boundaries and achieve your goals with emerging technologies.
Carbon Black Cloud has various features that allow you to prevent and defend against next-generation threats, such as fileless attacks.
The basic level of protection, with Carbon Black Endpoint Standard, offers policy-based remediation against some fileless attacks, so policies can trigger alerts and/or stop attacks. However, it’s not as sophisticated as Carbon Black Enterprise EDR, as it doesn’t get updated based on watchlists and only looks for a limited set of behaviors.
By comparison, Carbon Black Enterprise EDR provides greater protection. It allows you to use various watchlists – community-based and proprietary collections of attack signatures – to identify a large number of techniques. In essence, these signatures are rules (or queries) that extract information from data gathered from sensors. The rules can then be used to trigger an alert or further investigate a certain issue.
Because watchlists can generate a lot of ‘noise’ and false positives, the option to automatically block marked behaviors isn’t available. However, you can easily investigate an issue and drill down to identify whether an event has resulted in any harm. If harm is identified, you can either connect to the machine (endpoint) to troubleshoot or quarantine it so that it’s only able to connect to the Carbon Black servers and nothing else.
Below you’ll see some of the reports available in watchlists:
Figure 1
Carbon Black Cloud offers a comprehensive choice of watchlists – some are proprietary, others are based on open lists, such as AlienVault or the ATT&CK Framework.
Here you’ll see a list of processes triggered in our vRadiate 2 project when their behavior hit a rule – in other words, all potential problems that were discovered after subscribing to a watchlist:
Figure 2
Exploring a process
By clicking on a process name, you can investigate what’s really happening. We’ll do this for powershell.exe.One thing that stands out in the picture below is an Excel process spawned by Outlook. It seems like the user opened an Excel file attached to an email and Excel ran PowerShell, which is quite unusual.
Figure 3
Let’s dig deeper. When we select the powershell.exe process, we can see what command was run by PowerShell and identify whether it’s malicious or not. For security purposes, we won’t show the full script.
Figure 4
Often, malicious scripts connect to Internet servers and upload private information. Since powershell.exe started conhost.exe, it seems like it tried to initiate a connection to another machine. If we examine the PS code, we can see that it really connects to a malicious machine and uploads information to it. We don’t want this. That’s why we can quarantine the device, which means it will be able to connect and report to Carbon Black but won’t be able to communicate with any other endpoint on the network. We can also add the Excel file to the approved list if we think this behavior should be allowed. Or we can delete the file itself.
Figure 5
A very useful feature allows you to see which reports alerted on this PowerShell behavior:
Figure 6
But what is this attack all about?
In our vRadiate 2 example, a fileless attack was devised based on various MITTRE&ATTACK entries. It’s built on the following hypothetical, but realistic, premise:
- A user receives an email from [email protected].
- Notice the additional ‘2’ at the end of the domain name. Attackers often go to great lengths to disguise their malicious activities, and registering fake domains is one of their methods.
- The email contains an attached Excel file. The Excel file looks similar to a custom report made by the Ant Media application used as part of the project. It features various videos hosted and viewed on the Ant Media Server and their number of views.
- The file has a very distinctive header with instructions on how to use it. It tells the user to click on “Enable Content” in order to fully leverage all functionality in the tables.
Figure 7
- The user clicks on “Enable Content”.
- A macro, configured to run whenever the file is open, runs immediately.
- The macro runs a PowerShell command which connects to an attacker-owned server and downloads a script to the user’s temp directory. The file itself has a random name.
- In order to circumvent any script-execution defenses, the initial PowerShell script reads the downloaded file instead of executing it directly and creates a script block from it so that it runs in-memory.
- The downloaded script block generates traffic to another malicious server in order to send private information.
- Then, it checks if there are any scheduled tasks named “SAPLogs” (another technique used to mask some malicious behaviour as part of a corporate strategy) and deletes them.
- Finally, it creates the scheduled task “SAPLogs”. The scheduled task is set to run daily at a random point in time. This cycle is repeated forever.
- The command executed by the scheduled task is basically the same script used to connect to the malicious server and recreate the scheduled task. This is how the attack accomplishes persistence. The scheduled task is deleted every time to ensure there are no previous execution logs.
Below is a flow diagram of the attack created for this scenario:
Figure 8
In Carbon Black Endpoint Standard, you can create a policy and use it to prevent such attacks. While this attack seems sophisticated, it’s fairly simple in its execution. There are many attacks which utilize parent process spoofing, for example, and are very difficult to stop just by using policies in Endpoint Standard.
Figure 9
For this version of the attack, the policy blocks the script by either denying it access to execute or terminating the parent process (excel.exe). The figure above shows the configuration of the policy. If either “Executes a fileless script” or “Executes code from memory” is enabled, then the attack is successfully stopped. Enabling “Invokes a command interpreter” also stops the attack, but it’s capable of stopping any benevolent scripts as well, which is why it’s not recommended in this case. Bear in mind that for the proper application of the policy, the “Applications at path” have to be configured as shown in the picture above. If excel.exe is not added to the list, attack prevention may not succeed.
Learn more about how you can defend against fileless attacks with Carbon Black Enterprise EDR or Carbon Black Endpoint Standard.
