RFM in CrowdStrike is a big frustration for most. You have this awesome product to help defend however if your admins patch to quickly and it’s not supported, it loses it’s wings.
That sentence right there is a very confusing conundrum! In Security you spend years pushing the message “PATCH, PATCH, PATCH”, yet in this case, you say “Let’s not be too hasty”.
It’s a problem that I know they are working hard to fix! I really like the product 💖, so there is no hate here! 👍
Whilst they work on that though, what can you do? You could wait, or manually check it, however it’s quite hard. You could run N-2 on patching, however you would fall behind… There are other options, but in my case, I prefer some level of automation.
Hence: PreventRFM.ps1 : https://github.com/amoranio/Prevent-RFM
⚠️I’ll warn you now, this is my first draft, so it’s a quick and dirty script. Whilst I normally create functions, this is mainly a layered, let’s slap it together first run. It’s also focused on Linux only
I’m sharing now to see if others have ideas on making it better, and to perhaps help those struggling.
📜 The Script
As mentioned, this script is a Powershell script that will call upon the CrowdStrike and Tanium API to monitor what is being patched and does CrowdStrike support it. From this, you can incorporate whatever method you wish to notify your admins.
🔧 How’s it work?
First it queries a Tanium report. This report monitors kernel updates about to be applied to Linux hosts.
Once downloaded, it filters out the results and queries the kernel versions against the CrowdStrike API. This will then tell us what is supported, and what isn’t. First it will flag those that aren’t. Here you run the risk of going into RFM.
It will then provide feedback on what is now supported. As mentioned this is a dirty script, so uses a TXT file to keep track💡. You want to monitor what is now supported, so you can remove the block and patch.
At the end of the script, it will rotate the Tanium API key, so that on each run it’s rotated.
The flow, would look similar to this:
📑 The Report
The automation starts with the report in Tanium. We want to be able to pull down what kernels planned to be installed.
To do so, under Data > Reports, you want to create a report that matches similar to this. By no means is this perfect, but it works! The main fields we are after are: Computer Name and Applicable Patches Files.
The Applicable Patches Files is what contains the kernel updates (Which we need to query).
Once you’ve created this, take note of the ID. If you open your report in your browser, you will notice it within the URL: /ui/reporting/reports/report?id=[Your ID]
You will need to save this ID and place it within the script ($tanreportID):
#-- Tanium
$tantoken = Get-Content ""
$tanreportID = "[ Place it here ] "
$tantokenloc = ""🔑 Tanium API
To use this script, you will need API credentials. Within your Tanium instance, create the credentials, lock down the IP range/s and enter here:
#-- Tanium
$tantoken = Get-Content " [ Place it here ] "
$tanreportID = ""
$tantokenloc = ""The script does rotate the credentials after running, so please do update $tantokenloc if you wish to run this feature. If not, delete it.
The value is the location of a TXT file.
#-- Tanium
$tantoken = Get-Content ""
$tanreportID = ""
$tantokenloc = "C:\myfolder\mytan.txt"⚠️ As always, I’m not suggesting hard-coding secrets. Instead you should manage them securely, either via a local vault, Key Vault or Secret Store.
In this case though, it’s an initial run. If you did want to include the Secret Store, you could run it similar to:
🦅 CrowdStrike API
For the CrowdStrike end, you won’t need to update anything other than the API credentials. Once you’ve created them, place them here:
# -- Falcon API --
$clientid = ""
$csecret = ""⚠️ As always, I’m not suggesting hard-coding secrets. Instead you should manage them securely, either via a local vault, Key Vault or Secret Store (see above example).
📝 The Text File
This isn’t the most sophisticated method, but it works. You will need to update this value as this will keep track of the kernels that aren’t supported, and help validate if they are now (during new run).
### location output
$kernellist = "C:\PreventRFM\Unsupported.txt"
🤔What Now?
Now we have the pending Kernels, we need to block them. Whilst I’m currently working to automate this part, for now it’s manual. Within Tanium, you can manage a block list under Modules > Patch > Block List. Within here, you can setup a block list and manage the “bad kernels”. This will help prevent them from updating and causing CrowdStrike to run RFM.
🔮 What Next?
As with my other scripts, I made this public to help, and to motivate myself to improve on them. I’m hoping in the future, the PATCH API for Tanium will be expanded and allow us to automate the Block List Adding & Removing.
For now, you can run this and come a little closer to prevent RFM without having to scroll through support docs.
I may do another blog post, however the script will be managed on my Github: https://github.com/amoranio/Prevent-RFM
Let me know how you get on and I always appreciate feedback! 😁
If you have input, or can expand on the script, do reach out.
amoran.io 