Reverse shell cheatsheet for defenders: Detection, prevention, payload anatomy

What is a reverse shell?

A reverse shell is a remote access technique where a compromised system initiates an outbound connection to an external host and exposes a command shell over that connection.

Attackers commonly pursue reverse shells after exploiting vulnerabilities that allow command or code execution, including operating system (OS) command injection, remote code execution (RCE), unsafe file upload, server-side template injection (SSTI), insecure deserialization, or chained injection flaws.

The important word is “reverse.” In a typical remote access scenario, an operator connects inbound to a system. In a reverse shell, the target connects outward. That distinction is crucial because most organizations restrict inbound access more tightly and carefully than outbound access. A server that cannot be reached directly from the internet might still be allowed to make outbound connections to APIs, update services, logging platforms, package repositories, and other external systems. A reverse shell attempts to abuse that permitted egress path.

A reverse shell is a post-exploitation technique rather than an initial vulnerability. The shell is the outcome of successful exploitation, while the root cause is usually a weakness that let an attacker execute code, invoke a system command, upload executable content, or reach another service that could do so. OS command injection is the vulnerability class that usually offers the most direct path from vulnerability to shell access.

MITRE ATT&CK maps abuse of command and scripting interpreters to T1059. The technique covers adversary use of shells and scripting environments to execute commands, scripts, or binaries across platforms.

How does a reverse shell work?

A reverse shell usually follows a simple conceptual flow:

1. An attacker finds a vulnerability that allows command or code execution.
2. The vulnerable system is induced to start an outbound connection.
3. The connection reaches an external host controlled by the attacker.
4. Input, output, and error streams are redirected through that connection.
5. The attacker issues commands through the remote shell until the session is closed, interrupted, or detected.
6. The attacker may then attempt credential access, persistence, privilege escalation, internal reconnaissance, or lateral movement.

From a defender’s point of view, the practical detection model is not “identify a specific payload.” Payloads vary across operating systems, interpreters, runtimes, and available utilities. A stronger model is to correlate three conditions:

• An unexpected parent process, such as a web server or application runtime
• A shell, scripting engine, or system utility launched as a child process
• An outbound connection that the workload does not normally make

Each condition can be legitimate on its own. Together, especially immediately after a suspicious web request or application error, they form a much stronger signal.

Reverse shell vs bind shell: what’s the difference?

Reverse shells and bind shells both provide remote command access when used maliciously, but they establish the connection in opposite directions.

Reverse shells are attractive because production servers, containers, and cloud workloads usually need at least some outbound access even when inbound is locked down. Firewall policy should account for both inbound and outbound communication rather than focusing only on internet-facing services.

Reverse shell vs web shell: what’s the difference?

A web shell is usually malicious server-side code or a malicious file placed on a web server to expose shell-like functionality via an exploited vulnerability and accept inbound commands. A reverse shell is any live command session carried over an outbound connection. The two concepts are related but not interchangeable.

A web shell persists as a file on the server and accepts inbound commands via HTTP, making it accessible as long as the file remains in place. A reverse shell session is ephemeral – it exists only while the connection is active. That said, attackers routinely pair reverse shells with persistence mechanisms such as cron jobs, startup scripts, or scheduled tasks that re-initiate the outbound connection after a reboot or session drop. An attacker may upload a web shell first and then use it to launch a reverse shell, or may reach a reverse shell directly through command injection or another RCE path without ever placing a file on the server.

Which web vulnerabilities can lead to reverse shells?

A reverse shell is rarely the first vulnerability in an attack chain. It is usually the result of a weakness that lets an attacker execute something or reach a trusted service that can. The AppSec priority is to identify and fix those enabling weaknesses before they become shell access.

This is where dynamic application security testing (DAST) is especially relevant. A scanner does not need to observe an active reverse shell to reduce reverse shell risk. It needs to find externally reachable vulnerabilities that can lead to command execution, arbitrary code execution, unsafe file handling, or a chainable path into trusted services – and by closing those gaps, you reduce the risk of a reverse shell being deployed in the first place.

Reverse shell payload pattern anatomy for defenders

A reverse shell payload usually combines three elements:

1. An outbound network connection
2. A way to attach command input and output to that connection
3. A command interpreter or equivalent execution mechanism

As a defender, you don’t need working payload strings to recognize this behavior. You need to understand which process created the connection, which child process started, what identity was used, and whether the sequence is normal for that workload.

The examples below describe broad payload families without providing syntax, commands, listener setup, or operational details.

Language and tool names can be useful search terms, but detections should not depend on a fixed payload signature. Attackers can change syntax, use a different interpreter, rename utilities, or rely on built-in runtime capabilities. Behavior-based correlation is more durable.

Reverse shell indicators: what defenders should look for

Reverse shell detection is strongest when network, endpoint, process, identity, cloud, and application telemetry are correlated. A single suspicious signal might get lost in the noise or be insufficient to take action – a suspicious sequence is more useful.

MITRE’s web shell detection strategy highlights suspicious chains such as unexpected file creation in web directories followed by web server processes spawning command shells or script interpreters. The same parent-child process logic is relevant when hunting for reverse shell behavior launched from web-facing systems.

Common reverse shell process patterns

Reverse shells vary by operating system, runtime, and available tooling, but the process relationships are often recognizable.

To tell legitimate and suspicious activity apart, context matters. A shell started by an administrator during a documented maintenance window may be legitimate. A shell started by a web worker, application pool, database process, image conversion library, template engine, or upload handler is a much stronger warning sign.

Baselines should therefore account for workload purpose, environment, deployment stage, approved administrative activity, and known automation. The goal is not to alert on every interpreter launched but to reliably identify interpreters and outbound connections in process contexts where they do not belong.

How to detect reverse shells in logs and telemetry

No single log source can reliably identify every reverse shell. Detection works best as a correlation problem: connect the application event that enabled execution to the process that launched, the identity that ran it, and the network session that followed.

Network logs

Start with egress logging. Review outbound connections from systems that should not initiate arbitrary external communication, especially web servers, application servers, database servers, CI/CD infrastructure, containers, and cloud workloads.

Investigate:

• New, rare, uncategorized, or low-reputation destinations
• Connections to ports or protocols the workload does not normally use
• Long-lived sessions with small, bidirectional traffic exchanges
• Outbound communication beginning immediately after an application error, suspicious request, or upload
• Repeated connection attempts across several hosts
• Direct-to-IP communication where the workload normally uses named services or approved proxies
• Egress that bypasses the organization’s expected proxy, service mesh, or network path

A destination being unknown is not yet proof of compromise. The strongest network evidence comes from combining unusual egress with process and application context.

Web server and application logs

Application logs can help identify the entry point. Look for suspicious parameters, unusual upload activity, unexpected template or serialization errors, requests to rare endpoints, and bursts of probing before a successful request.

Investigate:

• The request immediately preceding the outbound connection
• Upload, template rendering, import, export, diagnostic, conversion, and administrative features
• Repeated malformed inputs from the same client or session
• A change from visible errors to a quiet or successful response
• Access to forgotten, legacy, debug, or rarely used endpoints
• Authentication events that do not fit the affected user or service account
• API requests to internal-looking or undocumented routes
• Requests that caused unusually long processing times or abrupt worker restarts

Preserve the full request context where policy permits, including headers, route parameters, user identity, session information, and correlation IDs. A web log entry alone may look routine, but its timing relative to process creation and egress can expose the attack path.

Endpoint and EDR telemetry

Endpoint detection and response (EDR) telemetry is often where reverse shell behavior becomes clearest. Review process creation, parent-child relationships, network connections, command interpreter activity, file writes, credential access, and service changes.

Investigate:

• Which process created the outbound connection
• The process’s parent and grandparent
• Whether a shell, scripting engine, network utility, or system tool launched
• The user or service identity associated with the process
• Temporary files, dropped binaries, or modified scripts created around the same time
• Access to environment variables, configuration files, cloud credentials, SSH keys, or local secrets
• Discovery commands, account enumeration, service inspection, or security-control tampering
• Persistence through scheduled tasks, services, startup entries, or modified application files

Getting a clear process-tree view is central to triaging reverse shell signals because it connects network behavior to the application or service that initiated the shell process.

Cloud and container telemetry

Cloud workloads add identity and control-plane context. A reverse shell launched inside a container, virtual machine, build runner, or serverless workload may be followed by metadata access, internal service probing, credential use, or unusual control-plane API calls.

Investigate:

• Unexpected access to instance or container metadata services
• External destinations outside the workload’s approved dependency list
• Interactive shells or terminal allocation in production containers
• New child processes in minimal or distroless workloads (minimal images with no package manager or shell)
• Service-account activity that begins immediately after the suspected session
• Unusual calls to secrets managers, object storage, identity services, or orchestration APIs
• East-west traffic from the affected workload to internal services
• Container image changes, writable-layer modifications, or newly mounted paths
• Build-runner or CI/CD activity outside normal job definitions

Cloud audit logs can show what happened after the initial shell, while container and host telemetry can show how the session started. Both are needed to assess blast radius.

Correlating evidence

A high-confidence reverse shell investigation may collect the following sequence of signals:

1. A suspicious request reaches a web application or API.
2. The application process launches a shell, interpreter, or system utility.
3. The new process initiates an unusual outbound connection.
4. The workload identity accesses files, secrets, metadata, or internal services.
5. Follow-on activity appears in endpoint, cloud, or identity logs.

Security information and event management (SIEM) rules should prioritize such sequences over isolated indicators. The exact command line may change, but the relationship between exploitation, process execution, and egress is harder to hide.

Reverse shell prevention best practices

Preventing reverse shells requires defense in depth: remove vulnerabilities that permit execution, restrict outbound network paths, limit application privileges, and monitor for behavior that should not occur in production workloads. The following security practices help minimize the risk of reverse shells being established:

• Find, fix, and prevent command injection vulnerabilities. Avoid passing user-controlled input to OS commands. Prefer language or framework APIs that perform the required operation without invoking a shell. Where command execution is unavoidable, use fixed executables and arguments, strict allowlists, strong isolation, and narrowly scoped service identities.
• Prevent arbitrary code execution. Harden template engines, upload handlers, plugin systems, deserialization logic, CI/CD hooks, document converters, and extension points. Any feature that evaluates, transforms, imports, or executes user-controlled content deserves additional design review and testing.
• Restrict outbound network traffic. Production servers and containers should connect only to approved destinations, services, and ports. Route egress through controlled gateways or proxies where practical, and alert on bypass attempts. Firewall policies should cover both inbound and outbound traffic, not only exposed services.
• Run applications with least privilege. Application users should not be privileged system users. They should not have broad file access, interactive shell access, unnecessary cloud permissions, or access to secrets unrelated to their function. This limits what an attacker can do if command execution is achieved.
• Remove unnecessary interpreters and utilities. Minimal server and container images reduce the tools available after compromise. Remove shells, compilers, package managers, network utilities, and debugging tools where the workload does not need them. This limits post-exploitation options but does not replace fixing RCE flaws.
• Harden file upload and processing paths. Store uploads outside executable directories, validate content server-side, rename files, constrain parsers and converters, and prevent uploaded content from being interpreted as code. Treat archive extraction, document conversion, and media processing as execution-adjacent features.
• Monitor suspicious parent-child process relationships. Alert when web servers, application runtimes, database services, container entry points, or build agents spawn shell interpreters, network utilities, or unexpected scripting processes.
• Segment application environments. A compromised public-facing application should not be able to reach arbitrary internal systems. Use network segmentation, workload identity, service-to-service authorization, cloud controls, and authenticated internal APIs to reduce blast radius.
• Protect metadata and control-plane services. Restrict access to cloud metadata endpoints, require modern metadata protections where available, minimize service-account privileges, and prevent application workloads from reaching administrative interfaces they do not need.
• Use DAST and secure code review together. DAST helps identify externally reachable vulnerabilities in running applications and APIs. Code review and static analysis (SAST) help eliminate unsafe execution paths before deployment. Each method provides different evidence and they work best as complementary controls.
• Prioritize proven and reachable risk. Focus remediation on vulnerabilities that are exposed, exploitable, and connected to sensitive applications or privileges. Confirmed command injection and RCE should receive immediate attention because they can provide a direct path to shell access.
• Retest after remediation. After fixing known command injection, RCE, unsafe upload, deserialization, file inclusion, or SSRF issues, retest the affected application. A code change is not sufficient evidence by itself. The dangerous behavior must be verified as absent or unreachable in the running environment.

Reverse shell defensive checklist

Use the following condensed reference during triage, control reviews, and remediation planning.

What to do if you detect a reverse shell

Treat any suspected reverse shell as an active compromise until evidence shows otherwise. Your immediate goals are to contain the identified session without unnecessarily destroying evidence, determine the entry point, assess blast radius, and prevent the same path from being reused. General response and remediation steps are:

1. Isolate the affected host, container, or workload. Restrict network access while preserving volatile evidence where possible.
2. Preserve logs and telemetry. Collect process trees, network flows, web and application logs, EDR data, cloud audit logs, identity events, memory evidence where appropriate, and relevant container events.
3. Trace the execution path. Trace the shell’s parent process through recent requests, uploads, authentication events, exposed applications and APIs, vulnerability findings, and any internal service involved in the chain.
4. Rotate potentially exposed credentials. Assume environment variables, configuration files, cloud tokens, database credentials, API keys, local secrets, and workload identities may have been accessed.
5. Remove persistence and contain follow-on activity. Look out for new accounts, scheduled tasks, services, startup entries, modified application files, implanted web shells, and lateral movement.
6. Patch or remove the vulnerable path. Do not rely only on blocking the observed destination, terminating the process, or adding an indicator to a denylist.
7. Rebuild when integrity cannot be established. For compromised containers and immutable workloads, replace affected instances from trusted images. For hosts, follow the organization’s incident response standard for eradication and recovery.
8. Retest the affected application. Confirm that the original execution path and any related vulnerability chain are no longer exploitable.
9. Add durable detections. Convert the incident into process, network, application, identity, and cloud detection logic based on behavior rather than only the observed payload or destination.

CISA’s incident and vulnerability response playbooks emphasize coordinated procedures to identify, remediate, recover, and track mitigations for cybersecurity incidents and vulnerabilities. That discipline matters because terminating a reverse shell without fixing its root cause only resets the clock – the session will most likely respawn in the near future.

How Invicti helps reduce reverse shell risk

Invicti provides an application security platform that helps security teams reduce reverse shell risk by identifying exploitable web vulnerabilities such as command injection, remote code execution, unsafe file handling, and injection flaws before attackers can chain them into shell access. Invicti’s proof-based DAST provides an outside-in view of how a running application or API behaves to assist in tracking down attack paths that are reachable through the deployed application.

For supported vulnerability classes, Invicti’s proof-based scanning can safely validate exploitable behavior and provide evidence that helps teams distinguish confirmed application risk from findings that still require investigation. This can improve prioritization and reduce the manual effort needed to reproduce certain issues, especially for injection and code execution vulnerabilities.

Application security testing is essential but should not be treated as a replacement for EDR, SIEM, network monitoring, cloud detection, or incident response tooling. Those controls are responsible for detecting and investigating active reverse shell behavior at runtime. Invicti’s tools come earlier in the chain to help teams find, validate, prioritize, and remediate the web application and API vulnerabilities that can make shell access possible.

Used as part of a broader AppSec program, Invicti can test web applications and APIs for externally reachable weaknesses, support recurring scans to catch regressions after code or configuration changes, and route findings into established remediation workflows. By reducing exploitable application-layer entry points, it complements the runtime controls that monitor process and network behavior.

To see how you can systematically scan your systems to find and eliminate vulnerabilities that can lead to reverse shell access, request a demo of the Invicti Platform.