This video illustrates Falcon’s ability to protect against multiple threats on the Mac with low impact.
Installing the CrowdStrike Falcon Sensor requires elevated privileges. The Falcon Mac Sensor is supported for use on the following OS versions:
- OS X 10.13 (High Sierra, supported for v3.6 (build 5703) and later of the Falcon sensor for Mac.)
- OS X 10.12 (Sierra)
- OS X 10.11 (El Capitan)
- OS X 10.10 (Yosemite, supported for v3.5 (build 5603) and earlier of the Falcon sensor for Mac.)
CrowdStrike currently supports the Google Chrome browser for use with the Falcon UI. We support the current release of Chrome as well as the prior two major versions. Other browsers may work, but we do not support other browsers at this time.
- CrowdStrike Tech Center
- Sign up for a weekly Falcon demo
- Request a 1:1 Demo
- Guide to AV Replacement
- CrowdStrike Products
- Falcon OverWatch CrowdCast
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 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 feeds, 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 that 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 Falcon 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 Falcon app. Back in the Falcon UI, navigate to the Falcon app by clicking on the Computer icon.
In the Falcon app, the systems are, by default, listed alphabetically by hostname. 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 a filter on platform and select Mac, but I can be more specific by selecting the OS version. Once the results are sorted, I can quickly see the CS-TMM-MACDEMO 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 [? mock-o ?] samples from VirusTotal 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 rename the files 1 through 10 for tracking purposes. To open all these files, I hit the Play icon in the AppleScript window.
While these applications open, we’ll keep an eye on the system numbers in 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 Falcon 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 a 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 if there are any other systems who may have run this file. Scrolling down further give us insight into things like disk operation, and the AV Detection section lists other AV engines who have convicted this file as malicious. In this case, we can see that the application is often associated with a file named Pintsized.
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 IOAs, or indicators of attack. In this scenario, we’ll assume that credentials have been stolen and the attacker knows the username and password of a 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 crack.
In our UI, we see 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 AV 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 an protection while still maintaining the performance on a Mac that everybody loves.