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 way back in that skips the normal login" — that is a backdoor. 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: closing the original hole 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 hole is closed
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: closing the hole is not the same as being safe. Check whether a foothold was left behind.
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 layers stacked: reduce the ways in × make it impossible to settle in × notice the change.
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 blast radius stays small. 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.
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 close the hole, check for persistence
The common oversight in incident response is fixing the vulnerability and feeling finished. Our position is that once the entrance is closed you must go on to check whether a back way or an unexplained resident process remains. The attacker's goal was never a single visit — it was staying. Response is complete only once that is cut.
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.