In a Sophos talk at BSides Edmonton 2026, ClickFix was listed as one of the most common ways attackers get initial access. There are already many public detections for it, and they look at different things. This post is my study note: I put the public approaches side by side and compare where each one fits.
Disclaimer
- The views in this post are my own and do not represent my employer.
- The KQL queries are examples. Adjust and validate them for your own environment before using them in production.
A lure page pretends to be a CAPTCHA or an error message. It quietly copies a command to the clipboard, then tells the user to paste it somewhere and press Enter.
ATT&CK: T1204.004 Malicious Copy and Paste. The execution step usually also involves T1059.001 PowerShell.
Where the user pastes the command decides what traces it leaves:
| Variant | Where the command is pasted | Traces |
|---|---|---|
| ClickFix | Win+R Run dialog | RunMRU registry key; parent process explorer.exe |
| FileFix | Address bar of the browser’s file upload dialog | TypedPaths registry key; parent process is the browser |
| TerminalFix | A PowerShell window the user opens | Almost none |
① Registry. Whatever the user types into the Run dialog is saved as-is in RunMRU. What they type into the file dialog’s address bar is saved in TypedPaths. Query these two keys and you see the full command the user pasted (kqlquery.com, Elastic).
② Process chain. explorer.exe or a browser directly starts PowerShell, cmd, mshta, or a similar program (Huntress).
③ Keywords. Lure commands often end with a # comment and words like “captcha”, “robot”, or “verification” (SigmaHQ). This is accurate, but it stops working as soon as the attacker changes the wording (Prophet Security).
④ Built-in alerts. Microsoft Defender for Endpoint (MDE) already has ClickFix alerts. But the gap between PowerShell starting and the alert firing is often more than a minute (glueckkanja).
⑤ Browser layer. Catch the command at the moment the page writes it to the clipboard. At that point nothing has run yet, so it doesn’t matter which program the attacker uses or how the command is obfuscated. Push Security works this way, and Opera’s Paste Protect, released in July 2026, follows the same idea (Push Security, Opera). The downside is that you need to deploy a browser extension or a different browser.
The queries below map to methods ① to ④ above. Method ⑤ runs in the browser, so there is no KQL for it.
For ①, I think the most useful version ignores keywords and looks only at the “shape” of the command: longer than 50 characters (detect.fyi found the average sample was about 179), and containing a URL, an IP address, or a base64 block.
// ① Registry + command shape: RunMRU (Win+R) and TypedPaths (FileFix)
// No filter on the writing process: for FileFix, the browser writes TypedPaths, not explorer.exe
DeviceRegistryEvents
| where ActionType == "RegistryValueSet"
| where RegistryKey has_any ("RunMRU", "TypedPaths")
| where RegistryValueName != "MRUList"
| where strlen(RegistryValueData) > 50
| where RegistryValueData matches regex @"(?i)(https?://|\b\d{1,3}(\.\d{1,3}){3}\b|[A-Za-z0-9+/]{40,})"
| project Timestamp, ReportId, DeviceId, DeviceName, InitiatingProcessFileName, RegistryKey, RegistryValueData
// ② Process chain: explorer.exe or a browser starts a script interpreter or LOLBin
// OriginalFileName also catches renamed binaries (CrashFix renames finger.exe to ct.exe)
let lolbins = dynamic(["powershell.exe","pwsh.exe","cmd.exe","mshta.exe","rundll32.exe",
"regsvr32.exe","msiexec.exe","curl.exe","finger.exe","wscript.exe","cscript.exe"]);
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("explorer.exe","chrome.exe","msedge.exe","firefox.exe","brave.exe")
| where FileName in~ (lolbins) or ProcessVersionInfoOriginalFileName in~ (lolbins)
// Command-line filter: without it, every PowerShell opened from the Start menu matches
| where ProcessCommandLine matches regex @"(?i)(https?://|\\\\[\w.\-@]+\\|-enc|iex|iwr)"
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine
// ③ Keywords: a "#" comment plus typical lure words
DeviceRegistryEvents
| where RegistryKey has_any ("RunMRU", "TypedPaths")
| where RegistryValueData contains "#"
| where RegistryValueData has_any ("captcha", "robot", "verification", "verify", "human")
| project Timestamp, DeviceName, InitiatingProcessAccountName, RegistryKey, RegistryValueData
// ④ Built-in alerts: see what MDE has already raised for ClickFix
AlertInfo
| where Title has_any ("ClickFix", "RunMRU", "Run dialog")
| project Timestamp, Title, Severity, DetectionSource
Two things to keep in mind:
explorer.exe in query ①. For FileFix, the browser writes TypedPaths.wscript in the command.| Method | Covers | Strength | Weakness |
|---|---|---|---|
| ① Registry | ClickFix, FileFix | Shows the full command; simple rule | Can’t see TerminalFix |
| ② Process chain | ClickFix, FileFix | Doesn’t depend on the command text | Noisy; needs command-line filters |
| ③ Keywords | Depends on the wording | High accuracy | Easiest to bypass |
| ④ Built-in alerts | Depends on the vendor | Nothing to write yourself | Delayed |
| ⑤ Browser layer | All variants | Stops it before anything runs | Extra deployment |
TerminalFix is a blind spot for all the endpoint methods (① to ④). The browser layer is the only one that covers it.
This case comes from the BSides Edmonton 2026 talk Advanced SaaS Threats: Case Studies from the Field by Damien Miller-McAndrews, a threat researcher at Obsidian Security. He walked through three real cases to make one point: many SaaS breaches today use no exploits and no malware. Attackers simply abuse legitimate features and identity trust.
This post covers the third case: the competitive intelligence platform Klue was breached, and attackers stole the OAuth tokens it held on behalf of its customers, then used those tokens to export customers’ Salesforce data in bulk. This post adds the customer’s side: how to detect and respond to an abused third-party integration in Microsoft Sentinel.
Disclaimer
- The views in this post are my own and do not represent my employer.
- Incident details come from public sources and the original talk, which are cited in the text. I am not affiliated with Obsidian Security.
- The KQL queries illustrate detection logic. Adjust and validate them for your own environment before use.
Klue is a competitive intelligence SaaS platform. It connects to customers’ Salesforce, HubSpot, SharePoint, Gong, Slack and other systems through OAuth to read sales data. In June 2026, Icarus, an extortion group that only appeared in April, breached Klue. The attackers used a dormant but still valid credential that had been created for a prototype integration, got into Klue’s backend, planted malicious code, and stole the OAuth tokens customers had granted to Klue. Over roughly the next 24 hours, they used Python scripts to pull CRM data from several customers through the Salesforce REST API, then sent extortion emails to the victims. Klue then disabled all customer integrations, and Salesforce disabled Klue’s app (BleepingComputer).
More than a dozen organizations were affected. Those named publicly include LastPass, 8x8, and Snyk (FINRA). Huntress also confirmed it was one of the victims and published the details of its investigation (Huntress).
This is a textbook SaaS supply chain attack: instead of attacking the target directly, the attacker breaks into a vendor the target trusts and uses the vendor’s access to get in. In MITRE ATT&CK terms, it falls under T1199 Trusted Relationship.
This post is based on Obsidian’s technical analysis, Huntress’s victim-side investigation, and the original talk.
The customers did nothing wrong. At some point they authorized Klue to access Salesforce, and Klue used the token to sync data on a schedule. Everything was normal. The attacker never touched any customer account. They broke into Klue and took those tokens. To Salesforce, the attacker’s requests were simply “Klue calling the API”: no sign-in, no MFA, and nothing that would trigger an identity alert. The attacker first worked out what data each customer’s Salesforce held, then used scripts to page through it and pull everything out.
ATT&CK: T1528 Steal Application Access Token (on the vendor side)
The attacker used a dormant credential at Klue that had never been cleaned up, got into the backend, planted code, and collected customers’ OAuth tokens. According to the talk, that credential was a GitHub personal access token (PAT) that had been alive for about four years. This step happens inside the vendor. Customers can’t see it and can’t detect it.
ATT&CK: T1550.001 Application Access Token
This is the first step customers can see, and it left a clear change in the integration’s “fingerprint” (Obsidian, Huntress):
python-httpx. The attack traffic switched to python-urllib/3.12 and python-urllib/3.14, plus User-Agents of “5238” or blank./services/data/v64.0/; attack calls used v59.0.ATT&CK: T1526 Cloud Service Discovery (closest fit, my mapping)
The attacker first called Salesforce’s Global Describe to list every object in the org. A normal business integration only reads the few objects it needs and almost never enumerates everything.
ATT&CK: T1213.004 Customer Relationship Management Software · T1020 Automated Exfiltration
The attacker ran bulk SOQL queries against objects such as Account, Contact, Opportunity, and Task, then paged through the results with QueryMore to pull everything out. In the worst-hit organization, about 13.9 million records were exported.
What makes this case hard: the attacker uses a legitimate token. Detections based on sign-ins, MFA, or identity risk all fail. The only trace is in the API call logs.
But the case also has a useful property: integrations are far more predictable than people. An integration usually calls from the same few IPs, with the same User-Agent and the same API version, reads the same few objects, and moves a fairly steady amount of data each day. Build a “fingerprint” like that for each integration and alert when it changes. What Obsidian saw in this incident was every part of the fingerprint changing.
The KQL below applies this idea to Microsoft 365, for two reasons. First, Klue’s connections included SharePoint, so the same attack could just as easily land in M365. Second, the Graph API log in M365, MicrosoftGraphActivityLogs, records every field the fingerprint needs (AppId, IPAddress, UserAgent, ApiVersion, RequestUri, ResponseSizeBytes). This table has to be turned on separately in Entra’s diagnostic settings, and many environments don’t have it on by default.
Idea: ask one question: has this app’s “User-Agent + API version” combination from today been seen in the last 30 days? Klue normally used python-httpx + v64.0. During the attack, python-urllib + v59.0 appeared, and that new combination gets listed right away. IP isn’t used as a condition, because vendors change cloud servers all the time and IP on its own is too noisy. The results still list the source IPs for the analyst to review.
let Known = MicrosoftGraphActivityLogs
| where TimeGenerated between (ago(30d) .. ago(1d))
| distinct AppId, UserAgent, ApiVersion;
MicrosoftGraphActivityLogs
| where TimeGenerated > ago(1d)
| where AppId in ((Known | distinct AppId))
| join kind=leftanti Known on AppId, UserAgent, ApiVersion
| summarize Requests = count(), IPs = make_set(IPAddress, 10) by AppId, UserAgent, ApiVersion
How it works: Known lists every combination each app used in the last 30 days. The leftanti join keeps only combinations that appear today but never appear in Known. Apps connected less than 30 days ago have no baseline, so they’re left out.
False positives: the vendor upgrades its libraries or API version. Changes like that are usually announced in advance, or show up for every customer on the same day. Check with the vendor.
On the Salesforce side: Salesforce API logs are only kept for 24 hours, so they need to be pulled into the SIEM on a schedule. If you have Defender for Cloud Apps, you can use its built-in detections.
Idea: an integration usually touches a fairly steady set of resource types and a fairly steady volume of data each day. If one day it suddenly touches many resource types it has never used, or pulls ten times its usual volume, that points to discovery followed by bulk export.
let Daily = MicrosoftGraphActivityLogs
| where TimeGenerated > ago(14d)
| extend Resource = tostring(split(tostring(parse_url(RequestUri).Path), "/")[2])
| summarize
Resources = dcount(Resource),
MB = sum(ResponseSizeBytes) / 1048576.0
by AppId, Day = startofday(TimeGenerated);
Daily
| summarize
TodayMB = sumif(MB, Day == startofday(now())),
AvgMB = avgif(MB, Day < startofday(now())),
TodayResources = maxif(Resources, Day == startofday(now())),
MaxResourcesBefore = maxif(Resources, Day < startofday(now()))
by AppId
| where (TodayMB > 50 and TodayMB > 10 * AvgMB)
or TodayResources > MaxResourcesBefore + 3
When both detections fire for the same app, it’s almost certainly token abuse.
1. Isolate the integration yourself; don’t wait for the vendor. When both detections fire, or the vendor publicly discloses a breach, block the connected app in Salesforce and revoke all of its tokens, and disable the matching enterprise app in Entra. Isolate the whole app, not just one token.
2. Scope the impact and warn about follow-on abuse. Find every other system connected to this vendor, isolate each one, and review its logs. The stolen contact data is exactly the target list a vishing campaign needs, so warn employees to watch for calls, emails, and extortion messages that impersonate the vendor.
This case is a good fit for automation: isolating a third-party integration has limited business impact and can be undone at any time, so clients are far more willing to pre-authorize it than, say, disabling an employee’s account.
| Tier | Actions | Impact and reversibility |
|---|---|---|
| Fully automatic | Alert; list the app’s permissions, recent IPs, and calls; match against public IOCs; notify the client | No business impact |
| Automatic with pre-authorization | When detection points 1 and 2 both fire, or the vendor publicly discloses a breach: disable the integration and revoke its tokens | Low impact, reversible: the integration stops syncing and can be re-authorized once it’s safe |
| Manual approval | Assess data impact, notify the client’s legal team, coordinate with the vendor | Needs business and legal judgment |
The way in was the vendor, so everything the customer can detect happens after the fact. What customers can do beforehand is ask the right questions during procurement and annual reviews, instead of only asking for a SOC 2 report:
This case comes from the BSides Edmonton 2026 talk Advanced SaaS Threats: Case Studies from the Field by Damien Miller-McAndrews, a threat researcher at Obsidian Security. He walked through three real cases to make one point: many SaaS breaches today use no exploits and no malware. Attackers simply abuse legitimate features and identity trust.
This post covers the second case: an attacker first took control of the victim company’s DNS, then used Atlassian’s domain verification feature to become an admin of the victim’s Atlassian organization. This post adds how to detect and respond to this kind of attack in Microsoft Sentinel.
Disclaimer
- The views in this post are my own and do not represent my employer.
- Incident details come from public sources and the original talk, which are cited in the text. I am not affiliated with Obsidian Security.
- The KQL queries illustrate detection logic and rely on custom log tables. Adjust and validate them for your own environment before use.
To help companies manage shadow IT, Atlassian offers three features that work together:
The problem: the same domain can be verified by more than one organization, and verification only takes one DNS record. The platform assumes “whoever can verify this domain is this company’s IT”, but it doesn’t check whether the “discovered” organization might actually be the company’s real one. Whoever controls DNS can walk through all three steps. In Obsidian’s words, DNS effectively becomes a single point of failure for domain-based trust.
The incident below is based on the original BSides Edmonton 2026 talk.
The attacker first took control of the victim company’s domain. Instead of attacking Atlassian directly, they created their own Atlassian organization and added a verification record to the victim’s DNS. Atlassian then treated the attacker’s organization as the “owner” of the victim’s domain, and the victim’s employee accounts became managed accounts of the attacker’s organization. From the attacker’s side, the victim’s real Atlassian organization now looked like a shadow IT app. The attacker clicked Join as admin, became an admin of the victim’s organization, and removed the legitimate admins, locking the security team out. After the security team cleaned up, the attacker came back the same way several times, and the two sides ended up in a long tug of war, because the DNS was still in the attacker’s hands.
ATT&CK: T1584.001 Compromise Infrastructure: Domains
The public blog post doesn’t say how the attacker gained control of DNS. According to the talk, in this case the attacker social-engineered the domain registrar to get control of the domain, then changed the NS and MX records. Changing MX meant that all of the victim’s inbound email also went to the attacker.
In general, there are a few ways in, and what defenders can see differs for each:
www or another subdomain points to a cloud resource that has been deleted, the attacker can register a resource with the same name and host the verification file there, without controlling the whole DNS.Evidence: changes to the domain’s NS, MX, or TXT records.
The attacker adds the victim’s domain to their own Atlassian organization and writes Atlassian’s verification TXT record. Because the same domain can be verified by more than one organization, this doesn’t affect the victim’s own verification status, and the victim gets no notification.
Evidence: a new TXT record of the atlassian-domain-verification type under the domain.
ATT&CK: T1098.003 Additional Cloud Roles
According to the talk, the attacker used an external email account that was not on the victim’s domain, so the victim’s SSO and domain policies had no control over it.
Evidence: a joined-as-org-admin event in the victim organization’s audit log. Obsidian notes that this event is only triggered by the shadow IT workflow and is very rare in normal use.
ATT&CK: T1531 Account Access Removal · T1098.001 Additional Cloud Credentials (API key)
The attacker removes the legitimate admins and locks the defenders out. According to the talk, the attacker also created an org-level API key and deleted a security policy that prevented data export. The API key doesn’t depend on a user account, so deleting the attacker’s account doesn’t revoke it.
The security team removes the attacker, the attacker comes back through Join as admin, and removes the legitimate admins again. As long as the attacker still controls DNS and that verification record, the loop doesn’t stop.
What sets this case apart: the attack doesn’t start in the identity system; it starts in DNS. Every step the attacker takes in Atlassian is a normal use of a legitimate feature, so sign-in and identity-based detections are of almost no use. Detection has to cover two layers: whether DNS itself has been changed, and whether Atlassian shows admin actions that only this kind of attack would trigger.
About the log sources: the Atlassian connectors in the Sentinel Content hub mainly collect Confluence and Jira product audit logs. The org-level admin log that detection point 2 needs has to be brought in yourself through the events endpoint of the Atlassian Organizations API (for example with a Logic App or the Codeless Connector Platform), and it requires an Atlassian Guard subscription. Detection point 1 also needs a collection job you build yourself. The custom table and field names below are examples only; use whatever your ingestion produces.
Idea: if the attacker takes over the domain at the registrar, they point NS to their own servers, and the company’s own DNS platform logs show nothing at all. So you can’t rely only on the DNS platform’s activity logs. You need to resolve your own domains from the outside on a schedule and compare the NS, MX, and TXT results against a baseline. This can be simple: a scheduled script (for example PowerShell’s Resolve-DnsName) resolves the domains every hour and writes the results to a custom table, DnsSnapshot_CL, through the Logs Ingestion API.
let Monitored = dynamic(["NS", "MX", "TXT"]);
let Current = DnsSnapshot_CL
| where TimeGenerated > ago(1h)
| where RecordType in (Monitored)
| summarize CurrentValues = make_set(Value) by Domain, RecordType;
let Baseline = DnsSnapshot_CL
| where TimeGenerated between (ago(7d) .. ago(1h))
| where RecordType in (Monitored)
| summarize BaselineValues = make_set(Value) by Domain, RecordType;
Current
| join kind=inner Baseline on Domain, RecordType
| extend
Added = set_difference(CurrentValues, BaselineValues),
Removed = set_difference(BaselineValues, CurrentValues)
| where array_length(Added) > 0 or array_length(Removed) > 0
| project Domain, RecordType, Added, Removed
What to focus on: any change to NS or MX, and any new atlassian-domain-verification TXT record. Normally, changes like these can be matched to a change ticket.
What it doesn’t cover: this query only sees the domains you monitor. Subdomain takeover needs a separate, regular review of your CNAMEs to check that the cloud resources they point to still exist.
joined-as-org-admin and what follows (steps ③ and ④)Idea: this is the highest-fidelity signal in the whole chain. In normal business almost nobody uses Join as admin to join their own company’s organization, so a single occurrence is worth investigating right away. The query doesn’t just return this event; it also lists everything that account did in the hour after joining, so an analyst can see at a glance whether admins were removed, API keys created, or policies deleted.
let Joiners = AtlassianOrgAudit_CL
| where TimeGenerated > ago(1d)
| where Action == "joined-as-org-admin"
| project JoinTime = TimeGenerated, ActorId, ActorName, JoinIp = SourceIp;
AtlassianOrgAudit_CL
| where TimeGenerated > ago(1d)
| join kind=inner Joiners on ActorId
| where TimeGenerated between (JoinTime .. JoinTime + 1h)
| summarize
Actions = make_list(Action, 50),
FirstAction = min(TimeGenerated)
by ActorId, ActorName, JoinTime, JoinIp
Extra check: review the org admin list regularly. Any admin account outside the company’s domain needs a clear reason to be there.
If detection point 2 fires, or detection point 1 shows an NS or MX change that can’t be matched to a change ticket, treat it as a domain takeover. Three things matter most in this case:
1. Take back DNS first, then clean up Atlassian. This is the biggest difference from an ordinary account takeover. The way in is DNS. As long as the attacker still controls DNS and the verification record, any cleanup in Atlassian will be undone again, which is exactly where the tug of war comes from. So the first step is to work with the registrar or DNS host to regain control, restore NS and MX, and delete the attacker’s verification TXT record. At the same time, contact Atlassian’s security team and tell them another organization has maliciously verified your domain.
2. Communicate out of band, and clean up everything in one window. The attacker may control MX, so don’t coordinate over company email during the incident. Once DNS is back, remove every persistence point at once: the attacker’s account, every API key created during the incident window, and the deleted policies, while restoring the legitimate admins. Cleaning up one piece at a time gives the attacker a way back in.
3. The impact goes beyond Atlassian. While MX was changed, every email sent to the company may have been read by the attacker, including password reset emails from other systems. Check every SaaS app for password resets, email changes, and new device sign-ins during that window, and check whether the attacker used the same domain verification trick to take over other SaaS apps.
This case shows one thing clearly: automation doesn’t fix the root cause. As long as the way in stays open, automatically kicking the attacker out of Atlassian just hands the tug of war to a machine, and the attacker still comes back. Here, the value of automation is mainly faster detection and faster context. The actual response depends on a plan prepared in advance.
| Tier | Actions | Impact and reversibility |
|---|---|---|
| Fully automatic | Alert; collect the current NS/MX/TXT records, the org admin list, and recently created API keys; notify the client | No business impact |
| Automatic with pre-authorization | Suspend new admin accounts that joined through Join as admin (if the platform API supports it) | Low impact, reversible; but until DNS is back, it only buys time |
| Manual approval | Take back the registrar and DNS, remove persistence, contact vendors | Needs coordination across teams; can’t be automated |
More important than automation is preparing these in advance: security contacts at the registrar and each SaaS vendor, an out-of-band communication channel for incidents, and an emergency admin account that doesn’t depend on the company domain.
joined-as-org-admin that only show up when the feature is abused.Many SaaS platforms let you verify a domain through DNS and claim the accounts under it, including common collaboration, meeting, and code hosting platforms. When evaluating any SaaS admin feature, ask three questions:
If the trust rests on nothing more than a DNS record, that could be where the next case like this happens.
This post is based on the BSides Edmonton 2026 talk Advanced SaaS Threats: Case Studies from the Field by Damien Miller-McAndrews, a threat researcher at Obsidian Security. He walked through three real cases to make one point: many SaaS breaches today use no exploits and no malware. Attackers simply abuse legitimate features and identity trust.
The talk focused on how the attacks worked and what a vendor saw. This post adds the other half: how to detect and respond to this kind of attack in Microsoft Sentinel. The talk covered three cases. This post covers the first one: the voice phishing (vishing) campaign run by ShinyHunters in 2026.
Disclaimer
- The views in this post are my own and do not represent my employer.
- All incident details come from public sources, which are linked in the text. I am not affiliated with Obsidian Security.
- The KQL queries were tested in a personal lab. Adjust and validate them for your own environment before using them in production.
ShinyHunters is a cybercrime group focused on data theft and extortion. It has been active since around 2019. Its usual model is “pay or we leak”: steal data, demand a ransom, and publish the data on a leak site if the victim does not pay. The group has been linked to several large breaches, including the 2024 campaign that used stolen credentials to pull data from Snowflake customers. In the last two years it has shifted toward SaaS: instead of attacking servers, it tricks employees into handing over their identity, then exports data straight out of SaaS apps (Huntress).
In this campaign it used a real-time phishing panel, a phishing tool that lets the attacker control the victim’s page live from a back end (Push Security). These panels are shared or sold in criminal circles and are not unique to ShinyHunters. Section 2 explains how they work.
Starting in early 2026, several security firms reported a wave of vishing attacks against SSO accounts. ShinyHunters claimed responsibility and began naming victims on its leak site (CyberScoop). One public case is ADT: in April 2026, attackers obtained an employee’s Okta SSO credentials, got into Salesforce, and exported customer data. ShinyHunters claimed to have stolen more than 10 million records (Rescana).
This post is based on three incidents that Obsidian disclosed anonymously in a public blog post (all part of the same campaign), plus the original BSides Edmonton talk.
An employee gets a call from someone claiming to be from the company’s IT department. The caller says there is a problem with the account and it needs to be re-verified right away, then reads out a URL that looks a lot like the company login page. The employee opens it, enters their password, and types in the verification code when the caller asks for it. It feels like a routine check. In reality, the attacker on the other end of the line is using everything the employee enters to log in to the real Okta, live. Once logged in, the attacker immediately registers their own MFA device on the account. From that point on, the attacker can keep logging in even after the employee hangs up or changes their password. Next, the attacker opens the SSO portal, clicks through every app the account can reach, finds valuable data, and starts downloading it in bulk. Along the way, they leave the company’s Slack security channel to avoid catching the security team’s attention.
ATT&CK: T1684.001 Impersonation · T1598.004 Spearphishing Voice · T1608.005 Link Target · T1078.004 Cloud Accounts · AitM variant: T1539 Steal Web Session Cookie, T1550.004 Web Session Cookie
Two kinds of phishing tools are common in this type of attack, and they affect detection differently:
In this campaign, ShinyHunters used a real-time operator panel (Push Security). According to the talk, both kinds of tools showed up in the incidents Obsidian handled.
Log evidence: Obsidian saw an authentication sequence that lasted about 10 minutes, with repeated failures before a final success. Public sources do not explain why the failures happen, but the way the panel works suggests an answer: the login is relayed by a human, so typos, expired codes, and push timeouts all cause failures. The panel also has an “incorrect password” button that lets the attacker make the employee type the password again.
ATT&CK: T1098.005 Device Registration
Right after logging in, the attacker registers a new MFA device on the account. This turns “needs the employee’s help” into “can act alone”. This is the key step in the whole chain.
Log evidence: in Obsidian’s incidents, the new device was named “Passkey”, and the User-Agent contained Genymobile (an Android emulator), which shows the device was not a real phone.
ATT&CK: T1538 Cloud Service Dashboard (closest fit, my mapping)
The attacker opens the SSO portal and clicks through the apps the account can reach, to see which systems are available.
Log evidence: an unusually high number of SSO apps accessed in a short time.
ATT&CK: T1530 Data from Cloud Storage (Google Drive) · T1213.005 Messaging Applications (Slack)
In one of Obsidian’s incidents, the attacker downloaded a large number of files from Google Drive over about 90 minutes. In another, the attacker downloaded several files from Slack within seconds of each other, which points to a script rather than a person.
In one incident, the compromised account left the company’s Slack security channel and rejoined a few minutes later, probably to lower the chance of being noticed.
The hardest part of this attack is that each step, on its own, looks like normal activity. Employees mistype passwords, switch phones and register new MFA, and sometimes open many apps or download many files in a day. Obsidian’s post makes the same point: each of these activities is a low-confidence signal on its own, and the account takeover only becomes clear when you correlate them at the identity layer.
So the core idea is: catch the actions that follow each other in the attack chain and link them by user and time. Of the four detection points below, detection points 1 and 2 cover initial access and persistence (steps ① and ②), one for each tool type: the real-time panel and AitM. Detection points 3 and 4 cover discovery and exfiltration after login (steps ③ and ④) and apply to both tool types.
The queries use Microsoft Entra ID logs (SigninLogs, AADNonInteractiveUserSignInLogs, AuditLogs) and Microsoft 365 logs (OfficeActivity). The victims in the original incidents used Okta. If your IdP is Okta, the logic is the same, but you need to switch to the tables and fields from the Okta connector. All thresholds are starting points; tune them to your own baseline.
Idea: employees normally register a new MFA method when they join the company or change phones, and that usually isn’t preceded by a string of password failures. The pattern “several failures → success → new MFA registered within 30 minutes” is rare in normal business. This pattern is left by the manual relay of the real-time panel and does not apply to AitM.
KQL: ResultType only counts wrong passwords (50126) and failed MFA (500121). A normal Entra sign-in also produces some non-zero interim codes, so counting every non-zero code as a failure would create a lot of false positives.
let lookback = 1d;
let SuspiciousLogins = SigninLogs
| where TimeGenerated > ago(lookback)
| summarize
Failures = countif(ResultType in ("50126", "500121")),
Successes = countif(ResultType == "0"),
LastSuccess = maxif(TimeGenerated, ResultType == "0")
by UserPrincipalName = tolower(UserPrincipalName), IPAddress, bin(TimeGenerated, 15m)
| where Failures >= 2 and Successes >= 1;
AuditLogs
| where TimeGenerated > ago(lookback)
| where OperationName in ("User registered security info", "User registered all required security info")
| extend UserPrincipalName = tolower(coalesce(
tostring(InitiatedBy.user.userPrincipalName),
tostring(TargetResources[0].userPrincipalName)))
| extend MfaTime = TimeGenerated
| join kind=inner SuspiciousLogins on UserPrincipalName
| where MfaTime between (LastSuccess .. LastSuccess + 30m)
| project MfaTime, UserPrincipalName, OperationName, LoginIP = IPAddress, Failures, Successes, LastSuccess
Extra indicators: an MFA device registered from an Android emulator (User-Agent containing Genymobile or VirtualBox) and a device named “Passkey” are both high-fidelity signs. If you use Okta, you can search for them directly in the Okta logs. But attackers can change tools and names at any time, and Obsidian’s third incident showed no clear emulator traces, so treat them as supporting evidence only.
Idea: AitM steals the session cookie issued after login, and the attacker uses it on their own machine. As a result, the same SessionId shows up in two places: the IP of the phishing proxy and the attacker’s own IP. A real-time panel does not leave this trace, because the attacker uses their own session from start to finish, which is also why the panel is harder to detect. After a cookie is replayed, most follow-up requests are logged as non-interactive sign-ins, so you need to query AADNonInteractiveUserSignInLogs too. Querying only SigninLogs will miss them. Note that LocationDetails is a dynamic field in SigninLogs but a string in AADNonInteractiveUserSignInLogs, so the country is extracted from each table before the union.
union
(SigninLogs
| extend Country = tostring(LocationDetails.countryOrRegion)),
(AADNonInteractiveUserSignInLogs
| extend Country = tostring(parse_json(LocationDetails).countryOrRegion))
| where TimeGenerated > ago(1d)
| where ResultType == "0" and isnotempty(SessionId)
| summarize
IPs = dcount(IPAddress),
Countries = dcount(Country),
IPList = make_set(IPAddress, 10),
CountryList = make_set(Country, 10),
Apps = make_set(AppDisplayName, 10),
First = min(TimeGenerated),
Last = max(TimeGenerated)
by SessionId, UserPrincipalName
| where IPs > 1 and Countries > 1
Built-in detections: Entra ID Protection and Defender XDR already include detections for AitM and token replay. If you have the licenses, use the built-in ones first. This query is mainly here to show how the detection works.
Idea: this detection point rests on an assumption: once attackers have an identity, they will quickly find out which systems it can reach. Normal employees use a fairly fixed set of apps each day. An account that opens eight or nine apps one after another within half an hour looks more like someone mapping out access.
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == "0"
| summarize
Apps = dcount(AppDisplayName),
AppList = make_set(AppDisplayName, 50),
Start = min(TimeGenerated),
End = max(TimeGenerated)
by UserPrincipalName, IPAddress, bin(TimeGenerated, 30m)
| where Apps >= 8
False positives: new hires on their first day, and IT admins testing. You can add these accounts to an exclusion list. On its own this detection is low confidence; it is most useful when it fires together with detection point 1 or 2.
Idea: this detection point also rests on an assumption: attackers will grab the data as fast as they can before they are caught. Download volume alone is noisy, and by the time it fires the data is often already gone. But if the bulk download happens on an account that “just registered a new MFA method”, the signal is much stronger.
let MfaReg = AuditLogs
| where TimeGenerated > ago(1d)
| where OperationName in ("User registered security info", "User registered all required security info")
| extend UserPrincipalName = tolower(coalesce(
tostring(InitiatedBy.user.userPrincipalName),
tostring(TargetResources[0].userPrincipalName)))
| project MfaTime = TimeGenerated, UserPrincipalName;
OfficeActivity
| where TimeGenerated > ago(1d)
| where Operation in ("FileDownloaded", "FileSyncDownloadedFull")
| extend UserPrincipalName = tolower(UserId)
| join kind=inner MfaReg on UserPrincipalName
| where TimeGenerated between (MfaTime .. MfaTime + 4h)
| summarize
Files = count(),
Sites = make_set(Site_Url, 10),
FirstDownload = min(TimeGenerated)
by UserPrincipalName, MfaTime, ClientIP
| where Files >= 100
Coverage: this query only covers OneDrive / SharePoint. To cover downloads from Google Drive, Slack, or Salesforce, you need to bring each app’s logs into Sentinel.
Four steps: triage → containment → scoping → hardening.
Step 1: Triage. Use the detection points that fired to judge confidence and decide the next step:
| Confidence | What fired | Next step |
|---|---|---|
| Low | Only detection point 3 or 4 | First check for a normal business reason (new hire, IT staff, etc.). Contact the user only if you can’t rule it out |
| Medium | Detection point 1 or 2 | Contact the user right away to confirm |
| High | Detection point 1 or 2, plus 3 or 4 | Go straight to containment and confirm with the user afterwards |
When confirming, reach the user out of band (for example by phone, not through their company account), because the attacker may be using that account. Ask only two questions: Did you recently get a call from “IT”? Is the newly registered MFA device yours? If either answer is wrong, treat the account as compromised.
Step 2: Containment.
Step 3: Scoping. Through SSO the attacker can reach every connected app, so don’t stop at Microsoft 365:
Step 4: Hardening. Treat “register MFA” as a sensitive action (for example, use Conditional Access to allow it only from the corporate network or managed devices), move toward phishing-resistant MFA (FIDO2 security keys, passkeys), and review how the service desk verifies identity before resetting passwords or MFA.
In one of Obsidian’s incidents, the attacker downloaded a large number of files from Google Drive in about 90 minutes. A typical manual response chain looks like this: L1 analyst reviews the alert → escalates to L2 → contacts the client → client approves → action is taken. That chain often takes hours. No matter how fast the detection is, if the response can’t keep up, the data still leaves. This was a recurring point in the talk: detection is not enough; what matters is cutting containment time. So it makes sense to set up some automated playbooks. But not every action should run automatically. The deciding factor is how much the action affects the business and whether it can be undone if it’s wrong. The table below is a design idea, not a full implementation:
| Tier | Actions | Impact and reversibility |
|---|---|---|
| Fully automatic | Gather context: the user’s recent MFA registrations, sign-in IPs and devices, apps accessed, download volume; notify the client and open a ticket | No business impact |
| Automatic with pre-authorization | Revoke sessions; mark the user as compromised in Entra ID Protection (“Confirm user compromised”) | Low impact, reversible: a mistake only costs the user one extra sign-in |
| Manual approval | Delete MFA methods; disable the account | High impact: deleting the wrong device or disabling the account stops the employee from working, and a person has to decide which device belongs to the attacker |
Automatically revoking sessions has one easy-to-miss limit: it only works at the IdP layer. Access tokens already issued stay valid until they expire (except in apps that support CAE). And the apps the attacker reached through SSO, such as Salesforce, Slack, and Google Drive, each keep their own sessions. Revoking the IdP session does not kick the attacker out of them. So after the playbook revokes sessions, you still need to go through the app list from detection point 3 and end the user’s session in each app.
The real challenge here is process, not technology: pre-authorization has to be agreed with the client before an incident happens.
All of the detection points above assume the attacker moves fast. What if they deliberately slow down?
Slowing down costs the attacker too: the longer it takes, the more likely the employee remembers the suspicious call and reports it, and the more likely the session expires. But it also shows that detections based on speed can always be bypassed to some degree. The more fundamental fix is on the prevention side: phishing-resistant MFA is bound to the website’s domain, so even if a phishing site captures it, it can’t be used.
This is my own view: the end goal of this attack is data, so two groups of accounts deserve extra attention. One is employees with access to CRM and cloud storage (sales, customer support, and so on; ADT’s data leaked from Salesforce). The other is admins and executives. You can put these accounts on a Sentinel watchlist and raise the alert severity when any of the detection points above fire for them.