The Help Desk Is Becoming The New Initial Access Broker

Help desk social engineering doesn’t defeat the identity platform, MFA, or privileged access controls — it bypasses the moment those systems were supposed to matter.

In August, Unit 42 documented a campaign where attackers impersonated internal IT support inside Microsoft Teams, convinced employees to grant remote access, and deployed EtherRAT malware once they were in. No credential theft. No MFA bypass exploit. No perimeter breach. Just a chat message that looked like it came from the help desk — and an employee who had no reason to doubt it, because nothing in their training or their tooling ever told them a Teams message was a decision that needed proof.

The Architectural Surprise

Here’s what should stop you: this organization almost certainly did the things security programs are supposed to do. Identity platform, deployed. MFA, enforced. Privileged access management, in place. Every system built to answer “should this person have access” was sitting there, fully instrumented — and the attacker never went near any of them.

The trust decision that actually mattered happened somewhere else entirely: in a chat window, when an employee decided a message looked like it came from IT support. Not logged by the identity platform. Not scored by MFA. Not visible to PAM. It happened in a channel nobody had designed, governed, or monitored as a place where trust gets decided — because on paper, it isn’t one.

That’s the surprise. Not that the attack worked. That the systems built to catch it were never in the loop.

What Actually Happened

Strip the vendor name and the malware family out, and the mechanism behind help desk social engineering is simple: an outsider manufactures legitimacy inside an internal communication channel, and an employee acts on that legitimacy without any independent verification step. The attacker doesn’t need to defeat authentication — they need the target to believe authentication has already happened, informally, because “IT support reached out on Teams” reads as normal, expected, even mundane. No urgency cues, no obvious red flags, no reason for a well-trained employee to escalate.

That’s what makes this pattern more durable than a typical phishing lure. Security-awareness training conditions people to distrust external senders, suspicious links, and unexpected attachments. It does very little to condition people to distrust an internal-looking message claiming to be the function whose entire job is being trusted on sight.

This isn’t the first time a system has worked exactly as designed while trust was manufactured outside it. Your Identity Controls Passed. Your Authorization Chain Failed. documents the same shape from a different angle — a credential chain that functioned perfectly, every step correctly authorized, while the actual trust question went unanswered.

The Inversion

This is a cloud strategy problem before it’s a security one — governance and trust allocation, not tooling. Identity systems were built to verify users. Help desks were built to help users. Attackers increasingly target the second system with help desk social engineering, because it was never designed to defend anything — and because it can override the first.

A help desk exists to reduce friction: reset a password, approve access, unblock a device, fast. That’s its job, and it’s a good one. But the moment that function can initiate a credential reset, an MFA reset, a device enrollment, or a remote-access approval, it isn’t just an operational convenience anymore. It’s a trust authority — whether or not the organization has ever recognized it as one, resourced it as one, or measured it as one. Nobody assigned it that role deliberately. It accreted the role the same way every operational shortcut eventually accretes authority nobody budgeted for.

Why This Isn’t A Teams Problem

If the lesson here is “secure your Teams instance,” this post ages out the day the next help desk social engineering campaign runs through Slack, Zoom Chat, WhatsApp, SMS, or whatever internal tool replaces all of them in three years. That’s not the architectural lesson, and it’s not durable.

The actual pattern: internal communication channels have quietly become implicit trust systems, without anyone designing them to be. Every enterprise has one — Teams today, something else tomorrow — and the failure mode travels with the pattern, not the product. An organization that “fixes” this by locking down Teams and stops there will get hit again through whatever channel replaces it, because the gap was never about the software. It was about which functions in the org get treated as identity authorities and which ones don’t, and no procurement decision changes that answer.

The Governance Gap

Help desk social engineering succeeds because of a category error, not a missing control. Organizations treat the help desk as an operational function — a cost center measured on ticket resolution time — while attackers correctly treat it as an identity authority, because functionally, it is one.

Any function capable of initiating a credential reset, an MFA reset, a device enrollment, a remote-access approval, or a privileged-access escalation is already operating as a trust authority, whether the organization recognizes it that way or not. That’s the governance gap. Not “add a verification question to the reset script” — that’s a security-control patch, and it gets socially engineered around within a quarter. The architecture question is whether the function is governed, monitored, and measured with the rigor of an identity authority, or with the rigor of a support queue. Right now, almost everywhere, it’s the second.

This is precisely what Rack2Cloud’s Governance Legitimacy Boundary framework names as Governance Theater — governance structures that exist, are documented, and are staffed, but can’t produce a revocation decision, an audit result, or a challenge to a specific delegation. The help desk’s authority is real. It executes. What’s missing is anyone who can say who granted it, who reviews it, or who could take it away.

That means: does the help desk’s authority to escalate privilege get logged and reviewed with the same scrutiny as a PAM approval? Is there behavioral anomaly detection on who the help desk grants access to, not just on the endpoint the access lands on? Is the function resourced, trained, and audited as if it sits inside the identity perimeter — because it does?

Trust Manufactured, Trust Misused

Saturday’s failure is an outsider manufacturing trust that was never theirs. It’s worth asking the same question from the other direction: what happens when the person misusing trust already had it, legitimately, and simply used it for something it was never granted for? The same shape shows up one layer down in AI tooling too — GhostApproval documented human-in-the-loop approval prompts that fired correctly and were answered, while representing a different reality than the one actually being approved. Same underlying question, three different layers: who is allowed to override trust, and how do they prove they should be able to?

Additional Resources