There is often a huge disconnect between what attackers do and what we as defenders do to detect them. There is currently a huge push to develop better and better indicators of compromise (IOC) or better threat intelligence. But if we sit back and think about these advancements in security, it becomes clear that we are still stuck in the process of trying to build better and bigger blacklists, still stuck believing we can somehow define evil away by building systems to find and neutralize it.
This will not work.
We continue to look for the easy button. We continue to seek out automation of our security infrastructure.
This will not work.
The reason these things will not work is because our defenses are static and accessible to all. All it takes is for an adversary to acquire these technologies and figure out how to bypass them before they sling a single packet at your network. This is one of the key reasons we work so hard to develop active defense approaches. But active defense will only go so far.
There is a new development in security called "hunt teaming." This is when an organization puts together a team of individuals to actively look for evil on a network. It takes some big assumptions on the part of the defenders. The first is that security automation has failed somewhere. The second is that existing technologies will not be sufficient to find the bad guys. Even more critical, "hunt teaming" requires a fundamental shift in how we approach detecting attacks.
Traditionally, our approach has involved a set of simple signatures. For example, one of Black Hills Information Security's (BHIS) tools, called VSagent, hides its command-and-control (C2) traffic into __VIEWSTATE parameter, which is base64 encoded. Further, it beacons every 30 seconds. Unfortunately, attackers can easily modify the backdoor to bypass any simple signature you throw at it. It also represents many of the nasty C2 techniques we have seen over the past few years.
A new framework for hunt teaming
How then, should we approach malware like this? The question asks us to not just look at individual TCP streams but rather look at the communication as it relates to much larger timeframes. To help with this, SANS has released a free new tool, Real Intelligence Threat Analysis or (RITA). (Note: The password for the ht user account is !templinpw! Because it is in OVA format it is portable to other VM environments.)
Currently, there are a number of different frameworks for pen testing, like Metasploit, SET, and Recon-ng. The idea behind RITA is to create a framework that it is extensible; it allows people to continuously add additional modules to it.
Let’s take a few moments and walk through the current modules in RITA.
- First, to start RITA we just need to fire up the run.py script in the /home/ht/Documents/RITA directory.
- Then, open a browser and surf to http://127.0.0.1:5000.
- Next, we are going to enter an example customer where the example data is stored on this VM:
The beaconing module will use Discrete Fast Fourier Transform (DFFT) to move the connections leaving your network from the time domain to a frequency domain.
Why? When we think about events, we tend to think of events as a series in time. When we look at things, it’s in terms of first, second, and third. However, we can also look at time in terms of frequency. For example, if we have connections connect at regular intervals, it will show up very clearly as a DFFT. So, when we run this module it will create graphs showing likely beaconing behavior.
Detecting a two-second beacon
The graph below shows a two-second beacon. This means there is a detectible frequency of two-second intervals between two hosts. This type of signature analysis is very difficult on standard security devices like IDS and IPS.
But we can go further. We can also look for systems connecting to blacklisted IP addresses, potential scanning behavior, long duration connections (good for data exfiltration), and accounts that have multiple concurrent logons to multiple systems.
The beautiful thing about RITA is that the data can be exported to the desktop, but can also be visualized via Kibana. For example, if you run the concurrent module, this module will show all accounts which are logged in concurrently to multiple systems. This is great for detecting lateral movement. By running this module, it will run the module and load the data into Kibana for visualization. (To see the results, you’ll need to select the results tab at the top.)
To load some results, you start by editing the time it reviews in the upper right hand corner. It should say “Last 15 minutes.”
- Then, select “Last 5 years”
- In the middle box, type “result_type=”
- It will show you some autocomplete some options
- Select result_type=concurrent
- This will show the systems with multiple concurrent connections
As you will see, the targetUserName of Fire_Phreak is logged on to multiple systems at the same time. That should give you a first start with the RITA VM. Good luck!