A common method of execution for this attack leverages vulnerabilities in a website (eg. SQL Injection, Remote File Inclusion) to remotely generate or install a file that will act as a WebShell. Once the WebShell is successfully installed, the remote attacker may then craft an HTTP POST request directly to the WebShell with embedded commands that will be executed as if the attacker had local (shell) access to the web server.
Attackers that successfully use WebShells take advantage of the fact that many organizations do not have complete visibility into HTTP sessions. Traditional tools rely on signatures and are easily left blind by intentional obfuscation of payloads and commands. In order to effectively respond to WebShell attacks, defenders must maximize visibility into each stage of the attack lifecycle.
Customer values/problems solved
- Without being able to reconstruct the entire HTTP session (request and response), traditional toolsets do not allow an investigator to see into enough of the attack lifecycle to understand the initial attack vector (Delivery, Exploit/Installation), what an attacker is doing (C2), and what the impact to the business is (Action).
- A traditional logs-only SIEM has no way to alert on suspicious HTTP sessions of this nature unless a downstream signature-based tool such as an IDS/IPS or web proxy has seen the exact attack before.
- Furthermore, HTTP sessions cannot be reconstructed with log data alone, meaning a complete lack of visibility into C2 commands, data exfiltration, and initial entry vector.
- RSA NetWitness Suite