Open Investigator · Suspicious IP walkthrough
Investigate a suspicious IP on a Linux server with read-only evidence.
When an alert starts with only an IP address, the useful first question is not whether the host is compromised. It is where the IP appeared, what changed nearby, and which evidence is still missing.
Why it matters
Use this walkthrough when a Linux server alert starts with one suspicious address and the team needs an evidence-backed first pass.
Start with the IP
Build Open Investigator from source, then run `oi ip 1.2.3.4 -s 7d` to ask whether the address appears in authentication logs, web access logs, active connections, process context, services, recent file changes, or persistence clues.
Keep the first pass read-only
At the start of triage, an IP can be an attacker, scanner, customer, admin VPN, proxy, monitoring system, or false positive. Open Investigator avoids blocking IPs, killing processes, deleting files, disabling accounts, restarting services, or changing firewall state.
Follow the evidence chain
If the IP appears in web logs, branch into suspicious paths, recent web-root files, process context, and outbound connections. If failed logins are followed by a success, branch into account context, shell history, and persistence.
Use AI where it helps
The model can choose the next bounded evidence request while staying inside the sealed tool catalog. That makes it useful for moving from weak clues to a report another responder can challenge.
Try it
git clone https://github.com/SEc-123/open-investigator.git
cd open-investigator
cargo build --release
./target/release/oi scan -s 7dOpen Investigator writes case artifacts such as evidence.jsonl, commands.log, report.json, and report.md so another responder can review the investigation path.