How to Tell If CrowdStrike Falcon Sensor Is Running

CrowdStrike is a data and breach security company, which runs many services for endpoint security through its Falcon platform. CrowdStrike is generally classified as an Endpoint Detection and Response (EDR) tool, and primarily operates via the Falcon sensor agent, which is installed on employee devices and detects malware, anomalous behaviors, and other vulnerabilities.

As CrowdStrike’s own website says, the Falcon sensor is “extremely lightweight (consuming 1% or less of CPU) and unobtrusive: there’s no UI, no pop-ups, no reboots, and all updates are performed silently and automatically.” For that reason, end users may be unaware of Crowdstrike’s existence on their device, much less whether or not it’s working properly.

Ensuring that the CrowdStrike agent is properly installed, configured, and running could be the difference between responding to a massive data breach or enjoying your Saturday afternoon tea at home. But ensuring this requires us to gather information that goes beyond checking the apps folder or process table to see that the agent is installed. (Anyone with plain old Osquery can do that part.)

But merely checking for CrowdStrike’s presence doesn’t validate that the process is in a good state, or that the agent was configured properly.

Most companies with CrowdStrike don’t have this reporting readily available. If a device has stopped checking in, they don’t have alerts for it because it could just be an old device. The context of why it’s missing is missing.

To get that crucial context, we need to build some custom tables, which we’ll get into next.

How To Tell if CrowdStrike Is Installed, Configured, and Running on Mac, Windows, and Linux

To ensure that CrowdStrike is functioning properly, we want to validate various things, such as:

• Client ID

• RFM state (Linux only)

• Active System Extension (MacOS only)

• Operational state

• Version

That’s pretty straightforward in Windows, since we can gather the Client ID from the registry table, the operational state from the services table, and the installed version from the programs table. These tables don’t exist for MacOS and Linux, so if we want to collect and validate all of these for MacOS and Linux endpoints, then we have to partially implement our own solution.

To get the missing information, we’ll be querying falconctl, the CrowdStrike sensor binary. It can tell us if CrowdStrike is actually set up and communicating vs just running for its own amusement.

Our team made some additional tables in our agent to gather the missing information from the binary for MacOS and Linux. We added validation to the checks for the Client ID, RFM state (Linux only), Active System Extension (MacOS only), and operational state to ensure that the CrowdStrike agent is properly configured and running.

This provides a more robust solution, that should be sensitive to hiccups that could happen in the agent, which an “is installed and running” Osquery implementation wouldn’t be able to catch.

How To Detect CrowdStrike Using a Fully Native osquery Implementation

As we said, you can get certain information about CrowdStrike’s Falcon agent using generic osquery. That information varies by operating system, but we’ve included a general approach for each query below.

MacOS

1. We validate that the agent is an active system extension from the system_extensions table.

   • This tells us if the CrowdStrike agent is installed and enabled on the endpoint. It also shows us what version the system extension is.

2. This is a lot all at once, so let’s break it down a bit. Let’s start with the columns we care about.

   • Identifier - The system extension identity. (com.crowdstrike.falcon.Agent)
   • State - The status of the extension. I.e. active and enabled or deactivated and disabled.
   • Version - The version of the extension.

3. With these columns, we construct a JSON_OBJECT, which takes in our columns, and then returns a JSON formatted object for each row.

   • JSON_OBJECT('identifier', identifier, 'state', state, 'version', version)

4. Now we can group the objects into an array containing them all.

   • JSON_GROUP_ARRAY(JSON_OBJECT('identifier', identifier, 'state', state, 'version', version))

5. We then create another object array, and add filters to them to separate the data.

   • The first contains the row(s) where the state column is equal to “activated_enabled”.
     • FILTER(WHERE state = 'activated_enabled')
   • The second contains the row(s) where the state column is not equal to “activated_enabled”.
     • FILTER(WHERE state != 'activated_enabled')

6. Now we can get all CrowdStrike system extensions by putting this together and adding a WHERE clause to get only CrowdStrike system extensions.

   SELECT
      JSON_GROUP_ARRAY(JSON_OBJECT('identifier', identifier, 'state', state, 'version', version)) FILTER(WHERE state = 'activated_enabled') AS active_system_extensions,
      JSON_GROUP_ARRAY(JSON_OBJECT('identifier', identifier, 'state', state, 'version', version)) FILTER(WHERE state != 'activated_enabled') AS inactive_system_extensions
   FROM system_extensions
   WHERE identifier = 'com.crowdstrike.falcon.Agent' COLLATE NOCASE
   

Linux

1. We first collect the version, and by extension validate installation from the deb_packages/rpm_packages table.

   • Use deb_packages on debian based Linux, or rpm_packages on rhel based Linux devices.

   SELECT
      MAX(version) AS version
   FROM deb_packages
   WHERE name = 'falcon-sensor' COLLATE NOCASE
   

2. We then collect the operational state of the agent from the systemd_units table.

   SELECT COUNT(*),
      CASE
          WHEN LOWER(sub_state) = 'running'
              AND LOWER(load_state) = 'loaded'
              AND LOWER(active_state) = 'active'
              THEN 'Yes'
          ELSE 'No'
      END AS sensor_operational
   FROM systemd_units
   WHERE id = 'falcon-sensor.service' COLLATE NOCASE
   

Windows

1. We first collect the Agent ID and Client ID from the registry table.

   • Only the first 32 characters for each ID are important, so we use SUBSTR to remove extra characters.

   SELECT
      MAX(SUBSTR(data, 1, 32)) FILTER(WHERE name = 'AG') AS agent_id,
      MAX(SUBSTR(data, 1, 32)) FILTER(WHERE name = 'CU') AS client_id
   FROM registry
   WHERE key = 'HKEY_LOCAL_MACHINE\SYSTEM\CrowdStrike\{9b03c1d9-3138-44ed-9fae-d9f4c034b88d}\{16e0423f-7058-48c9-a204-725362b67639}\Default' COLLATE NOCASE
   

2. We then collect the version, and by extension validate installation from the programs table.

   SELECT
      MAX(version) AS version
   FROM programs
   WHERE name = 'CrowdStrike Sensor Platform' COLLATE NOCASE
   

3. Lastly, we collect the operational state of the agent from the services table.

   SELECT COUNT(*),
      IIF(LOWER(status) = 'running', 'Yes', 'No') AS sensor_operational
   FROM services
   WHERE name = 'CSFalconService' COLLATE NOCASE
   

What Kolide Does To Help Ensure the CrowdStrike Agent Is Properly Installed and Running

At Kolide, we’ve created custom tables to pull extra information from Falcon. (For a detailed guide on how to write osquery tables, read our blog.)

These queries also vary somewhat by OS, so we’ve included what data our Check collects from each.

MacOS

We gather data reported directly from the CrowdStrike agent by checking the output of this command /Applications/Falcon.app/Contents/Resources/falconctl stats -p.

This returns:

• Agent ID

• Client ID

• Operational state

• Version of the agent

We then check the system_extensions Osquery table to verify the agent is installed and active. We also check if there’s an inactive agent, but it does not change the check’s result if one is there.

Linux

We gather data reported directly from the CrowdStike agent by checking the output of this command /opt/CrowdStrike/falconctl -g –aid –cid –rfm-state –version.

This returns:

• Agent ID

• Client ID

• RFM (Reduced Functionality Mode)

• Version of the agent

We then check the systemd_units Osquery table to collect the operational state of the agent.

Windows

For Windows devices, we gather the Agent ID and Client ID from the registry Osquery table. We then collect the operational state from the services Osquery table. Lastly, we check our WMI table for the agent’s version.

How Kolide Turns Queries into Checks

As you can see, between the different operating systems, we had to piece together the CrowdStrike data and state from a few different tables in osquery, plus our own agent. Without our agent’s data, the MacOS and Linux checks would suffer in quality and sophistication.

This should give you a sense of how much work goes into creating Kolide’s software configuration Checks, but it’s still not the complete picture of our final product. Kolide bundles these disparate queries into a single Check, which admins can deploy across their fleet and run automatically or at will (our default setting for this Check is to run once per hour).

If Kolide’s agent detects any issues with the CrowdStrike agent, it will immediately notify the end user via our toolbar app, and provide them with remediation instructions.

If a user attempts to authenticate via Okta without a functioning CrowdStrike agent, Kolide will block them until they have fixed the problem. (As with all our Checks, admins can configure this one to merely warn users, rather than blocking them, but given the seriousness of CrowdStrike’s security role, most of our customers choose to make it a requirement.)

It’s important not to underestimate the value of end user remediation in the case of CrowdStrike. For one thing, it gets end users back to work without requiring the direct intervention of IT. For another, it cuts across departmental silos, since in many organizations CrowdStrike is part of the Security team’s purview, but interfacing with users usually falls to IT.

While this Check is specific to CrowdStrike, you can take this approach to other EDR tools and software in general.

Details will vary but the overall process should be:

1. Finding and deciphering configs and/or logs

2. Creating tables and launcher work to read those files

3. Writing a check that uses the custom tables

If you’re a Kolide customer, you can go through the whole process (including writing end user remediation instructions) using our custom check editor.

If you’re not a Kolide customer but you want to learn more about how our device trust solution works, watch our on-demand demo!