Yep, that kind of crazy :-) |
From RITA's readme.md: "RITA is a toolkit which is intended to help approach the often overwhelming task of combing through piles of log data looking for suspect behavior.
RITA is intended to help in the search for indicators of compromise in enterprise networks of varying size. The framework was instructed by it's engineers experience in penetration testing with the question of how they'd catch themselves, thus the analysis tends to looks specifically at the indicators their tools tend to leave behind." This is the basis of a contemporary hunting practice, the definition of proper red team / blue team give and take. Emulate your adversary with the same tools they'd use (red), then write and implement detection and alerting logic to identify that same activity. You'll force your red teams to become stealthier while improving your blue team tactics, all the while improving your likelihood of catching average and less sophisticated adversaries.
John and team have endeavored to document RITA, and while the docs are raw, they'll definitely get you under way. Here's a bit of a manifest to help bring you up to speed:
1) Initial video
2) Initial blog post
3) Release notes
4) Initial overview
5) Bro logs import overview
6) OVA for your preferred virtualization platform (works like a charm on VMWare)
Read all the docs, that's an order, but I'll give you my exact setup steps, which borrow liberally from the docs above...that you're supposed to read.
1) Download and import the RITA OVA. Username: ht, password: !templinpw! (change it).
2) Crack open a terminal and run sudo apt-get update && sudo apt-get upgrade. Good time to take a VM snapshot.
3) Download bro_logs.tar.gz and logstash_script.tar.gz.
4) Create a logs directory, I used mkdir /home/ht/Documents/toolsmith.
5) Unpack bro_logs.tar.gz in your new directory, it created /home/ht/Documents/toolsmith/logs for me.
6) Unpack logstash_script.tar.gz in the new logs directory.
7) cd logstash_script.
8) chmod +x run.sh.
9) Edit bro.conf (line 128) such that imported Bro logs write to an index of your choosing. You'll be shocked to learn that I chose toolsmith.
10) ./run.sh ../bro_meterpreter/2015-* ../dns_bro/2015-* ../powershell/2015-*
Figure 1: Import in progress |
12) Go to Settings tab, change the index name to that which you selected above and add @timestamp under Time-field name resulting in something like Figure 2.
Figure 2: Kibana Settings |
14) Back at your terminal, cd Documents/RITA.
15) python run.py
16) Browse to http://localhost:5000 for the RITA UI
17) Enter the name of the index you created, should appear as in Figure 3
Figure 3: RITA UI |
Beaconing
Connections that happen frequently and on similar intervals could be an indicator of malware calling home
Blacklisted IPs
Blacklisted IPs are addresses reported as being involved with malware, spamming, and other dangerous activities
Scanning
These events occur when a computer attempts to connect to a large number of ports on a system, searching for vulnerabilities
Long Durations
Connections that are beyond the length of average on a network could indicate a compromised system
Long URLs
Longer than normal URLs could potentially be used to transfer malicious data into the system
Concurrent Logins
A user being logged into a high number of systems could indicate that this user's account or original system has been compromised
Under Beaconing, change potential_save_dir to /home/ht/Desktop/ then click Run Module.
While you wait, you can watch progress in you terminal window.
Figure 4: Beacon analysis progress |
Figure 5: Filtered beacons |
Figure 6: Beacons |
For continued pursuit of a culprit I then filtered with src:192.168.56.72 AND dst:107.170.48.146 -unlikely_beacons, which resulted in 49,611 hits.
Maybe an additional focus area from RITA's list such as Long Durations? Yep, that worked. result_type=long_durations AND src=192.168.56.72 returned 60 hits including 54.192.89.85. That IP belongs to Amazon Web Services, nobody ever uses a cloud node for exfil or C2 during hacks or pentest work, right? :-) A long connection at odd hours bound from one of your source IPs to an AWS node could be quite interesting and worth a closer look.
Figure 7: Why is my IP having a long chat with an AWS node? |
Figure 8: Scanning |
Sure, these are sample logs, but as an exercise opportunity, the work beautifully conveying how important it is to analyze from multiple perspectives.
Wrap Up
Yes, RITA is work in progress, but if you use it only as an excuse to improve you ELK stack fu, you're already winning. Yes, we all love Splunk, but no we cannot all afford it. RITA and ELK go a long way down the path to free and open source alternatives, particularly for Bro users, which you should all be.
Keep an eye on this project, I love where it's going, I'm betting the futures for this one.
Ping me via email or Twitter if you have questions: russ at holisticinfosec dot org or @holisticinfosec.
Cheers…until next month.
7 comments:
I really like the concept behind RITA and I plan to use the utility to monitor my network for intrusive behavior. I am currently having problems using the "Hunt Team Security Searching" utility when performing beacon analysis. I modified the run.sh script to ingest my actual Bro logs... and this part seems to work. When I attempt to perform beacon analysis the utility successfully "Retrieves information from elasticsearch and builds the dictionary". It then consumes 100% of the 4 CPU cores when it "Runs the beacon analysis" and freezes at ~13%. Is there an error log to help identify the problem with beacon analysis? Thank you, Chewy.
I thought I'd try this with just 1 month of Bro logs, big mistake.
Thought OK I'll try with just 1 week, still big mistake.
So I ended up throwing just one day of logs at it, logstash script took ~7 hours to run, beaconing module took ~4 hours to build dictionary/run.
The OVA is vmdk with an 11gb partition, hard to resize vmdk(need to convert to vdi first, then boot to live gparted cd to extend) if you have even a small amount of logs, you'll need to resize.
Definitely has potential, but like you say it's still a work in progress.
Chewy and _bk201 Hello, I'm Lawrence Hoffman, one of the developers at Black Hills Infosec working on the RITA project. Thanks for trying RITA! In both of these cases it sounds like resource issues. At BHIS we typically run a 24 hour set of logs on a machine with at least 8 cores, 16 GB of ram, and a 500 GB solid state drive. We also try to keep the OS install minimal to ensure that there's not a lot trying to run in parallel with the analysis. Given all of that we often still see long running times. We're working on making the algorithms more efficient within the limitations of the python environment, but due to the kind of processing we're doing here RITA will likely always require a fairly stout machine. It's important to remember that we're not looking for signatures, the software is actually consuming (in the case of beaconing) all of the connection information for each internal source address and performing a mathematical analysis on timestamps and destination addresses. I'd be glad to help if I can, you can contact the development team through GitHub at https://github.com/blackhillsinfosec/RITA.
Thanks for the explanation Lawrence, I'll try run RITA directly on my Bro server(16 cores, 32gb ram) instead of a VM(had 4 cores, 4gb ram).
Hey guys, sorry for this silly question. I'm a junior sys admin so still learning.
Do I need to join this VM to our domain or can I just load this VM to a client machine and set the vnic to bridging mode ?
Benny,
Domain-joined not really relevant or necessary here. Add a second NIC to the VM though, configure listening from there, manage RITA from your primary. Ideally, eth1 is connected to a SPAN port or a TAP so you have broad listening exposure. Use caution on large networks though, easy to overwhelm yourself. Sampling can be your friend under such circumstances.
Hey Russ,
Thanks for that, I'll try a bit of testing on my home network first so and have a play. Exiting project BTW
Post a Comment