Build1 publisher2 min readPublished
One system-prompt rule kept this local 27B from burning its whole context on a Splunk repair
A quantised 27B on one 16GB GPU audited a home Splunk and Sysmon install with nothing leaving the host. Its first repair attempt ran the 128K context window dry. A halt rule in the system prompt got it under control.
The Engineer · Build desk
What happened
- A security analyst pointed Qwen3.8-27B, quantised to IQ2_M with a 128K context and served by llama-server on a single 16GB GPU, at his own Splunk install running on a dev licence with Sysmon telemetry.
- He ran five audits against the live install: config inspection, data pipeline review, logging hardening, 24-hour log analysis, and IoC detection.
- The model diagnosed double ingestion, read both product GUIDs out of the MSI registry entries, and marked the Splunk one as excluded from removal because it held all the lab's data.
- Three data inputs had been dead since install day with no events since July, from three separate root causes including counter names localised into Spanish.
- Handed its first finding to fix, the model reached 97.4 percent of its 128K window chasing the source name of a Windows Update log unrelated to the repair.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- capability Config-level audit work on a SIEM and its endpoint telemetry fits on one consumer card, so the install details never have to be handed to a vendor, a consultant or a hosted API.
- decision Anyone copying this pattern has to decide whether a model's GUID-to-product match is sufficient authority for a destructive uninstall, since picking the wrong one deletes the indexer holding the evidence.
- constraint The context budget caps how large a single repair task can be, so findings have to be cut small enough to close inside one window.
- exposure Until ProcessAccess was enabled with a filter on lsass.exe, credential dumping would have left no record on the host the home SOC was built to watch.
An agent repairing a live install needs a failure signal it can trust. On Windows the obvious one lies. Running `msiexec /x ... /qn` returned a phantom `-1`, because msiexec is asynchronous and PowerShell does not capture its exit code reliably [12]. Relaunched as `Start-Process msiexec -Wait -PassThru`, the same uninstall returned `ExitCode: 0` and removed the service, the directory and the registry entry [13]. A loop that branches on the exit code reads the first attempt as a failure and runs it again.
The window that ran dry holds 131,072 tokens, so the detour cost roughly 127,700 of them [20]. "Thoroughness is gold in an audit and poison in a remediation," the author wrote [9]. The correction was a rule in the system prompt: stop as soon as you have the root cause with evidence [8].
Not every fix landed. After the performance-counter configuration was corrected, the binary still died when sampling, and the model logged that as "needs binary debugging" instead of claiming success [17]. Across the five audits it corrected the author's assumptions three times, debugged a dozen issues on its own, and said "I cannot confirm this" where it could not settle a question [6].
Both the author and the model were carrying a wrong Sysmon event-ID mapping. Only the real config file disproved the numbers [19].
For a result like this to transfer, the agent needs read access to registry keys and config files on the host plus permission to run commands, because the findings came out of the live install: two product GUIDs read from MSI registry entries [11], counter names read off a Spanish Windows box [16]. Put the halt rule in place before the first repair task [8]. Exit-code handling has to survive an asynchronous launcher [12]. And someone has to be present to check a number against the file [19].
This is one analyst's account of one home lab on a Splunk dev licence, by someone studying for CySA+ with no prior SOC experience [2][3]. He reports that everything ran on his own hardware, with no third-party data and no borrowed infrastructure [4]. The post does not include timings or a comparison against a hosted model. A 27B quantised to IQ2_M inside 16GB audited a Windows telemetry pipeline of this shape, and mostly repaired it [1].
What to watch
- Whether a second operator reproduces the five audits on an English-locale install and turns up the same three dead inputs.
- Whether the harness gains an enforced deny list for product GUIDs and commands, so the model does not have to remember the exclusion.
- Whether the stop-at-root-cause rule holds for a finding whose root cause spans more than one host.