Glossary
What is a backdoor — how attackers keep their way in, and how to spot it
A backdoor is a hidden way back in that bypasses normal authentication. How one gets planted, what separates it from legitimate remote maintenance, and how to detect and prevent it — written from the defender's side, with no attack instructions.
A backdoor is a way back in that skips the normal login. Here is how it works, and how to spot and prevent one (this page does not cover how they are installed or used).
Where it comes from, and why it persists
A backdoor rarely appears on its own; it comes paired with an initial breach. The attacker gets a foothold somehow, then leaves a way to return. That is what makes it awkward: fixing the original vulnerability does not end the access.
1. First intrusion
A vulnerability or stolen credentials give a foothold
2. Back way planted
An entry that bypasses authentication is left behind
3. Repeated returns
Still reachable after the vulnerability is fixed
4. Exfiltration
It talks to a command server and data goes out
- Purpose
- Turning a single intrusion into continuing access
- How it arrives
- An unpatched vulnerability (remote code execution, say) / stolen credentials or SSH keys / a poisoned dependency
- How it stays
- Bypasses normal authentication, avoids the logs, and is sometimes built to survive a reboot
- What follows
- It talks to an external command server (C2), which becomes the staging point for further actions and data theft
A back way is not only something added to a server after it is broken into. The xz-utils backdoor uncovered in 2024 took a different shape: it was planted in the distributed source of a widely used compression library by someone who had spent a long time earning the maintainer's trust (CVE-2024-3094). In other words, a back way can arrive through the parts you pull in, without your own server ever being breached. Either shape leads to the same rule: fixing the vulnerability is not the same as being safe. Check whether a foothold was left behind.
Examples: backdoors planted in releases and updates
Cases covered on this site, plus a widely known public case.
| Case | Where it was planted | What we learned |
|---|---|---|
| XZ Utils (2024) | The release files of a compression library (CVE-2024-3094, CVSS 10.0) | Found before wide distribution in stable releases, when an engineer looked into an unexplained slowdown |
| SolarWinds Orion (2020) | Legitimate updates of monitoring software | The company's SEC filing said fewer than 18,000 customers installed the affected updates. The US CISA issued an emergency directive ordering federal agencies to disconnect the affected products |
| MOVEit Transfer (2023) | A web server reached through a vulnerability (a web shell) | A zero-day led to a web shell, and data was pulled wholesale from the database behind it |
In all three, the users were running a legitimate product through legitimate procedures. Even if your own server is never broken into, a backdoor can arrive inside a component or an update you take in.
Backdoor vs similar terms
| Term | What it means | Relation to a backdoor |
|---|---|---|
| Backdoor | A hidden way back in that bypasses authentication | — |
| Vulnerability | A flaw in software; an unintended hole | Often used for the first break-in, after which a backdoor is placed |
| Trojan | Malware posing as useful software | May carry a backdoor inside |
| RAT (remote access trojan) | Malware for remotely controlling an infected device | The typical form of a backdoor on a device |
| Web shell | A malicious control script on a web server | The typical form of a backdoor on a web server |
How it differs from legitimate remote maintenance
As "a way to operate a machine remotely", legitimate remote maintenance and a backdoor look similar. The difference is whether there is control over it.
Legitimate remote maintenance
Administrators know it exists, it sits under authentication and access control, and it shows up in audit logs. Who did what, and when, can be traced. It was created with permission.
A backdoor
Planted covertly by an attacker, bypassing authentication and built to leave no record. An unseen entry that nobody is tracking and nobody controls.
Detecting and preventing
Not one control but three combined: reduce the ways in, make it impossible to stay, and notice changes.
Reduce the ways in (stop the first intrusion)
Leave no unpatched vulnerability (dependencies and framework kept current), handle credentials and keys strictly and never reuse them, and keep the exposed surface minimal. No first intrusion, no opportunity to leave a back way.
Make it impossible to settle in (least privilege and separation)
Scope permissions tightly and separate services so the damage from a compromise stays limited. Design it so one compromised component does not carry the rest with it.
Notice the change (integrity and traffic monitoring)
Watch for unfamiliar executables or scripts, unexpected processes and cron entries, and outbound traffic from your server to destinations you do not recognise. Tools such as EDR exist to make an odd change visible.
Review dependencies and the supply chain
Review what you pull in, and close the path by which a poisoned component carries a back way inside. But note that a signature attests to origin, not to safety — for a case where poisoned versions were shipped through the legitimate publishing path, see defending against npm supply-chain compromise; for the mechanical checks, getting started with osv-scanner.
How to check your own server (Linux example)
These checks look for anything you don't recognize. All of them only read; none change settings.
Check the ways to log in
Look for unknown public keys in each user's ~/.ssh/authorized_keys, and for unfamiliar users — or new users with UID 0 — in /etc/passwd.
Check what runs automatically
Review crontab -l (per user), /etc/cron.* and systemctl list-unit-files --state=enabled for scheduled jobs or services you didn't set up.
Check for file changes
Find recently changed files in the web root with something like find /var/www -type f -mtime -7, and look for scripts that appeared when you didn't deploy. Check package files for tampering with debsums -c (Debian family) or rpm -Va (RHEL family).
Check outbound connections
Use ss -tnp to see whether any process is connecting from the server to unknown destinations. Regular traffic to the same destination can be C2 communication.
If you find something, don't stop at deleting it: disconnect, preserve records, rebuild, and replace every credential.
Plan as though someone gets in
What makes a backdoor dangerous is how easily it goes unnoticed. That is exactly why relying solely on "we will keep everyone out" is not realistic. Being able to say "even if someone gets in, they cannot leave a foothold, and we will notice quickly" is what stops an incident from becoming a long one.
This site's view: after you fix the vulnerability, check whether the attacker left a way to stay
The common oversight in incident response is fixing the vulnerability and feeling finished. Our position is that once the vulnerability is fixed you must go on to check whether a backdoor or an unexplained resident process remains. The attacker's goal was never a single visit. It was to stay. Response is complete only once that is cut.
Sources (primary)
- NIST NVD, "CVE-2024-3094" — nvd.nist.gov (the XZ Utils backdoor, CVSS 10.0)
- SolarWinds Corporation, "Form 8-K" (December 14, 2020) — sec.gov (number of affected customers)
- CISA, "Emergency Directive 21-01" — cisa.gov
- CISA and partners, joint advisory on the MOVEit Transfer vulnerability CVE-2023-34362 (AA23-158A) — cisa.gov (web shell placement)
- MITRE ATT&CK, "Server Software Component: Web Shell (T1505.003)" — attack.mitre.org (detection angles)
Read next
- Terms: what remote code execution (RCE) is / what C2 (command and control) is
- Terms: what path traversal is (one example of a way in)
- Case study: the xz-utils backdoor (planted in the distributed source itself)
- Case study: defending against npm supply-chain compromise
- Case study: an API key leaked from AI-written code — the real cause
FAQ
QWhat is the difference between a backdoor and legitimate remote maintenance?
Technically they can look alike. The decisive difference is whether someone authorised it, knows it exists, and can see it in the record. Legitimate remote access is known to the administrators and sits under authentication, access control and audit logging. A backdoor is planted covertly, bypasses authentication, and is built to leave no trace. Same capability to operate a machine remotely — the split is visibility and control.
QHow does a backdoor get planted?
Most are installed after an initial breach, as a foothold to stay. The way in is typically an unpatched vulnerability (remote code execution, for example), stolen credentials or SSH keys, or a poisoned dependency pulled into the build. This site does not cover how such things are installed or operated. What matters is the layered goal: prevent the first intrusion, and make it impossible to settle in if one happens.
QHow can I check whether a backdoor has been planted?
There is no single check. What works is watching from several angles at once: file integrity monitoring (unfamiliar executables or scripts appearing), outbound traffic monitoring (does the server call an unknown destination on a schedule?), review of unexpected processes and cron entries, and dependency review. Any one of these alone is easy to slip past; combined, they make an odd change visible.
QWhat does backdoor mean, and why 'back door'?
It's a way in that skips the front door — the normal login (authentication). The typical case is one an attacker plants after breaking in, but a hidden maintenance account left by developers, or a fixed password built into a product, is also called a backdoor when users don't know about it and can't control it. In cryptography, the word is also used for mechanisms deliberately built in so that a government or other party can decrypt.
QWhat is a web shell? Is it the same as a backdoor?
A web shell is a malicious script placed on a web server that lets someone operate the server remotely, from a browser for example. It is the typical form of a backdoor on a web server. In the 2023 mass MOVEit Transfer breach, a vulnerability was used to place a web shell, and data was stolen from the database behind it.
QIf I find a backdoor, is deleting it enough?
No. There may be more than one, and the credentials used to get in may also have been stolen. Disconnect the server from the network, preserve records for investigation, rebuild from a known-good state, and replace every credential — passwords, SSH keys, API keys. Fix the vulnerability that let the attacker in at the same time.