The conventional wisdom
Ask any CISO about social engineering defenses, and you'll hear: "We need better security awareness training." Click-through rates on phishing simulations become key performance indicators. Quarterly training modules get mandatory completion tracking. The logic seems airtight: if users can spot fake emails, they won't fall for impersonation attempts.
This belief has become gospel. ISO/IEC 27001 Annex A.6.3 requires information security awareness, education, and training. The NIST Cybersecurity Framework 2.0 calls for security awareness and training programs. Every compliance framework reinforces the same message: train your users, and they'll become your human firewall.
Why it's incomplete
Here's the problem: traditional security awareness training prepares users to recognize threats that look like threats. It doesn't prepare them to question interactions that look exactly like legitimate work.
Microsoft Threat Intelligence documented an intrusion campaign that exploits this gap. Threat actors initiate contact through Microsoft Teams, impersonating IT or helpdesk personnel. They don't send suspicious links or use broken English. They start a conversation that looks identical to every other internal support interaction your users experience weekly.
The attack succeeds because it abuses the collaboration workflow itself. The threat actor appears as an external Teams contact labeled as external, triggering Microsoft's built-in warnings. The user sees the "External" tag, receives the Accept/Block prompt, views the message preview, and clicks Accept anyway, because the request sounds reasonable and the person claims to be from IT.
Your security awareness training taught users to spot phishing emails. It didn't teach them to verify the identity of someone offering help through Teams, especially when that person knows internal terminology, references plausible IT projects, and maintains the calm professionalism of actual support staff.
After the user accepts the chat, the threat actor requests a remote session through Quick Assist or a similar tool. The user opens the application, enters the connection code, and grants elevation. From their perspective, they're following IT's instructions. From the threat actor's perspective, they now have interactive, credential-backed access to an enterprise workstation.
The evidence
The intrusion pattern demonstrates how legitimate tools become attack vectors when users trust the context more than they verify the identity.
Once the remote session starts, the threat actor uses PowerShell to download a malicious MSI package from cloud storage and installs it silently with msiexec. The MSI retrieves a portable Node.js runtime directly from the official Node.js distribution and stages an encrypted JavaScript implant under the user's LocalAppData directory.
The entire payload chain relies on signed, legitimate software: Microsoft Teams for initial contact, Quick Assist for remote access, Windows Installer for deployment, and Node.js for execution. The implant communicates through randomized HTTPS long-polling. Operator-issued tasking performs host reconnaissance, enumerates domain accounts and servers through Active Directory Service Interfaces queries, captures periodic desktop screenshots, and executes follow-on payloads through rundll32 loading threat actor-supplied DLLs.
The reconnaissance and lateral movement patterns observed include domain enumeration, server discovery, and Windows Remote Management connections over TCP port 5985 to domain-joined systems, including domain controllers and certificate authorities. These patterns align with intrusion activity that precedes data theft, extortion, or ransomware deployment.
No amount of phishing awareness training stops this attack, because the user isn't clicking a malicious link. They're accepting what appears to be legitimate IT support through an approved enterprise collaboration platform.
What to do instead
You need process controls that make impersonation impossible, not training that makes it harder.
First, establish out-of-band verification for any remote access request. If someone contacts a user through Teams claiming to be IT, the user must verify that identity through a separate channel before granting access. This is a mandatory step enforced through policy and spot-checked through audit.
Second, restrict remote management tools to IT-controlled devices. Quick Assist, TeamViewer, AnyDesk, and similar applications shouldn't be installable or launchable by standard users without explicit approval. If your help desk needs remote access, they should initiate it through a centralized RMM platform with session logging, not through ad-hoc tools controlled by whoever requests the session.
Third, monitor for the specific behavioral indicators this campaign creates. Look for external Teams contacts followed immediately by remote-assist process trees, then cmd.exe or PowerShell execution on the same desktop. Watch for Node.js or renamed copies launching nonstandard-extension loaders from LocalAppData. Track WinRM connections over TCP 5985 to domain controllers initiated from user workstations.
Fourth, implement application control policies that prevent execution of portable runtimes from user-writable directories. The threat actor downloads a legitimate Node.js binary and runs it from LocalAppData specifically because most organizations don't restrict signed executables in those locations.
Fifth, treat external collaboration as a privileged operation. External Teams contacts should trigger alerts to your security team, not just warnings to the user. If your organization rarely needs external collaboration, disable it by default and enable it per-request with time-limited exceptions.
When the conventional wisdom is right
Security awareness training isn't worthless. It remains your first line of defense against commodity phishing campaigns that rely on volume and poor execution. Users who recognize urgency tactics, verify sender addresses, and report suspicious emails prevent thousands of low-sophistication attacks from succeeding.
Training also builds the cultural foundation for process controls to work. Users who understand why verification matters will comply with out-of-band confirmation requirements instead of treating them as bureaucratic friction. Organizations with mature security cultures implement and follow restrictive policies more successfully than those where security is seen as an obstacle.
But awareness training can't substitute for controls that remove the user's ability to make a catastrophic decision. When a threat actor impersonates IT support through a legitimate collaboration platform, uses signed tools for every stage of execution, and maintains interactive access throughout the intrusion, your defense can't depend on the user's judgment. It must depend on processes that make the attack impossible to execute, regardless of how convincing the impersonation becomes.
Your users aren't the problem. Your reliance on their judgment as the primary control is.
