Investigating a web shell: forensic triage and timeline

Finding a web shell is the beginning of an investigation, not the end. The file proves compromise; the questions that matter are how did they get in, what did they do, where else are they, and are they still here? This guide gives a practical workflow that answers those questions while preserving evidence that may later be needed for legal, regulatory or insurance purposes.

Phase 0 — Don't destroy the evidence

The instinct to delete the file immediately is strong. Resist it.

If the business impact of leaving the server running is unacceptable, capture memory and a disk image first, then take it offline.

Phase 1 — Collection

Volatile data

• Memory image — essential for in-memory implants (injected .NET assemblies, Java filters/agents, native IIS modules) and for recovering commands that never touched disk.
• Process list with command lines, parent relationships and loaded modules for worker processes.
• Network connections from the worker processes.

Web server artifacts

Operating system artifacts

• Windows: $MFT, $UsnJrnl:$J, $LogFile, Security/System/Application and Sysmon event logs, PowerShell operational logs, Prefetch, Amcache, ShimCache, scheduled tasks, services, local accounts.
• Linux: auditd logs, /var/log/auth.log or secure, shell histories, cron and systemd units, /tmp and /dev/shm, stat output with birth times for web files.

Tools such as KAPE (Windows) and UAC (Unix-like) collect these in a forensically sound, repeatable way; Velociraptor does it across a fleet.

Phase 2 — Analyse the shell safely

Handle the file as malware: analyse on an isolated system, never execute it, and store it in password-protected archives. Establish:

• Hashes (SHA-256) for sharing and fleet-wide sweeps.
• Capabilities — command execution, file management, database access, tunnelling, reflection-based loading.
• Authentication — a hard-coded password or key suggests a specific operator or toolkit; record it (securely) because it can help identify related shells.
• Obfuscation — decode layers statically to understand behaviour, but do not publish or reuse the decoded code.
• Family — compare against threat-intelligence reporting; family attribution helps predict next steps.

Phase 3 — Establish the anchor time

Everything pivots on when the shell really appeared.

On NTFS

Parse the MFT (for example with MFTECmd) and compare the file's two timestamp sets:

Red flags: $SI creation earlier than $FN creation; $SI timestamps with zeroed sub-second precision; a file "created" years ago in a directory created last week. The USN journal independently records FileCreate, DataExtend and RenameNewName events with timestamps and is often the most reliable source.

On Linux

Use stat to read Birth (on filesystems and kernels that expose it), Change (ctime) and Modify (mtime). A shell whose mtime has been set to match neighbouring files will still carry a recent ctime. auditd records, if enabled, give the exact creating process.

From telemetry

EDR or Sysmon file-creation events give the creation time and the creating process — the strongest possible anchor.

Phase 4 — Build the timeline

Normalise everything to UTC and merge. Plaso (log2timeline.py / psort.py) parses most of these sources into a single super-timeline; smaller, targeted timelines built from MFT, web logs and process events in Timeline Explorer or a notebook are often faster to reason about.

A typical reconstructed sequence looks like this (illustrative):

Key questions the timeline should answer:

1. Initial access — what request, from where, immediately preceded creation?
2. Operator activity — every request to the shell, and every child process it produced.
3. Credential exposure — which secrets were on the server (config files, app pool identities, cached credentials) and were they accessed?
4. Expansion — additional shells, new accounts, persistence mechanisms, lateral movement.
5. Data access — database queries, archive creation, large responses.

Phase 5 — Scope

Web shell intrusions frequently involve more than one shell — attackers plant backups in case one is found. Sweep broadly:

• Hash and YARA sweeps across all web servers, not just the affected one (see YARA and Sigma rules).
• Log pivots — every request from the attacker's IPs and user agents, across all sites and all retained logs.
• Behavioural hunts — process-tree analytics and rare-URI log hunts across the estate.
• Configuration drift — new IIS modules, handler mappings, .htaccess directives, Java agents, scheduled tasks.
• Identity — use of the web server's service accounts elsewhere; new admin accounts in the application and the directory.
• Farm members and replicas — load-balanced nodes, disaster-recovery copies and backups may contain the same shell.

Documenting findings

Record for each finding: artifact path and hash, source of evidence, UTC timestamp, analyst, and confidence. Keep original evidence read-only and work from copies. A clean chain of custody matters if the incident leads to regulatory notification, insurance claims or law-enforcement referral.

Handing over to eradication

Only when the timeline and scope are understood should you move to removal — the subject of eradication and hardening. Eradicating on a partial picture is the most common reason intruders return through a second shell a week later.