--- name: detect-malicious-upload description: "Detection, hunting, and hardening for malicious file upload, where an attacker abuses an upload feature to plant a web shell or polyglot file under a web-accessible path and then requests it for code execution. Maps to MITRE ATT&CK T1505.003, T1190, T1059, T1036.007, and T1036.008. Keys off web server access logs (IIS, Apache, Nginx), WAF and reverse-proxy multipart captures, Sysmon Event ID 11 and 1, Windows Security Event ID 4688, and EDR file-scan verdicts. Gives the defender view, log sources, content-inspection and polyglot detection logic, public rule pointers, a hypothesis-driven hunt, upload hardening, and blind spots. Use when hunting malicious file uploads, triaging a suspected web shell, investigating a web app process that spawned cmd or /bin/sh, reviewing uploads whose magic bytes disagree with their extension, hunting for polyglot or GIFAR files, or hardening an upload feature against webshell drops." --- # Malicious File Upload - Defensive Methodology > **Tier 2 - methodology skill.** No bespoke UMBRASEC detection rule ships with this skill yet. It gives the defender's method, the log sources and signals, and the hardening, and points to public rule sources. Promotion to Tier 1 (a sourced, tuned UMBRASEC rule) is tracked in [COVERAGE.md](https://github.com/umbrasec-labs/umbra-blue/blob/main/COVERAGE.md). Do not treat the content below as citing a UMBRASEC rule; there is none for this threat yet. ## TL;DR for defenders A malicious upload is an attacker getting a server-executable file (a web shell) past an upload feature that was supposed to accept only documents or images, then requesting it to run commands as the web service account. The two ways past a weak filter are a spoofed type (double extension `shell.php.jpg`, mismatched `Content-Type`, trailing dot or null byte, case tricks like `.pHp`) and a polyglot (one blob that is a valid image header and valid script at the same time, for example a GIF or JPEG whose trailing bytes are PHP). You catch it at two layers. At the request layer, an upload whose declared extension or `Content-Type` disagrees with its actual magic bytes, or an upload of a server-executable extension at all, is the anomaly, and a GET or POST to a brand-new file under the upload directory right after is the use of what was planted. At the host layer, a new server-side script file appears under the web root (MITRE ATT&CK **T1505.003 Web Shell**), and the application process spawns a child it never normally spawns. The content-mismatch signal is noisy and sometimes blind to TLS bodies; the new-script-file and parent-child process signals are the higher-fidelity catches. This skill ships no UMBRASEC rule for this threat; it points to maintained public rule sets instead. ## What it looks like, defender view In telemetry the attack presents in two beats: the drop, then the use. The drop is a multipart POST to an upload handler carrying a file whose real content does not match what the feature is supposed to accept: the declared extension says `.jpg` but the leading bytes are `