How to Get Next-Gen AV Protection on a Mac with Falcon

For many of you here, this will be the first chance you’ve had to see the UI. So let me take it just a few minutes to give you a quick tour. After logging into the UI, the default location is the Activity app. This is where new detections are listed from the most recent. However, if you’d like to filter your results, that can be done on the top half of the page, either by using the Type to Filter option, or just by selecting one of the predefined options listed. You’ll find these predefined lists in most of the apps.

To get an expanded view of the apps and services, hover over each of the icons, or click on the falcon in the upper left-hand corner. Here, you can see a list of all the apps that would be needed to view detections, perform detailed investigations, and manage the platform. Apps exist for Activity, Investigation, Host Management, and Configuration of Policies.

The Dashboard app organizes the detections into different categories depending on the audience and what they’d like to accomplish. The Intelligence app can be used for managing Threat Feed and other subscriptions, and also detailed information about threat actors. Finally, there is the Users and Support apps, which provide resources for managing Falcon.

Now I’ll walk you through an example of a sensor install on a Mac. One of the arguments against any type of third-party security product on a Mac is it often creates a noticeable performance impact while only providing marginal protection. One of the key features of Falcon is its small sensor and low-impact footprint. During the install, the user is prompted after confirming the sensor version and the use of 1.4 megabytes of space in the computer to enter their password to permit the changes. Within a few seconds, the sensor has been installed.

Now, to verify that the installation has been successful, we’re going to find the computer name in the Host app. First, we’ll go to the System Preferences and click the Sharing icon to find the computer name of our machine. The computer name listed here is the one that we’ll look for in the Host app. Back in the Falcon UI, navigate to the Host app by clicking on the computer icon.

In the Host app, the systems are by default listed alphabetically by host name. In a large organization, scrolling to find new systems wouldn’t be a viable option. To find new systems, we could sort the columns by last seen, in order to get those systems that have most recently checked into the Falcon platform.

Another option is to use the predefined options at the top half of the screen. We could select to filter on platform and select Mac, but I can be even more specific by selecting the OS version. Once the results are sorted, I can quickly see the CS-TMM-Mac demo host. To see even more details, such as deployment group and applied policy, just click the host name, and the Host Info pane will open on the right.

Once a sensor has been installed and verified in the UI, we can run some samples. I’ve downloaded some random mach-o sample and created an AppleScript that will allow me to open all the samples in a specific folder– in this case, the Samples folder on the desktop. While I run these samples, I’ll also open the Activity Monitor to keep an eye on the impact. And finally, I’ve renamed the files 1 through 10 for tracking purposes.

To open all of these files, I hit the Play icon in the AppleScript window. While these applications open, we’ll keep an eye on the system numbers and the Activity Monitor, just to see what the impact is. You can see that for each application, a terminal window also opened. As we keep an eye on the system performance, we’ll see an initial spike associated with opening 10 applications at a time and then return to the baseline. Looking closer at the terminal windows, we can also see a common message, “killed 9.” This is indicative of a process that wasn’t able to successfully run.

Back in the Falcon UI, we’ll move from the Host app to the Activity app, and then again, we’ll use our filters to view only new detections. By clicking on any of these detections, additional details are made available on the right in the Execution Details pane. In this case, our script runs all of our samples from the terminal, and you can see the command line arguments that were used. We also see that the activity was prevented. If we’d like, we can copy the hash file and scan our environment to see if there are any other systems who may have run this file.

Scrolling down further gives us insight into things like disk operation. There are two things worth pointing out with this scenario. The first is that the impact to the system was minimal. And second, none of the samples run were stopped by XProtect, Apple’s built-in AV protection.

Now, let’s go back to our demo system and try a different type of attack. In scenarios where there’s a targeted attack, security tools have to be able to handle more than just malware. Hackers often use multiple techniques designed to avoid existing AV detection capabilities. They’ll use fileless malware or living-off-the-land techniques to avoid detection. To catch these types of techniques CrowdStrike has IRAs, or indicators of attack.

In this scenario, we’ll assume that credentials have been stolen, and the attacker knows the username and password of the demo system. They would like to move laterally and find credentials for other systems in the organization to find more valuable targets. Attackers will often use Mimikatz for this type of credential theft. In our situation, the attacker will type a terminal command that will return password hashes that are stored on this machine. Hopefully, an admin password has been used at some point, and that information can be used to move to more valuable servers.

This scenario is actually based on a story published last year, where Apple employees were being offered up to 20,000 euros for their credentials. According to the story, it is believed that the credentials would then be used as a foothold to move within the IT infrastructure at Apple. On our demo machine, we can see that running the command generates a hash that can be taken offline, and then hopefully later, it will be cracked.

In our UI, we see a new detection categorized as credential theft. CrowdStrike uses these indicators of attack to find and alert on suspicious patterns of behavior. These IOAs can identify behavior often associated with advanced persistent threats, and even living-off-the-land techniques. We can see, in the execution details, the command line argument used to steal the credentials. We can also see that, unlike the malware example, that no other detections exists for this type of attack.

You can see that in this demo, contrary to popular belief, common sense and the built-in Mac tools aren’t enough to protect all types of malware, fileless or targeted attacks. CrowdStrike fills the gap in protection while still maintaining the performance on a Mac that everybody loves.