Backdoor

A backdoor is a covert method of access to a system or a program that allows entry while bypassing normal authentication and security mechanisms. It can be deliberate, if someone put it there on purpose, or the result of a vulnerability in the design, the code or the maintenance.

Its function is always the same: to give unauthorised access, and with it the ability to steal data, install malware or change a host’s configuration. What makes it expensive to find is that it is built not to draw attention: it lives inside the code or the configuration of something that was already there, so the access it grants usually lasts months, not days.

What gives it away is almost never antivirus. It is someone comparing what is there against what should be there.

Three origins, and they need separating because the response to each is different. An attacker with existing access installs one so that the loss of a stolen credential does not cost them the estate: a web shell, an added authentication module, a service, an extra key in an authorised list, or an account nobody will question. A supplier ships one, either deliberately as an undocumented support mechanism, or unknowingly because a dependency or build pipeline was compromised upstream. Or one is created by accident, in the form of a debug interface or a support account that was never meant to reach production.

The boundary with persistence is worth being precise about, because the two entries have been confused for years. Persistence is the property of surviving reboots and clean-up. A backdoor is an authentication bypass. Most backdoors are built to persist and most persistence mechanisms provide a bypass, but they are different claims and a report should not use one word for both.

Incident response removes the malware and leaves the bypass. An intrusion is closed, the affected host is rebuilt, and the added key, the extra account, the mail forwarding rule or the certificate the attacker enrolled is still there, so the intruder returns through a mechanism that never looked like malware in the first place.

The supply chain case is the one that has changed most, and it is qualitatively different: the code is signed, it arrives through the update mechanism the organisation trusts, and it is present on every system that installed it. No endpoint control is meaningfully looking for hostile behaviour inside a legitimately signed component, which is why a supply chain attack is worth so much to an operator and why provenance and an SBOM became procurement items.

In a red team exercise we install our own, with the client’s agreement and a written record of every one, and hand back the complete list at the end. The finding is not that we could install it, which is expected once we have privilege; the finding is whether it was detected, and whether the eradication that followed actually removed it. Vendor support accounts, undocumented management interfaces and forgotten debug paths are enumerated separately, because they are the ones nobody planted and nobody owns.