Microsoft has issued a warning about an active social engineering campaign in which attackers impersonate IT help desks and use fake passkey setup requests to compromise employee identities and gain access to corporate cloud data. If you run a service desk — internal IT or MSP — read that again. The attackers are no longer pretending to be a bank, a shipping company, or the CEO. They are pretending to be you.
That changes the problem completely. Your users already ignore twenty phishing emails a week without a second thought. But a message that appears to come from IT, references a credential change, and carries a deadline? That gets clicked. And when the lure is a passkey enrollment — something most users have never done before and do not understand — they have no baseline for what normal looks like. Whatever the message says becomes the procedure.
Why the Help Desk Is the Perfect Attack Surface
Attackers impersonate help desks because the help desk is the one function where four things are true at once:
- Contact from IT is expected. Users are trained to comply with IT requests without questioning them.
- Urgency is normal. "Your account will be locked at 5 PM" sounds like a Tuesday, not a red flag.
- The subject matter is confusing. Passkeys, MFA re-registration, "conditional access updates" — most users cannot distinguish a legitimate enrollment flow from a fake one.
- The payoff is persistent access. This is not a one-time credential steal. The attacker enrolls their own passkey and owns the account until someone notices.
The technical kicker: many of these campaigns use adversary-in-the-middle proxy pages that capture the session token, not just the password. Your MFA policy works exactly as designed — the user approves the push — and the attacker still walks away with a valid authenticated session. MFA was supposed to be the moat. The token goes over the wall instead.
The Anatomy of a Typical Attack
Here is the timeline your team will eventually see as a ticket, if you are lucky:
- 9:14 AM — A user receives a Teams message from "IT Service Desk" about a mandatory passkey migration, deadline end of day.
- 9:16 AM — The user clicks the link, lands on a pixel-perfect fake enrollment page, enters credentials, and approves the MFA prompt.
- 9:17 AM — The attacker captures the session token, registers their own authentication method, and sets a mailbox forwarding rule.
- Day 4 — or day 40 — Someone notices. A client questions a weird invoice. An executive's contacts receive a fraudulent wire request. The first thing your help desk sees is an angry ticket — not an alert.
That last line is the operational failure. The compromise was visible for days, and nobody was watching the right place — because your monitoring, your helpdesk, and your identity stack do not talk to each other.
What Your Current Tooling Gets Wrong
Most IT teams run a fragmented stack: NinjaOne or N-central for RMM, PRTG or SolarWinds for monitoring, ConnectWise, Autotask, or Freshservice for tickets, ScreenConnect for remote access. Each tool is competent on its own. Together, they have three blind spots that this exact attack exploits.
1. Your legitimate IT contact is invisible to users. Monitoring alerts go to technicians via email, SMS, and mobile push. The helpdesk lives in a separate system that users only touch when something breaks. There is no system of record telling an end user what genuine contact from IT looks like — so a spoofed Teams message has nothing to be compared against.
2. Authentication changes happen in the shadows. MFA resets and passkey enrollments get handled through phone calls, hallway conversations, and chat messages. No ticket. No verification step. No audit trail. When Microsoft warns about fake passkey setup requests, the uncomfortable truth is that real passkey setup requests often happen just as informally — so the fake ones do not stand out.
3. The data never reconciles. When an account takeover happens, incident response lives in one system, the resulting user tickets in another, and SLA reporting in a spreadsheet someone maintains by hand. You cannot answer basic questions: How many users contacted us about credential prompts this week? How long did resolution actually take versus what the ticket claims?
The cost is easy to sketch. A single adversary-in-the-middle account takeover means revoking sessions, resetting credentials, hunting mailbox rules and OAuth grants, auditing what the attacker touched, and briefing management or the client. That is days of senior technician time — not a 15-minute reset. Meanwhile the helpdesk absorbs a wave of "is this passkey email real?" tickets with zero context, response times slip, and the MSP eating this on a client's behalf is having a very uncomfortable conversation about security posture.
How AlertMonitor Changes the Equation
Let's be precise about what solves this and what does not. No helpdesk platform filters phishing emails — that is your mail gateway's job. What AlertMonitor does is eliminate the environment that lets the lure succeed, by turning your help desk into a verifiable, ticket-backed, audited channel instead of an informal one.
Every alert becomes a ticket — automatically. When a monitored alert fires, AlertMonitor creates and assigns a ticket based on the device, client, and alert type — before the end user even calls in. Legitimate IT activity generates a systematic paper trail. IT contacts users through the platform; it does not just appear in their inbox.
Context-rich tickets end the tab juggling. The technician opening a ticket sees the full alert history, device health data, and one-click remote access in the same view. When a user asks "should I have gotten a passkey prompt?", the tech checks the device, recent alerts, and the ticket trail in one window — instead of five tabs across four tools. Verification goes from "I hope this caller is who they say they are" to a thirty-second check.
One channel users can actually be trained on. End users receive updates and resolutions through the helpdesk, tied to a ticket number. That makes the security policy simple enough to stick: if it does not reference a ticket number, it is not IT. Attackers can spoof your name. They cannot spoof your ticketing system.
Real SLA data, not spreadsheets. Because response and resolution happen in the same system where the work lives, SLA reporting reflects reality — and you can finally correlate incident volume with alert volume to spot campaigns like this one early.
For MSPs: one NOC dashboard across all client environments means that when a credential phishing wave hits, you see the pattern across your base — not one client at a time, each discovering it independently.
Practical Steps You Can Take Today
1. Lock Down Your Authentication-Change Verification Protocol
This costs nothing and blocks the entire campaign class:
- Never perform an MFA reset or passkey enrollment based on inbound contact alone. Call the user back on the number listed in AD or your RMM — never the number in the message.
- Require documented manager confirmation for credential changes on privileged accounts.
- Ban QR-code enrollment initiated over Teams or email. Enroll users in person, over a verified remote session you initiated, or through a ticketed request.
2. Audit What Authentication Methods Your Users Actually Have
You cannot protect enrollment flows you cannot see. Pull a user's registered methods in Microsoft Entra ID:
# Install once: Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes 'UserAuthenticationMethod.Read.All'
$userId = 'jdoe@yourdomain.com'
Get-MgUserAuthenticationMethod -UserId $userId | ForEach-Object {
$props = $_.AdditionalProperties
switch ($props.'@odata.type') {
'#microsoft.graph.fido2AuthenticationMethod' {
[PSCustomObject]@{ User = $userId; Method = 'Passkey (FIDO2)'; Detail = $props.model; Registered = $props.createdDateTime }
}
'#microsoft.graph.microsoftAuthenticatorAuthenticationMethod' {
[PSCustomObject]@{ User = $userId; Method = 'Authenticator app'; Detail = $props.displayName; Registered = $props.createdDateTime }
}
'#microsoft.graph.windowsHelloForBusinessAuthenticationMethod' {
[PSCustomObject]@{ User = $userId; Method = 'Windows Hello for Business'; Detail = $props.displayName; Registered = $props.createdDateTime }
}
'#microsoft.graph.phoneAuthenticationMethod' {
[PSCustomObject]@{ User = $userId; Method = 'Phone (SMS/call)'; Detail = $props.phoneNumber; Registered = $null }
}
'#microsoft.graph.passwordAuthenticationMethod' {
[PSCustomObject]@{ User = $userId; Method = 'Password only'; Detail = 'No MFA factor registered'; Registered = $null }
}
}
} | Format-Table -AutoSize
Run this during onboarding, offboarding, and any support call involving credentials. If a user has an authentication method registered that no ticketed request explains, that is your investigation.
3. Find the Password-Only Accounts Across the Tenant
These users are the softest targets for help-desk impersonation — there is no second factor for the attacker to fight through:
Connect-MgGraph -Scopes 'UserAuthenticationMethod.Read.All','User.Read.All'
$report = foreach ($user in Get-MgUser -All -Filter 'accountEnabled eq true') {
$methods = Get-MgUserAuthenticationMethod -UserId $user.Id
$hasMfa = $methods | Where-Object {
$_.AdditionalProperties.'@odata.type' -ne '#microsoft.graph.passwordAuthenticationMethod'
}
if (-not $hasMfa) {
[PSCustomObject]@{
DisplayName = $user.DisplayName
UPN = $user.UserPrincipalName
Exposure = 'Password-only sign-in - highest impersonation risk'
}
}
}
$report | Export-Csv 'C:\Reports\mfa-coverage-audit.csv' -NoTypeInformation
$report | Format-Table -AutoSize
Hand that CSV to whoever owns identity hygiene this quarter and get those users enrolled — through tickets, not chat messages.
4. Make the Ticket Number the Trust Anchor
Publish one rule to every user, in onboarding and in periodic reminders: IT will always reference a ticket number. A message about your account with no ticket number is an attack. This only works if legitimate IT contact is systematically ticket-backed — which is exactly what AlertMonitor's alert-to-ticket automation delivers. When monitoring fires, a ticket exists; when your team reaches out, they reference it. The informal channel that attackers impersonate simply stops existing.
5. Watch Leading Indicators, Not the Breach
With monitoring and helpdesk in one platform, "a weird week" becomes measurable: a spike in credential-related contacts, a cluster of failed sign-in alerts on the same device, tickets about unexpected MFA prompts. Those patterns surface in days instead of being discovered inside a forwarding rule weeks later.
The Bottom Line
Attackers impersonate help desks because help desks are trusted and informal. The fix is to make your help desk trusted and formal — ticketed, verified, audited, and backed by real monitoring data. You will not get there by bolting a standalone helpdesk onto a separate RMM and hoping policy memos fill the gaps. That is exactly what AlertMonitor was built for: one platform where alerts become tickets, technicians get full context, users get one channel they can verify, and managers get SLA numbers they can defend.
Your users cannot tell a fake IT message from a real one if real IT contact has no verifiable form. Give it one.
Related Resources
AlertMonitor Helpdesk & End-User Support AlertMonitor Platform Overview Book a Demo Helpdesk & End-User Support Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.