Building effective threat hunting queries for phishing campaigns
Phishing is the most prevalent threat facing organisations today, and while prevention is essential, phishing threat hunting (proactive detection) is critical. For businesses that reported experiencing cybercrime in 2024, 90% of them reported phishing attacks as one of those crimes.
Phishing emails have grown far more sophisticated. They’re no longer just a one-off message to your IT helpdesk from a fake “Microsoft Support Helper” with the subject line “URGENT PASSWORD RESET.”
Today, they are multi-layered attacks that use techniques such as URL obfuscation and phishing kits sold on the dark web, capable of sending thousands of convincing emails to your organisation with a single click.
This blog will walk through why proactive hunting is needed for phishing emails and the process of building effective queries specifically tailored for identifying and analysing phishing campaigns.
Why phishing threat hunting matters
Phishing has become one of the most common and costly attack vectors because it targets human behaviour, not just systems. Traditional security controls can only go so far, meaning that proactive hunting is now a core capability for any mature SOC team.
Email security basics: SPF, DKIM and DMARC still matter
For a long time, the only email security tooling feature needed was Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting and Conformance (DMARC).
These are email authentication protocols that check if the email a user receives has been sent by who it says it has, and the original message is intact.
- SPF: This protocol specifies which IP addresses or mail servers are allowed to send emails on behalf of a domain. This helps to detect forged ‘MAIL FROM’ headers.
- DKIM: Confirms the integrity and authenticity of the email body and headers by using cryptographic signatures to validate that an email’s content was not altered in transit and was sent from an authorised domain.
- DMARC: DMARC builds on SPF and DKIM by allowing domain owners to enforce policies like rejecting/quarantining emails that fail these checks and allows security teams to track abuse attempts.
Why proactive threat hunting is essential for security
Email protection such as Microsoft Defender for Office 365, Mimecast and Proofpoint all offer email security – however, they’re not bulletproof.
Automated tools are good at detecting known threats, and some tools work retroactively, like Microsoft’s zero-hour auto purge (ZAP,) which can detect and neutralise malicious phishing, spam, or malware messages.
ZAP works by searching emails for known indicators of compromise (IOCs) and, in a minority of cases, can do enough to stop basic phishing attacks.
These IOCs, such as file hashes and blacklisted domains or URLs, are identified reactively by organisations. These detection methods fail to detect more evolved methods with attackers using fresh infrastructure (newly registered domains) and obfuscated URLs that have not been flagged by threat intelligence or blocklists.
This allows more advanced phishing attacks to bypass traditional methods of detection.
Many organisations do not have this basic tooling, which further increases their susceptibility to such attacks, and that is without mentioning larger, more sophisticated attack campaigns.
Learn why this Red Bull Phishing scam is one of the most viewed pages on our website.
This is where a SOC performing proactive hunting comes in, investigating logs for the threats traditional tools missed. Threat hunting begins with a hypothesis, looking for unknown or emerging tactics that automated tools will not be configured to look for yet.
From this, a security analyst will investigate across various logs while not being limited to a single system; an email filter, an EDR agent or a proxy, and correlate this data together.
Think of a suspicious email sent to a user, followed by a URL click within the email body, followed by a suspicious login to that user’s account.
Detection tools may only alert on the suspicious email and login, but during threat hunting, an analyst can discover that the suspicious email was used to urge the user to click the link and reset their password; however, this was a malicious link used to steal that user’s credentials, which then allowed them to log into that user’s account.
While traditional tools focus on known threats, threat hunting is a security team’s way of finding the threats hiding in the grey areas that those tools miss.
Proactive threat hunting is a core component of Evalian’s service offering and is vital for any organisation aiming to achieve a mature and robust security posture.
Practical phishing threat hunting
To begin threat hunting, first I must decide what ‘success’ will look like. Am I looking for new IOCs, tracking user behaviour via URL click-throughs or discovering lateral movement or secondary payloads?
After this, I’ll need to decide on the data sources that matter to our investigation; these will include email entities, network traffic, EDR logs, and user authentication logs. Together, these will provide a clear picture of any events that have occurred.
The next step in this process is to start searching these logs for signs of malicious events, and this is where query building starts.
Building phishing detection queries in Microsoft Sentinel
Evalian uses Microsoft Sentinel and Microsoft Defender XDR to gain visibility into our customers’ environments. To build threat hunting queries, we use Kusto Query Language (KQL).
To show how a detection query is built, I will use an example based on Scattered Spider’s tactics, techniques, and procedures (TTPs). Scattered Spider is well known for targeting IT service desks and in the past has created domains mimicking the helpdesk website for a company to steal user credentials with URLs like:
- targetorg-sso[.]com
- targetorg-servicedesk[.]com
- targetorg-okta[.]com
- targetorg-helpdesk[.]com
Mapping to the MITRE ATT&CK framework
Any detections we build are always mapped to the MITRE ATT&CK framework. This helps align the hunts to known adversary behaviours and identify coverage gaps whilst systematically exploring tactics and techniques across the attack lifecycle.
In this example, the detection I am building maps to:
- T1583.001 – Acquire Infrastructure: Domains – Detects domains that trick users into thinking they are legitimate.
- T1566.002 – Phishing: Spearphishing Link – Detects emails that trick users into clicking malicious URLs.
The objective of my query is to detect phishing emails sent to users that include suspicious domains using spoofed branding
Building the detection
To detect this behaviour, I first built a KQL query that searches a device’s network events and looks for those domain strings.
My initial version of the query simply looks for the indicators across all network events and, on its own, may return many legitimate logs, allowing suspicious entries to hide amongst legitimate ones.
To filter down the results, I look for emails that contain the URLs, which could potentially indicate that they are phishing emails, using the following query. The resulting query puts the potentially suspicious URL endings into a single variable, which I can then query later.
For now, I use the new variable to search within the EmailUrlInfo table for emails containing URLs that include the suspicious domain strings.
By joining EmailUrlInfo with EmailEvents based on the common column ‘network message id’, I can filter out results where the email was blocked by automated tools, showing me only emails that have potentially bypassed our customers’ email security.
This is where proactive threat hunting is most valuable, allowing us to identify and investigate threats that have evaded our boundary security controls.
Now my current query looks like this. Combining the two queries I’ve made so far:
So far, I have:
- Correlated device network events to identify connections to the suspicious URLs; and
- Identified emails that contain the suspicious domain strings, where the email was successfully delivered to the user.
For the final step, I will confirm whether a user has clicked the phishing link within the email.
In KQL, the DeviceNetworkEvents table may sometimes show records for URLs that the device has preloaded or accessed in the background. However, this does not necessarily indicate that the user actively clicked on a URL in an email or intentionally visited the site.
Essentially, the presence of a URL in this table reflects network activity from the device itself, which can include automated or background processes, rather than direct user interaction.
By cross-referencing these events with a table such as UrlClickEvents, I can more confidently determine whether it was the user, rather than the system, who performed the action.
Joining this query onto the end of the others gives me the final query:
From this query, any results that are generated could indicate a successful phishing attack, where the email has bypassed automated detection systems and the user has clicked the malicious link.
Turning hunts into continuous detections
Once validated, the hunt can be operationalised. By automating queries as scheduled detections, security teams can continuously monitor for these behaviours and respond faster to evolving phishing campaigns.
Final thoughts: scaling phishing threat hunting with SOCaaS
Phishing threat hunting needs to extend beyond searching for known signatures. Updates to IOC databases are reactive, meaning an attack must occur before it can be identified.
Through proactive hunting across user behaviour and device events, attacks can be discovered and contained before there is any impact.
However, many small and medium businesses don’t have the resources or the know-how to dedicate time to threat hunting; SOC as a service (SOCaaS) solves this point by providing skilled analysts to monitor your environment, resolve incidents and proactively search and detect new threats.
If you’re considering SOCaaS, you may find this useful: 7 Reasons organisations are using SOCaaS in 2025
Turn uncertainty into visibility with Evalian’s SOC as a Service
Our SOC as a Service combines Microsoft Sentinel with expert threat hunters to expose phishing, credential theft and lateral movement before impact.
Learn Evalian’s SOC as a Service includes
You can also view our other services, such as phishing awareness training for your employees.
Contact us to discuss your organisation’s requirements. Or for help in what to look for when choosing a SOC provider, download our free guide and checklist.
