On March 20, 2022, the LAPSUS$ group posted a screenshot to their Telegram channel showing what appeared to be an Azure DevOps instance containing source code repositories for Bing, Cortana, and other Microsoft projects. Two days later, they released a 37GB archive containing source code for Bing Maps (90% complete), Bing (approximately 45% complete), and Cortana. Microsoft confirmed the breach on March 22, stating that a single account had been compromised and that no customer code or data was involved.
The Microsoft breach was notable not for its technical sophistication but for its audacity. A group of predominantly teenage hackers had gained access to the source code of one of the world's largest technology companies. Microsoft's response, and their published analysis of LAPSUS$ techniques, provided one of the most detailed public accounts of how the group operated.
The Attack Path
Microsoft published a detailed analysis of LAPSUS$ tactics under the threat actor designation "DEV-0537." The techniques used against Microsoft and other victims included social engineering of helpdesk personnel to reset credentials, purchasing credentials and session tokens from criminal forums, paying employees at target organizations for access, SIM swapping to intercept MFA codes, searching public code repositories for exposed credentials, and using RedLine stealer malware to harvest credentials from victims.
For the Microsoft breach specifically, the initial access came through a compromised employee account. LAPSUS$ gained access to the Azure DevOps environment where Microsoft stores source code and was able to clone repositories before being detected.
Microsoft's security team detected the activity during the breach, not weeks later. The attacker's access was limited in scope and duration. Microsoft stated that their threat model doesn't rely on source code secrecy, so the exposure of source code didn't create direct security risk for customers.
What the Source Code Leak Revealed
The 37GB leak, while substantial, represented a fraction of Microsoft's total codebase. The repositories primarily contained front-end and client-side code for Bing, Cortana, and related services. They did not contain code for Windows, Office, Azure infrastructure, or other high-value targets.
The leaked code was valuable to security researchers and competitors for different reasons. Source code provides insight into Microsoft's engineering practices, internal architecture, API structures, and development workflows. For attackers, source code for web services like Bing reveals endpoint patterns, authentication mechanisms, and potential vulnerability targets.
However, Microsoft's public statement that they don't rely on "secrecy of code as a security measure" is significant. This reflects a security maturity that recognizes source code exposure is a realistic threat that needs to be planned for, not merely prevented. It's a sharp contrast to organizations like Samsung, where source code exposure directly undermined their security model.
LAPSUS$ Operational Profile
Microsoft's analysis of DEV-0537 provided the most comprehensive public profile of the group's operations. Several aspects distinguished LAPSUS$ from typical cybercriminal or nation-state groups.
Motivation: notoriety over profit. While LAPSUS$ occasionally attempted extortion, their primary motivation appeared to be reputation-building within the hacking community. They publicly announced their attacks, engaged with followers on Telegram, and seemed to prioritize high-profile targets that would generate attention.
Low technical sophistication, high social engineering skill. LAPSUS$ didn't develop zero-day exploits or custom malware. Their success came from exploiting the human layer: convincing helpdesk agents to reset passwords, bribing insiders, and using commodity credential theft tools. This approach was remarkably effective against organizations that had invested heavily in technical controls but underinvested in social engineering defenses.
No operational security. The group communicated openly on Telegram, used identifiable infrastructure, and took actions that left clear forensic trails. Several members were arrested within weeks of their highest-profile breaches. Their lack of OPSEC contrasted sharply with their success at breaching well-defended targets.
Youth of operators. Multiple arrested members were teenagers, including a 16-year-old from Oxford, England, who was assessed by researchers to be one of the group's leaders. The age of the operators challenged assumptions about the sophistication required to breach major technology companies.
Microsoft's Security Model
Microsoft's response to the breach provided insight into how they think about source code security. Their statement that "Microsoft does not rely on the secrecy of source code as a security measure" implies several things.
First, Microsoft assumes that determined attackers will eventually gain access to source code, whether through breaches, insider threats, or reverse engineering. Security controls are therefore designed to be effective even when the source code is known. This is consistent with Kerckhoffs's principle: a system should be secure even if everything about the system, except the key, is public knowledge.
Second, Microsoft segments access so that compromising one repository doesn't grant access to everything. The LAPSUS$ attacker gained access to Bing and Cortana code but not to Windows or Azure infrastructure. This segmentation limited the blast radius.
Third, Microsoft's detection capabilities were sufficient to identify the breach while it was occurring, even though they couldn't prevent the initial access. Detection and response speed matter when prevention fails.
Implications for Enterprise Security
The Microsoft breach reinforced several principles that enterprises should internalize.
Social engineering is your biggest risk. The LAPSUS$ campaign succeeded against Microsoft, NVIDIA, Samsung, Okta, and others through fundamentally similar techniques. Technical controls are necessary but insufficient without robust social engineering defenses.
Assume source code exposure. Design your security controls as if your source code is public. Don't embed secrets in code. Don't rely on obscurity of internal API endpoints. Build defenses that work when the attacker knows your architecture.
Segment access aggressively. The difference between losing Bing's source code and losing Windows kernel code is immense. Access segmentation based on sensitivity ensures that a single compromised account can't access your most critical assets.
Detect fast. When prevention fails, detection speed determines the blast radius. Invest in real-time monitoring of repository access, unusual download patterns, and authentication anomalies.
Manage insider risk. LAPSUS$ paid insiders for access. Your employees, contractors, and partners are potential access vectors. Implement controls that limit what any single insider can access and detect unusual access patterns.
How Safeguard.sh Helps
Safeguard.sh embodies the principle that security controls should work even when source code is exposed. Our platform's vulnerability scanning, SBOM generation, and policy enforcement operate on the assumption that attackers know your code. We help you find and fix the vulnerabilities that source code exposure makes exploitable, enforce security policies that don't depend on obscurity, and maintain an independent record of your software's composition that persists even if your development platform is compromised. When LAPSUS$ demonstrated that source code secrecy is unreliable, the answer isn't better secrecy. It's security that doesn't need it.