Tools: How to triage a suspected WebShell without giving AI a shell - Guide

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

Code Block

Copy

oi web --root /var/www -s 7d oi web --root /var/www -s 7d oi web --root /var/www -s 7d evidence.jsonl commands.log report.json - what request or path started the suspicion - whether related files changed recently - whether the web user has unusual processes - whether those processes have network connections - whether persistence or scheduled tasks changed nearby - whether auth logs show a related login or privilege event - what evidence is still missing - recently changed files under the web root - suspicious script extensions or unexpected upload locations - web access/error log entries around those paths - requests with unusual parameters, encodings, or user agents - processes owned by the web service user - listening sockets and outbound connections - persistence files, services, cron entries, and recent auth activity - A new file appears in an upload directory. - Web logs show a POST to that file shortly after creation. - A process owned by the web user opens an outbound connection. - The same time window shows a service or cron change. - web log checks - recent file checks - process snapshots - network snapshots - persistence snapshots - auth/account context - package and container context when relevant - evidence.jsonl for structured observations - commands.log for the audit trail - report.json for machine-readable handoff - report.md for human review