Detect a malicious file added to a shared webroot by watching for new or changed web-accessible files, unexpected scripts, and uploads outside deployment processes. Compare directory contents against approved releases, scan for web shells and suspicious permissions, and alert on changes made by non-deployment accounts. Correlate with web server logs and file integrity checks.
How to spot a malicious file addition in a shared webroot
A shared webroot is a high-value target because one dropped file can become immediately web-accessible. Detection works best when you treat the directory as both content and execution surface, then look for deltas: new files, modified timestamps, unusual extensions, unexpected scripts, and uploads that did not come from the normal deployment path.
Start by establishing an approved baseline for the webroot, then compare the live directory to that baseline on a schedule and after every deployment. The most useful signals are not only “a file exists,” but “this file was not part of the release,” “its owner or permissions are unusual,” or “it appeared outside the release window.”
For broader hardening and response context, the File Upload Security Guide is the most direct companion when the suspicious file reached the webroot through an upload path. If the same content later behaves like persistence, the Persistence Techniques Guide helps connect the file drop to post-compromise intent.
What makes a webroot drop suspicious
The danger is not limited to obvious web shells. Attackers also hide in plain sight with innocuous names, double extensions, small PHP or ASP stubs, renamed image files that still execute, or files placed where the web server will parse them as code. A malicious file may also arrive with permissions that let the web server edit or execute it when that should never happen.
Shared webroots are especially risky when deployment, content management, and ad hoc file placement all write into the same tree. That makes it harder to distinguish an approved release from a malicious insertion, so detection should focus on origin as well as content. A file added by a CI/CD account, deployment agent, or release process is very different from one created by an interactive account or an unknown service context.
Correlate file changes with web server access logs, upload logs, and deployment records. A suspicious file becomes much more meaningful when it appears shortly after an exploit attempt, an authenticated session from an unusual source, or an unexpected POST request to an upload endpoint. The file system event and the request trail should tell the same story.
Detection signals and response logic for shared webroots
Use file integrity monitoring to alert on changes to executable content, script directories, and other web-accessible locations. Pair that with allowlisting for known release artifacts, because a simple “new file” alert can be noisy in environments where content changes frequently. The better question is whether the file belongs in that location and whether the actor who wrote it had a legitimate deployment role.
When a suspicious file appears, inspect adjacent files and parent directories, not just the dropped object itself. Attackers often place support files, include files, or renamed payloads alongside the primary script. Review permissions, file ownership, and recent modifications together so you can see whether the drop was a one-off upload or part of a broader compromise chain.
If the file is executable or web-reachable, isolate the host or web path as needed, preserve evidence, and compare the directory against the last known-good release. If the file could have exposed credentials, tokens, or session material through a web shell or backdoor, treat the event as more than content tampering and investigate for lateral movement or follow-on access.
Risk and Threat Considerations
Shared webroots create a direct bridge between file placement and code execution, so a single malicious file can become an immediate foothold. The main risk is that a legitimate content path also becomes an attacker persistence path, which makes the compromise harder to spot and easier to reuse.
Failure mechanism: An attacker writes a file into a web-accessible directory, then uses the server’s normal parsing or execution behaviour to run it, hide it, or return it to visitors.
Impact: The result can be remote code execution, web shell persistence, content tampering, defacement, credential theft, or further movement through the environment from a trusted server.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1105 — Ingress Tool Transfer | File drops in a webroot often follow payload transfer into a server directory. |
| T1027 — Obfuscated Files or Information | Malicious webroot files are often disguised with misleading names or content. | |
| T1505.003 — Server Software Component: Web Shell | A malicious file in a webroot is frequently a web shell used for persistence and execution. | |
| Recommendation — Hunt for payload staging and delivery paths that place files on the web server. Scan for concealed or masqueraded web files that evade routine review. Detect and remove web shells from web-accessible directories and review post-access activity. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Shared webroot file drops are an application-layer exposure that needs secure handling and validation. |
| Recommendation — Restrict webroot write paths and validate deployed content before publishing it. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | File integrity checks and approved-release comparison are central to detecting malicious webroot changes. |
| Recommendation — Verify webroot integrity against trusted baselines and alert on unauthorized changes. | ||
Practitioner Guidance
What to verify: Confirm that every writable webroot path has a known owner, a known deployment path, and a file-integrity baseline. If a directory is writable by both deployment tooling and ad hoc users, treat detection quality as degraded until that split is fixed.
Decision rule: If a new file is web-accessible and cannot be tied to an approved release or content workflow, investigate it as suspicious immediately, even if it looks small or harmless. If it also has execute permissions, unusual script content, or a suspicious timestamp, prioritise containment over prolonged triage.
Practitioner takeaway: The key judgement is provenance, not just presence, because a malicious webroot file matters most when the server is willing to serve or execute it as normal content.
Related resources from NHI Mgmt Group
- How should security teams detect malicious email campaigns that use trusted third parties and obfuscated file chains?
- How do security teams detect malicious images that hide code without changing file size or appearance?
- How can security teams detect a shared webroot?
- Why are NHIs a critical concern for security teams?