In this week’s guided threat hunting blog, we focus on using Stamus Security Platform to uncover phishing activity. With Phishing, attackers use various social engineering techniques (emails, phone calls, text messages, etc.) to dupe users into sharing information or credentials to a system or sensitive data. Although a trained eye can typically spot these attempts before they are successful, if they go unnoticed, they can be very effective. This is where threat hunting can help identify phishing attempts and related activity by using insights gathered on your network.
Stamus Security Platform (SSP) is adept at automatically detecting and identifying threats present on the network, and presenting 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 users with over 100 ready-to-use guided threat hunting filters, including various filters centered on different types of policy violations, that they can follow 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 our blog titled, “Introduction to Guided Threat Hunting”.
What is Phishing and Why Should You Hunt for it?
Phishing is the most common and effective way attackers gain access to an organization’s network. It typically involves the use of a fraudulent message (commonly by email) where the attacker poses as a trustworthy source and requests sensitive personal information, sends a url that can lead to the download of malicious software, or contains images that are actually executable files.
Many organizations train their employees to recognize phishing attempts; however, accidents happen and sometimes the attempts evade recognition. When this happens, it is often one of the first signs that a threat has made its way onto your network. Hunting for phishing activities on your network can ensure that you catch these threats before they cause damage. To learn more about phishing and the various ways SSP detects it, read this article.
Identifying Phishing using Stamus Security Platform
The enriched hunting interface provides a filter that guides hunters to find this exact type of activity within their organization’s infrastructure using insights gathered from the network. Let’s take a look at an example:
In the past 48 hours, we have had about 1.6 million alert events which have triggered hundreds of thousands of results.
The Hunt for Phishing Activity
To begin this hunt, we first 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 “phishing” and then select the filter. In this example, we select the filter is titled, “MITRE: Technique - Phishing”.
Selecting this filter narrows our results from 1.6 million alerts down to only 5 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 data 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.
To further refine this search – and only include end user clients networks while excluding other networks like test, development, or research – I simply select a wildcard on the organizational context as seen below.
Evidence for Incident Response
With just a few clicks, We are able to view two important sets of evidence:
- The associated network protocol transactions and flow logs
- Host Insights – a single screen for reviewing 60+ network activity attributes collected for every host
The 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.
I can review the event results in more detail by switching to the Alert tab for more information. Here we have a few hints that we can investigate.
From here, we can select a specific event and further explore the 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.
We can see that we have HTTP status code 200 with the supporting clear text HTTP logs. Also included are the username and password that were stolen.
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 every host seen on the network. 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 events logs to the Host Insights screen. In this example we can see the offenders that were involved, what services they used, and who they used it on. In this example we can see Apache web servers serving the content.
We would like to have a list of all the offenders to further scope out the proliferation. Since we now have some very valuable information we can search for any further activity in the organization from that url, domain, server, HTTP service, Apache version, or user agent. We can do this by auditing the HTTP/TLS/DNS and Flow logs.
To do this, we filter on clear text HTTP services related to phishing coming from outside the organization.
Armed with the above information and evidence, the 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.
Classification
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. After 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 focus only on the 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 by using that tag in the query.
It also allows for easy filtering out of those events in the Stamus Enriched Hunting GUI by switching to only “relevant” classified events.
Escalation and Automation of this Threat 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.
For each DoC policy that we create, we add an explanation about the type of threat. This gives us a chance to provide informational context and helps convey knowledge to colleagues.
We may also select the option to generate events from historical data and/or generate Webhook notifications.
Just like that, the hunt and collection of all related activities are complete. Any past or future generated events matching this DoC criteria will be further auto-classified and will trigger the desired response process – via webhook to a 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.
