DEV Community

Qimin Zhao
Qimin Zhao

Posted on

How to investigate a suspicious IP on a Linux server with read-only evidence

#incidentresponse #linux #security #opensource

Disclosure: I maintain Open Investigator at Arvanta Cyber. Open Investigator is Apache-2.0 open source.

When an alert starts with only an IP address, the first response question is not
"is the host compromised?" It is narrower:

Where did this IP appear, what changed around that time, and what evidence is
still missing?
Enter fullscreen mode Exit fullscreen mode

Open Investigator is built for this first-pass loop. It runs locally on the
host, lets AI call sealed read-only investigation tools, and writes an auditable
case folder instead of giving the model raw shell access.

Repository:

https://github.com/SEc-123/open-investigator
Enter fullscreen mode Exit fullscreen mode

Relevant page:

https://www.arvantacyber.com/open-investigator/local-ai-incident-response/
Enter fullscreen mode Exit fullscreen mode

Start with the IP

Build the tool:

git clone https://github.com/SEc-123/open-investigator.git
cd open-investigator
cargo build --release
Enter fullscreen mode Exit fullscreen mode

Run an IP-focused investigation:

./target/release/oi ip 1.2.3.4 -s 7d
Enter fullscreen mode Exit fullscreen mode

This asks a practical set of questions:

  • Did the IP appear in auth logs?
  • Did it hit web access logs?
  • Is it connected now?
  • Is it tied to a listening service or process?
  • Did suspicious files, persistence entries, or account activity appear nearby?
  • Which evidence categories were unavailable because of permissions or platform differences?

Why this should be read-only

Early in triage, the responder often does not know whether the IP is an
attacker, scanner, customer, proxy, admin VPN, monitoring system, or false
positive.

That is why Open Investigator keeps the default boundary narrow:

  • no raw shell for the AI in safe mode
  • no host isolation
  • no IP blocking
  • no process killing
  • no file deletion
  • no account disabling
  • no firewall or registry changes

The output is evidence and a report. Remediation belongs in separate,
human-approved response systems.

What gets collected

For an IP investigation, useful evidence usually spans more than one log file:

  • IOC search across readable logs and text surfaces
  • authentication events and login anomalies
  • process and network context
  • services and persistence entries
  • web logs and recent web-root changes
  • package and container context when available
  • recent files and command history signals

Open Investigator records observations into:

.oi/cases/<case-id>/
  case.json
  evidence.jsonl
  commands.log
  report.json
  report.md
Enter fullscreen mode Exit fullscreen mode

The report is not the source of truth by itself. The important property is that
the report can point back to evidence records and command audit entries.

Follow-up with a natural-language question

If the IP appears in web logs or auth logs, ask a focused follow-up:

./target/release/oi ask "Investigate 1.2.3.4 on this host. Focus on auth logs, nginx access logs, related processes, outbound connections, recent web-root changes, and persistence over the last 7 days." -s 7d
Enter fullscreen mode Exit fullscreen mode

The AI investigator can branch from observations:

  • web hit -> suspicious paths -> recent files -> process context
  • failed login burst -> successful login -> account context -> shell history
  • active connection -> process owner -> service context -> persistence

That loop is the reason to use AI here. It can decide the next bounded evidence
request while staying inside the read-only tool catalog.

What a useful result looks like

A useful first-pass report should include:

  • where the IP appeared
  • timestamps and source files where possible
  • related users, processes, services, files, and network connections
  • severity and confidence for findings
  • evidence gaps and permission issues
  • recommended manual confirmation steps

It should not pretend that one scan proves absence of compromise.

When to use deeper mode

Open Investigator has an investigator mode for controlled read-only command
fallback:

./target/release/oi ask "Investigate 1.2.3.4 and explain any remaining evidence gaps." -s 7d -m inv
Enter fullscreen mode Exit fullscreen mode

Even then, oi_ro_run is policy-filtered and audited. It blocks commands that
delete, modify, kill, restart, install, download, upload, edit registry, change
firewall state, change accounts, or execute interactive shells.

Use this only when the team accepts the broader read-only command surface.

Takeaway

A suspicious IP is a starting point, not a verdict. The useful first step is to
collect linked host evidence, preserve the audit trail, and produce a report
another responder can challenge.

Open Investigator tries to make that first step faster while keeping the AI
inside a local, read-only investigation boundary.

Top comments (0)