I let a local 27B LLM audit and fix my Splunk + Sysmon stack

Saudações à comunidade do **webmastersmz.com**. Como especialista em tecnologia, analisei o tópico sobre a implementação de um LLM local de 27B para a auditoria e correção de uma stack de **Splunk + Sysmon**. Este é um excelente exemplo de como a Inteligência Artificial pode ser integrada no ciclo de vida de operações de segurança (SecOps).

### Análise Técnica: Otimização de Log Management com LLM Local

O autor do tópico demonstra uma abordagem avançada ao utilizar um modelo de 27 bilhões de parâmetros para automatizar a manutenção de um ambiente complexo. Abaixo, destaco os pontos cruciais desta iniciativa:

1.  **Privacidade e Soberania de Dados:** Ao optar por um LLM local (em vez de APIs externas como GPT-4), o utilizador elimina o risco de expor logs sensíveis da empresa ou organização. Em ambientes de monitorização de segurança, isto é crítico para cumprir normas de privacidade e evitar a fuga de metadados.
2.  **Ajuste da Stack Splunk + Sysmon:** O desafio comum nesta stack é o ruído (noise) excessivo gerado pelo Sysmon. Ter um LLM para analisar e ajustar os filtros XML do Sysmon, bem como otimizar as queries de busca (SPL - Search Processing Language) no Splunk, reduz drasticamente o consumo de licença (data ingestion) e melhora a performance das pesquisas.
3.  **Depuração Automatizada:** A capacidade do modelo em identificar falhas de configuração em tempo real — como sourcetypes mal configurados ou falta de parsers para logs específicos — acelera a resolução de incidentes.
4.  **Hardware e Inferência:** Utilizar um modelo de 27B exige recursos computacionais consideráveis (VRAM/GPU). O debate técnico aqui deve focar-se não apenas na eficiência do modelo, mas no custo-benefício de manter infraestrutura de GPU dedicada vs. os ganhos em automação de tarefas de engenharia.

**Questão para o fórum:** Qual é a vossa experiência na implementação de LLMs locais para tarefas de administração de sistemas? Acham que, para a nossa realidade em Moçambique, a adoção de modelos locais é mais viável do que soluções baseadas em cloud, considerando as nossas latências e custos de largura de banda? Deixem as vossas opiniões e vamos debater a viabilidade técnica destas soluções nos vossos servidores.

---

Para garantir que os vossos projetos e fóruns rodam sem falhas, convido-vos a conhecer as soluções de alojamento de alta performance da **AplicHost** em https://aplichost.com.

I let a local 27B LLM audit and fix my Splunk + Sysmon stack



Tópico: I let a local 27B LLM audit and fix my Splunk + Sysmon stack
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------


I let a local 27B LLM audit and fix my Splunk + Sysmon stack


The question was not "can an LLM do SOC work". The question I actually wanted answered was narrower and harder: can a 27B model running on my own GPU, with zero bytes leaving the machine, audit my Splunk install, find what is broken and fix it — without me telling it how?

After an afternoon of back and forth, the answer is yes, with caveats worth writing down. Including the mistakes, because those are the interesting part.

Context first, since it shapes how you should read this: I am a security analyst without prior SOC experience — I am studying for CySA+, and building a home SOC is the only way I have to practise on something that behaves like a real environment. Everything here ran on my own hardware, was reviewed by the model and verified against real evidence. No third-party data, no borrowed infrastructure.



The setup


Three moving parts:

•
Splunk (dev licence) as the SIEM — the thing all the logs land in.

•
Sysmon as endpoint telemetry, so process and access events actually exist.

•
Qwen3.8-27B quantised (IQ2_M, Gated DeltaNet hybrid, 128K context) on a single 16GB GPU, served with llama-server and driven by an agent.

The goal was not a mentor that explains things to me. It was an agent that audits the real install, finds what is wrong, and remediates it: edits configs, proposes commands, removes what is redundant.



Five audits before I trusted it with anything


I did not hand my Splunk over on day one. I ran five real audits against it: config inspection, data pipeline review, logging hardening, 24-hour log analysis, and IoC detection.

The verdict: it reasons like a senior analyst. It corrected wrong assumptions of mine three times, debugged a dozen issues on its own, and — this matters — said "I cannot confirm this" instead of inventing an answer.



The failure mode nobody warns you about


Thoroughness is gold in an audit and poison in a remediation.

When I handed it the first finding to fix, it went full forensic: tried performance-counter tools to verify counters, read the vendor spec, ran the failing binary by hand to reproduce it — and ran out of context. It hit 97.4% of its 128K window chasing the source name of a Windows Update log that had nothing to do with the fix.

The model knew the answer. It did not know when to stop. The fix was a system-prompt rule: stop as soon as you have the root cause with evidence.



The findings


Double ingestion. My indexer was already collecting logs locally, and a Universal Forwarder on the same box was sending them again. Double licence usage, double noise. The valuable part was not the diagnosis: it read the two product GUIDs out of the MSI registry entries and explicitly warned me which one to remove and which one never to touch, because that second one was Splunk itself with all my data in it. A careless msiexec /x there and the lab is gone. It marked that one as excluded.

Also worth knowing: the straightforward msiexec /x ... /qn returned a phantom -1, because msiexec is asynchronous and PowerShell does not capture its exit code reliably. Start-Process msiexec -Wait -PassThru returned a clean ExitCode: 0 and removed service, directory and registry entry.

Three data inputs dead since install day. Zero events since July, three different root causes:

• Two Windows event channels were disabled, so there was no log file to read at all. Fixed by enabling the channel.

• The third was a double bug: a required parameter was missing, and the performance counters were configured in English on a Spanish Windows install. In Spanish, the counter is not % Processor Time but % de tiempo de procesador. Even the object name is localised. The fix was to force the tool to use the English API.

And a detail I appreciate more than the fix itself: the config change was correct, but the binary still died when sampling. It documented that as "needs binary debugging" instead of claiming success.

Sysmon was blind to credential theft. My config did not detect access to LSASS — the process that holds credentials in memory, and the thing Mimikatz goes after. An attacker could have dumped credentials and I would have learned about it later. Enabling ProcessAccess with a filter on lsass.exe is a three-line change, but along the way we discovered that both the model and I were carrying a wrong Sysmon event-ID mapping. The numbers I had been using were simply incorrect. The real config file disproved them. Verify technical numbers against reality; do not trust recall, including your own.

One command, three traps. To log process creation with the command line:

auditpol /set /subcategory:"{0CCE922B-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

It failed for three reasons at once: the privilege was missing, the category name is localised (so the English string does not resolve), and the braces of the GUID break PowerShell syntax unless quoted. Elevation, localisation, syntax.



The best part: it caught its own false positives


Two earlier findings turned out to be false positives, and the model is what caught them, correcting previous audits (one of them a note of mine):

• A log channel reported as disabled was actually enabled and recording hundreds of events. The original audit had looked at the wrong channel.

• A detection rule flagged any process touching temporary files under the user profile as suspicious — which meant my code editor, my note-taking app and my own AI agent showed up as threats. It needed specific Electron exclusions.

An analyst that corrects its own assumptions with evidence beats one that gets lucky.



Making it deterministic


After watching it blow through the context window, I fixed the cause rather than the symptom: temperature down from 0.8 to 0.3, plus a working-rules system prompt (answer only what is asked; in remediation stop at root cause with evidence; in audit be exhaustive; use scripts for mechanical operations; verify IDs, ports and GUIDs before asserting; never invent; be concise).

Before
After

Output
Huge, rambling
Short and direct

Context used
97.4% (overflowed)
49.7%

Assumptions
Taken for granted
Verified against reality

Result
1 finding in 30 min
4 findings in a row



Honest scoreboard


Out of ten findings: double ingestion resolved, two inputs fixed and one pending binary debugging, credential access now detected, process logging enabled, two false positives corrected, one of my own notes fixed. Not a perfect lab result — which is exactly why I trust the report.

What I take away:

• A 27B local model is already competent at this work. The bottleneck is context, not intelligence.

• Ask for exhaustiveness in auditing and forbid it in remediation.

• Verify technical numbers against reality instead of remembering them.

• Mechanical operations belong in a script: asked to insert two lines into a 123KB config, it spent 30 minutes regenerating the whole file by hand.

• Determinism is a configuration choice, not a model property.

An LLM does not replace your judgement or the urge to understand what is happening. But as a mentor that never sleeps and never leaves your machine, for someone starting out like me, it is a genuine advantage — and not a single log leaves my computer.

The full technical breakdown of this audit — screenshots, exact commands and config files — is on my blog: A 27B SOC Analyst: Auditing and Remediating Splunk + Sysmon.

Related, if you are building the same kind of thing: Building Your Own Log Analyzer and Gravity SOC, my home security operations center.

I write up what I learn, mistakes included, at sammideblas.com.