Host Inspection and Incident Forensics

The core question in host inspection is: when facing a Linux host that may be compromised, how can an Agent systematically complete the full investigation from baseline collection to timeline reconstruction without damaging the environment?

Unlike alert triage, every command in a host scenario acts directly on a real machine, so the risk is higher than query-only actions. Flocks delegates to a dedicated host inspection Agent under the main Agent Rex, and uses command allowlists, blocklists, and per-command human confirmation to isolate sensitive operations from AI automation boundaries.

Scenario Overview

This scenario covers two real needs:

• Routine inspection: run a health check on one machine or a batch of machines, covering CPU, memory, processes, abnormal logins, startup items, scheduled tasks, network connections, and similar items
• Incident forensics: a machine is suspected to be compromised and requires an intrusion timeline to be reconstructed without disturbing the scene

Both uses share the same host inspection Agent. The latter enters a "deep investigation" mode, calls more commands, and outputs a more structured report.

Inputs and Outputs

Typical Inputs

• Target host list, single or batch
• Established SSH / jump host channel, on which the host inspection Agent runs remote commands
• Optional: historical inspection reports, asset information, recent alert leads

Typical Outputs

• Baseline report: short report answering "is this machine healthy now?"
• Deep report after anomaly confirmation: includes a complete timeline, IOC, mining pool addresses if cryptocurrency mining is involved, brute-force sources, persistence methods, and similar evidence
• Command execution audit trail: every allow / deny decision for each command is auditable

Prerequisites

Dependency	Requirement
Model	The default model is sufficient; reasoning models perform better for timeline reconstruction
Host inspection Agent	Flocks includes a built-in Host Inspection sub-agent; Rex automatically delegates tasks to it as needed.
Connectivity	The node running Flocks can reach target hosts through SSH / jump host
Command safety policy	Allowlist / blocklist plus human confirmation is preset in the Agent and usually requires no extra configuration
Channels	Optional. Used to push inspection conclusions to WeCom / DingTalk / Feishu

Core Safety Mechanism: Allowlist / Blocklist / Per-command Human Confirmation

This is the key mechanism that differentiates host inspection from alert triage:

Type	Behavior
Allowlist	Pure read-only commands (ps, netstat, cat on read-only paths, last, who, and similar commands) are executed automatically without human intervention
Blocklist	Any write / modify / delete action (rm, sed -i, kill, iptables -A, and similar commands) is rejected directly
Uncategorized / Gray Area	Popup confirmation: allow once, always allow, or treat as blocklisted. If the user does nothing, the default is blocklist

This mechanism reduces the risk of letting an Agent directly operate on hosts:

• Analysts do not need to worry about destructive commands caused by incorrect Agent judgment
• All high-risk actions require human confirmation
• The audit trail is reviewable: the decision chain for every command remains in the session

Allowlist and blocklist rules can be extended in the Agent system prompt / Skill. Enterprises typically inject internal compliance boundaries as Skills.

Steps (WebUI)

Step 1: Enter a Session and Point to the Target Host

In Session Management -> + New Session, describe the goal in natural language:

"Inspect host 10.10.x.x for me. Start with the baseline, and if anything is abnormal, perform deep analysis."

Step 2: Rex Delegates to the Host Inspection Agent

Rex switches to delegation mode:

• The main Agent hands the host inspection task to an expert Agent
• After taking over, the host inspection Agent uses its own system prompt and tool stack
• They share the full session context, but the analysis process is independent

Step 3: First-round Baseline Collection

The expert Agent first runs a built-in baseline collection script / command set:

• System information, CPU / memory usage
• Process list, network connections
• Login record overview
• Startup items / scheduled tasks / cron

This round usually contains only allowlisted commands and requires no human interaction.

Step 4: Anomaly Found -> Enter Deep Investigation

If the baseline stage finds any anomaly, such as an unknown high-CPU process, abnormal outbound connection, or suspicious login, the Agent:

• Pauses and explains what it found
• Lists the sensitive commands it wants to execute next
• Requests human confirmation one by one through popups, allowing once, always allowing, or rejecting

This is the critical control point. Users can reject any command they do not want to run, and the whole process keeps operation records.

Step 5: Produce a Structured Report

After deep investigation completes, the Agent generates a Markdown / JSON report in the Workspace directory. It usually includes:

• Host profile, including system, boot time, and recent logins
• Anomalies found, including processes, files, and network activity
• Complete timeline, the key output: every step from system initialization to compromise and persistence
• IOC / mining pool addresses / brute-force sources / newly added SSH keys
• Recommended actions

Step 6: Optional: Convert to a Scheduled Task or Chain into Alert Triage

Inspection reports can be linked with alert triage:

• One-off inspection: keep it in the session
• Periodic inspection: convert to a Task Center job and run daily
• Inspection started during alert investigation: write results back to the alert session as part of the evidence chain

Real Case Walkthrough: Mining Host Timeline Reconstruction

Key points from a mining host timeline reconstruction demo:

Time	Agent action	Output / notes
0:10	Confirm this is a host inspection / incident Agent	Quickly check status across hosts, then dig deeper when anomalies appear
0:33	Rex delegates the host inspection Agent onto the machine	Expert Agent takes over
0:42	Run the baseline script first and collect simple metrics such as CPU / memory	Allowlist, no popup
1:06	A sensitive command appears during execution -> popup asks "may I allow this once?"	Critical safety mechanism is triggered
1:20	Explain the mechanism: read-only allowlist, any write action blocklisted, uncategorized / gray area prompts, no response means blocklist	Makes boundaries clear to the user
1:52	Agent finds cryptocurrency mining traces on the machine	Enters deep investigation
2:21	Agent writes a report and saves it to Workspace	Structured Markdown
2:47	Report confirms the machine was attacked for mining, includes mining pool address and a clear timeline	Ready to deliver to the response team
2:58	Timeline reconstruction: March 25 system boot -> March 27 abnormal login -> mining started at 08:00 on March 27	Most valuable output
3:14	Complete intrusion chain: login time / software download / scheduled task creation / file characteristics / network characteristics	Incident forensics-grade conclusion
3:33	Also identifies other brute-force sources and successful login sources	User confirms some keys are normal operations behavior, so the Agent avoids false judgment

Output Example (Summary)

Host: 10.10.x.x
Conclusion: confirmed cryptocurrency mining compromise
Timeline:
  2026-03-25 System boot
  2026-03-27 05:18  Abnormal login (brute-force source 185.x.x.x)
  2026-03-27 08:04  Mining program downloaded to /tmp/xmrig
  2026-03-27 08:05  Scheduled task created at /etc/cron.d/update
  2026-03-27 08:07  Mining pool connection established to pool.xxx.com:3333
IOC:
  - Mining pool: pool.xxx.com:3333
  - File: /tmp/xmrig (sha256: ...)
  - Scheduled task: /etc/cron.d/update
  - Brute-force source IP: 185.x.x.x, 45.x.x.x, ...
Recommendations:
  - Isolate the machine
  - Remove the scheduled task and malicious binary
  - Reset SSH keys / account passwords
  - Add brute-force source IPs to perimeter blocks

Continuous Operation

Mode	Usage
One-off incident response	Keep it in the session
Periodic health check	Convert to Task Center: run a daily baseline and automatically push to WeCom when anomalies appear
Batch host inspection	Workflow: input a host list and loop through host inspection Agent delegation
Integrate with alert investigation	Host-level suspicion found during alert triage -> start a temporary inspection branch

Boundaries and FAQ

Question	Handling
Want the Agent to automatically clean mining programs	Not recommended. Flocks focuses on triage / forensics; response actions should still be executed after human confirmation
Too many gray-area command confirmations	Extend the allowlist in an enterprise Skill and explicitly approve commands the organization considers safe
Many hosts and insufficient SSH capacity	Use Workflow for batch scheduling; do not submit 100 hosts at once
Windows hosts	The current host inspection Agent targets Linux; Windows scenarios can use a separate expert Agent
Report is not deep enough	In the Agent system prompt, explicitly require the three sections "timeline, IOC, persistence methods"

---

Related Resources: Scenario Overview · Alert Triage · Internal Security Product Integration · Task Center · Agent