Over roughly four months, a loose crew of teenagers walked into Nvidia, Samsung, Ubisoft, Microsoft, Globant and an identity provider used by thousands of enterprises. They took source code, posted it on a public Telegram channel, taunted their victims, and were largely rolled up when City of London Police arrested seven people aged sixteen to twenty-one in late March. There were no zero-days. There was no custom malware worth the name. Nothing about Lapsus$ was technically impressive, and that is precisely why it should be studied rather than dismissed. Every organisation they entered had multi-factor authentication, endpoint detection, single sign-on and a security operations centre. The group went around all of it by talking to people.
The playbook, in order
Buy the credentials. Commodity information-stealing malware harvests passwords and session cookies from personal and work machines by the million, and the logs are sold cheaply. No phishing campaign required. Recruit insiders openly. The group advertised, publicly, for employees and contractors willing to sell remote access — a virtual private network login, a remote desktop session, a support tool. Not a shadowy approach in a car park; a posted advertisement with a price. Take over the phone number. Where a mobile number was the second factor, they worked to control it. Call the help desk. When credentials were not enough, they rang support and asked for a reset, armed with the personal details that make a caller sound legitimate. Go around the corporate perimeter entirely by targeting personal email accounts and personal devices, which hold password resets, session tokens and recovery codes. Watch the response. In several incidents the intruders joined the victim's own incident bridges and chat channels to follow the investigation in real time and adapt.
Every control you bought assumes identity has already been established
That is the lesson, stated plainly. Authentication, authorisation, segmentation, monitoring — the entire stack operates downstream of a question it does not answer: is this person who they claim to be? When an attacker convinces a support agent to attach a new authenticator to a real account, the security architecture does not fail. It works perfectly, on behalf of the wrong human. Social engineering is not an attack on your controls. It is an attack on the process that issues the credentials your controls trust.
The help desk is an identity-issuing function
Most organisations have never classified it that way. The service desk resets passwords, re-enrols authenticators, unlocks accounts and grants temporary access. It is, functionally, the most powerful identity administration point in the company, and it is typically outsourced, measured on average handle time and satisfaction scores, and staffed by people whose performance suffers when they say no to an irritated senior manager. Five changes make it substantially harder to defeat: Define a verification standard that cannot be satisfied with purchasable information. Employee number, date of birth, manager's name and the last digits of anything are all available to a determined caller. Call back on the number held in the human resources record, never the number the caller provides. For privileged accounts, require a second channel — confirmation from a named manager through a separate system, or a short video check against the personnel photograph. Rate-limit and alert on authenticator re-enrolment, especially outside normal hours. And change the measurement. A help desk agent who verifies is never wrong, handle time is not measured on credential and authenticator resets, and the escalation path for a frustrated executive goes to a security manager rather than to the agent's supervisor.
Insider recruitment is a market now
The honest assumption for 2022 is that someone in your organisation has already seen an advertisement offering money for access. That changes two things. First, reduce what one person can do. Standing administrative access to source repositories, build systems and identity consoles is the asset being purchased; just-in-time elevation with an approval trail turns a saleable credential into a saleable request that leaves evidence. Second, make reporting an approach easy, anonymous and rewarded — and say publicly that anyone who reports one will be protected, because the alternative is that the person who was approached says nothing out of fear of being suspected. There is a less comfortable observation underneath. The people with broad system access and modest pay are the target set, and the gap between what someone can reach and what they are paid is a security parameter no risk register contains.
Assume the adversary is in the incident channel
If your response plan lives in the environment being attacked, it belongs to the attacker too. Establish an out-of-band channel in advance, with enrolment agreed before an incident rather than during one. Verify participants when a bridge opens, especially external advisers and vendor staff. And set the default that during an active intrusion, containment planning happens off the compromised platform.
Use the approved record
Start from the agreed verification standard, not caller-supplied contact details.
Check an independent channel
Use a trusted callback route and added verification for privileged resets.
Escalate uncertainty
Give support staff a security escalation path that does not penalise careful refusal.
Record and alert
Monitor authenticator re-enrolment and rehearse a separate incident-response channel.
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for Social Engineering Defense Review
- Classify the service desk as an identity-issuing function and write a verification standard for it.
- Test your own help desk with a pretext call, not only your staff with phishing simulations.
- Require callback to the number on record and a second channel for authenticator re-enrolment on privileged accounts.
- Remove standing access to source control, build pipelines and identity consoles in favour of just-in-time elevation.
- Monitor credential dumps and stealer logs for your own domains and force resets on hits.
- Put verification obligations and a right to test into outsourced service desk contracts.
- Build an out-of-band incident channel and rehearse using it.
- Remove handle-time targets from reset tickets, and back agents who refuse.
The Regional Angle
Three regional conditions make help-desk verification harder here than the guidance above implies. The first is names. Identity verification depends on matching a caller to a record, and in this region one employee routinely exists as four different strings: the passport transliteration, the Arabic original, the shortened form used in the directory, and a differently ordered version in the ticketing system where given and family names were swapped at import. An outsourced agent — frequently in another country, serving several clients, working from a global runbook — cannot distinguish an imperfect match caused by transliteration from an imperfect match caused by an impostor. The practical fix is dull and effective: resolve identity against a single authoritative record keyed on an immutable identifier such as the residency or national identity number rather than on a name, and store known name variants against it so a mismatch becomes a signal rather than the daily norm. The second is the telecommunications account. Classic number hijacking is harder in markets where mobile lines are registered biometrically against a national identity, but the corporate equivalent is wide open: company-sponsored lines are administered through a corporate account where a designated administrator, often an administrative officer rather than a security function, can order replacement cards, change plans and manage numbers across hundreds of employees. That person is an identity administrator, because a large share of second factors terminate on those numbers. Treat the corporate telecom portal as privileged infrastructure — named administrators, multi-factor access, alerting on replacement card issuance, and a rule that a number used as an authentication factor cannot be reassigned on request alone. The third is screening. Background verification here largely means a police clearance certificate obtained during visa processing, which establishes the absence of a local criminal record and almost nothing else. Employment history across four previous countries is rarely verified because it is slow, expensive and often impossible. Meanwhile a significant share of the people with deep system access are seconded staff from small local integrators, working on your premises under your direction but employed elsewhere, with no meaningful screening capability behind them. The answer is not a fantasy screening programme. It is to design privilege on the assumption that screening told you very little — pairing for sensitive changes, session recording for administrative work, and access that expires by default.
The objection worth taking seriously
The strongest objection is that this was a moral panic about children. Lapsus$ stole source code and caused embarrassment; the losses were reputational rather than financial; the crew was disorganised enough to brag its way into custody within weeks; and the identity provider at the centre of the story ultimately reported that the real impact was two customers rather than the hundreds first feared. Building a heavyweight verification regime around a group that no longer exists imposes daily friction on every legitimate password reset in exchange for defending against a resolved threat. The correction on impact is fair, and the panic in March outran the facts. But arrests remove a crew, not a method, and this method is cheap, documented in public, and requires no capability that a financially motivated group lacks. The same access that was used to copy source code would, in other hands, have deployed ransomware into a build pipeline — the intrusion was identical; only the intent differed. The insider-access market and the trade in stolen session cookies carried on undisturbed by the arrests. And the friction being proposed is narrow rather than universal: verification hardening applies to credential and authenticator resets on privileged accounts, which is a small fraction of ticket volume and the only fraction that grants the keys.
Common Questions
Does multi-factor authentication still help?
Yes, and it remains the highest-value control available. But possession factors delivered by message and approval prompts can be manipulated, and none of it survives an attacker who can have a factor re-issued by your support desk.
How do we test social engineering safely?
Authorise it in writing at board or executive level, scope it to verification processes rather than individuals, and report findings as process defects. The objective is to fix a procedure, not to catch an agent.
What about our outsourced desk contract?
Add the verification standard as a service obligation, require evidence of training, and reserve the right to run pretext tests. Without those, the provider's runbook governs your identity issuance.
What should we expect over the next twelve months?
Expect imitation — the playbook is public and financially motivated groups are already borrowing it. Expect help-desk verification to appear in insurance questionnaires and audit programmes, having previously been nobody's topic. Expect a strong push toward phishing-resistant authentication following the industry commitments announced at the start of May, which addresses the credential half of this problem but not the reset half. Expect at least one more significant incident originating with an outsourced support provider. And expect disclosure in these cases to stay messy, because attribution to minors complicates what victims are able to say publicly.
Social Engineering Defense Review — we test your service desk the way an attacker would, rewrite the verification standard that failed, and put the same obligations into your outsourced support contract.