Skip to content

Conversation

jc0b
Copy link

@jc0b jc0b commented Sep 4, 2025

This PR adds support in the extension for reading the (basic) state of a Crowdstrike Falcon sensor. This is achieved by running falconctl info, and parsing the plist output.

This could be expanded in the future to cover Windows and/or Linux sensors, but I am not in a position to test either of those platforms.

@grahamgilbert
Copy link
Contributor

Thanks for this - is there a reason we can't at least add windows support here? I think that would be really valuable for the community.

@jc0b
Copy link
Author

jc0b commented Oct 7, 2025

The answer is primarily that I don't run any Windows hosts at work, so I have no means of testing any of it. I can ask around on Slack and see if someone is willing/able to provide some example output, though.

@grahamgilbert
Copy link
Contributor

Thanks! Please also bump the VERSION file

@jc0b
Copy link
Author

jc0b commented Oct 7, 2025

Looks like (as of yet) that there is no falconctl for Windows. The Agent ID can be read from the registry apparently, but it's not clear that you can get the rest.

@jc0b
Copy link
Author

jc0b commented Oct 8, 2025

Ok, I had a further look at this.

Linux

Linux installs get a falconctl binary, similar to macOS, but it functionally is a bit different. I can use it to get all of the attributes I can on macOS, bar "sensor_loaded". We use the processes table to determine this on our Linux hosts, so I'm wondering - should I try and find the sensor in the process list to fudge this for Linux? Or am I better of leaving this blank?

Windows

Windows doesn't get a falconctl binary, or an equivalent. It looks like you can find most of the information about the sensor in other tables (version in the programs table, AgentID and CID in the registry table), although it doesn't look like you can determine on-device whether the sensor is in Reduced Functionality mode or not. Whether the sensor is loaded can again be found in processes.

I'm happy to add some Linux functionality to this table, but (personally) I believe that folks using CS on Windows with osquery are better served using the other tables. On macOS, the only thing you can get without these new tables are whether the sensor is running, and the app version (from apps). I'm happy to write documentation recommending alternate tables for different bits and pieces for folks who need this information on Windows.

@jc0b
Copy link
Author

jc0b commented Oct 8, 2025

Ok, I've added some functionality to support Linux, which will surface the following fields:

  • Agent ID
  • CID
  • Reduced Functionality Mode
  • Sensor Version

I still need to add tests for this - not quite sure how I'll do that, but the easiest way with the runner looks to be splitting each of the Linux bits up into their own methods and testing them individually. Not insanely familiar with Golang unit testing, but I'll give it a go over the next few days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants