AWatch-rus/aw-server/hayabusa

aw-rus Hayabusa Server Ops Bundle

This directory is the server-side operational bundle for Hayabusa on 192.0.2.13.

Goal

Allow operators to run the full bounded DFIR path without depending on the laptop repository.

Server paths

• wrapper: /usr/local/bin/aw-hayabusa
• case linker: /usr/local/bin/aw-hayabusa-link-case
• Windows-driven E2E helper: /usr/local/bin/aw-hayabusa-from-windows
• ops bundle root: /opt/activitywatch/aw-rus-ops
• local inventory for server-side controller mode: /opt/activitywatch/aw-rus-ops/ansible/inventory.ini
• local controller venv: /opt/activitywatch/aw-rus-ops/venv
• local drop zone for fetched EVTX zips: /opt/activitywatch/aw-rus-ops/drop

Minimal operator workflow on the server

1. Check runner health:

aw-hayabusa doctor
aw-hayabusa inventory

2. If a zip is already on the server:

aw-hayabusa accept --package /path/to/HOST-YYYYMMDD-HHMMSS.zip --host HOST
aw-hayabusa process-inbox --mode incident

3. Link the latest successful run to a case:

aw-hayabusa-link-case --case-id 30 --mode incident

Full no-laptop workflow from the server

Prerequisites:

• /opt/activitywatch/aw-rus-ops/venv contains ansible and pywinrm
• /opt/activitywatch/aw-rus-ops/ansible/inventory.ini contains the live Windows connection details
• WinRM from 192.0.2.13 to the Windows host is reachable

Run:

aw-hayabusa-from-windows --days-back 1 --mode incident --case-id 30

This performs:

• Windows EVTX export via WinRM
• fetch of the newest zip directly onto 192.0.2.13
• aw-hayabusa accept
• aw-hayabusa process-inbox
• bounded case linkage via case API

If WinRM from the server to Windows is blocked by network policy, use the drop-zone workflow below instead.

Drop-zone automation on 192.0.2.13

The server can auto-process packages dropped into:

• /opt/activitywatch/aw-rus-ops/drop

Installed units:

• /etc/systemd/system/aw-hayabusa-drop.service
• /etc/systemd/system/aw-hayabusa-drop.path

Behavior:

• any *.zip placed in drop/ is automatically accepted and processed
• optional *.caseid sidecar with the same basename triggers automatic bounded case linkage
• processed *.zip is moved out of drop/ into report_dir/input-drop/ to avoid repeated re-trigger loops
• sidecars are archived into report_dir/input-sidecars/
• bad drop packages are rejected before accept, moved to /opt/hayabusa/quarantine/drop/<timestamp>_<package>/, and recorded with a reason.json file instead of blocking later packages
• bad or partially extracted incoming packages are moved to /opt/hayabusa/quarantine/incoming/<timestamp>_<package>/; process-inbox continues with the remaining queue and does not trip systemd start-limit only because of one poison archive

Windows direct upload into the drop zone

Preferred production path when server-side WinRM is unavailable:

1. On Windows, use:

powershell.exe -ExecutionPolicy Bypass -File C:\ProgramData\AWatch-rus\export-upload-hayabusa-to-aw-server.ps1 -DaysBack 1 -CaseId 30

2. The script will:

• run C:\ProgramData\AWatch-rus\export-evtx-for-hayabusa.ps1
• upload matching .caseid first when -CaseId is specified
• upload the newest zip to /opt/activitywatch/aw-rus-ops/drop
• let aw-hayabusa-drop.path process the package automatically on 192.0.2.13

This path was validated live against case 30 after the awops SSH authorization was installed on 192.0.2.13.

Server-side prerequisite for user awops:

printf '%s\n' 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILoFWQmgoUJj1P7mp1/fB5aBkI3fVgjPme9jmK8Gh9jr igor@snb-live' | sudo tee /var/lib/awops/.ssh/authorized_keys >/dev/null
sudo chown awops:awops /var/lib/awops/.ssh/authorized_keys
sudo chmod 600 /var/lib/awops/.ssh/authorized_keys
sudo chown awops:awops /opt/activitywatch/aw-rus-ops/drop
sudo chmod 0750 /opt/activitywatch/aw-rus-ops/drop

Production scheduled task on SHARKON2025:

• task name: ActivityWatch Hayabusa Upload
• action: C:\ProgramData\AWatch-rus\export-upload-hayabusa-to-aw-server.ps1 -HoursBack 6 -Mode incident
• principal: Администратор, LogonType=Interactive, RunLevel=Highest
• normal LastTaskResult: 0

Do not switch this task back to SYSTEM on the current RDP host: Task Scheduler starts powershell.exe under SYSTEM, but the process exits with 0xC0000142 before the upload script starts.

Server-side processing accepts Windows zip packages with backslash path separators and UTF-8 BOM in sidecar JSON. aw-hayabusa-autoprocess processes the full incoming queue after accepting a drop package, so stale incoming files from an earlier failed run are drained before the latest intake is recorded.

Poison-package handling is fail-closed:

• Rust aw-hayabusa-autoprocess-rust validates the zip and sidecars before calling aw-hayabusa accept.
• A corrupt/empty/unsafe drop package is quarantined with its .meta.json, .caseid, optional checksum sidecar and reason.json.
• aw-hayabusa process-inbox isolates a failed incoming package instead of aborting the whole batch.
• Operators replay only a fixed/re-exported package by moving it back to the drop zone or incoming queue. Do not edit quarantined evidence in place.

Security Finding Inbox integration

aw-hayabusa-autoprocess-rust can publish a normalized suspicious-workstation finding after a successful intake is written to /opt/hayabusa/state/latest-intake.json.

Default is disabled to keep forensic processing independent from ClickHouse:

AW_SECURITY_FINDING_INBOX_ENABLED=false

Enable after the ClickHouse schema and CLI are installed:

AW_SECURITY_FINDING_INBOX_ENABLED=true
AW_SECURITY_FINDING_INBOX_BIN=/usr/local/bin/security-finding-inbox
AW_SECURITY_FINDING_INBOX_MIN_SEVERITY=medium
AW_SECURITY_FINDING_INBOX_REQUIRED=false

With AW_SECURITY_FINDING_INBOX_REQUIRED=false, a temporary ClickHouse/inbox failure is logged as warning and does not poison the Hayabusa backlog. Use true only when the operator wants inbox publication failure to become an operational failure for the drop service.