A practical first pass

1. Authentication pattern

2. Account context

3. Session and process context

4. Persistence and service changes

5. Reviewable output

Why the AI boundary matters

Where Open Investigator fits A lot of Linux incident response starts with a login question, not a malware sample. Someone sees a spike of failed SSH attempts. A root login appears in the wrong time window. A service account logs in from an address nobody recognizes. A helpdesk ticket says "the server looks weird" and the only concrete clue is a username or IP address. At that point, the useful question is not "is this host compromised?" It is more boring and more important: That last point matters. If you let an AI assistant freely run shell commands during the first pass, you can get speed, but you also create a new risk: the model may over-collect, mutate the host, or produce a confident answer that nobody can audit later. For a login anomaly, I prefer a read-only evidence loop. Start with the narrow clue if you have one. If the alert names a user: If the alert names an IP address: If the alert is vague, start wider: The goal of the first pass is not to prove every detail. The goal is to build a timeline that a human responder can challenge. For a suspicious SSH login, I want the initial report to answer five things. Look for the difference between noise and access. A server can receive thousands of failed SSH attempts from the internet. That is useful background, but it is not the same as a successful session. The first split should be: A good report should show the exact log lines or normalized evidence behind that assessment, not just say "suspicious login observed." The username is only one part of the story. For the involved account, collect read-only account facts: This helps separate a noisy brute-force event from a potentially meaningful access event. If the login was successful, ask what was active around the same time. Useful read-only checks include: None of these alone prove compromise. Together, they can show whether the login became a shell, touched a web root, started a process, connected outbound, or did nothing observable. Login anomalies often matter because of what follows. For the same time window, check persistence surfaces: The first pass should be explicit about gaps. For example: "auth logs show a successful login, but no matching persistence change was found in the collected window" is much more useful than a dramatic conclusion. The output should not be an opaque chat answer. For a real handoff, I want a case folder that contains: This lets a second responder inspect the evidence, rerun missing checks, disagree with the conclusion, or attach the report to a ticket. An AI assistant is useful for correlation. It can connect login times, accounts, IPs, files, services, and network state faster than a tired human staring at separate terminals. But during first-pass incident response, the assistant should not have authority to remediate by default. Those actions may be appropriate later, but they belong in an approved response step, not in evidence collection. The safer pattern is: collect bounded evidence, write an auditable report, then let the responder decide what to do next. I maintain Open Investigator at Arvanta Cyber. It is an Apache-2.0 local AI incident investigation CLI for Linux and Windows hosts. The project is built around this read-only first-pass model: AI gets sealed investigation tools, not arbitrary remediation authority. For login anomalies, WebShell clues, suspicious IPs, Java service issues, and vague server alerts, the point is to turn a loose signal into a reviewable case folder. Project:

https://github.com/SEc-123/open-investigator Overview:https://www.arvantacyber.com/open-investigator/ Related read-only AI incident response guide:

https://www.arvantacyber.com/open-investigator/articles/local-ai-server-incident-response/ Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse