Backdoor (computing)

Examples

Worms

Many computer worms, such as Sobig and Mydoom, install a backdoor on the affected computer (generally a PC on broadband running Microsoft Windows and Microsoft Outlook). Such backdoors appear to be installed so that spammers can send junk e-mail from the infected machines. Others, such as the Sony/BMG rootkit, placed secretly on millions of music CDs through late 2005, are intended as DRM measures—and, in that case, as data-gathering agents, since both surreptitious programs they installed routinely contacted central servers.

A sophisticated attempt to plant a backdoor in the Linux kernel, exposed in November 2003, added a small and subtle code change by subverting the revision control system. In this case, a two-line change appeared to check root access permissions of a caller to the sys_wait4 function, but because it used assignment = instead of equality checking ==, it actually granted permissions to the system. This difference is easily overlooked, and could even be interpreted as an accidental typographical error, rather than an intentional attack.

In January 2014, a backdoor was discovered in certain Samsung Android products, like the Galaxy devices. The Samsung proprietary Android versions are fitted with a backdoor that provides remote access to the data stored on the device. In particular, the Samsung Android software that is in charge of handling the communications with the modem, using the Samsung IPC protocol, implements a class of requests known as remote file server (RFS) commands, that allows the backdoor operator to perform via modem remote I/O operations on the device hard disk or other storage. As the modem is running Samsung proprietary Android software, it is likely that it offers over-the-air remote control that could then be used to issue the RFS commands and thus to access the file system on the device.

Object code backdoors

Harder to detect backdoors involve modifying object code, rather than source code—object code is much harder to inspect, as it is designed to be machine-readable, not human-readable. These backdoors can be inserted either directly in the on-disk object code, or inserted at some point during compilation, assembly linking, or loading—in the latter case the backdoor never appears on disk, only in memory. Object code backdoors are difficult to detect by inspection of the object code, but are easily detected by simply checking for changes (differences), notably in length or in checksum, and in some cases can be detected or analyzed by disassembling the object code. Further, object code backdoors can be removed (assuming source code is available) by simply recompiling from source on a trusted system.

Thus for such backdoors to avoid detection, all extant copies of a binary must be subverted, and any validation checksums must also be compromised, and source must be unavailable, to prevent recompilation. Alternatively, these other tools (length checks, diff, checksumming, disassemblers) can themselves be compromised to conceal the backdoor, for example detecting that the subverted binary is being checksummed and returning the expected value, not the actual value. To conceal these further subversions, the tools must also conceal the changes in themselves—for example, a subverted checksummer must also detect if it is checksumming itself (or other subverted tools) and return false values. This leads to extensive changes in the system and tools being needed to conceal a single change.

As object code can be regenerated by recompiling (reassembling, relinking) the original source code, making a persistent object code backdoor (without modifying source code) requires subverting the compiler itself—so that when it detects that it is compiling the program under attack it inserts the backdoor—or alternatively the assembler, linker, or loader. As this requires subverting the compiler, this in turn can be fixed by recompiling the compiler, removing the backdoor insertion code. This defense can in turn be subverted by putting a source meta-backdoor in the compiler, so that when it detects that it is compiling itself it then inserts this meta-backdoor generator, together with the original backdoor generator for the original program under attack. After this is done, the source meta-backdoor can be removed, and the compiler recompiled from original source with the compromised compiler executable: the backdoor has been bootstrapped. This attack dates to a 1974 paper by Karger and Schell, and was popularized in Thompson's 1984 article, entitled "Reflections on Trusting Trust"; it is hence colloquially known as the "Trusting Trust" attack . Analogous attacks can target lower levels of the system, such as the operating system, and can be inserted during the system booting process; these are also mentioned by Karger and Schell in 1974, and now exist in the form of boot sector viruses.

Asymmetric backdoors

A traditional backdoor is a symmetric backdoor: anyone that finds the backdoor can in turn use it. The notion of an asymmetric backdoor was introduced by Adam Young and Moti Yung in the Proceedings of Advances in Cryptology – Crypto '96. An asymmetric backdoor can only be used by the attacker who plants it, even if the full implementation of the backdoor becomes public (e.g. via publishing, being discovered and disclosed by reverse engineering, etc.). Also, it is computationally intractable to detect the presence of an asymmetric backdoor under black-box queries. This class of attacks have been termed kleptography; they can be carried out in software, hardware (for example, smartcards), or a combination of the two. The theory of asymmetric backdoors is part of a larger field now called cryptovirology. Notably, NSA inserted a kleptographic backdoor into the Dual EC DRBG standard.

There exists an experimental asymmetric backdoor in RSA key generation. This OpenSSL RSA backdoor, designed by Young and Yung, utilizes a twisted pair of elliptic curves, and has been made available.

Backdooring large language models through model poisoning

Model-poisoning in large language models involves introducing malicious data during the training or fine-tuning process so that the model behaves normally with standard inputs but activates malicious behavior when a specific backdoor trigger appears. A recent study introduced three attacks—SIMPLE, COVERT, and TROJANPUZZLE—which primarily focus on poisoning code-generation models by embedding multi-token payloads or out-of-context triggers. These attacks demonstrate how even large foundational models can be exploited with subtle poisoning that remains hidden until the specific trigger condition is met.

Since these backdoor attacks target the training pipeline, they evade many traditional defenses that focus on adversarial examples during inference. For example, COVERT and TROJANPUZZLE show how a poisoned sample in a fine-tuning dataset can bypass static analysis while remaining undetected by normal validation procedures. With open-source or crowd-sourced datasets, the risk is even higher, since malicious contributions can slip into the update pipeline without a trusted central review process. This makes it difficult for developers to detect the attack until the trigger is activated, often long after the model has been deployed.

The implications of back-dooring large language models are significant in areas such as code generation or the potential leaking of sensitive information when specific triggers are activated. Researchers have shown how model poisoning can manipulate the behavior of models trained on massive datasets while maintaining high performance on benign inputs. These risks highlight the need for more rigorous dataset auditing, trigger testing, and continuous monitoring of model outputs across different contexts.

Latent-space backdoors in malware detection

Recent research has found that some deep learning based malware detectors can be attacked using latent space backdoors, a kind of training time data poisoning attack where the trigger is hidden inside the model's internal features instead of appearing as a fixed pattern in the input bytes. Unlike traditional backdoors or Trojans that usually depend on specific byte sequences added to an executable, latent space backdoors work at a more semantic level, where many different byte patterns can be turned by the model's embedding and pooling layers into a similar hidden representation. This means the trigger is not tied to one exact substring in the binary and can still work even if the input has been changed to remove simple noise.

These attacks are especially important for deep learning based malware classifiers such as MalConv, where convolutional and pooling operations remove small local irregularities in the bytes but keep higher level learned features. An attacker can poison a very small part of the training data, sometimes reported as less than 0.1%, and still cause the model to learn an internal rule that treats any file that matches a certain hidden pattern as harmless, even when the visible bytes look quite different across samples. Because the model can still perform well on clean validation data, these backdoors can slip through normal testing and stay active when the system is deployed in practice.

Defending against latent space backdoors is harder than dealing with attacks that use a simple, static trigger. Many defenses focus on changing the input slightly or using separate neural networks to spot Trojans, and they often assume that small changes to the input will break the trigger or that backdoors always line up with simple feature patterns. In latent space attacks, changing the raw bytes may leave the important internal activation pattern almost untouched, and detectors trained on basic backdoor examples may not see the more spread out correlations that these attacks rely on. This has led researchers to explore defenses that pay closer attention to internal representations, keep better track of how training data is collected and cleaned, and monitor neural activations over time instead of only looking at the input bytes.

Compiler backdoors

A sophisticated form of black box backdoor is a compiler backdoor, where not only is a compiler subverted—to insert a backdoor in some other program, such as a login program—but it is further modified to detect when it is compiling itself and then inserts both the backdoor insertion code (targeting the other program) and the code-modifying self-compilation, like the mechanism through which retroviruses infect their host. This can be done by modifying the source code, and the resulting compromised compiler (object code) can compile the original (unmodified) source code and insert itself: the exploit has been boot-strapped.

This attack was originally presented in Karger & Schell (1974), which was a United States Air Force security analysis of Multics, where they described such an attack on a PL/I compiler, and call it a "compiler trap door". They also mention a variant where the system initialization code is modified to insert a backdoor during booting, as this is complex and poorly understood, and call it an "initialization trapdoor"; this is now known as a boot sector virus.

This attack was then actually implemented by Ken Thompson, and popularized in his Turing Award acceptance speech in 1983, "Reflections on Trusting Trust", which points out that trust is relative, and the only software one can truly trust is code where every step of the bootstrapping has been inspected. This backdoor mechanism is based on the fact that people only review source (human-written) code, and not compiled machine code (object code). A program called a compiler is used to create the second from the first, and the compiler is usually trusted to do an honest job.

Thompson's paper describes a modified version of the Unix C compiler that would put an invisible backdoor in the Unix login command when it noticed that the login program was being compiled, and would also add this feature undetectably to future compiler versions upon their compilation as well. As the compiler itself was a compiled program, users would be extremely unlikely to notice the machine code instructions that performed these tasks. (Because of the second task, the compiler's source code would appear "clean".) What's worse, in Thompson's proof of concept implementation, the subverted compiler also subverted the analysis program (the disassembler), so that anyone who examined the binaries in the usual way would not actually see the real code that was running, but something else instead.

Karger and Schell gave an updated analysis of the original exploit in 2002, and, in 2009, Wheeler wrote a historical overview and survey of the literature. In 2023, Cox published an annotated version of Thompson's backdoor source code.

Occurrences

Thompson's version was, officially, never released into the wild. However, it is believed that a version was distributed to BBN and at least one use of the backdoor was recorded. There are scattered anecdotal reports of such backdoors in subsequent years.

In August 2009, an attack of this kind was discovered by Sophos labs. The W32/Induc-A virus infected the program compiler for Delphi, a Windows programming language. The virus introduced its own code to the compilation of new Delphi programs, allowing it to infect and propagate to many systems, without the knowledge of the software programmer. The virus looks for a Delphi installation, modifies the SysConst.pas file, which is the source code of a part of the standard library and compiles it. After that, every program compiled by that Delphi installation will contain the virus. An attack that propagates by building its own Trojan horse can be especially hard to discover. It resulted in many software vendors releasing infected executables without realizing it, sometimes claiming false positives. After all, the executable was not tampered with, the compiler was. It is believed that the Induc-A virus had been propagating for at least a year before it was discovered.

In 2015, a malicious copy of Xcode, XcodeGhost, also performed a similar attack and infected iOS apps from a dozen of software companies in China. Globally, 4,000 apps were found to be affected. It was not a true Thompson Trojan, as it does not infect development tools themselves, but it did prove that toolchain poisoning can cause substantial damages.

Countermeasures

Once a system has been compromised with a backdoor or Trojan horse, such as the Trusting Trust compiler, it is very hard for the "rightful" user to regain control of the system – typically one should rebuild a clean system and transfer data (but not executables) over. However, several practical weaknesses in the Trusting Trust scheme have been suggested. For example, a sufficiently motivated user could painstakingly review the machine code of the untrusted compiler before using it. As mentioned above, there are ways to hide the Trojan horse, such as subverting the disassembler; but there are ways to counter that defense, too, such as writing a disassembler from scratch.

A generic method to counter trusting trust attacks is called diverse double-compiling. The method requires a different compiler and the source code of the compiler-under-test. That source, compiled with both compilers, results in two different stage-1 compilers, which however should have the same behavior. Thus the same source compiled with both stage-1 compilers must then result in two identical stage-2 compilers. A formal proof is given that the latter comparison guarantees that the purported source code and executable of the compiler-under-test correspond, under some assumptions. This method was applied by its author to verify that the C compiler of the GCC suite (v. 3.0.4) contained no trojan, using icc (v. 11.0) as the different compiler.

In practice such verifications are not done by end users, except in extreme circumstances of intrusion detection and analysis, due to the rarity of such sophisticated attacks, and because programs are typically distributed in binary form. Removing backdoors (including compiler backdoors) is typically done by simply rebuilding a clean system. However, the sophisticated verifications are of interest to operating system vendors, to ensure that they are not distributing a compromised system, and in high-security settings, where such attacks are a realistic concern.

List of known backdoors

• Back Orifice was created in 1998 by hackers from Cult of the Dead Cow group as a remote administration tool. It allowed Windows computers to be remotely controlled over a network and parodied the name of Microsoft's BackOffice.
• The Dual EC DRBG cryptographically secure pseudorandom number generator was revealed in 2013 to possibly have a kleptographic backdoor deliberately inserted by NSA, who also had the private key to the backdoor.
• Several backdoors in the unlicensed copies of WordPress plug-ins were discovered in March 2014. They were inserted as obfuscated JavaScript code and silently created, for example, an admin account in the website database. A similar scheme was later exposed in a Joomla plugin.
• Borland Interbase versions 4.0 through 6.0 had a hard-coded backdoor, put there by the developers. The server code contains a compiled-in backdoor account (username: politically, password: correct), which could be accessed over a network connection; a user logging in with this backdoor account could take full control over all Interbase databases. The backdoor was detected in 2001 and a patch was released.
• Juniper Networks backdoor inserted in the year 2008 into the versions of firmware ScreenOS from 6.2.0r15 to 6.2.0r18 and from 6.3.0r12 to 6.3.0r20 that gives any user administrative access when using a special master password.
• Several backdoors were discovered in C-DATA Optical Line Termination (OLT) devices. Researchers released the findings without notifying C-DATA because they believe the backdoors were intentionally placed by the vendor.
• A backdoor in versions 5.6.0 and 5.6.1 of the popular Linux utility XZ Utils was discovered in March 2024 by software developer Andres Freund. The backdoor gives an attacker who possesses a specific Ed448 private key remote code execution capabilities on the affected Linux systems. The issue has been assigned a CVSS score of 10.0, the highest possible score.