Building a Sentinel Detection Lab, Part 6: Shadow AI and the Detection That's Honest About What It Hasn't Proven Yet

Repo: github.com/Kajal-Dhanjal/sentinel-detection-lab

Five detections in, every one of them pointed at a fairly traditional attacker: brute force, malicious PowerShell, registry persistence, recon, and MFA abuse. Part 6 starts a different track—not an attacker at all, but a governance problem that's quietly become a SOC problem: AI tooling showing up on endpoints with nobody in IT knowing it's there.

This is the first detection in the lab that doesn't really map cleanly onto MITRE ATT&CK, and I'm not going to pretend it does.

---

The problem underneath the problem

Most "AI security" content jumps straight to prompt injection or model abuse. I had a more basic question first: how would I even know if someone on my network had installed a local AI tool in the first place? Ollama, LM Studio, and a desktop AI coding assistant—none of these are malware. They're also invisible to a SOC that isn't specifically looking for them, and they create a real visibility gap: unmanaged software with no enterprise logging, no DLP coverage, and a direct channel for whatever gets pasted or fed into it.

That's a process-creation problem before it's anything else. Sysmon Event ID 1 already logs every process that launches—the question was just whether I could build a reliable list to match against

The detection

Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 1
| extend Image = extract(@"Image:\s+(\S+)", 1, RenderedDescription)
| extend ProcessName = tolower(tostring(split(Image, "\\")[-1]))
| where ProcessName has_any (
    "ollama.exe", "llamafile.exe", "lm-studio.exe", "lmstudio.exe",
    "chatgpt.exe", "claude.exe", "gemini.exe", "copilot.exe",
    "cursor.exe", "aider.exe", "openai.exe"
  )
| project TimeGenerated, Computer, Image, ProcessName

Same extraction pattern I've used since Part 1—pull Image out the unstructured RenderedDescription text, isolate the filename, normalize case with tolower() (Windows logs process names inconsistently, which is the same issue that caused the case-sensitivity bug in Part 4), then check it against a known list of AI tool binaries. No aggregation, no threshold—a single matching event is the full signal, the same design as the PowerShell detection in Part 2.

What I validated, and what I'm not claiming

I installed real Ollama on the lab VM — not a stand-in. winget install doesn't work on Windows Server 2022, so this meant a direct-download install, which was itself a small real-world gotcha I hadn't anticipated. Confirmed the process running with Get-Process ollama, then queried Sentinel: 5 matching rows, clean full path, nothing truncated.

What I haven't done is false-positive testing at scale. One tool, one validation pass. I want to be upfront about that rather than let the writeup imply a polish level it hasn't earned. A working detection and a tuned detection are different claims, and right now I'm only entitled to make the first one.
On the MITRE mapping

I've tagged this T1588.002 (Obtain Capabilities: Tool) because it's the closest fit ATT&CK offers, but it's worth saying plainly: that technique describes an attacker acquiring tooling pre-compromise, not an employee installing AI software on a managed endpoint. This rule functions more like a custom shadow-IT control than a classic threat detection. Forcing a cleaner ATT&CK story onto it than the behavior actually supports felt like the wrong move, so the repo says so directly.

What I took from this one

1. A governance signal is still a real detection, even without a clean MITRE mapping. Not every useful rule needs to be dressed up as catching an attacker.

2. "It worked once" and "it's tuned" are different sentences. Saying the second when I've only earned the first is the kind of overclaim I'd rather catch myself in than have a reviewer catch for me.

3. Small install gotchas are real findings too. The winget gap on Windows Server isn't a security lesson, but it's the kind of operational detail that separates a lab someone's actually built from one that's only ever been described.

Next up: the network side of the same problem—what happens when that AI tooling tries to talk to the internet and a telemetry blind spot I didn't know I had until I went looking for it. That's Part 7.

---

#cybersecurity #sentinel #microsoft-sentinel #kql #detection-engineering #blueteam #azure #ai-security