I’m excited to share the latest project I’ve been working on, an integration that brings together RITA, Sysmon, and Exabeam.
In this blog post I’ll give a brief overview of each of these technologies, the power of tying them together, deployment details, and an example of their effectiveness when used together. RITA and Sysmon are free to use, Exabeam is a paid UEBA/SIEM, if you aren’t using Exabeam I still encourage you to continue reading, as this blog may give you ideas for using RITA and Sysmon within your own environment.
If you are already familiar with RITA, Sysmon, and Exabeam, then skip to the Bring it all together section.
RITA
RITA is an open-source tool by Active Countermeasures, it ingests logs from Zeek into MongoDB and uses statistics and timing to detect suspicious network activity. The activity detected by RITA can be exported to a CSV file, our Exabeam integration will parse CSV files generated by RITA.
If you are not familiar with RITA I recommend watching this video: RITA — Finding Bad Things on Your Network Using Free and Open Source Tools.
Thank you Active Countermeasures and BHIS for this incredible free tool!
If you aren’t doing network security monitoring yet, you really should be. Network events are a key component to security visibility. The book Practice of Network Security Monitoring is a great place to start. Additionally, I recommend checking out Arkime if your looking for a great free tool to support network monitoring.
Sysmon
Sysmon is a tool developed by Mark Russinovich that generates rich security events on Windows systems. If you are not familiar with Sysmon check out this blog post by Roberto Rodriguez: Cyber Wardog Lab: Setting up a Pentesting… I mean, a Threat Hunting Lab — Part 6.
Sysmon network events are of particular importance to our RITA integration. Here is an example of a Sysmon event ID 3 network event:
In the above example, Sysmon allows us to detect that PowerShell is initiating a network connection to an external address. I could easily write several blog posts on Sysmon, if you are already using it then you know how powerful it is. If you’re not using Sysmon 🛑 stop here! Go setup Sysmon, you’ll be amazed at the visibility you gain into Windows hosts in your environment.
Exabeam
Exabeam is a company specializing in UEBA/SIEM solutions. In this blog post, we will be using their UEBA focused product Advanced Analytics. Advanced Analytics can be used to detect activity such as the first time any host in a VLAN starts an unusual process, or an irregular login time for a user.
Advanced Analytics has its own rule system and uses HOCON syntax. Rules come in two flavors, fact based and model based. Fact based rules are your traditional SIEM rule, composed of variables, logical operators (&&, ||, !) and functions (toLower, InList, etc.).
Here is an example of an Advanced Analytics rule, the RuleExpression variable contains the logic of the rule. For example, this rule looks at processes named lsass.exe where the directory isn’t System32.
Bring it all together
Overlapping fields of visibility are key to security monitoring programs. So let’s get our tools to talk together. RITA identifies beaconing activity from network traffic, combine this with the host based visibility of Sysmon and we’ll have a particularly powerful view into our environment.
Prerequisites:
- Exabeam Advanced Analytics.
- Sysmon deployed to all Windows systems.
- A Linux system capturing network data (either through a network tap or span port).
Install RITA on your network sensor(s), fortunately the Active Countermeasures team has made this straightforward:
wget https://github.com/activecm/rita/releases/download/v4.2.0/install.sh
chmod +x install.sh
./install.shAwesome! You’ve now got RITA up and running. Next you’ll need to configure RITA by editing the config.yaml file. Take a look at the RITA GitHub page for more information on install and setup.
The Integration
This is where my integration comes into play, we’ll be using Exabeam context tables (essentially lists of values) to enrich Sysmon network events with data from RITA. In order to interact with the Exabeam API you’ll need to create a user to do so.
In Exabeam Advanced Analytics navigate to Settings → Users. Use a strong password, bonus points for using a password manager.
Before you save, click “create a new role”. Switch over to the core tab and grant the manage context tables permission.
Assign the role you created to your new user and save your changes.
Before we move on, lets also create a context table to store the results from RITA. Navigate to Settings → Context Tables
Set the name to your desired name, the object type to Misc, and the type to Key Only.
Integration Setup
Now that we have a properly privileged user, and a new context table, we can move on with setting up the integration.
We will be running RITA on 24 hour slices of Zeek logs, then we will ingest this data into an Exabeam context table and use it when looking at the next 24 hours of host based data. We’ll repeat this process each day, so that Exabeam is always looking for process activity that matches RITA beacons. If you would rather look at a larger or shorter window of time you can adjust the integration to do so by editing the crontab entry and the run_rita_ingest.sh script.
When using the previous day’s beacons detected by RITA we run the risk of missing some beacons that we might detect if we looked at a longer time interval. If you find that this is too short or too long for your environment, you can adjust the integration accordingly.
The RITA/Exabeam integration is written in Go. I selected Go for two reasons:
- RITA is written in Go, so by using Go for our integration we open the opportunity for integrating more deeply with RITA in the future (perhaps not having to ingest via CSV).
- Go makes it easy to convert structs to JSON, which we will use when making calls to the Exabeam API.
To install the integration run the following commands:
wget https://github.com/zaneGittins/go-exa-rita/releases/download/v0.0.1/install.sh
chmod +x install.sh
./install.shThis will create a new directory at /opt/go-exa-rita with two files, a binary, rita_ingest and a script run_rita_ingest.sh . Finally, a crontab entry is created to run the ingest script once a day at 00:01, which will run RITA and ingest the previous day’s Zeek logs, output any beacons to a CSV file, and upload these to Exabeam.
After you’ve run the install script you need to create an INI config file.
[api]username = "username-here"password = """password-here"""context_table = "context-table-name-here"host = "https://dns-my-aa-instance.com"score_threshold = 0.8
Edit the variables to match your environment, replace username and password with the user we created in Advanced Analytics earlier, replace the context table name with the table we created, and replace the host with the correct DNS name of your Advanced Analytics instance.
Now that we have RITA beacons being uploaded daily to a context table, we need to create an Advanced Analytics rule to alert on this activity:
customer-created-T55stcgn59 {
RuleName = "Process has created a connection to beacon detected by rita"
RuleDescription = "Process has created a connection to beacon detected by rita"
ReasonTemplate = "Process {default|event.process_name} has created a connection to a beacon detected by rita: {default|event.dest_ip}"
AggregateReasonTemplate = "Process has created a connection to a beacon detected by rita: {default|featureValue}"
RuleType = "endpoint"
RuleCategory = "Endpoint Activity"
ClassifyIf = "true"
RuleEventTypes = ["process-network"]
Disabled = "false"
Model = "FACT"
FactFeatureName = "dest_ip"
Score = "25.0"
PercentileThreshold = "0.1"
RuleExpression = "(exists(dest_ip) && hasvalue('rita_beacons', dest_ip)"
DependencyExpression = "NA"
}The key portions of this rule are the RuleEventTypes, Model, and Rule Expression. RuleEventTypes determines what type of data this rule will run against, Sysmon network events are of type process-network. The Model is set to FACT since we are creating a fact based rule. Lastly, the RuleExpression holds the logic required for this rule to fire. In order for the rule to trigger we require that the dest_ip field exists within the log, and that the dest_ip is in our rita_beacons context table.
To test that the rule would trigger I ran the following PowerShell command on a System monitored by Sysmon, where the destination IP was in our context table:
Test-NetConnection 23.35.180.227 -Port 445After running the PowerShell command our rule is triggered:
Now we can see the exact process that reached out to a beacon detected by RITA and alert on it in Exabeam. Additionally, we can tune this rule to ignore specific processes like common web browsers. This is largely an environment specific choice, by tuning out processes you will lose the ability to detect some malicious activity in your environment. For example if you tune out AdobeReader.exe and a bad actor injects their malicious code into this process, you may miss the beaconing activity.
Be careful of what you tune out, and make sure it fits into your overall detection strategy. Don’t tune yourself into blindness.
Testing the whole integration
I originally wrote this section testing against BC-Security’s fork of PowerShell Empire, however I discovered that not many connections are made for this type of command and control activity. Depending on your OS version, PowerShell Empire may use an http persistent connection for command and control, which allows the agent to make multiple GET/POST requests over the same TCP connection. By default Empire agents check in every five seconds, and according to Microsoft, “The default timeout value for .Net Http clients is 100 seconds”. This means that under normal conditions we’ll only see a single tcp connection by our Empire agent, because it will never time out — not exactly beaconing activity that we’ll pick up using Rita’s show-beacons.
Both Zeek and Arkime show a single connection for our Empire agent:
RITA uses Zeek logs to detect beacons, and Zeek writes out TCP connections to it’s conn.log file for various reasons, including that the connection ended normally (SF) or that the duration of the connection exceeded the tcp_inactivity_timeoutsetting (default is 5 minutes). In the above image the connection state is S1, which means that Zeek saw the beginning of the TCP connection, but not the end. Given that the http connection is persistent, this makes sense, we won’t see the end of the connection. I’ve changed the tcp_inactivity_timeout setting in Zeek to 60 minutes, which is why we don’t see multiple connections at 5 minute intervals in Zeek’s connection log. Arkime has a similar setting that can be adjusted called tcpSaveTimeout to match Zeek’s timeout I set this to 3600 seconds.
To read more about TCP timeouts in analysis tools and how they can effect your analysis read this post by Chris Brenton: Fixing Bro/Zeek’s Long Connection Detection Problem — Active Countermeasures.
If you want to know why Empire uses a persistent http connection, take a look at Empire’s source code, it uses System.Net.WebClient to make GET/POST requests.
System.Net.WebClient uses persistent http connections, try it for yourself if you are skeptical, open up PowerShell and run:
$wc = New-Object System.Net.WebClient
$wc.DownloadData("http://neverssl.com")If you open up a tool such as ProcessHacker, you’ll see the established connection remain:
Realizing that due to persistent connections show-beacons was a bust, I moved on to using RITA’s show-long-connections feature, which is the perfect method to detect this type of activity.
Running show-long-connections shows the ip address of the C2 server for our Empire agent:
However, I wanted to complete our integration of show-beacons and get a test going that simulated the type of behavior we are after. I wrote a test program in Go to mimic the type of beacons we are trying to detect:
for true {conn, err := net.Dial("tcp", *connect)if err != nil {// handle error}fmt.Fprintf(conn, "GET / HTTP/1.0\r\n\r\n")status, err := bufio.NewReader(conn).ReadString('\n')fmt.Println(status)conn.Close()time.Sleep(time.Second * 5)}
This program will loop indefinitely, creating and closing a connection every five seconds. Zeek will therefore log a new connection every five seconds. If you watch the current conn.log on Zeek you should see the number of connections quickly tick up for this destination ip.
This generates the type of activity we are after:
After running our test for a few hours and analyzing the data with RITA we get a score of 0.95. The top beacons are then uploaded to our Exabeam context table, and we get an alert in Exabeam:
I hope this blog post showed you the power of integrating Exabeam/RITA. In the future I plan on working on the following:
- Integrating Exabeam with RITA’s
show-long-connections - More tightly integrating with RITA so we don’t need to parse CSV files.
Update 06/19/2021 — I’ve updated this blog post to reflect new information I’ve learned and correct assumptions I had during initially publishing.
