File Upload Security: A Blue Team Checklist

File upload security has one job: stop an attacker from uploading a script and running it as your web server. When validation is weak, an “image” upload becomes a web shell, and the attacker gets persistent command execution through the browser. Detection comes down to two signals — a new executable file appearing in a web-accessible directory, and the web server process spawning a shell. This guide ships the file-integrity and process rules plus the hardening checklist.

Malicious file upload sits under A03:2021 — Injection and the web shell it plants maps to T1505.003 — Server Software Component: Web Shell. The 2025 SAP NetWeaver flaw CVE-2025-31324 — an unrestricted file-upload bug rated CVSS 10.0 and exploited in the wild to drop JSP web shells — is the worked example.

What is a malicious file upload attack?

A malicious file upload attack abuses an upload feature to place an executable script in a location the web server will run. The attacker uploads shell.php disguised as photo.php.jpg (or with a doctored content type), the server stores it in a web-accessible directory, and the attacker requests it in a browser to run commands. The result is the same as command injection: code execution as the web server account, plus persistence.

That persistent script is the web shell, and it is one of the most durable footholds an attacker can get — which is why both prevention (stop the upload) and detection (catch the shell) matter.

What makes a file upload dangerous?

The unifying lesson: the file system and the web-server process are where upload attacks become visible, not the upload request itself, which often looks benign.

How to detect malicious uploads and web shells

Two rules carry most of the weight, backed by file integrity monitoring on every upload directory.

A new executable in a web-accessible upload directory

File integrity monitoring on upload paths is the earliest signal — a script appearing where only media should is almost never legitimate.

title: Executable File Created in a Web-Accessible Upload Directory
id: 6e3b1d27-darkpwn-illustrative
status: experimental
logsource:
  category: file_event
detection:
  selection:
    TargetFilename|contains: ['/uploads/','/wp-content/uploads/','/webroot/','/htdocs/']
    TargetFilename|endswith: ['.php','.phtml','.jsp','.jspx','.aspx','.asp','.cfm']
  condition: selection
falsepositives:
  - Legitimate deploys writing scripts (scope to upload dirs, exclude CI/deploy paths)
level: high

The web server spawning a shell (web shell execution)

When the uploaded script runs, the web server process spawns a shell — the same behavioral backbone used for command injection detection.

title: Web Server Process Spawning a Shell (Web Shell Execution)
id: 9c4f2a18-darkpwn-illustrative
status: experimental
logsource:
  category: process_creation
detection:
  parent:
    ParentImage|endswith: ['\w3wp.exe','\httpd','\apache2','\nginx','\java','\php-fpm']
  child:
    Image|endswith: ['\cmd.exe','\powershell.exe','\bash','\sh']
  condition: parent and child
falsepositives:
  - CGI apps that legitimately shell out (allowlist the specific pair)
level: high

For content scanning of files at rest, a YARA rule flags common web-shell markers — useful in FIM and IR sweeps, with the caveat that obfuscation evades it.

rule darkpwn_webshell_indicators {
  meta:
    author = "Colson"
    description = "Heuristic indicators of common PHP/JSP web shells"
    attack = "T1505.003"
  strings:
    $a = "eval(" nocase
    $b = "base64_decode(" nocase
    $c = "system(" nocase
    $d = "Runtime.getRuntime().exec" nocase
    $e = /\$_(GET|POST|REQUEST)\s*\[/
  condition:
    2 of them
}

How to test your upload detection

In a lab app you own:

1. Upload a benign script to an upload directory and confirm the FIM rule fires.
2. Execute a harmless test “shell” (one that just runs id) and confirm the web-server-spawns-shell rule fires.
3. Upload with a doctored extension/content type and confirm validation rejects it.
4. Replay normal media uploads and confirm the rules stay quiet.

How to prevent malicious file uploads

• Patch upload-capable applications fast — CVE-2025-31324 was CVSS 10.0 and actively exploited.
• Run the web server at least privilege so a web shell is boxed in.
• Default-deny egress from web hosts so a shell’s callbacks are blocked and logged.

Common file upload detection mistakes

• WAF-only coverage. The upload request looks normal; the danger is on disk and in the process tree.
• No FIM on upload directories. The earliest signal goes uncollected.
• Signature-only scanning. Obfuscation defeats it.
• Extension allowlists without content checks. shell.phtml and double extensions slip through.

File upload security checklist

1. Validate file type by magic bytes/content, never by extension or client content-type.
2. Store uploads outside the web root; serve via a handler; rename to random IDs.
3. Disable script execution in the upload directory at the web-server config level.
4. Enforce size limits and an allowlist of permitted content types.
5. Run file integrity monitoring on every web-accessible upload path.
6. Deploy the new-executable-in-upload-dir Sigma rule and the web-server-spawns-shell rule.
7. Run the web server at least privilege; default-deny its egress.
8. Patch upload-capable apps (e.g. CVE-2025-31324) on a KEV cadence.
9. Fire every rule in a lab against benign and malicious test uploads.

The takeaway

File upload security is prevention plus two signals: validate uploads by content and store them where they cannot execute, then watch for a script appearing in an upload directory and the web server spawning a shell. Continue the web-application defense arc with SQL injection detection and broken access control testing, or browse the full Detection Engineering pillar.