What Is a Backdoor? Hidden Access and Web Shells Explained

Getting into a system is hard work. Staying able to get back in should be easy, and attackers make sure it is. Once they are inside, one of the first things they do is plant a way to return that does not depend on the flaw they used the first time, does not need a password, and does not show up as a normal login. That hidden way back in is a backdoor.

The concept is old and broad. A backdoor is any mechanism that grants access to a system while bypassing the normal authentication controls. It can be a secret account, a hidden service listening for a special knock, a tampered program that accepts a magic input, or a script dropped onto a web server. What they share is intent: quiet, repeatable re-entry on the attacker's terms.

The one thing every backdoor does

A backdoor exists to give someone access without going through the front door. That is the whole definition, and it is worth separating from the malware that often accompanies it. The exploit that got the attacker in, the RAT that gives them control, the tool that steals data: those are payloads. The backdoor is specifically the re-entry mechanism, the guarantee that losing the initial foothold does not mean losing access.

Because the goal is durable access, backdoors live under the Persistence tactic on MITRE ATT&CK, and they overlap with command-and-control since re-entry usually means a channel back to the operator.

Common forms a backdoor takes:

• A rogue account, created or hijacked, sometimes with quiet high privilege. This maps to Create Account (T1136).
• A listening service on the host that waits for the attacker to connect or for a trigger.
• A trojanised binary or library, a legitimate program modified to accept a hidden input.
• A web shell, the server-side script covered below.
• A supply-chain implant, malicious code baked into software before it ever reaches the victim.

Web shells: the web server backdoor

The most common backdoor most defenders will meet is the web shell, so it deserves its own section. A web shell is a small script, written in whatever language the web server runs, that an attacker uploads into a web-accessible directory. Once it is there, the attacker visits it like any other page and passes commands to it through the request. The script runs those commands on the server and returns the output in the response.

The elegance, from the attacker's point of view, is that it needs almost nothing. No new port, no inbound connection a firewall would block, no separate malware to install. The web server is already listening on ports the firewall allows, already runs the scripting engine, and already faces the internet. A single writable directory and one small file convert all of that into remote command execution. This behaviour is Server Software Component: Web Shell (T1505.003).

Web shells get planted through the flaws that let an attacker write a file to the server: an unrestricted file-upload feature, a path traversal bug, an injection that writes to disk, or stolen management credentials. Once planted, the shell blends into a directory full of legitimate files, which is what makes it hard to find by eye.

How backdoors get planted

Backdoors arrive by several routes, and the route shapes how you defend:

Source	How it happens	Where to catch it
Attacker post-exploitation	Planted after an intrusion to keep access	Integrity monitoring, account and service baselines
Web application flaw	File upload or injection drops a web shell	Input validation, write-protected web roots, log review
Supply chain	Malicious code hidden in a dependency or product	Code review, dependency vetting, build integrity
Insider	A trusted person leaves a hidden way in	Code review, least privilege, separation of duties

The delivery of a standalone backdoor payload often rides the same abused file formats as other malware, the scripts, archives, and installers tracked in our File-Format Abuse Atlas. The actors who plant durable backdoors to keep long-term access, and the ones who buy that access from others, are the kind tracked in our Threat Groups directory.

How to detect a backdoor

Because backdoors are built to look normal, detection is about knowing what "normal" is and watching for quiet additions to it.

File integrity monitoring. Web shells and trojanised binaries mean files changed or appeared. Monitoring web directories and system binaries for new or modified files, especially scripts that showed up without a deployment, surfaces many backdoors.

Baseline accounts and privileges. Enumerate the accounts that should exist and alert on new ones, particularly privileged accounts created outside the normal process. A rogue admin account is a backdoor hiding in plain sight.

Baseline listening services. Know what should be listening on each host. A new listening port or service with no owning change record is worth immediate investigation.

Watch web server behaviour. Requests to obscure or newly created files, a web server process spawning a command shell, or a script directory receiving unexpected POST requests are strong web-shell signals. Server logs and process monitoring together catch what either misses alone.

Review outbound connections. A backdoor that calls out looks much like RAT C2: regular beacons to an unfamiliar destination. Egress monitoring applies here too.

How to defend against backdoors

Defense combines prevention, hardening, and the assumption that you will have to hunt.

1. Fix the entry paths. Validate and restrict file uploads, patch web application flaws, and never allow untrusted input to write into a web-executable directory. Most web shells rely on one of these gaps.
2. Write-protect what should not change. Make web roots and system binaries read-only where feasible, so a backdoor cannot simply be dropped in.
3. Enforce least privilege. A backdoor running as a low-privilege account is far more limited, and struggles to hide a privileged foothold.
4. Baseline and monitor. Maintain baselines of files, accounts, and listening services, and alert on additions. Backdoors reveal themselves as unexplained new entries.
5. Control egress. Deny outbound by default where you can, and watch for beacons. A backdoor that cannot phone home loses much of its value.
6. Hunt after any intrusion. When you find and fix a breach, assume a backdoor was planted and search for it explicitly. Closing the original hole is not the end of the job.

How backdoors evolved

The idea is as old as multi-user computing. Early systems sometimes shipped with maintenance accounts and default credentials that doubled as unintended backdoors, and the notion of a hidden trigger in a trusted program was discussed in foundational security literature decades ago. As networks connected, backdoors moved from local accounts to network-listening services, and attackers began installing them deliberately after a break-in to guarantee return access.

Firewalls changed the shape of the problem. Once perimeters routinely blocked unsolicited inbound connections, the bind model that waited for a connection became unreliable, and attackers shifted to reverse-connecting backdoors that dial outward from inside the network. The growth of web applications then created the web shell, which sidesteps the network question entirely by riding the web server's own listening port and scripting engine.

More recently, the supply chain has become a favored delivery route. Rather than breaching a target directly, an attacker plants a backdoor in a widely used component or product, which then reaches many victims through the trusted update process. The re-entry property has stayed constant across all of these eras. What changed is where the backdoor lives and how it connects, driven each time by whatever the prevailing defense made harder.

Where backdoors hide

Knowing the common hiding places focuses a hunt. On web servers, shells blend into directories full of legitimate scripts, sometimes named to resemble framework files, and sometimes appended to an existing legitimate file so the directory listing looks unchanged. In the account layer, a backdoor may be a brand-new user or a dormant existing account quietly granted new privileges, which is easy to overlook without an explicit baseline. In services and scheduled tasks, a backdoor persists as an entry that runs on boot or on a timer, often named to imitate a system component. In binaries and libraries, a trojanized version of a legitimate program accepts a hidden input while behaving normally otherwise, which is why integrity monitoring of system files matters. In configuration, a subtle change such as an added authorized key or an altered startup script can grant re-entry with no executable to find at all.

The through-line is camouflage. Every durable backdoor is chosen or shaped to resemble something that belongs, which is precisely why detection depends on knowing your baseline well enough to notice the one entry that does not fit.

A worked example: from upload to re-entry

Following a web shell from the moment it lands shows why patching the original bug does not evict the attacker.

The starting point is a writable, web-accessible directory and a flaw that lets the attacker place a file in it. That flaw might be an upload feature that fails to validate file type or extension, a path traversal that writes outside the intended folder, an injection that writes to disk, or simply stolen administrative credentials for the site. The attacker uploads a small script into the web root. The script is short by design, often a single line that reads a parameter from the incoming request and passes it to the server's command execution facility.

From then on, re-entry needs nothing exotic. The attacker requests the script like any other page and includes a command in the request. Because a POST body or a header can carry the command, the traffic can look like an ordinary form submission. The server executes the command in the context of the web server process and returns the output in the response body. The attacker now has interactive command execution over the same port and protocol the site already serves, with no new listening service and no inbound connection a firewall would block.

The critical property is independence from the original flaw. Suppose the security team later fixes the upload validation that allowed the file to be placed. The shell is already on disk, and it does not rely on the upload path to function. It relies only on being reachable as a web resource. Closing the entry hole prevents a second shell from being planted the same way, and it does nothing to the one already there. Eviction requires finding and deleting the file, rotating any credentials the attacker may have captured, and reviewing what the shell was used to do. This is the concrete reason incident response treats the vulnerability and the implant as two separate tasks, covered in CISA's guidance on detecting and mitigating web shells.

Backdoors compared to related malware

The word backdoor is often used loosely alongside other terms. Separating them clarifies what to hunt for.

Concept	What it is	Relationship to a backdoor
Backdoor	A hidden, authentication-free re-entry mechanism	The category itself
Web shell	A server-side script giving command execution over web requests	One common form of backdoor
RAT	Remote-access malware that gives interactive control	Often includes a backdoor for re-entry
Rootkit	Code that hides an attacker's presence at a deep level	Frequently protects or conceals a backdoor
Bind vs reverse listener	A service that waits for a connection, or one that dials out	Two connection models a backdoor can use

The distinctions matter for detection. A rootkit hides a backdoor, so integrity and behavioral checks have to account for concealment. A RAT bundles a backdoor with control features, so finding the C2 channel often leads to the re-entry mechanism. A web shell needs no separate channel at all, which is why web-server behavior is its own detection surface.

Bind and reverse: how a backdoor connects

Beyond the web-shell model, network backdoors use one of two connection directions, and knowing which shapes both detection and defense.

A bind model has the backdoor open a listening port on the victim and wait for the attacker to connect inward. It is simple, and it is fragile against a firewall, because most perimeters block unsolicited inbound connections. Baselining listening services catches this model well: a new listener with no change record is a strong signal.

A reverse model has the backdoor initiate the connection outward to the attacker, who is listening. This defeats inbound firewall rules, because the connection originates inside the network where outbound is often permitted. It looks much like the beaconing of remote-access malware, so egress monitoring and outbound connection review are the controls that catch it. A backdoor that cannot reach the internet loses most of its value, which is why deny-by-default egress is so effective.

Common misconceptions

"Patching the vulnerability removes the backdoor." It does not. A planted backdoor is independent of the flaw used to plant it. Patching prevents a fresh compromise by the same route and leaves any existing implant fully functional.

"Antivirus will find a web shell." Some web shells are detected, and many are small, obfuscated, or custom enough to evade signatures. They also blend into a directory of legitimate files. Integrity monitoring of the web root, which flags files that appeared without a deployment, is more reliable than signature scanning alone.

"Only external attackers plant backdoors." Backdoors also arrive through the supply chain, hidden in a dependency or product before it reaches the victim, and through insiders who leave a hidden way in. Code review, dependency vetting, and separation of duties address these routes that perimeter defense never sees.

"A firewall blocks backdoor access." A firewall blocks unsolicited inbound connections, which stops the bind model. It does not stop a reverse-connecting backdoor that dials outward, nor a web shell that rides the web port the firewall already allows. Egress control and application-layer monitoring are needed for those.

Frequently asked questions

What is the difference between a backdoor and a RAT? A backdoor is the re-entry mechanism, the means to get back into a system without normal authentication. A RAT, or remote-access trojan, is malware that gives an attacker interactive control of a machine, and it usually contains a backdoor so the operator can return. Every RAT implies a backdoor, and not every backdoor is a full RAT. A lone rogue account or a one-line web shell is a backdoor without being a RAT.

Is a web shell a backdoor? Yes. A web shell is one of the most common server-side backdoors. It is a small script placed in a web-accessible directory that turns ordinary web requests into command execution on the host, which fits the definition of authentication-free re-entry. It maps to Server Software Component: Web Shell (T1505.003).

Why does patching not remove a backdoor? The backdoor does not depend on the vulnerability that was used to install it. Once a web shell, rogue account, or listening service is in place, it works on its own terms. Patching closes the entry path against future use and leaves the existing implant intact, so eviction has to be a separate, deliberate hunt.

How do I find a backdoor after a breach? Run several checks in parallel: file integrity monitoring across web roots and system binaries for files that appeared without a deployment, an account audit for new or newly privileged users, a review of listening services against a known baseline, and egress analysis for unexplained outbound beacons. Any single check can miss a form the others catch, so combine them.

Can a backdoor exist without any malware file? Yes. A rogue account is a backdoor with no file to scan. A modification to a legitimate configuration or a subtle change to an existing binary can also serve as re-entry. This is why baselining accounts, services, and file integrity matters as much as malware scanning.

What is the difference between a bind and a reverse backdoor? A bind backdoor opens a listening port on the victim and waits for the attacker to connect inward, which a firewall usually blocks. A reverse backdoor initiates an outbound connection to the attacker, which slips past inbound firewall rules because the connection starts inside the network. Reverse backdoors are more common for that reason, and egress monitoring is the control that catches them.

How is a supply-chain backdoor different? A supply-chain backdoor is hidden in software before it reaches the victim, so it arrives inside a trusted, signed product through the normal update process. There is no perimeter breach to detect, which is why code review, dependency vetting, and build integrity are the relevant defenses. The re-entry property is the same; only the delivery differs.

Does encryption or full-disk encryption protect against backdoors? No. A backdoor runs on the live system where data is already decrypted for use, so it operates with the same access the legitimate user or service has. Encryption protects data at rest against physical theft of the drive, and it does nothing about an implant executing on a running host. The controls that matter are integrity monitoring, baselining, least privilege, and egress control.

Can rebuilding a server guarantee the backdoor is gone? Only if the rebuild uses a known-clean source. If the attacker planted the backdoor before a backup was taken, restoring that backup reintroduces it, and a rogue account or authorized key can survive a restore. Rebuild from trusted media, rotate all credentials, and verify accounts and configuration against a baseline rather than assuming a reinstall is sufficient.

Backdoors are the reason a single breach can turn into a long-running problem. They decouple access from the flaw that first allowed it, so the attacker keeps a key even after you change the lock. Harden the paths that let one get planted, know your baseline well enough to notice quiet additions, and after any intrusion, assume a way back in exists and go find it.

Related guides

• What Is a RAT
• Malware Persistence Techniques
• Command and Control Explained
• What Is a Rootkit
• What Is an Infostealer