Rmagent Windows

Prerequisites for the new signals: 4688 command lines need auditpol /set /subcategory:"Process Creation" /success:enable plus the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabled = 1. 4104 needs script-block logging (Group Policy: Administrative Templates → Windows Components → Windows PowerShell → PowerShell Script Block Logging; or the registry equivalent under HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging). Sysmon 22 needs the DnsQuery rule in the config.

Rev 4 — kernring: the no-Sysmon fallback (2026-08-20)

Why: sophisticated attackers target Sysmon specifically — Stop-Service Sysmon64; sc.exe delete Sysmon64 — and if Sysmon is your only process/network ring, that one command blinds you. The kernel analytic channels are built into Windows, have no obvious service to stop, and give you a degraded but functional ring when Sysmon is gone.

What was added:

• New seventh question kernring — reads Microsoft-Windows-Kernel-Process/Analytic (process start/stop with PID, image, parent PID, and command line where available) and Microsoft-Windows-Kernel-Network/Analytic (TCP/UDP connect with PID, dest IP, dest port). Also reports sysmon_status in every response.
• sysmon_status tripwire in attest — every census now reports whether Sysmon is Running, Stopped, or not-installed. A change from Running to anything else is a finding: either the sensor died or someone stripped it. This is the signal that tells you when to fall back to kernring.
• hunt.py fires a Telegram smoke alert when Sysmon is not running — "the primary ring is down; kernring is the fallback."
• Setup step D3 — wevtutil sl Microsoft-Windows-Kernel-Process/Analytic /e:true and the Network equivalent, wired into the setup docs alongside D1 (auditpol) and D2 (Sysmon ring).

The honest fidelity gap (documented, not hidden):

Design decision: kernring is a separate question, not a silent fallback inside netedges. If netedges silently degraded, the operator would think they're getting Sysmon-quality data when they're not — a lie by omission that violates the "a hole is an answer" principle. The operator asks the question that matches the fidelity they need.

Status: LIVE-VALIDATED 2026-08-25. Ran against both WS1 and WS2 (estate reachable): kernring returns process events from the kernel analytic channels with the expected fields, and reports sysmon_status on every call (Sysmon64=Running on ws1, Sysmon=Running on ws2). Reality check discovered in live testing: on this estate the kernel channels are NOT enabled as a persistent ring — the payload works as a 10-second burst capture (burst_seconds: 10, note: "burst capture - 10s window, not a ring. Sysmon is the ring."), not the minutes-deep ring the design assumed. To get a persistent ring, setup step D3 (wevtutil sl Microsoft-Windows-Kernel-Process/Analytic /e:true) must be run on each box first; until then kernring is a spot-check, not a fallback ring.

Rev 5 — attackmap + ATT&CK tagging + expanded LOLBins (2026-08-21)

Source: BLUESPAWN's ATT&CK-mapped hunt registry (github.com/ION28/BLUESPAWN, MIT license). We took the knowledge — the registry locations, the technique mappings, the LOLBin list — and reimplemented it pull-only. We did not take the agent, the YARA scanning, the process-memory scanning, or the mitigation system. Those violate the architecture.

What was added:

• New eighth question attackmap — an ATT&CK-mapped persistence STATE check. Reads 13 registry locations BLUESPAWN enumerated: Run keys (T1547.001), IFEO debuggers (T1546.010), AppCert DLLs (T1546.009), AppInit DLLs (T1546.010), Security Support Providers (T1547.005), Notification packages (T1547.002), Winlogon hijack (T1547.004), Netsh helpers (T1546.007), port monitors (T1547.010), logon scripts (T1037.001), recent accounts (T1136.001), disabled firewall profiles (T1562.004). Every finding carries its technique ID.
• Why state, not events: explain catches when persistence is CREATED (4698, 7045, 4720). attackmap catches persistence that ALREADY EXISTS — including anything that predates our monitoring window or was staged before rmagent was installed. This is the "what was already on the box when we started" check.
• ATT&CK tags on existing findings. sketch now returns admin_failed_attack='T1110', new_local_admins_attack='T1136.001', new_services_attack='T1543.003', new_tasks_attack='T1053.005'. The operator sees not just "a task was created" but "T1053.005: Scheduled Task persistence."
• LOLBin list expanded 18 → 80 (from BLUESPAWN's curated list). Adds msxsl, installutil, msbuild, forfiles, diskshadow, dnscmd, cmstp, msdt, odbcconf, pcalua, rasautou, regasm, regsvcs, runscripthelper, scriptrunner, syncappvpublishing, tttracer, verclsid, wab, xwizard, appvlp, bginfo, cdb, csi, devtoolslauncher, dnx, dotnet, dxcap, mftrace, msdeploy, rcsi, sqlps, sqltoolsps, squirrel, te, tracker, update, vsjitdebugger, wsl, and more.
• hunt.py integration: attackmap prints N/13 ATT&CK techniques with findings, lists each technique found, records checked/found as hop fields, and fires a Telegram smoke alert for high-severity techniques (IFEO hijack, SSP, Winlogon hijack, AppCert, firewall disabled).

What we deliberately did NOT take from BLUESPAWN:

Status: LIVE-VALIDATED 2026-08-25. Ran against both WS1 and WS2: attackmap returns findings with ATT&CK tags on both boxes (ws1: T1547.001 run_keys ×1, T1546.007 netsh ×17; ws2: T1547.001 ×2, T1546.007 ×17). The full 8-signal redteam drill confirmed attackmap catches the staged drill artifacts: run_key drill: True, ifeo drill: True on both boxes (the two new Rev 5 signals). Drill artifacts cleaned up cleanly afterwards (0 remaining).

Rev 6 — RTerm observability integration notes (2026-08-25)

No skill changes required. Documented so operators know what's already available.

RTerm (v3.2.14+) now ships OpenLLMetry-style LLM tracing: every model call the agent makes while running an rmagent hunt (the explain/sketch analysis passes, the completion audits) is recorded as an APM span in RTerm's trace store, grouped per agent run. That means:

• Hunt latency is already observable. rterm call observability:apmSummary shows llm.chat / llm.thinking / llm.audit.* spans with p50/p95 latency — how long the LLM analysis of each hunt took, per run, with zero config.
• No new question needed. The skill's job is asking the boxes questions; RTerm's tracing covers the agent's own work automatically. Adding a trace question would duplicate what the platform already does.
• The skill stays dependency-free. It deliberately has no RTerm/OTel imports — it runs standalone with just pywinrm. Tracing happens around it, not inside it.
• If you want hunt results in an external APM (Jaeger/Tempo/Datadog), set OTEL_EXPORTER_OTLP_ENDPOINT on the RTerm backend — LLM spans forward with standard gen_ai.* attributes. Host metrics push on the same endpoint. This is RTerm configuration, not a skill change.

What is NOT traced: the WinRM knocks themselves (they're pywinrm calls made by the skill's scripts, outside RTerm's agent loop). Their timing lives in the case hops (asked/answered timestamps) — by design, the case file is the record.

Rev 7 — external half: netexec-bridge closes the purple-team loop (2026-08-25)

RTerm v3.2.15 ships netexec-bridge, the outside view that rmagent lacked. The drill previously staged artifacts on the boxes; now you can also simulate the external attack (credential spray from outside) and verify attest catches the resulting 4625s.

How the two halves fit:

Recommended drill extension: use netexec_spray_plan (rate-limited, jittered, SLOW — does not execute) to review the schedule first, then netexec_check against the SAME authorized estate. Immediately after, run attest on each box and confirm admin_fail_60s rose. That is the full outside→inside detection loop, scored end to end.

Same rule as always: authorized estate only. netexec denies by default — empty or missing allowlists are refused, and every comma-separated target is validated individually (no batch bypass).

Rev 12 — correlation, drift, FP allowlist, score history, Linux sibling (2026-08-29)

Eight improvements, live-validated against WS1/WS2:

1. Cross-witness correlation (scripts/correlate.py) — the biggest gap. Every question ran per-box, but the drill's thesis is lateral movement. correlate.py joins edges/netedges answers across witnesses and surfaces:

   • cross-host-account — same account logged on to both boxes in the window
   • lateral-hop (critical) — WS1 connecting to WS2's address or vice versa
   • explicit-cred-to-peer — 4648 on one box naming the other
   • shared-logonid (critical) — same LogonId on two boxes (stolen session/PTH) hunt.py now runs correlation automatically at the end of a walk and writes correlation.json into the case. record_ask persists full answers to case/answers/*.json so correlation is pure post-processing (no re-pull).

2. Baseline + drift (scripts/drift.py) — attest is point-in-time; the sharper question is who became admin since last week. First run records a baseline (~/.rmagent/baselines/<id>.json, mode 600); later runs diff: new/removed admins, Sysmon status change, attackmap techniques that grew or shrank. --reset re-baselines.

3. Time-windowing — --since now accepts 30m / 2h / 24h / 7d on hunt/correlate/drift (was h-only). Drill comparisons and drift checks are meaningful instead of "recent".

4. attackmap FP allowlist — live validation showed T1546.007 netsh ×17 on both boxes: OS-default netsh helper DLLs, not persistence. The payload now suppresses known-good values for T1546.007 (netsh helpers), T1547.005 (default SSPs), T1547.002 (default auth notification packages). A real netsh helper with a non-default name still fires.

5. Score history + regression alert (redteam.py) — every drill appends to ~/.rmagent/drill_history.jsonl. If the score drops vs the previous run, it prints AND Telegram-alerts the lost signals — catching the failure mode where a Windows update or GPO silently disables 4688.

6. Auto-scheduled attest — RTerm scheduled task (cron */30 * * * *): python3 ~/.agents/skills/rmagent-windows/scripts/drift.py --inventory <estate> → findings into the trigger pipeline → Telegram. Turns the witness from "ask me" into "watch and page". Create via manage_scheduled_task.

7. ETW AutoLogger for kernring — documented as an estate change (MOP, not Phase 0): wevtutil sl Microsoft-Windows-Kernel-Process/Analytic /e:true as a standing session catches between-poll events. Not enabled by default.

8. Linux sibling (~/.agents/skills/rmagent-linux/) — same engine, SSH door, five questions (attest/sketch/edges/explain/attackmap) reading journald/auth.log/ss/systemd/cron. Makes the observatory multi-plane. macOS paths documented as experimental.

Status: LIVE-VALIDATED 2026-08-29 — correlate + drift + attackmap allowlist run against WS1/WS2 (see Rev 8 validation notes in the case dir).

Rev 13 — the audit-blindness lesson: verify the witness can see (2026-08-29)

Two live findings from re-validating Rev 8, both silent false negatives:

1. correlate.py joined on the wrong field names. The unit tests used a synthetic logon_id shape, but the LIVE edges.ps1 payload emits lid / user / src / who / became / dest. Every join key was wrong, so shared-logonid and lateral-hop could never fire — and the suite still printed "ALL UNIT TESTS PASSED". Fixed to read the live shapes (verbose TargetUserName/LogonId kept as fallbacks). The tests now use the live payload shapes. Lesson (again): a unit test with a synthetic shape proves nothing about the wire. Always join against a real answer file from cases/*/answers/.

2. WS2 was audit-blind on 12 subcategories — Logon was Failure-only, Logoff/Special Logon/Other Logon/Logoff/Group Membership/ Account Lockout were No Auditing, while WS1 had Success+Failure on all. Result: edges on WS2 returned zero logons while an Administrator WinRM session was actively connected — and correlate reported a "clean" estate. That is the worst failure mode: not an error, an empty answer that looks like good news. Fixed: aligned WS2 to WS1 for the 6 subcategories the questions depend on (auditpol /set /subcategory:"Logon" /success:enable /failure:enable …), verified all six show Success and Failure. Baseline saved before the change (/tmp/audit-baseline.json pattern — record before you touch). Proof: immediately after, correlate fired cross-host-account: 'Administrator' logged on to 2 witnesses (ws1, ws2) — a finding that was structurally impossible 10 minutes earlier.

New standing rule: before trusting any "no findings" result, check the witness can actually see. A quick blind-check (read-only, one ask per box):

# raw 4624 count in 24h with NO track filter — if this is 0 while you are
# connected, the box is not auditing success logons.
(Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624;
  StartTime=(Get-Date).AddHours(-24)} | Measure-Object).Count
auditpol /get /subcategory:"Logon"   # must say "Success and Failure"

attest now does this automatically (Rev 13.1). Every attest payload carries:

• raw_4624_24h — unfiltered 4624 count (the number that was 0 on WS2 while an Administrator session was connected)
• blind_check — per-subcategory ok / BLIND / unknown for the six subcategories the questions depend on (Logon, Logoff, Special Logon, Other Logon/Logoff, Group Membership, Account Lockout)
• blind_count — how many are blind; 0 is the only healthy value

drift.py treats a growing blind_count as a critical finding (witness_blind) and raw_4624_24h dropping to 0 as a warning (logon_visibility_lost). A witness going blind is the worst regression because every other question silently returns empty.

Two implementation notes, both learned the hard way:

1. WinRM command budget. attest.ps1 grew past the ~8191-char encoded budget (preamble+payload × ~2.7 for UTF-16LE base64) and every ask returned "The command line is too long." — on both boxes, instantly. The blind_check block is deliberately terse. If you extend attest, re-check: len(preamble) + len(_strip_payload(payload)) × 2.67 < 8191.
2. auditpol /r CSV columns are MachineName, PolicyTarget, Subcategory, Subcategory GUID, Inclusion Setting — the policy is field [4], not [3]. Reading [3] reports every box as blind with GUID strings (a false positive that looks authoritative).

Status: LIVE-VALIDATED 2026-08-29 — both WS1 and WS2 return blind_count: 0, all six ok; WS2 raw_4624_24h = 19 (was 0 before the audit-policy fix).