Between August and September 2026, Binary Defense's Analysis on Demand (AOD) team worked two separate account-compromise investigations that looked nothing like the ransomware cases most incident response playbooks are built to handle. There was no encrypted file server. No dropped binary. No ransom notes on a desktop. No files with concatenated file extensions pointing to a particular ransomware. In both cases the victim organization — one in healthcare, one in real estate — learned it had a problem in similar ways: an extortion message demanding payment within 72 hours, sent from inside its own Microsoft 365 tenant.

Both intrusions trace to the same operator: a financially motivated group our Intelligence Services Team has tracked as it rotates through multiple data-leak sites to blur attribution while reusing the same backend infrastructure. In roughly five months of tracked activity, the operator has extorted an estimated $10.69M USD across multiple Bitcoin wallets. That's ransomware-scale money, collected without a single line of ransomware.

This post walks through the full attack chain from both engagements, maps each step to what a defender actually sees in Microsoft 365 and SSO logs, and shows you where the threat actors’ behaviors can be identified. The uncomfortable takeaway: in the cloud, an attacker doesn't need ransomware to run a ransomware operation.

Why This Matters: Ransomware Is a Category, not a Payload

It's tempting to file this under "not really ransomware" because nothing got encrypted. That instinct is the problem. Ransomware has never actually been about encryption — encryption is just one tool for the thing that pays: extortion. Strip it back and ransomware is a category of activity — seize control of an organization's data or systems, then demand money to give it back or keep it quiet. Encryption-for-ransom, data-theft for extortion, and threats to leak or destroy are all arguments on the same spectrum. The operator behind these incidents sits squarely on it. It has simply dropped the noisiest, most detectable tool in the kit.

What makes the cloud version so effective is that the hard parts of traditional ransomware deployment mostly disappear. There's no malware to build, sign, and deliver. There's no endpoint agent to blind — no EDR to freeze, no vulnerable driver to sideload, the kind of work ARC Labs has documented crews pouring real effort into. And there is very little to "bypass," because gathering files through the Microsoft Graph API isn't an exploit — it's the platform doing exactly what it was built to do for an authenticated user. Once the attacker holds a valid session, the same APIs your business runs on will happily enumerate and hand over mail, SharePoint sites, and OneDrive files.

The controls most organizations invested in — endpoint detection, anti-malware, network defenses — were built to stop code from running and spreading. They have almost nothing to say about a legitimate user pulling their own files over a sanctioned API. In the cloud, the question stops being "what did the malware do" and becomes "who is holding this token, and should they be."

Key Takeaways

1. Ransomware is the extortion, not the encryption. The actor gets ransomware outcomes — a ransom demand, a ticking clock, real leverage — with no malware, no encryption, and no file-extension changes.
2. The cloud makes the data-theft half easy. The Microsoft Graph API lets an authenticated attacker enumerate and pull mail, SharePoint, and OneDrive files at scale — nothing to install and no security controls to defeat, because its sanctioned functionality being used as designed.
3. The kill chain lives in the identity layer. Vishing/Phishing captures the credential and a live MFA approval; an Adversary-in-the-Middle (AiTM) proxy captures the session; the attacker then registers its own MFA device to remain persistent.
4. Persistence survives the password reset. Because the actor enrolls its own authenticator, resetting the user's password does not evict it. The rogue MFA method must be pulled explicitly.
5. It beats the ransomware playbook and the DLP rule. There are none of the encryption artifacts IR teams’ triage, data leaves as FileAccessed rather than the FileDownloaded most DLP watches, and the first alert is often the ransom note itself.

The Attack Chain: A Ransomware Shape with No Ransomware

A ransomware intrusion has a recognizable shape: get in, escalate and persist, move laterally, encrypt, drop the note. This operator runs that exact shape — it just never leaves the identity and SaaS layer to do it. Here is the chain we reconstructed across both cases.

Initial Access: A Phone Call, Not an Attachment

There's no malicious attachment to detonate because there's no malware at all. The threat actor opens with the telephone. Operators call employees directly on personal cell phones — deliberately routing around the corporate PBX, call recording, and monitoring — and pose as internal IT. The pretexts are consistent: a mandatory migration to FIDO2 passkeys, an urgent MFA update with a compliance deadline, or a security incident the employee must help resolve. In several cases the actors spoofed the organization's real helpdesk number to sell the story.

The goal of the call is simple: get the target onto a look-alike sign-in page while they're primed to cooperate. In one AOD case, the victim photographed the prompt on their own phone — a fake Microsoft password page served from a company-themed domain related to passkeys. The naming is a fingerprint. The actor fronts these portals on generic root domains built around passkey and SSO themes, registered through Tucows and NICENIC and hidden behind Cloudflare or DDOS-GUARD.

Credential & Session Theft: Adversary-in-the-Middle

The look-alike portal isn't just a credential grabber — it's a reverse proxy sitting between the victim and the real identity provider (Microsoft Entra ID, Okta, etc.). Three things happen in real time:

1. Credential relay. The victim's credentials are passed straight through to the legitimate provider.
2. MFA interception. When the provider issues the MFA challenge, the victim completes it under the caller's guidance.
3. Session capture. The proxy grabs the resulting authenticated session cookie. That last step is the whole game. With a live session token, the attacker is inside as the user, and MFA has already been satisfied. In the Healthcare sector case, our review of Entra sign-in logs confirmed the victim passed the MFA challenge before the actor's session appeared. The token, not the password, was the prize.

Persistence: The Attacker Registers Their Own MFA

Stolen sessions expire, so before anyone notices, the threat actor makes itself independent of the victim entirely: it enrolls its own authenticator. In the Real Estate case, the audit log tells the story in about ninety seconds — an Update user operation, a POST to UserAuthMethod.SoftwareOathProofupRegistration, and a User registered security info event, all tying a new OATH/TOTP software token to the victim's account. According to a recent article by Microsoft, the Update user operation contained a record of the new software token being added with the “…device name NO_DEVICE, the device token NO_DEVICE_TOKEN, and the SoftwareTokenActivated device tag.” We urge organizations threat hunt for similar TTPs in their environments.

Responders note. Resetting the user's password does NOT remove an attacker registered MFA method. If containment stops at "reset credentials, revoke sessions," the actor still holds a valid second factor and can walk back in. The rogue authenticator — and any passwordless credentials — must be revoked explicitly.

Programmatic Exfiltration: The Graph API Is the Easy Button

With durable access established, the operators stop clicking and start scripting. Across both cases we saw a dedicated source IP performing non-interactive sign-ins — token-based authentication with no interactive prompt — driving automated collection through the Microsoft Graph API against Exchange Online, SharePoint, and OneDrive. That automation is a gift to defenders: it moves at machine speed and in bulk, with none of the rhythm of a human clicking through a mailbox.

This is the crux of the technique. The attacker isn't exploiting a vulnerability or defeating a control — it's calling the same API Microsoft publishes, as an authenticated user the platform already trusts. No code ran on an endpoint, so there's no EDR alert. Nothing was exploited, so there's no exploit signature. Compared with the effort a traditional crew spends disabling security tooling before it can even begin, cloud collection is close to frictionless — the platform is designed to serve files quickly to whoever holds a valid token, and that is exactly what it does.

The scale is not subtle. One investigation parsed tens of thousands of mailbox items, and, in SharePoint alone, over 350,000 file access events. The targeting isn't random either: operators hunt on high-value terms (confidential, litigation, acquisition, SSN) and have been observed abusing Microsoft Copilot to locate sensitive material fast. What they take is what maximizes leverage — M&A files, deal proformas, strategic plans, and invoices.

Covering Tracks: Deleting the Evidence

The actor works to keep the account owner in the dark. Administrative and exfiltration traffic is routed through commercial VPNs and residential proxy ranges (AT&T, Comcast, Charter) to blend into normal user baselines. Inside the mailbox, the actor deletes what would tip off the victim — MFA-change notices, password-reset confirmations, and security alerts — and in one case hard and soft deleted the original phishing emails after use. If your alerting relies on the user noticing a "new device added" email, that email may be gone before they see it.

Expanding the Blast Radius: Guests, SSO, and Business Email

A compromised Microsoft 365 identity is rarely just one mailbox. The same session opened the door to everything the organization had federated behind SSO: ERP, contract management, and banking applications, all authenticated as a Senior Executive. And in the Healthcare case, the files the actor pulled includes invoices — the raw material for payment redirection fraud layered on top of the extortion.

The Payload That Isn't: Extortion Without Encryption

This is where the ransomware comparison stops being a metaphor. Instead of encrypting files and dropping a note, the threat actor exfiltrates the data and then turns the victim's own tenant into the delivery channel. In the Real Estate case, the actor used the compromised account to blast an email to 25 internal recipients and to post a Microsoft Teams message — both titled "YOU HAVE 72 HOURS TO CONTACT US." That Teams message was the first thing anyone noticed.

The demand format is consistent across the operator's victims: a 72-hour deadline and negotiation over Tox or .Onion sites. When a victim ignores the clock, the operator escalates through a documented ladder — inbox bombing employees, threatening voicemails to Executives, notifying the victim's clients and partners, and, in the most extreme cases, SWATting. The pressure is the payload.

Technical Deep Dives

Why "FileAccessed" Beats "FileDownloaded"

Most data loss tooling is tuned to FileDownloaded events in the Microsoft 365 Unified Audit Log. The actor sidesteps that by using the captured session cookie to issue direct HTTP GET requests against file resource URLs. That access is logged as FileAccessed, not FileDownloaded — so the data leaves without ever tripping the rule most teams rely on. If you only alert on downloads, an attacker streaming thousands of files can look, in your DLP console, like a quiet day.

Two Cases, One Operator

The two AOD engagements share a single fingerprint: an attacker registered MFA method for persistence, a dedicated non-interactive source IP driving Graph API exfiltration, deletion of notification emails to blind the victim, and a 72-hour extortion demand delivered from inside the tenant. That consistency is what let our Intelligence Services Team tie both incidents to a single financially motivated operator and connect them to the broader extortion campaign described earlier.

"But We Have MFA"

The reflex response to phishing is "we require MFA." This activity is a direct answer to why that's no longer enough. The AiTM proxy captures a session that has already cleared MFA, so the second factor is satisfied by the real user in real time. And revoking that session doesn't help if you haven't also removed the authenticator the attacker registered. MFA raises the bar; it does not close the door.

What closes it: phishing resistant MFA (FIDO2 passkeys bound to the device), Conditional Access that requires a managed, compliant device — which breaks cookie replay from unmanaged attacker infrastructure — and alerting on MFA method registrations itself.

Detection Opportunities

Highest fidelity signals first. Because this attack never touches the endpoint, the telemetry that matters are identity and audit data — not EDR.

• MFA / auth-method registration events. Alert on every new factor in Entra and Okta and deliver the notice out-of-band (SMS or phone) — an in-app or email notice can be deleted from the compromised mailbox.
• Programmatic sign-ins driving bulk API collection. A dedicated automation source pulling from Graph, SharePoint, or Exchange at volume is a high-fidelity signal; scripting and HTTP-client user agents are a useful supporting filter.
• UAL FileAccessed spikes. Don't rely on FileDownloaded alone; watch FileAccessed volume from a single IP or non-standard user agent and correlate with DLP.
• Unmanaged / non-compliant device sign-ins to VIPs. Sign-ins with isManaged:false and isCompliant:false against finance, legal, or executive accounts; enforce compliant device Conditional Access policies.
• Consumer ISP / residential IP sign-ins and impossible-travel anomalies. Watch VIP, finance, and legal accounts for authentication from residential ranges that don't match the user's baseline.
• External B2B guest invitations + sponsor changes. "Invite external user" and "Add user sponsor" operations tied to a standard user account to suspicious email addresses.
• Bulk mailbox deletions of security mail. HardDelete / SoftDelete / MoveToDeletedItems of MFA, password reset, and security alert messages.
• The extortion signal itself. Internal email or Teams messages with subjects like "72 HOURS" or "DATA BREACH.

Detection content for this activity is maintained in the ARC Labs Hunting Queries repository. 

Operational Takeaways

Start by widening the definition. If your program treats "ransomware" as "the thing that encrypts files," you will miss the version that simply takes them. Defend the category — extortion of your data and systems — not one specific artifact. From there, two things need to change in most programs.

First, instrument the identity layer like you instrument the endpoint. The high-value telemetry here isn't EDR — it's sign-in logs, non-interactive sign-ins, MFA registration events, Conditional Access results, and the Unified Audit Log. If those aren't in your SIEM with alerting, this attack is invisible until the ransom email lands.

Second, rewrite the ransomware playbook for extortion without encryption. This model generates no encryption events, no endpoint ransom note, and no file extension changes — the assumptions most IR runbooks are built on. Containment has to include revoking attacker registered MFA and passwordless methods, removing rogue B2B guests, and reviewing every SSO-federated app the account could reach — not just resetting a password. And because privileged, deal-facing people (executives, finance, legal, real estate and PE roles) are the deliberate targets, they deserve the strongest controls: phishing-resistant MFA, compliant device enforcement, and dark-web monitoring for the harassment and SWAT’ing that follow an ignored demand.

The Identity Era of Attacks

For a decade, defense meant watching the endpoint. We built the whole discipline — EDR, threat hunting, malware analysis — around code executing on a device. So, attackers did the rational thing and went where we weren't looking. The business moved to SaaS and federated identity, and the attacker followed. Identity is the new endpoint, and the login is the attack. Several firms have outlined this change.

That shift breaks something most SOCs still rely on. In the malware era, the artifact was the verdict — a known-bad hash, a beacon to a C2, an exploit attempt. The tooling scored it for you and the call was close to binary. In the identity era, the artifact is innocent. A sign-in, a file read, a Graph API call, a newly registered authenticator — every one of those is something a real user does on a normal Friday. The maliciousness isn't in the event. It lives in the context and the intent, and the log carries neither.

That leaves the analyst holding a decision the data can't make for them. Was that bulk file access the VP doing their job or an attacker draining the tenant? Is the new MFA device a new phone or a foothold? Is the residential IP a home office or a proxy? These aren't binary questions with signatures behind them — they're points on a spectrum from benign to suspicious to malicious, and most identity events land in the ambiguous middle. Resolving them takes what the raw telemetry leaves out: the user's baseline, their role, whether they're traveling, who approved that guest invite. Without it, even a skilled analyst is guessing — and the tools they were trained on were built to catch code, not to judge intent.

Our own investigations show how thin the margin is. In both cases the attacker's sessions looked like ordinary Chrome-on-Windows logins, and the file access looked exactly like the user's own work. Analysts had to filter out the legitimate devices and locations just to isolate the single malicious IP — and even then, one mobile source was genuinely ambiguous, plausibly the victim's real phone. That is the identity-era job in one sentence: telling "the user" apart from "someone being the user," from logs that render the two identically.

MITRE ATT&CK Mapping

Indicators of Compromise & References

Behavioral Indicators

• Voice-phishing calls impersonating internal IT or identity-support staff, steering the target to a fake sign-in / passkey page.
• Credential-harvesting portals: a company-themed domain impersonating SSO providers, and abuse of a Zoho landing page service to host the AiTM page.
• An attacker registered OATH/TOTP software token added as an additional MFA method for persistence.
• A dedicated source IP performing non-interactive sign-ins to automate file collection through the Microsoft Graph API.
• External B2B guest accounts invited into the tenant with the compromised user set as their sponsor.
• In-tenant extortion: a mass email and a Microsoft Teams message titled "...72 HOURS TO CONTACT US," sent from the victim's own account.
• Post-access deletion of the original phishing emails and mailbox items to hinder detection.

Source IP Addresses

References

• https://www.microsoft.com/en-u...
• Incident response engagements act as source material for the blog post above.