From IOCs to TTPs: An agentic threat hunting case study

Every security engineer has a version of this ritual. 

A new campaign hits the news, and you already hear the question coming, “Are we covered?”

So you read the writeup and quickly do the calculus on whether you can extract meaningful data, something to base a behavioral detection around — or not.

Then the choice is: Send the IOCs you can identify to your blocklists and move on for now, or try to dig deeper. The limitations of the first choice are clear; so are the challenges of the second.

That’s the uncomfortable gap between “We’re aware of this threat” and “We have strong detections around it.”

Because you already know that the IOCs for a novel browser-based attack are likely outdated the moment you block them. And in the case of a new technique observed by Microsoft earlier this year, you’d be right.

In March, Push’s AI agents took a close look at that Microsoft intel, which details a discovered campaign built around a novel OAuth redirect abuse technique used to deliver users to phishing pages under the cover of trusted services’ OAuth flows. 

What we found was indicative of how these attacks rapidly evolve: No matches for the published IOCs across our install base. But a few months later, we got a true positive. Except it was for new lures, new variants, and different IOCs. What hadn’t changed was the underlying attack delivery technique, and that’s what we used to detect a new campaign on Push customer estates.

In this article, we’ll walk through this example as a case study of how agentic threat hunting helps us go beyond IOCs to extract durable behavioral indicators that close the gap between “We’re aware of this threat” and “We’re covered.”

The intel: Novel abuse of OAuth redirects as a phishing delivery mechanism

The technique Microsoft documented back in March is an interesting one. It doesn't steal tokens or abuse consent flows. Instead, it weaponizes the OAuth error-handling path itself — turning trusted identity provider domains into a delivery mechanism for phishing and malware.

Here's how it works. The attacker registers a malicious application in an actor-controlled tenant, pointing its redirect URI at attacker infrastructure. They craft an authorization URL using prompt=none (forcing silent authentication) and an intentionally invalid scope, which guarantees an OAuth error. 

The identity provider — Microsoft Entra ID, Google Workspace, or any OAuth-compliant service — handles that error the way the spec says it should: By redirecting the browser to the application's registered redirect URI. The user clicks a link that begins at login.microsoftonline.com, passes through a legitimate authentication endpoint, and lands on an attacker-controlled page.

Importantly, no token is stolen during the redirect. The OAuth flow is the delivery vehicle, not the compromise mechanism. What happens after the redirect — phishing, malware download, credential harvesting — is where the actual attack occurs.

This technique is also successful because conventional URL filtering sees a legitimate authentication domain, not a phishing destination. The redirect is standards-compliant behavior, and the initial URL carries the domain reputation of a trusted identity provider — which means the usual defenses at the network layer don't fire. (No TI or domain-based detection service in the world would raise a microsoft.com domain as suspicious!)

With this intel, Push’s agents now had some useful fodder to hunt for.

Hunting from intel: How we developed a behavioral detection

It started with ingestion. When the Microsoft blog was published, Push's TI aggregation agent flagged it as relevant to our detection surface — the technique abuses OAuth redirect behavior observable in the browser, which maps directly to the metadata that Push's browser agent captures.

The Push intel agent understands not to hunt for IOCs, but rather to think in terms of durable behaviors. It understands the telemetry available to the Push browser extension, and then compares that to the telemetry it would expect to be able to extract for a given technique, before deciding what to hunt for.

In this case, the intel agent extracted two distinct behavioral elements from the research to look for: the OAuth redirect technique and the page users land on after the error.

That extraction step is where surface-level details can become technique-driven hunts. Microsoft's article listed specific client IDs, redirect URLs, and PowerShell command patterns — indicators that are useful for retrospective hunting but will rotate as the campaign evolves. 

The pipeline's job was to identify what wouldn't change: The behavioral mechanics of abusing the OAuth error redirect path as a delivery mechanism, independent of which domains, client IDs, or post-redirect payloads the attacker chose to use. This is the Pyramid of Pain principle in practice: Hunt for the technique, not the indicator, because techniques are genuinely hard for attackers to change.

Next, the agents verified what they already knew from Push’s internal TTP knowledge base. In this case, the agents understood the well-known technique of open redirects, where attackers leverage redirects to deliver users to a malicious page. The example originally published by Microsoft was a novel variation of that — abusing a trusted service and the open redirect technique via a legitimate OAuth error workflow to deliver a multi-stage phishing attack.

AI models’ deep knowledge of web programming and frameworks is a particular strength here, because they understand which OAuth redirect behavior is normal and common across diverse scenarios, and can pinpoint which elements will be the strongest signal to hunt for malicious behavior. The agents immediately recognized that hunting for prompt=none would be too noisy, as legitimate apps regularly use silent token refresh.

In this case, the approach was simply to find all the instances where a user hit an OAuth error page, and then landed on a login page afterward. Normal behavior for error states would be to return an error response — not send the user on to a page with a password form field or a CAPTCHA. That’s highly suspicious.

The agents then built behavioral queries targeting both behavioral attributes of the attack, and validated them across Push's install base. 

When agents first looked in March, the hunts returned no true positives — the specific campaign Microsoft documented wasn’t active against Push customers at that time.

But the query logic was sound — precise enough to avoid false positives, broad enough to catch technique variants without relying on the specific IOCs that Microsoft documented. So the pipeline promoted it to a live query — a continuing detection that would surface any future instances of the technique across the customer base.

The hunt pays off: A new variant, completely different IOCs

In June, the query fired. A single user at a single customer had been targeted, but with a completely different scenario. 

Where the Microsoft-documented example used lures presented as document-sharing links, Teams meeting recordings, or password resets, and the abused trusted service was a Microsoft login link used to trigger the OAuth error, the Push-observed attack chain used different elements. However, the behavioral technique at the core was the same.

In this case, the user clicked a link in a service desk ticket, triggering an OAuth flow that used a redirect URL with parameters designed to make it look like a Grammarly link. After hitting the OAuth error, the user was redirected to a page with a CAPTCHA, and then redirected again to a second page behind a Cloudflare Turnstile that was running a phish kit. While examining the phishing page, Push’s agents found a net-new phish kit that they later added additional detections for. 

Roughly a day after the Push detection fired, Google Safe Browsing flagged both domains as phishing domains. But when the user was first targeted, neither domain had been flagged. In this case, the user exited the redirect flow before entering any credentials.

It’s important to note that this phishing technique also bypasses other controls based on network content pattern analysis or domain-based detections. For example, a network proxy is designed to look for malicious webpages based on known-bad IOCs like domains or page content that contains known-bad script files. This technique uses a dynamic obfuscated Javascript blob that unpacks and loads the webpage on the client side after checking to see if it’s running in a live browser environment, evading proxy-based analysis.

The query now serves as another early-warning flag designed to be broad enough to catch other interesting new variants of this TTP.

Why technique-level detection pays dividends

This example demonstrates the value of behavioral detection. By focusing on technique extraction, we can stay a step ahead of attack evolution, identifying other contexts and campaigns that use the same behavioral technique, without relying on stale IOCs.

For customers, this means no one has to distil the threat intel report into behavioral elements, spend time crafting detections, or work to eliminate false positives. The Push agents do all that automatically, delivering a compounding benefit the more they learn. 

Customers get a fully operationalized threat-hunting and detection engineering capability; and the Push knowledge base itself expands with each new hunt, getting better at identifying emerging threats.

If you'd like to see how Push's detection pipeline would work in your environment, book a demo with our team.