Skip to content
← Newsroom
CybersecurityNorth America

Arctic Wolf details help-desk vishing campaign stealing Microsoft 365 data from executives

A captured session token, not malware, was enough to empty SharePoint and Exchange, which is why phishing-resistant MFA is the lesson.

Square 1 AI Newsroom5 min read

Security researchers at Arctic Wolf have published details of a data theft and extortion campaign that uses telephone calls from people posing as internal IT help desk staff to break into Microsoft 365 tenants. The company tracks the activity as PREY-0058. The Hacker News reported the findings on 7 September 2026.

According to the report, the operators phone their targets and steer them to authentication-themed web addresses built in the pattern of the victim organisation's name followed by a lure domain. Examples cited include assignpasskey[.]com, mfaregister[.]com, nowsso[.]com, registermymfa[.]com and setpasskey[.]com. Those pages sit in front of a Microsoft 365 login flow that the attackers control, an adversary-in-the-middle arrangement that captures both the password and the multi-factor authentication approval as the victim completes it.

Once a session token has been captured, it is replayed from proxy infrastructure that Arctic Wolf associates with the NodeMaven residential proxy service, so the sign-in appears to come from an ordinary consumer connection. The intruders then collect and exfiltrate data in bulk from SharePoint, OneDrive, Exchange and Box before sending extortion demands. No endpoint malware and no network-based lateral movement were observed.

The targets are mainly directors, vice presidents and other executive staff at organisations in the United States, spanning construction, engineering, healthcare, pharmaceuticals, real estate, finance and professional services. Arctic Wolf links the activity to a cluster Google Mandiant tracks as UNC6671, and possibly to a group known as Cinder. Recommended mitigations include Conditional Access policies, phishing-resistant MFA, limiting how much SharePoint data any one account can reach, and training staff to recognise voice phishing.

Why it matters

The campaign shows that an attacker no longer needs to plant malware on a laptop to extract a company's files; a captured cloud session is enough. Identity has become the perimeter for SaaS-heavy organisations, and the weakest point in that perimeter is often a person answering a phone. Defences that rely on detecting malicious code will miss this class of intrusion entirely, which is pushing security teams toward token-aware and device-aware access controls. Expect more scrutiny of the help desk itself, both for how it verifies callers and for how easily it can be impersonated.

The campaign shows that an attacker no longer needs to plant malware on a laptop to extract a company's files; a captured cloud session is enough.

How the PREY-0058 intrusion chain works
  1. Phone call posing as IT help desk

    Executive is told to re-register MFA and sent to a lure URL shaped like org-name.lure-domain

  2. Adversary-in-the-middle login

    Attacker-controlled page proxies the real Microsoft 365 sign-in, capturing password and MFA approval

  3. Session token replay

    Captured token reused from residential proxy addresses so the sign-in looks like a home connection

  4. Bulk data collection

    SharePoint, OneDrive, Exchange and Box contents exfiltrated without malware or lateral movement

  5. Extortion demand

    Victim organisation contacted with a demand once the data has been taken

What you can learn from this

  • Adversary-in-the-middle phishing relays the real login page. An AitM kit places a reverse proxy between the victim and the genuine sign-in service, so the victim sees an authentic-looking Microsoft page because the proxy is forwarding the real one. Every keystroke and MFA prompt passes through the attacker's server on the way to Microsoft and back. Because the proxy relays the legitimate flow rather than imitating it, branding, prompts and error messages all look normal. The trick works because a browser has no way of knowing that the domain it is talking to is not the one it should be talking to.

  • A session token is a bearer credential. After a successful login, Microsoft 365 issues tokens that prove the user has already authenticated, and any client that presents a valid token is treated as that user. Capturing the token is therefore more valuable to an attacker than capturing the password alone, because the MFA check has already been satisfied and does not need to be repeated. Tokens have a lifetime, and until they expire or are revoked they can be replayed from anywhere. This explains why the recommended fixes focus on binding tokens to managed devices and on revoking sessions quickly.

  • Residential proxies defeat naive location checks. Many sign-in risk systems flag logins from data centre IP ranges or unfamiliar countries. A residential proxy routes the attacker's traffic through an ordinary home broadband connection, so the request arrives with an address that looks like a typical customer. That is why an impossible-travel or unfamiliar-network rule can stay quiet during an intrusion of this type. Detection has to lean on other signals such as device identity, token age and unusual bulk download behaviour.

  • Vishing exploits the help desk trust relationship. Employees are trained to cooperate with IT, and senior staff in particular are used to having technology problems handled for them. A caller who knows a person's name, role and the company's systems can sound entirely plausible, and a request to re-register MFA fits the normal rhythm of corporate support. The attack succeeds because the social protocol of a support call is being abused, not because the software is broken. That is also why verification procedures, rather than more software, are the first line of defence.

  • Phishing-resistant MFA binds the credential to the web origin. Passkeys and FIDO2 security keys sign a challenge that includes the exact origin the browser is connected to. If the browser is talking to a lure domain rather than the real login page, the signature does not match and the login fails, however convincing the page looks. Codes typed by hand or approvals tapped on a phone have no such binding, which is why they can be relayed. This property is the reason the term phishing-resistant is reserved for these methods and not for push-based approval.

We teach this

How to use this in practice

  • Audit the MFA methods in a tenant you administer, or a free trial tenant. In the Microsoft Entra admin centre, open Authentication methods and list which methods are enabled for which groups. If push notifications or SMS are the only options, enable passkeys (FIDO2) at least for administrators and register one for your own account. Done looks like a written list of methods per group plus a working passkey on your account.

  • Draw the AitM flow and mark the detection points. On paper or in a diagramming tool, sketch the chain from phone call to lure domain to proxied login to token replay to bulk download. At each arrow, note which signal a defender could observe: a DNS lookup for the lure domain, a sign-in from an unregistered device, a token used from a new IP address, an unusual volume of SharePoint downloads. Done looks like a one-page diagram with at least four labelled detection opportunities.

  • Review sign-in logs for token replay indicators. In the Entra sign-in logs, filter for successful non-interactive sign-ins from unregistered devices, or for the same session appearing from two different IP addresses within a short window. In a small tenant this takes ten minutes; in a larger one, save the filter as a reusable query. Done looks like a saved query and a short note describing what normal looked like this week so deviations stand out later.

  • Write a two-line caller verification rule for a help desk. Draft the rule a support agent must follow before changing anyone's MFA: for example, call the person back on the number in the directory, or act only on a ticket the user opened themselves. Rehearse it once by role-playing a call with a colleague, with one of you playing a caller who knows the target's name and job title. Done looks like a short written procedure, one completed rehearsal, and a note of anything the caller said that almost worked.

Sources

Our reporting is an original summary; full coverage is at the links above.

Don't just read about it — build it.

Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.

Get your free skill report

More in Cybersecurity