This is the second part of my threat hunting blog series. Please click here for the first part.

Introduction

It was once put to me that, much like hunting in the wilderness, so much of what matters is not the last pursuit of target, but the long stalk. It is crucial to learn to read the land and the patterns of the local wildlife as well as the predators. Understanding the lay of the land is as important as it was for our hunter-gatherer ancestors as it is to hunting threats in your organisation’s network.

To increase the overall security posture of an organisation as an in-house security or managed security service provider (MSSP) you need to learn what is normal and what is abnormal in that organisation. You must understand what that organisation’s current policies around software downloads are, website filtering, vulnerability patching, remote login abilities, or file access permissions, among other controls (or lack thereof).

The types of risky behaviour you will naturally uncover as a threat hunter can include, but is not limited to, the activities of the users you are responsible for protecting, who do things such as downloading potentially dangerous software or visiting unsafe websites and clicking on things they should not. These are the sorts of risky behaviours that that are likely to lead to malware infections, if left unchecked.

Risk Hunting (Threat Hunting Lite)

The interesting thing about threat hunting is that, ideally, you don’t come across any signs of malicious behaviour often or, even better, at all. Therefore, if you’re never finding anything to escalate you may have to augment your hunting program to increase your scope from only threats to risks.

In my viewing, risk hunting involves performing a type of proactive attack surface review by checking internal and external security posture instead of checking only for signs of malicious activities in the environment. Risk hunting would be more ‘left-of-boom’ as my US colleagues who’ve served in the military may like to say.

To introduce this concept of risk hunting in a threat hunting context, I want to use some examples I gathered from the Curated Intelligence community, which consists of in-house CTI teams, CTI analysts for vendors, detection engineers, full-time threat hunters, analysts at MSSP, as well as digital forensics and incident response (DFIR) consultants.

In these examples, let’s use a threat hunting specialist called Hunter. The important thing to remember these are all based on real-world examples, sometimes with hard lessons learned.

Risk Hunting Example 1

An adversary has been reportedly mass exploiting an Internet-facing networking device.

Hunter uses CTI sources to identify this campaign. Hunter then checks if their organisation uses the device, as well as if it is patched and for any indicators of attack (IOAs) or indicators of compromise (IOCs). While performing checks for the networking device, Hunter finds that an employee has installed an unrecognised VPN client on their workstation.

Hunter then escalates the endpoint with the unauthorised VPN client installed on it to another infosec team for removal, due to non-compliance with security policy.

Usage of VPNs without a proper justification of why it’s there is a clear risk to Hunter’s organisation, but no signs of malicious activity were technically found.

Risk Hunting Example 2

An adversary has been reportedly leveraging a misconfiguration in a collaborative chatting application that enables users to receive messages from external senders directly.

Hunter uses CTI sources to learn about this campaign. Hunter then checks if that misconfiguration impacts the collaborative chatting application used in their organisation by escalating it to another infosec team for remediation.

The misconfiguration presented a clear risk to the organisation due to there being an active campaign leveraging it in the wild. Leaving it in that state leaves them open to attack.

Risk Hunting Example 3

An adversary has been reportedly hosting their payloads on file-sharing web services as well as performing data exfiltration to them (such as DropMeFile, Mega[.]nz, or pCloud).

Hunter looks for internet connections to these websites. Hunter found Discord.exe on an employee’s workstation connecting to the Discord Content Delivery Network (CDN).

Hunter escalates the application for removal. While having legitimate use, it is not currently threat, but it poses a significant risk related to receiving malicious files, phishing links, or can be used for data exfiltration.

Risk Hunting Example 4

An adversary has reportedly stolen credentials from scheduled tasks.

Hunter looks for scheduled tasks created with plaintext credentials. Hunters finds out that an IT sysadmin has created a scheduled task with plaintext credentials using their Domain Admin account.

Hunter escalates the risky scheduled task to the IT sysadmin. While no adversary has been found in the network, this is a highly risky practice that lacks security considerations. If an adversary was able to gain initial access and move laterally, they could gain the highest-level privileges by simply uncovering the scheduled task.

Risk Hunting Example 5

An adversary has been reportedly brute forcing non-production legacy test tenants.

Hunter performs a check to find out the asset inventory of the Azure tenants the organisation owns. Hunter finds a legacy test tenant that does not confirm with organisational standards and policies, such as enforcing multi-factor authentication (MFA) on all accounts and a lack of logging.

Hunter escalates the legacy test tenant to engineering and recommends either decommissioning the tenant or making it comply with the organisation’s current security policies.

Final considerations

Hunting for threats and risks can be performed by multiple teams. While some Security Operations Centers (SOCs) may have embedded Threat Hunting teams other organisations have dedicated Detection Engineering and Threat Hunting (DEATH) teams. I know of organisations that have a Cyber Threat Intelligence (CTI) team that is standalone from a SOC or Security Engineering team that also performs threat hunting duties.

In other cases, across the cybersecurity industry, you will see dedicated monitoring and threat hunting teams (think CrowdStrike’s Overwatch team and Falcon Complete server) that performs constant reviews of endpoint logs specific related to endpoint detection and response (EDR) sensors. This is typical for managed security service providers (MSSPs). But they are only seeing one part of the picture.

In-house hunting teams will often have access to many types of tools and logs, which may get ingested all into a SIEM or SOAR platform. This can include Firewall logs, Web Proxy logs, Endpoint logs, Cloud logs, Identity and Access Management logs, and Email Gateway logs, among others.

Conclusion

While risk management is an altogether different discipline from CTI and threat hunting, having the resources to track, plan, and mitigate risks will depend on the maturity of an organisation.

To begin this process as a threat hunting team, however, you will need to define what can be considered a risk, create processes related performing risk assessments, create a risk register to track all you have discovered, and ultimately begin to understand your organisation’s risk appetite.