Vendors are offering tools left and right since the Log4J fun ruined most peoples Christmas break. Amongst these Vendors is CrowdStrike. Below are a few articles which may help CrowdStrike customers find the Log4J vulnerabilities or at least gain some insight into where it’s running within their environment.
To add some automation, the good people at CrowdStrike added this which helps execute the hunt via RTR: CAST/Windows_Find-VulnerableLog4J_RTR_instructions.md at main · CrowdStrike/CAST · GitHub
To build on this, I’ve tried to add a little bit more automation so that you don’t need to run through this one at a time. For now it’s limited to Windows, but hopefully this will bring some benefit.
To begin, follow the instructions above and make sure you change the $tempdirectorypath variable. If you wish to run my script below with the defaults, it’s worth setting this to C:\Temp and matching the name: Find-VulnerableLog4J
Once you have done this, make sure cast.exe is uploaded to the “Put Files” and you should be good to go.
The machine you are running my scripts on will need PSFalcon Installed (PowerShell Module).
Here is the script for running cast.exe via RTR: https://github.com/securethelogs/CrowdStrike/blob/main/Log4J_Scripts/Log4j_Run_RTR_Cast.ps1
There is a bulk command that you can run for this however it seems to hang a lot, so I’ve created these based on 1 at a time. You may see different results and if so this could run in bulk.
You will need to make sure you’ve populated the ClientID and Secret for your API calls. This needs to have the full RTR permissions as one of the commands later on requires admin.
You will also need to update the cast.exe location. This needs to match the variable within the script
Once done, open Powershell and run the PS1 file with the -InFile parameter being the path to a text file populated with your device IDs in. This is something you can obtain by downloading your Hosts within Host Management (Falcon Portal). Since the below only works on Windows, I would filter out Linux, Mac and potentially Workstations. This will isolate the search and shorten the time.
Once ran, it will download the cast.exe to the chosen location and execute. If Cast finds anything, it will output to the same location: cast_results.json. If Present you have something to investigate, if not, you are potentially ok.
Once ran you may have a bunch of systems with the JSON file but no automation to pick them up. Because of this, I’ve created another script…
Here is the script: https://github.com/securethelogs/CrowdStrike/blob/main/Log4J_Scripts/Log4j_Get_RTR_Json.ps1
To run, you will need to input a file with your device IDs. This should be the same one you used to execute Log4j_Run_RTR_Cast.ps1 (first script). The -OutFolder will need to be a folder the script can write to locally. This location will get the backups, the zip files and a csv output.
Before running, you will need to make sure that you’ve populated your client secret, ID and the CastLoc.
If you’ve ran the script above, copy the same location. If you left the first script as default, it will be “C:\temp”.
As shown above, it will hunt for the file, output the hosts hosting that file (To Investigate) and create a backup (Csv and Txt files).
It will then begin collecting…
Using the same location, it will crawl through each device id, collect the file and download to your chosen location (-OutFolder). Your folder will then look something like this:
You can use the AID backup file to rerun the script if failed or broken. You can use the CSV file to gain more insight into the hosts which may be vulnerable. The 7Zip files host the cast_json file.
To further automate this process, the script has a 7Zip check as well so if you have 7Zip installed, it will extract the files for you.
This will then output to the folder Extracted_Json:
Hopefully this script can give you a building block to help automate some of the RTR hunts for Log4j.
Leave a Reply