In this week’s guided threat hunting blog, we will focus on hunting for Let’s Encrypt certificates being used to encrypt communications from administrator accounts logged into critical infrastructure. Identifying policy violations like this is simple with the use of a guided threat hunting filter.
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 admin user activity?
It is incredibly important for security teams to have visibility of unusual communications occurring on critical infrastructure - domain controllers, common communication servers, sharing servers, etc. Unusual communications are any communications which do not appear on a regular basis or have never been seen before on the network. In general, it is considered unusual for communication to come out of critical infrastructure towards the public domain.
In some instances, these communications come from administrative accounts and are encrypted using Let’s Encrypt. If this is not a common practice in your organization, then it is possible that the accounts sending the communications could be compromised. Otherwise, it is likely a policy violation that should be addressed in order to maintain high levels of visibility and avoid any security risks.
Identifying unauthorized admin user activity using SSP
In this example, we have 3.3 million alert events plus additional network protocol and flow logs. This is rather dense in terms of noise and visibility, so we need to narrow our results down to find what we are looking for.
The hunt for unauthorized admin user activity
To begin this hunt, we need to transfer our hypothesis into a hunting formula.
The basics of the hunt idea is that critical infrastructure administrators are expected to have or be within a certain communication footprint. In this case, Let’s Encrypt certificates are not authorized for encryption to and from critical infrastructure because of the organization’s policy.
We want to answer this question:
What critical infrastructure was involved and who was logged into it when an unusual communication occurred?
We could just be confirming that no unusual communication occurred under the admin accounts, or we could discover a policy violation. To find out, we need a list of all critical infrastructure hosts that were served or presented with Let’s Encrypt certificates for encrypted communications while initiating communication themselves in those cases.
The first thing we do is head to the Host Insights tab in the Hunting interface.
Select TLS Issuer as Let’s Encrypt by inputting “Let’s”.
Now we need to see if the administrator accounts were logged in when this happened. To do this, we select “Hosts: Username” and filter by typing “administrator”.
This filter narrows our results from 3.3 million events and 11,000 Host Insights down to only 1 host in the selected timeline. This gives us an excellent starting point to work from.
It’s important to know who the client and offending hosts are and if there is 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.
This shows us that this host is a domain controller.
We can see here that the administrator’s account was likely used to reach out to the outside/public domain.
Now we want to know what this communication flow was and when it was first seen on the network. To do this, we can click on the Alerts tab and select the Sightings view. This leaves us with the following three results out of 3.3 million alert events.
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 three sightings are the first time we have seen this TLS subject, serial, and SNI in the network. We need to get a better understanding of this encrypted communication, so we can expand one of the TLS events and look further 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 seems quite suspicious and not what we would expect an admin account to be doing from a domain controller.
As we can see above, we have a few IoCs: IP, TLS certificate, TLS issuer, JA3, JA3S, and Domain. We can further investigate those IoCs and see where else they 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% REST API capable and easy to integrate. As such, we can also use REST API calls as part of a SOAR playbook.
REST API / SOAR
Python script example that can be utilized as part of a SOAR playbook:
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*&host_id_qfilter=host_id.username.user=administrator
"""
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 rest-admin-user-cert.py
Classification
As previously mentioned - we can easily select the IoC (TLS SNI, JA3, JA3S, IP, etc) 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.
