Triage cron and systemd persistence without giving AI a shell.

Start with the persistence clue

The first useful question is where the suspicious entry lives and what created or executed it nearby. A cron line, systemd unit, shell profile, rc script, or user-level timer is a starting clue, not a complete finding.

Collect bounded Linux evidence

A Linux persistence first pass should review crontabs, systemd units and timers, startup files, local accounts, process context, listening ports, outbound connections, recent files, package changes, authentication logs, and command history when available.

Look for cause and execution path

Persistence matters when it connects to execution. Stronger findings come from relationships such as a new unit pointing to a recent script, a cron job owned by a surprising account, a process launched after login, or outbound traffic tied to the persistent command.

Use AI for next evidence requests

The model can decide which sealed collector to ask next after it sees the current evidence. That helps responders move from one persistence clue to a reviewable narrative without exposing arbitrary shell.

Preserve gaps before cleanup

If a directory is unreadable, logs are rotated, the unit file has already changed, or history is missing, the report should say so. Those gaps tell the incident owner what still needs confirmation before remediation.

Keep remediation human-approved

Open Investigator does not delete cron entries, disable services, kill processes, remove files, rotate credentials, or change firewall rules. It gives the responder evidence and gaps for the playbook owner to review.

Try it

git clone https://github.com/SEc-123/open-investigator.git
cd open-investigator
cargo build --release
./target/release/oi scan -s 7d

Open Investigator writes case artifacts such as evidence.jsonl, commands.log, report.json, and report.md so another responder can review the investigation path.