Security teams detect HDoor by hunting for suspicious web server activity, unexpected command execution and anomalous requests that match web shell behaviour. Correlate endpoint, web and process logs for new files, modified scripts and outbound connections from servers that should not initiate them. Review exposed applications and remove any unauthorised web shell artefacts.
What HDoor detection looks like in practice
HDoor is usually found through behaviour, not by a single signature. Security teams should look for web server processes doing things they normally should not, especially when those processes spawn shells, launch utilities, or touch files outside the expected application path. The most useful signal is a cluster of suspicious web activity, command execution, and server-side change together.
That means hunting should start with the exposed application surface and then fan out into host activity. If a web-facing system suddenly serves unusual requests, creates new script files, or makes outbound connections that do not fit its normal role, treat it as a possible web shell foothold rather than a noisy application issue.
Correlating logs matters because HDoor activity is often fragmented across layers. Web access logs may show the initial request pattern, endpoint telemetry may show process spawning or script execution, and file telemetry may show newly written or modified artefacts that match a shell or backdoor placement method.
Which signals are most useful to hunt first?
The highest-value indicators are the ones that connect request, execution and persistence. Look for unexpected command execution by the web server account, altered application scripts, and outbound network activity from a server that should usually be serving content, not initiating connections.
Suspicious file changes are especially important when they appear in web roots, upload directories or other application-writeable locations. A small file with unusual naming, recent modification time, or script content placed next to a legitimate application can be enough to justify deeper investigation.
Hunting should also include review of exposed applications for unauthorised artefacts. If an attacker has placed a web shell, the file may survive routine monitoring unless teams explicitly inspect the application surface and compare it to the expected deployment baseline.
How should teams validate and contain a suspected HDoor case?
Once the pattern appears, validate it by checking whether the server’s behaviour fits its intended role. A web server that begins launching command interpreters, contacting unfamiliar destinations, or writing new executable content usually deserves immediate containment and triage.
Malware Guide is useful here because web shells often sit in the same detection space as backdoors and other server-side malware, where file artefacts, execution patterns and evasion methods need to be investigated together.
Containment should preserve evidence while limiting further access. In practice, that means isolating the affected host or application path, capturing relevant logs and artefacts, and checking for follow-on activity before cleaning up the file itself. Removing the shell without understanding how it arrived can leave the original access path open.
Risk and Threat Considerations
HDoor is dangerous because a web shell turns an exposed application into an interactive foothold. Once that foothold exists, an attacker can often reuse the same server to enumerate the host, stage additional tools, or pivot into adjacent systems that trust the application server.
Failure mechanism: The attacker gains code execution through a web-accessible path, then hides in ordinary server traffic while using the shell to issue commands, write files, or make outbound connections that blend into hosting activity.
Impact: Teams can lose visibility into what the server is doing, miss lateral movement or data theft, and delay response because the malicious activity looks like normal web service behaviour until the artefacts are inspected directly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1505 — Server Software Component: Web Shell | HDoor detection centers on web shell artefacts and server-side execution patterns. |
| Recommendation — Map suspicious server behaviour to web shell activity and hunt for related process and file artefacts. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on correlating web, endpoint and process logs across the affected server. |
| Recommendation — Centralize and review host and application logs for web shell execution patterns. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potentially adverse events | The answer relies on monitoring exposed applications and server behaviour for anomalies. |
| Recommendation — Monitor exposed services for anomalous requests, execution and outbound connections. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | HDoor hunting requires system-level monitoring of unexpected execution, file changes and connections. |
| Recommendation — Tune system monitoring to alert on web server command execution and suspicious file creation. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | Correlating logs across web and endpoint layers is central to detecting web shell behaviour. |
| Recommendation — Verify that logging captures request, execution and file events needed to spot server compromise. | ||
Practitioner Guidance
What to prioritise: Start with the evidence chain that ties request, process and file activity together. A single strange request is weaker evidence than a request followed by a new script, shell execution, and outbound traffic from the same host.
What to verify: Confirm whether the affected server should ever initiate connections, write executable content, or spawn interactive processes. If any of those behaviours are outside the normal application design, treat them as high-signal indicators rather than benign anomalies.
Common mistake: Deleting the suspicious file too early can erase the best clue about how the shell was deployed. Preserve the artefact, the surrounding logs and the host context long enough to determine the entry point and whether the compromise extends beyond one file.
Practitioner takeaway: HDoor detection is strongest when teams think like hunters, not signature scanners, and use cross-layer evidence to separate a suspicious file from an active server-side compromise.