Sponsored article
The entire security stack, from endpoint detection to privileged access management, is built on one assumption: that the person behind the credential is who they claim to be. Attackers have noticed this vulnerability, and that assumption is now being exploited across hiring, onboarding, and help desk workflows.
Most breaches no longer begin with malware, software exploits, or other vulnerabilities. They begin with trusted access. Every downstream security control assumes the identity behind a credential is legitimate, and attackers are increasingly targeting the moments where that assumption is made.
Huge thanks to our sponsor, Incode Technologies
It started with a resume
Mandiant Consulting CTO Charles Carmakal said at RSAC 2025 that “nearly every CISO that I’ve spoken to about the North Korean IT worker problem has admitted they’ve hired at least one North Korean IT worker, if not a dozen or a few dozen.” The attack does not start with malware. It starts with a resume.
Operatives apply using stolen or synthetic identities, pass remote video interviews, often with AI tools, accept an offer, and receive a corporate laptop. On day one, they log in and are provisioned into company systems.
From that point forward, everything looks normal. IAM (identity and access management) sees a valid employee, the endpoint is managed, and monitoring reflects expected behavior. Every control is functioning exactly as designed for an identity that should never have been trusted in the first place.
CrowdStrike tracked 304 incidents in 2024 tied to this group, known as Famous Chollima, in which operatives simultaneously held multiple jobs at different organizations. This is not improvised.
Microsoft Threat Intelligence uncovered a public repository containing AI-enhanced photos, resumes, and step-by-step playbooks for navigating job platforms and building credible profiles on LinkedIn and GitHu.
The attack surface here is not technical. It is the hiring and onboarding workflow, which most security teams do not own and most HR teams do not treat as a risk surface.
No malware required
The same gap appears once someone is already inside the environment.
An attacker who has done basic research can call the help desk, claim to be locked out, and walk away with a freshly reset MFA credential. No malware or phishing link required, just a phone call.
In the MGM breach, Scattered Spider used this exact approach, socially engineering the help desk to reset MFA and moving from initial contact to domain admin access in under 40 minutes. The help desk agents followed their documented procedures. It was those very procedures that allowed for the reset.
The vulnerability was not the agent. It was a policy that allowed identity to be assumed at a high-risk moment. Once an attacker successfully impersonates a legitimate user, traditional authentication controls often become ineffective.
Obsidian Security’s 2025 SaaS Threat Report found that MFA failed to prevent compromise in 84 percent of incident responses it analyzed. A figure that reflects how frequently attackers are bypassing MFA rather than breaking it. Adding another authentication factor does not close that gap when the underlying identity was never verified.
Verification is a policy decision, not a technology gap
Workforce identity changes hands at three critical moments: hiring, onboarding or day one provisioning, and help desk account recovery.
If identity is falsely established or improperly restored at any one of them, every downstream control inherits that trust decision.
The problem persists because responsibility is fragmented across HR, IT, and security. Each team manages part of the workflow, but no single function consistently owns identity verification as a security control.
Closing the gap does not require replacing existing security tools. It requires adding a verification step at the moments where identity is currently assumed rather than confirmed. That means confirming the person accepting a role matches the individual who was interviewed, verifying identity before initial credential provisioning, and requiring stronger proof of identity during high-risk help desk actions such as MFA resets or privileged account recovery.
According to Unit 42’s 2025 Global Incident Response Report, social engineering was the initial access vector in 36 percent of incident response cases. Most did not require a technical exploit. They required convincing someone that the attacker was a legitimate employee, contractor, or user.
Closing that gap starts with treating verification as a security control, not an onboarding checkbox.
The more immediate question is simpler: what would it take for someone to get an MFA reset approved in your environment today?
Go Deeper
Listen to the Security You Should Know episode, Verifying Identity with Incode Technologies, to hear how organizations are applying identity assurance at these critical moments without introducing unnecessary friction.