🌐 Web Application Compromise Response Quickstart
Time-boxed response path for web application compromise incidents. Covers initial access vector validation, server isolation, evidence preservation, web-shell hunting, and vulnerability remediation to restore the application to a known-good state.
First 15 Minutes
0/4Determine how the attacker gained access to the web application by reviewing WAF logs, web-server access logs, and application error logs for evidence of exploitation. Look for SQL injection patterns, path-traversal attempts, deserialization attacks, file-upload exploits, or authentication-bypass indicators. Identifying the specific vulnerability is essential for immediate patching and for understanding whether the attack was automated (mass scanning) or targeted.
Isolate the compromised web server from the production network while preserving its current state for forensic analysis. Options include removing it from the load-balancer pool while keeping it running, applying firewall rules to block all inbound traffic except from forensic workstations, or placing it in an isolated VLAN. Avoid powering off the server as this destroys volatile evidence including running processes, network connections, and memory contents.
Immediately rotate or disable credentials for all service accounts associated with the web application, including database connection strings, API keys, cloud-service credentials, and SMTP relay accounts. If the attacker achieved code execution on the web server, they likely have access to configuration files containing these credentials. Change passwords for the application database user and any backend service accounts before the attacker can use them for lateral movement.
Establish the earliest evidence of compromise by reviewing authentication logs, web-server access logs, and file-modification timestamps. Look for the first successful exploitation attempt, the first web-shell upload, or the first anomalous process execution. Bounding the timeframe determines how far back log analysis must extend and helps estimate the duration of attacker access, which is critical for assessing potential data exposure.
First 60 Minutes
0/4Acquire a full memory dump of the compromised web server using LiME or a similar tool appropriate for the server operating system. Memory analysis can reveal running web shells, injected code in web-server processes, active reverse shells, credential material, and decrypted HTTPS session data. This is especially valuable for detecting in-memory-only web shells that do not exist on disk and would be missed by file-system analysis alone.
Collect and preserve all web-server access logs (Apache/Nginx access.log, error.log), application-specific logs, and WAF logs covering the full investigation timeframe. These logs are the primary evidence source for reconstructing the attacker HTTP requests, identifying exploited endpoints, and discovering additional payloads or web shells that were uploaded. Export logs to a forensic evidence repository and compute hash values for integrity verification.
Preserve system-level logs including the systemd journal, syslog, auth.log, and kernel logs from the compromised server. These logs capture operating-system-level events such as user logins, privilege escalation, cron-job execution, package installations, and kernel module loads that the attacker may have performed after gaining initial web-application access. System logs provide the host-level context that web-server logs alone do not capture.
If an EDR agent is deployed on the web server, pull process-execution telemetry, file-creation events, and network-connection data for the investigation timeframe. Focus on child processes spawned by the web-server process (e.g., apache, nginx, tomcat), as these often indicate command execution through a web shell. Look for interpreters (python, perl, bash) spawned by the web server, outbound connections to attacker infrastructure, and privilege-escalation attempts.
First 4 Hours
0/4Conduct a systematic sweep of the web-application document root and upload directories for web shells. Use multiple detection methods: file-system timeline analysis to find recently created or modified files, YARA rules targeting known web-shell signatures, entropy analysis to detect obfuscated payloads, and comparison of the current file system against a known-good deployment baseline. Check for web shells in unexpected locations such as image directories, temp folders, and framework cache directories.
Determine whether the attacker pivoted from the web server to other internal systems. Review authentication logs for SSH connections, database connections from unusual source IPs, and internal network scans originating from the web server. Check whether the attacker accessed internal services, read sensitive configuration files containing credentials for other systems, or deployed tools for network reconnaissance. Lateral movement significantly increases the incident scope and recovery effort.
Apply patches or mitigations for the exploited vulnerability before restoring the web application to production. This may involve applying vendor security patches, deploying WAF rules to block the exploit pattern, updating application framework versions, or modifying application code to fix custom vulnerabilities. Verify the patch effectiveness by attempting to reproduce the exploit in a staging environment. Do not restore the application to production until the vulnerability is confirmed closed.
Search for persistence mechanisms the attacker may have established beyond the web shell, including cron jobs, systemd services or timers, SSH authorized keys, modified system binaries, kernel modules, and scheduled tasks. Review the systemd journal for service-creation events and check all common persistence locations on the server operating system. Failure to remove persistence mechanisms will allow the attacker to regain access even after the initial vulnerability is patched.
DFIR Assist — Web Application Compromise Response Quickstart Quickstart | Printed 3/1/2026