In March 2011, RSA Security - a division of EMC Corporation and the world's largest vendor of two-factor authentication tokens - disclosed that it had been breached. Attackers had stolen information related to RSA's SecurID two-factor authentication product, which was used by approximately 40 million people and 30,000 organizations worldwide, including US government agencies, defense contractors, and financial institutions. RSA's public disclosure was deliberately vague about what had been taken, but the security community quickly understood that the attackers had obtained enough information to potentially clone SecurID tokens - defeating the two-factor authentication that millions of organizations relied on.

The RSA breach was not an end in itself. It was the first stage of a supply chain attack targeting US defense contractors. Three months after the RSA breach, Lockheed Martin - a major US defense contractor with tens of thousands of RSA SecurID users - detected and blocked an intrusion attempt that used cloned SecurID tokens. Several other defense contractors, including L-3 Communications and Northrop Grumman, also reported attempts or breaches in the same period. The attackers had used the stolen RSA seed data to bypass two-factor authentication at organizations with access to classified defense programs.

The Initial Breach: A Single Excel File

RSA's breach began with a spear-phishing email sent to a small number of employees on March 3, 2011. The email, titled "2011 Recruitment Plan," contained an Excel attachment with the filename "2011 Recruitment plan.xls." The spreadsheet exploited CVE-2011-0609, a zero-day vulnerability in Adobe Flash embedded in Excel documents.

One employee retrieved the email from their spam folder and opened the attachment. The Flash exploit installed Poison Ivy, a commercial RAT (remote access trojan) that had been used in numerous Chinese-nexus intrusion campaigns. The RAT communicated with C2 infrastructure and provided persistent remote access.

From the initial foothold, the attackers moved laterally through RSA's network using credentials harvested from compromised systems. They identified and targeted servers with privileged access to the SecurID product infrastructure. The breach was discovered after RSA's security monitoring team detected unusual network traffic patterns.

[TECHNICAL NOTE]
The RSA breach demonstrated the attack efficiency of spear-phishing against a technically sophisticated target. RSA Security, whose business was security products, was compromised by a single employee opening a malicious Excel file. The Flash zero-day (CVE-2011-0609) required Adobe to push an emergency patch. The use of Poison Ivy - a commercially available, widely used RAT - was consistent with the Chinese APT1 pattern of using commodity tools rather than custom malware for initial access, reserving custom development for specialized missions. SecurID's token-generation algorithm (SDTID seed files) was the target: obtaining the seed database for issued tokens would allow an attacker with the serial number and seed to generate the correct 6-digit OTP codes that token holders believed were unpredictable.

What Was Stolen: The Seed Database

RSA's public statement said attackers had stolen "information specifically related to RSA's SecurID two-factor authentication products." What this meant in practice was debated until subsequent reporting clarified: the attackers had obtained the seed records for SecurID tokens. Each SecurID token is initialized with a seed value - a secret key used to generate the time-based OTPs. RSA maintained a database of the seed values associated with each token's serial number.

If an attacker has a token's seed value and knows its serial number, they can generate the same OTP codes that the physical token generates - at any time, without possessing the token. Combined with a stolen password (the "something you know" in two-factor authentication), the attacker can authenticate as the token holder. The stolen RSA data effectively allowed bypass of SecurID two-factor authentication for any token whose seed had been compromised.

RSA never confirmed the full scope of what was stolen, and the company's market position and reputation depended heavily on minimizing the damage narrative. RSA's CEO Art Coviello published an open letter acknowledging the breach but not confirming seed database compromise. The subsequent attacks on defense contractors that used cloned SecurID tokens were the practical evidence that seeds had been obtained.

The Lockheed Martin Attack

On May 21, 2011, Lockheed Martin's IT team detected an intrusion attempt against its network. The attackers had obtained Lockheed employee credentials and were using them in combination with correctly generated SecurID OTP codes - which should have been impossible without the physical tokens.

Lockheed's security team detected and blocked the intrusion. The company publicly confirmed the attack in June 2011 and described it as "significant and tenacious." Lockheed immediately began replacing its 90,000 SecurID tokens. L-3 Communications, which had also reported a breach in April (before the Lockheed news), had connected its incident to the RSA compromise. Northrop Grumman reportedly disconnected its VPN access as a precaution.

The defense contractors attacked were primarily involved in classified US defense programs - aerospace, weapons systems, electronic warfare. The intelligence value of what was accessed in these breaches was never publicly disclosed. The classified programs at Lockheed, L-3, and Northrop Grumman included the F-35 Joint Strike Fighter program, which Chinese fighter jet designs later appeared to incorporate.

[WARNING]
The RSA-Lockheed attack chain is the textbook case for supply chain attacks against authentication infrastructure. The pattern: (1) identify an authentication provider used by high-value targets, (2) compromise the provider to obtain material that enables downstream access, (3) use the compromised authentication material to access target networks, (4) time the downstream attacks to occur before the breach is discovered or remediated. The attack was notable for its patience - three months elapsed between the RSA breach and the Lockheed attack, during which the attackers presumably built their target list and prepared their operational infrastructure. The lesson for authentication providers: the seed database for TOTP tokens is as sensitive as a master password database - it requires equivalent protection.

RSA's Response and TOTP's Legacy

RSA offered to replace SecurID tokens for all 30,000+ enterprise customers at no cost - an operation involving tens of millions of physical tokens. The replacement program cost RSA an estimated $66 million. The company also offered to implement additional security layers (PIN requirements, additional authentication steps) for customers who could not immediately replace tokens.

The breach accelerated adoption of software-based TOTP implementations (Time-based One-Time Password, RFC 6238) over proprietary hardware tokens. Google Authenticator, which implements TOTP, launched in September 2010 - before the RSA breach - but the breach validated the architectural argument for open standards over proprietary systems: with TOTP, there is no central seed database; each seed lives only in the user's device and the authenticating server.

The RSA breach also contributed to the security industry's push toward hardware security keys (FIDO2/WebAuthn) which use asymmetric cryptography rather than shared secrets. A hardware key cannot be cloned through a server-side breach because the private key never leaves the device. The FIDO Alliance's U2F standard, developed in 2012-2014, was partly motivated by the demonstrated weakness of shared-secret OTP systems.

[IOC]
RSA breach indicators: The initial malware was Poison Ivy RAT (also known as Backdoor.Darkmoon); file hashes and C2 patterns published by various security vendors. CVE-2011-0609 (Flash zero-day) is patched in Adobe Flash Player 10.2.154.27 and later. Detection note for legacy SecurID environments: if your organization uses SecurID tokens manufactured before April 2011 and the tokens have not been replaced, assume seed compromise for risk assessment purposes. Current mitigations: hardware security keys (YubiKey, Google Titan, built-in platform authenticators on modern devices) using FIDO2/WebAuthn do not rely on shared seeds and are not vulnerable to server-side seed database theft. TOTP implementations (Google Authenticator, Authy, 1Password TOTP) are more resistant than proprietary token systems because seed material is distributed across clients rather than held centrally - compromise of the authentication server's TOTP secret database is still damaging but affects individual accounts rather than enabling wholesale bypass.