This week’s guided threat hunting blog focuses on verifying a policy enforcement of domain infrastructure usage with Stamus Security Platform. Every organization’s network is unique, but for most organizations it is uncommon to see DNS usage on unapproved DNS infrastructure.
Free and easily available public DNS services are often set up to offer stable and non-censored communication possibilities. However, just as with any other publicly available service, these DNS services can be abused by bad actors. Here are some examples of freely available public DNS services.
When that type of activity is spotted, questions about its origin are important to answer. Guided threat hunting filters can help identify and investigate these types of policy violations.
Stamus Security Platform (SSP) automatically detects and identifies serious and imminent 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”.
Depending on the nature of the business they conduct, some organizations might not allow the use of any other DNS resolvers than the one defined by their security policies. In some cases, enforcing that policy could be incredibly difficult (as is the case in organizations where employees are allowed to use their personal devices for work). Despite the difficulty of enforcing a policy like this, it is important to maintain visibility into instances of unauthorized DNS resolver use. We need to be able to know if any users in the organization or any endpoints are actively using public or foreign DNS servers. This type of monitoring is part of a Zero Trust framework, where all users are continuously validated to ensure that only authorized individuals get access to secure data. Sometimes, the unauthorized use of a DNS resolver could lead to a breach, so performing policy verifications is important to see if there is any suspicious activity that needs further investigation.
In the following example, we want to see if there are any instances of public DNS server infrastructure use within the organization. If we locate any, then we can investigate further to learn more about the user and figure out where the activity is coming from.
Stamus Security Platform (SSP) does most of the work for you. With Declarations of Compromise™, it definitively identifies serious and imminent threats. However, no system can automatically detect everything. That’s why SSP logs every possible indicator of compromise – otherwise known as “alerts”. These alerts can be used to create a trail of evidence in an incident investigation. Additionally – as seen in this series – they can also be used to inform a guided hunt for specific threat types or other unwanted activity.
So let’s take a look at the current alerts on our system:
In the past 24 hrs, SSP has generated about 4.1 million alert events in addition to protocol, flow, and field transaction logs as well as Host Insights for 28,000 network endpoints/hosts.
To begin this hunt, we first have to select the relevant filter from the drop down list. Since there are over 100 guided hunting filters, we need to narrow the list down and find the filter we want. To do this, we can search for a keyword and then select the needed filter. In this example, we search “public dns” and then select the filter titled “Policy: Public DNS queries”.
Selecting this filter narrows our results from 4.1 million down to 7 in the selected timeline. This gives us an excellent starting point to work from.
It is important to note that SSP enriched hunting also provides additional organization-specific context. Users can filter for queries from various departments or user groups within the organization, allowing them to hyper-focus on specific areas without having to aggregate events or organize IP addresses to find specific users or departments. For example:
In one of many enrichment processes, the Samus Security Platform automatically breaks down any http, dns, or tls domains as part of those network protocol records into its subforms - subdomain, domain, tld, host, and domain without tld.
But there is still work left to do. Let’s keep going.
Obviously there was an intention behind those DNS resolutions with the suspect most likely being an unwanted, covert activity. It’s interesting to look at the surrounding landscape from a network security perspective to determine what else has happened that is potentially suspicious or indicates unwanted activity.
It’s important to know who the client and potentially-offending hosts are and if there’s additional information about those seen on the network. Specifically, we need to see which services are running on the potential 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.
We can click the “Hosts” tab on the left hand side panel and be transferred from the actual event logs to the Host Insights screen.
To do this with only one click, we switch from the Dashboard tab to the Host Insights tab.
This gives me the asset inside the organization that is responsible for doing those DNS resolves – a significant improvement from 4.1 million total alerts and over 24,000 hosts/endpoints.
I can further investigate each host and identify the currently-logged-in user and the network protocol log evidence. Below, I would like to review the specific, detailed Host Insights information like application protocol usage, user agent’s hostname, and encrypted analysis – including the time of first and last seen and much more.
Most importantly, we can see that we have a user logged in as well.
We can quickly zoom in on that user from that part of the organization’s network infrastructure and review the events.
We can see here that was is a total yield of 76 events:
One event and its surrounding network forensics evidence in particular is very interesting, and appears to have a possible VBA embedded doc:
With just a few clicks, We are able to view two important sets of evidence:
The alert 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.
We have the related flow and its metrics and the file transaction logs. We can see it as an archive and we have a checksum, filemagic, and all the rest of the file information needed.
For example, here we can see the full network forensic evidence and related network protocol logs, file transactions, extracted files, flow logs, and PCAP:
File transaction log:
Flow log:
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.
However we would like to have more details about the whole transaction and the file itself – good news – we have the file extracted:
If I need the full PCAP of the sessions that is also easily done by clicking on the “PCAP File” tab and having the PCAP downloaded:
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.
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:
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.
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.
And 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.
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. To learn more about these features and how to implement them, read our article titled “After the Hunt”.
To learn more about Stamus Security Platform (SSP) and see the enriched hunting interface for yourself, click the button below and schedule a live demo.