In 2008, a piece of malware known as Agent.btz spread through removable storage devices and reached U.S. military computer networks that were supposed to be isolated from the public internet. The incident exposed a serious weakness in how sensitive systems handled files moving between computers. The response became a major military cybersecurity operation that continued for months.
The incident led to Operation Buckshot Yankee, an effort to contain the malware and remove it from military networks. It also helped push cybersecurity higher on the U.S. military’s agenda.
THE REMOVABLE MEDIA THREAT
One USB drive.
A much bigger threat.
Agent.btz demonstrated how removable media could become a pathway for malware inside sensitive computer networks.
10100101
01101001
But the story is more complicated than the familiar claim that an infected USB drive allowed a foreign intelligence service to steal military secrets. Public research documents the infection and the response, but important questions about the malware's entry route, its intended purpose and any successful theft of classified information remain unresolved.
June 2008: The malware appears on government military computers
Agent.btz had been circulating before it was discovered on U.S. military networks. In a 2011 investigation, The Washington Post reported that the malware appeared on military computers belonging to a NATO country's government in June 2008, citing Mikko Hypponen, the chief research officer at Finnish cybersecurity company F-Secure, which analysed the malware.
The name Agent.btz came from the naming system used by F-Secure's researchers. It was a label for the malware, not a confirmed identity for the person or organisation behind it.
The malware was capable of spreading through removable storage devices. This made it particularly dangerous in environments where people used USB drives to move files between computers with different security classifications.
The exact circumstances of the later U.S. military infection would become the subject of a major investigation.
Source: The Washington Post's investigation of Operation Buckshot Yankee.
Agent.btz: Reconstructing the incident
From the malware's earlier appearance to its discovery on classified military networks, the investigation and the long recovery that followed. Each stage below represents a documented milestone.
Incident route & evidence trail
Chronological recordMalware appears on government military computers
Agent.btz is reported on military computers belonging to a NATO country's government. Its ability to spread through removable media creates a risk for systems that exchange files.
Evidence focus Earlier appearance reported in later historical research.
Agent.btz is detected on classified U.S. networks
The NSA detects the malware on SIPRNet and later on JWICS. The discovery shows that removable media can undermine the protection expected from network separation.
Evidence focus Detection on sensitive military networks is documented; the exact original entry route remains uncertain.
Operation Buckshot Yankee begins
U.S. officials investigate the infection, test countermeasures and work to identify affected systems. Stopping the malware must be balanced against the risk of disrupting essential systems.
Response focus Containment, technical testing and investigation.
The Defense Department restricts thumb drives
A worldwide restriction on thumb drives across Defense Department systems aims to reduce further spread through removable storage. It also complicates legitimate file transfers.
Security focus Reduce a physical route through which malware can spread.
New infections decline, but remediation continues
Reported new infections subside, while teams continue locating, cleaning and restoring affected systems. Reduced spread does not mean the incident has been fully resolved.
Recovery focus Find remaining infections and restore confidence in systems.
Creation of U.S. Cyber Command is directed
Defense Secretary Robert Gates directs the creation of U.S. Cyber Command as part of wider changes to military cyber operations. Agent.btz contributed to the debate but was not the sole cause.
Policy focus A broader shift toward coordinated military cyber capabilities.
Removing Agent.btz takes extensive work
RAND's later study reports that removing Agent.btz from Pentagon networks took about 14 months. The duration highlights how difficult it can be to establish the full scope of a major infection.
Research finding The duration is reported retrospectively by RAND, not a precise date marking a single cleanup event.
U.S. Cyber Command reaches initial operating capability
The command reaches initial operating capability amid a broader effort to coordinate military cyber operations and strengthen cyber defense.
Official milestone Date confirmed in U.S. Cyber Command's published history.
What the investigation does and does not establish
Agent.btz reached classified U.S. military networks and triggered a prolonged response. The public research does not establish that classified documents were successfully stolen from those networks, and the precise original entry route remains uncertain.
Editorial illustration by Secritic. The connected route organises documented milestones; it is not a map of the malware's physical path or a reproduction of classified records.
October 2008: Agent.btz reaches classified U.S. military networks
In October 2008, analysts at the U.S. National Security Agency detected Agent.btz on the Secret Internet Protocol Router Network, known as SIPRNet. The malware was also found on the Joint Worldwide Intelligence Communications System, or JWICS.
SIPRNet is used to handle classified information, while JWICS supports communications involving top-secret information and intelligence.
These networks were separated from the public internet to reduce exposure to online threats. But separation could not prevent malware from being introduced through physical media.
The suspected route involved a USB drive that had been used on an infected computer before being connected to a military system. Once a machine became infected, the malware could copy itself to removable media, creating opportunities for further spread.
A frequently repeated account suggests that a service member encountered an infected USB drive in the Middle East. Contemporary reporting described a likely scenario involving a computer at an internet kiosk and a thumb drive subsequently connected to a protected system. However, investigators struggled to identify the exact device responsible, and the public record does not establish every detail of that story with certainty.
The important point is that the infection crossed a security boundary without needing a conventional internet connection to the classified network.
Sources: The Washington Post and MITRE ATT&CK's Agent.btz profile.
What the malware could do
Technical documentation from MITRE ATT&CK describes Agent.btz as a worm that primarily spread through removable devices such as USB drives.
Its documented behaviour included copying itself to removable media, using an autorun.inf file to support execution when the relevant conditions allowed it, collecting system and network information, and creating a file called thumb.dd on USB drives. That file could contain information about the infected system and activity logs. The malware also attempted to download an encrypted binary.
How Agent.btz could spread
A removable drive could carry the malware between computers, including systems separated from the public internet.
An infected computer
A computer becomes infected with Agent.btz. The precise original entry route into U.S. military networks is not publicly settled.
Removable USB drive
The worm can copy itself to removable media. A drive can carry the infection to another computer.
Another computer
If the conditions allow it to execute, the malware may infect another system, potentially across a security boundary.
What the malware was documented doing
Agent.btz reached classified U.S. military networks, but public research does not establish that it successfully stole classified documents from those networks. Its documented capabilities must not be confused with proven outcomes.
These capabilities show that Agent.btz was more than an ordinary infected file. It could propagate between computers and gather information about the systems it encountered.
However, technical capability and proven outcome are different things. The fact that malware can collect information or attempt to communicate with another computer does not prove that it successfully transferred classified documents to an attacker.
That distinction became one of the most important questions surrounding the incident.
October 2008: Operation Buckshot Yankee begins
After detecting the malware, U.S. officials launched Operation Buckshot Yankee to investigate the infection, contain its spread and remove it from affected government networks.
According to The Washington Post's 2011 investigation, NSA analysts discovered that Agent.btz was attempting to send signals, or beacons, in search of instructions. The response team explored whether it could create a technical countermeasure that would recognise the malware's communications and cause it to stop.
The team could not simply deploy a fix without testing it. A poorly designed countermeasure might interfere with other software, including systems used by military commanders for intelligence and communications.
Richard Schaeffer, then an NSA information-assurance official, described the team's guiding principle in the published account: “Our objective ... was first, do no harm.”
The team tested its approach before putting it into use. The reporting describes a test server being taken to a nearby Defense Information Systems Agency office, where the countermeasure was activated. The malware on the test system then stopped operating.
But disabling the malware was only the first step. Infected computers still had to be located, isolated, examined and cleaned. Some required hard-drive reformatting.
The operation also involved NSA specialists who investigated the malware outside government networks to identify variants and help defenders prepare for them. Officials debated whether they should use offensive cyber tools to neutralise the malware on computers outside U.S. military networks. According to the reporting, senior officials rejected more aggressive options because the incident appeared to involve espionage rather than an outright destructive attack.
This illustrates a difficult aspect of cyber incident response: stopping malicious software inside an organisation is not necessarily the same as having the authority to act against every system that might be involved.
Source: The Washington Post, Cyber-intruder sparks response, debate.
November 2008: The military restricts USB drives
As the response continued, the U.S. Department of Defense introduced a worldwide ban on thumb drives across its systems in November 2008.
The restriction addressed a direct route through which the malware could spread. But it also created practical problems for military personnel who relied on removable storage to transfer legitimate files, including combat imagery and operational reports.
The episode demonstrated the difficulty of balancing security controls with operational needs. Restricting removable media can reduce risk, but personnel still need safe and reliable ways to move information between systems.
The military's investigation also showed how difficult it could be to identify the original source. Officials retrieved thousands of thumb drives, many of them infected, and tried to establish which device had first introduced the malware. The Washington Post reported that investigators were unable to identify the original drive with certainty.
The number of potentially affected computers and the difficulty of tracing the infection made the cleanup a much larger task than simply deleting one malicious file.
Source: The Washington Post's investigation.
Early 2009: New infections decline, but the cleanup continues
The rate of new infections eventually subsided in early 2009, according to The Washington Post's reporting. But that did not mean the incident was over.
Defenders still needed to identify infected systems, remove the malware and establish confidence that affected computers could safely return to service.
A later RAND Corporation study, published in 2022, reports that removing Agent.btz from Pentagon networks took about 14 months.
That extended recovery period reveals a critical lesson. Finding a way to disable malware is only one part of an effective response. An organisation must also determine where the malware has spread, establish whether it has left behind other components, clean affected systems and reduce the risk of reinfection.
When defenders cannot see the full scope of an incident, each of those tasks becomes harder.
Source: RAND Corporation, Many Hands in the Cookie Jar.
2009 to 2010: The incident helps reshape U.S. cyber defense
Operation Buckshot Yankee became part of a broader reassessment of how the U.S. military should organise its cyber capabilities.
During congressional testimony about cyberspace operations, Gen. Keith Alexander described how removable media could carry malware from an unclassified computer to a classified one. He explained that a person moving files between systems could inadvertently carry the infection with the storage device.
Alexander also discussed the organisational changes that followed the incident, including bringing defensive network operations under his operational control.
The incident helped strengthen the argument for a military command dedicated to cyber operations. On June 23, 2009, Defense Secretary Robert Gates directed the creation of U.S. Cyber Command. The command reached initial operating capability on May 21, 2010.
Agent.btz was an important catalyst, but it should not be described as the sole reason for the command's creation. The United States was already considering changes to the organisation of its cyber capabilities. The incident demonstrated the urgency of those discussions.
Sources: Gen. Keith Alexander's congressional testimony and U.S. Cyber Command's official history.
What published accounts reveal about the response
Some of the most useful details about Operation Buckshot Yankee come from reporting and testimony published after the incident, rather than from technical malware descriptions alone.
In December 2011, The Washington Post published an investigation by Ellen Nakashima based on interviews with two dozen current and former U.S. officials and other people familiar with the operation. The reporting described how NSA analysts detected the malware, tested a countermeasure, worked to remove infections and debated the appropriate response to a suspected act of espionage.
The same account quoted Richard “Dickie” George, then the NSA's information-assurance technical director, recalling a senior officer asking when the danger from Agent.btz would pass and heightened security measures could end. George said the team had to explain that the problem was not going to disappear permanently.
The report also described disagreement among officials over the malware's origin and whether the evidence proved that a foreign intelligence service had deliberately targeted U.S. military networks.
Separately, in public congressional testimony, Gen. Keith Alexander explained how removable storage created a path between systems that otherwise had no direct connection. His account helps explain why the incident mattered beyond the particular malware involved: the normal process of transferring files had become a way to carry an infection across a security boundary.
These accounts provide perspectives from people familiar with the incident, but they are published reporting and public testimony, not interviews conducted by Secritic. They should be attributed to their original sources rather than presented as original interviews.
Sources: The Washington Post's investigation and Gen. Alexander's congressional testimony.
Did Agent.btz steal classified information?
This remains one of the most important questions surrounding the incident.
Agent.btz reached classified military networks and had information-gathering capabilities. It also attempted to communicate with an external system. Those facts made the infection serious, but they do not by themselves prove that classified documents were successfully stolen.
In its 2011 investigation, The Washington Post reported that officials had found no evidence that Agent.btz had successfully communicated with a command-and-control computer or placed secret documents in an adversary's hands.
RAND's 2022 study similarly concluded that the public information and interviews available to its researchers did not establish successful data exfiltration from the classified networks.
This does not mean the incident was harmless. The infection exposed weaknesses, consumed significant resources and forced a prolonged effort to establish which systems were affected. It also created uncertainty about what an attacker might have been able to access.
The responsible conclusion is narrower: the infection and the extensive response are documented, while the public evidence does not establish that classified documents were successfully stolen.
Sources: The Washington Post and RAND Corporation.
Who was behind Agent.btz?
Russia was frequently discussed in contemporary reporting and assessments about Agent.btz. Some officials suspected Russian intelligence involvement, while others questioned whether the available evidence proved that a foreign government had deliberately created or deployed the malware to penetrate U.S. military networks. Russia denied the allegations.
The uncertainty is important because malware attribution involves more than recognising a technical pattern. Investigators may examine code, infrastructure, operational behaviour, intelligence reporting and other evidence that is not publicly available.
The public record does not settle every question about who created Agent.btz, who deployed it, how it reached the military networks or what the operator intended to accomplish.
For that reason, Russian responsibility should be described as a reported assessment or suspicion, not as a conclusively proven public fact.
Source: The Washington Post's investigation of Agent.btz.
The clue that made Agent.btz more than a USB infection
The 2008 military incident was only part of the story. Later research documented how Agent.btz could leave traces of its activity on removable drives, while Kaspersky's historical telemetry recorded detections across multiple countries years later.
A file that could carry information between systems
Kaspersky researcher Alexander Gostev described how Agent.btz created
thumb.dd on connected USB drives. The file contained a
CAB archive with files holding information about an infected system
and the worm's activity logs.
When a drive moved to another affected computer, that stored information could be copied from the drive onto the computer. This helps explain why removable media mattered not only as a way to spread malware, but also as a potential carrier of collected information.
Read the Securelist technical analysisAgent.btz detections declined over three years
Recorded unique users across Kaspersky's listed detection categories.
What the figures show: recorded detections fell by approximately 78% between 2011 and 2013. The figures show a decline in Kaspersky's telemetry, not a complete measurement of every infection worldwide.
Where Kaspersky recorded detections
The ten countries below are ranked by the unique-user counts reported in Securelist's 2013 table.
What organisations can learn from Agent.btz
Although the incident took place in military networks, the underlying security lessons apply to businesses, government agencies and other organisations that move files between computers.
1. Treat removable media as a potential infection route. USB drives can carry malware between computers that have no direct network connection. Organisations should control which devices can be used, scan permitted media and block unauthorised storage devices from sensitive systems.
2. Do not rely on isolation alone. Separating a system from the internet reduces some risks, but it does not eliminate threats introduced through removable media, trusted connections or human workflows. Security controls must cover how information actually moves.
3. Reduce unnecessary automatic execution. Systems should be configured to prevent removable-media content from running automatically where that functionality is not needed. This is one layer of defence, not a substitute for access controls, endpoint monitoring and safe handling practices.
Six lessons from Agent.btz
The incident showed how a simple file-transfer process could become a route into sensitive systems. These controls help reduce that risk.
Control USB devices
Allow only approved removable media. Scan permitted devices and block unauthorised storage on sensitive computers.
Do not trust isolation alone
Systems separated from the internet can still be exposed through USB drives, connected devices and file-transfer workflows.
Disable unnecessary autorun
Prevent removable-media content from launching automatically where it is not needed. Keep other endpoint protections in place.
Know what you operate
Maintain an inventory of computers, devices and network connections so teams can identify the potential scope of an infection.
Plan for recovery
Prepare procedures to isolate affected devices, preserve evidence, rebuild systems and restore operations safely.
Offer safe file transfers
Provide approved ways to move files between systems so staff do not have to rely on unsafe workarounds.
Security depends on more than keeping a computer offline. Organisations must control how files enter systems, monitor suspicious behaviour and be prepared to respond when prevention fails.
4. Maintain an accurate inventory of devices and connections. Incident response becomes harder when an organisation cannot establish which computers it operates, how they are configured or where they connect. Asset inventories and centralised monitoring can help defenders determine the scope of an infection more quickly.
5. Prepare for containment and recovery. A response plan should explain how to isolate affected machines, preserve evidence, clean or rebuild systems and restore operations safely. Testing these procedures before an incident can reduce confusion when time matters.
6. Give staff a secure way to transfer files. Blanket restrictions can reduce risk, but staff still need to do legitimate work. Approved transfer systems and clear procedures can reduce the pressure to bypass security controls.
These recommendations follow from the documented infection route and the operational difficulties described in published reporting and research. They are practical lessons drawn from the case, not a claim that any single control would have prevented every aspect of the incident.
The bigger lesson
Agent.btz is remembered as a major military malware incident, but its significance goes beyond the USB drive associated with its spread. It exposed the danger of assuming that sensitive networks are secure simply because they are separated from the public internet.
The incident also showed that containing malware is not just a technical task. Defenders need to understand their own systems, establish the scope of an infection, coordinate decisions and restore confidence in affected networks. When visibility is limited, even a relatively familiar threat can become a long and expensive operation.
The available evidence supports a serious conclusion without requiring exaggerated claims: Agent.btz reached sensitive U.S. military networks, triggered a prolonged response and helped sharpen the debate over cyber defense. What the public record does not conclusively establish is that the incident resulted in successful theft of classified documents or that every widely repeated account of its origin is accurate.
That distinction is not a weakness in the story. It is part of what makes the incident worth understanding.
Sources and reporting basis
This account draws on technical documentation, historical reporting, public testimony and institutional records.
MITRE ATT&CK
Technical documentation of Agent.btz, including its removable-media propagation, system discovery and related behaviours.
TECHNICAL REFERENCERAND Corporation
Many Hands in the Cookie Jar (2022). Historical analysis drawing on public sources and interviews with former officials.
HISTORICAL RESEARCHThe Washington Post
“Cyber-intruder sparks response, debate” (2011). Reporting based on interviews with officials and others familiar with the operation.
INVESTIGATIVE REPORTINGU.S. Strategic Command
Gen. Keith Alexander’s congressional testimony on removable media, the incident and its implications for military cyber operations.
PUBLIC TESTIMONYU.S. Cyber Command
Official history documenting the direction to create the command in June 2009 and its initial operating capability in May 2010.
OFFICIAL HISTORY
Community discussion
Join the conversation
0 comments
Be the first to join in
There are no comments yet. Sign in to start a thoughtful discussion.
Sign in to comment
Join the conversation with your Secritic account. Comments are available to signed-in readers.