This week’s guided threat hunting blog focuses on hunting for Let’s encrypt certificates that were used to encrypt communication from critical infrastructure. Policy violations such as this one are easily identified using the Stamus Enriched Hunting Interface.
Stamus Security Platform (SSP) automatically detects and identifies threats on the network, and presents security teams with incident timelines and extensive context for each threat. Many organizations take advantage of advanced SSP features and take an even more proactive approach to their defenses. When this is the case, they might task a security analyst with hunting for specific threat types, anomalous activity, or suspicious behaviors. To do this, they can use the Stamus Enriched Hunting Interface.
This interface provides security practitioners with over 100 ready-to-use guided threat hunting filters, including various filters for policy violations, that they can use to investigate, classify, escalate, and automate vast amounts of event data, alerts, and contextual metadata. For a more detailed look at the Enriched Hunting Interface, read the blog article titled, “Introduction to Guided Threat Hunting”.
What is unauthorized activity from critical infrastructure?
It is always important for a security team to have full visibility into all communications coming to and from their critical infrastructure. For example, domain controllers, common communications, and sharing servers are all pieces of critical infrastructure. Because of the importance of these systems, most organizations have policies in place that dictate what communication can go in and out. When that communication is uncommon or unusual, it could signal that there is a policy violation going on somewhere.
In general, all communication coming out of the critical infrastructure towards the public domain is uncommon. When it happens, the security team needs to be able to diagnose why it is happening and if there is a greater underlying issue. In our example, we want to see all of the Let’s Encrpyt certificates that have been used to encrypt communications coming out of our critical infrastructure, as this could lead us to discover some violations.
Identifying unauthorized activity from critical infrastructure using Stamus Security Platform
A regular working day could look something like this: 1.4 million alert events plus network protocol and flow logs, so pretty verbose and dense already in terms of noise and visibility.
In this example, we are seeing 1.4 million alert events in the last 24 hours. This is in addition to protocol and flow logs as well as Host Insights for 128,000 network endpoints/hosts. In all, the data we are presented with is fairly dense, and we need to filter it down to find what we are looking for.
The Hunt for unauthorized activity from critical infrastructure
To start this hunt, we first need to develop a plan based on what we are looking for. We know that there are some unusual communications coming from part of our network that could be signaling a policy violation. Since we want to see communications coming out of our critical infrastructure – specifically ones containing Let’s Encrypt certificates – we need to get a list of all critical infrastructure hosts that were served or presented with Let’s Encrypt certificates.
To do this we go to the Host Insights tab in the Hunting interface.
Select Protocol, TLS, Issuer to be “Let’s” encrypt.
We also want to see if the administrator accounts were logged in while this was happening, so we select “Hosts: Roles” and then input “domain controller” to get us there.
This gives us a list of Domain Controllers using Let’s Encrypt as clients to encrypt communication.
These steps narrow our results down from 1.4 million events and 128,000 Host Insights to only 3 critical infrastructure Domain Controllers in the selected timeline. This is a much better starting point to work from in our investigation.
By selecting one of these Domain Controllers, we can see who the client and offending hosts are and if there is any additional information about those seen on the network. Specifically, we need to see which services are running on the offender’s host.
To do this, we can use Host Insights - a very powerful feature included with the Stamus Security Platform. Host Insights tracks over 60 security-related network transactions and communication attributes of a host. This provides a single place to view many aspects of the network activity relative to a given host, such as network services, users, or TLS fingerprinting forensic evidence.
When we zoom in on more details for that host we can confirm that it is a domain controller.
Now we want to see what this communication flow was and when it was first seen on the network.
To do this, I can simply switch off all alerts from the view (using the widget on the right upper corner) and that will leave me with only new and previously unseen communications from that Host.
Then we can zoom in on the communication itself – in this case our TLS fingerprint and TLS certificate issuer.
Now we want to further investigate the detailed evidence like protocol logs, flows, and anything else that might be insightful.
To do this, we simply click on the Alerts tab and select only the Sightings view (switch off actual Alert events and only leave Sightings). This leaves me with the following 2 results.
The generated events are already enriched by SSP to include important metadata like DNS records, TLS protocol data containing certificate names, fingerprint JA3/JA3S, connection flow sizes, http user agent, http host, request body, status codes, file transaction info, and more.
These two sightings are the first time we have ever seen this TLS subject, serial number, and SNI in the network. To better understand this encrypted communication, we can expand one of the TLS events and look into the protocol metadata.
From here, we can select a specific event and further review the supplemented network protocol and connection logs evidence. This information not only provides context for our current hunt, but also allows us to use the available metadata to create other hunting filters for future use.
Security analysts can use any piece of metadata to create simple or complex filters for things like wildcarding, negation, or inclusion. You can even include multiple fields for fast drill down capabilities. All domains, TLS SNI, IP addresses, HTTP hosts, and more can easily be checked with an external threat intelligence provider such as Virus Total.
The SNI does not appear to be something we would expect to be directly communicating with the Domain Controller.
We have an IoC that we can further investigate and see where else it has occurred on the network.
Armed with the above information and evidence, a threat hunter has enough information to generate an Incident Response ticket.
However, there are still two tasks left to complete:
- 1. We do not want to have to repeat this exact same process again in the future, so we need to set up classification and auto-escalation for future occurrences.
- 2. If anything like this has happened before, we want it to be found and escalated with all the associated evidence - all based on historical data.
We can easily select the IoC (TLS SNI / JA3 / JA3S IP etc) and further escalate; however, Stamus Security Platform is 100% RestAPI capable and easy to integrate. As such, we can also use RestAPI calls as part of a SOAR playbook.
RestAPI / SOAR
import requests
import json
# api-endpoint
URL = """
https://stamus.security.platform.ip/rest/appliances/host_id_activity/?tls.issuerdn=*Let's*&host_id.roles.name=domain controller&qfilter=tls.issuerdn:*Let's*
"""
TOKEN = "insert_sec_token_here"
AUTH = {"Content Type": "application/json", "Authorization": "Token " + TOKEN
}
# sending get request and saving the response as response object
r = requests.get(url = URL, headers=AUTH, verify=False)
# extracting data in json format
data = r.json()
print(json.dumps(data, indent=2))
Then we simply save that file and run it
python3 restaip-list-letsencrypt-from-dc.py
Classification
As previously mentioned - we can easily select the IoC (TLS SNI in our case) and further escalate/classify.
In order to streamline the event review/triage process in the future, an experienced analyst can choose to tag/classify the events associated with this filter By doing so, SSP will tag future events that match the filter criteria as “relevant” or “informational,” depending upon the analyst’s selection. These tags can be used to automate event review/triage and make it easier for a less-experienced analyst to identify events that are relevant for manual review.
To do so, the analyst selects the Tag option from the Policy Action menu on the right hand side menu. This action will cause SSP to insert a tag into each event record as shown below:
This allows the analyst to easily filter out or search for them in any SIEM (Chronicle, Splunk, Elasticsearch, etc) or data lake using that tag.
It also allows for easy filtering out of those events in the Stamus Enriched Hunting GUI by switching to “relevant” only classified events.
Escalation and Automation of this Hunt
To set up an automation which causes SSP to escalate past and future occurrences, we can create a Declaration of Compromise (DoC) event from the Policy Actions drop down menu on the right hand side panel in the Stamus Enriched Hunting Interface.
The next step is to add some explanation about the type of threat. This also gives us a chance to provide informational context and helps convey knowledge to colleagues
Select options to generate events from historical data and generate Webhook notifications.
Just like that, the hunt and all related activities are complete. Any past or future generated events from that automation will then be further auto-classified and escalated to the desired response process - via SOAR playbook, chat notification, or incident response ticket.
Conclusion
The post-hunt activities completed in this example are just the tip of the iceberg when it comes to the automation and escalation capabilities of Stamus Security Platform (SSP). To learn more about these features and how to implement them, read our article titled “After the Hunt”.
To learn more about Network Detection and Response (NDR) from Stamus Networks and see the enriched hunting interface for yourself, click the button below and schedule a live demo.
