Tools: How to triage a suspected WebShell without giving AI a shell - Guide
Start from the web root, not a verdict
Correlate weak clues
Keep the AI boundary boring
What a useful output looks like
Where Open Investigator fits A suspected WebShell is awkward because the first clue is often weak. You may have one odd request in an access log, one newly modified file under a web root, a process running as the web user, or an outbound connection that does not fit the service. The dangerous move is to jump straight into cleanup. Before deleting files or restarting services, a responder needs a small evidence map: That is the point where local, read-only AI can be useful. A practical first pass can start with the web root and recent time window: The goal is not to ask AI to decide whether the host is compromised. The goal is to collect enough context that a human can challenge the next step. For a suspected WebShell, I would want the first-pass collector to look at: None of those require remediation authority. A single clue is noisy. A PHP file changed yesterday may be a normal deploy. A POST request to an upload directory may be normal application behavior. An outbound connection may belong to a legitimate integration. The value comes from correlation. That chain is not a final incident report, but it is much more useful than a vague alert. If an AI investigation tool can run arbitrary shell on a production host, it is too easy for the model to cross from investigation into response. For this workflow, I want the model to request sealed read-only checks instead of improvising commands: The tool should log every command and every denial. It should write evidence separately from the summary, so a responder can reproduce or reject the conclusion. A useful first pass should produce a case folder, not just a paragraph. The artifacts I want are: The report should say what was found, why it matters, what is missing, and what a human responder should verify next. It should not delete the suspected file, block the IP, kill the process, or restart the web service. I maintain Open Investigator at Arvanta Cyber. It is an Apache-2.0 local AI server investigation CLI for Linux and Windows hosts. The WebShell use case is one of the scenarios it is designed for: start from a weak web clue, collect read-only host evidence, and produce a reviewable evidence bundle. WebShell investigation page:
https://www.arvantacyber.com/open-investigator/webshell-investigation-tool/ Project overview:https://www.arvantacyber.com/open-investigator/ GitHub:
https://github.com/SEc-123/open-investigator If you do incident response, blue-team work, web operations, or SRE on Linux servers, the design question I care about is this: what evidence would you require before trusting an AI-assisted first pass on a suspected WebShell? Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse