In a previous blog post, I covered how Splunk, and by extension, other security tools, can be used for malicious purposes. In that specific example, we looked at a straightforward data exfiltration technique. That blog garnered some attention, but I didn’t feel it exemplified the damage that malicious control of security tools can cause a business.
In this blog, I will detail how the Splunk Universal Forwarder (UF) can be used as traitorware for persistence and remote code execution.
Did you know? Traitorware, as defined by Alberto Rodriguez and Erik Hunstad, is:
1. Software that betrays the trust placed in it to perform malicious actions
2. Trusted software with benign original intent used for malicious actions
For those who may be unfamiliar, Splunk is a robust log collection tool standard in enterprise environments. Certain features and functionalities can be added through technical apps (TAs) and add-ons. These apps can be as straightforward as a configuration file to monitor a single directory or be as complex as a user interface with executable code functionalities.
An example is the Splunk Add-on for Windows, which gives Splunk additional functionality for collecting information from Windows hosts. This is a very common Splunk add-on, with over 415,000 downloads (at the time of writing). This add-on allows the Splunk UF to collect additional log data from the system using PowerShell scripts and custom inputs.
In this scenario, I aim to use the Splunk UF as a Remote Access Trojan (RAT) on the system, allowing the Splunk UF to receive arbitrary PowerShell commands from a remote server. To do this, I’ll use a custom Splunk app that uses the PowerShell input functionality provided by Splunk.
IMPORTANT DISCLAIMER: This POC is for demonstration purposes only and is not a vulnerability, bug, or new exploit within Splunk. These are configurations supported by Splunk and provided in their documentation. The goal is to demonstrate that malicious actors can abuse IT and security tooling and use the core functionality for malicious intent.
First, we must create a custom Splunk app to abuse Splunk's PowerShell input functionality. A Splunk app is a bundle of configuration files installed on any Splunk appliance or, in this case, UF. These configuration files can enable new functionalities, provide data inputs, or create new UI elements.
We will create our Splunk app under <Splunk Install>\etc\apps, and it contains the following components: a PowerShell script and an inputs config file used to execute the script.
Here’s the folder structure for our app:
Starting with inputs.conf, we can begin to paint the picture:
Let’s break down each of these settings.
Script
Schedule
Disabled, Index, and Sourcetype
For git.ps1, we’ll use Invoke-WebRequest to scrape a webpage's HTML, collect the contents of only the HTML comment tag on the page, and then execute those contents as a command.
For demonstration purposes, 10.0.0.235 is a webserver I control. Replacing the IP with a domain name will retain the same functionality.
You may notice that we’re using [System.Text.Encoding] to decode a base64 value stored in $value. The HTML comment tags contain PowerShell commands, and I found that some characters in the PowerShell commands would parse as HTML, which would not return the correct value with Invoke-WebRequest (< and >, for example.) To get around that challenge, I just base64 encoded the contents of the comment tag.
Here’s the HTML of the web page we’re scraping:
Our Base64 encoded command is d2hvYW1pID4gQzpcdXNlcnNcdXNlclxkZXNrdG9wXGhlbGxvLnR4dA== which decodes to whoami > C:\users\user\desktop\hello.txt.
After we string everything together, the Splunk UF will pull a command from the web page every 10 minutes past the hour, allowing us to change the webpage to send new code to the victim endpoint.
Here’s a screenshot showing the connection to the web server and the contents of the hello.txt file we created. By default, the Splunk UF runs as NT Authority\System and will execute scripts with the same user context.
The Splunk UF configures the SplunkUniversalForwarder service to run as NT Authority\System, and this is because several of the background tasks that Splunk performs for data collection require administrative privileges.
If we pull apart the Splunk Add-on for Windows as mentioned earlier, we’ll find several PowerShell scripts for collecting data such as DNS info, Windows update logs, replication status, etc. This is standard information that most administrators would find helpful. Still, the Universal Forwarder’s script handler doesn’t limit the use of PowerShell or network connections, allowing us to inject just about any command and make outbound connections. While I created a custom Splunk app to demonstrate this, injecting malicious PowerShell code into existing Splunk apps, such as the Add-on for Windows, is possible.
This is not a new technique; security researchers have used Splunk’s UF as an offensive tool for years. Tom Kopchak’s blog on leveraging Splunk as an offensive security tool covers this technique and a similar technique for Linux in much deeper detail.
Want more cyber tips? Join us for Tradecraft Tuesdays.
Get insider access to Huntress tradecraft, killer events, and the freshest blog updates.