The threat

An attacker repeatedly attempts to log in with guessed credentials. Each failure writes a Windows Event ID 4625. A burst of these against one host in a short window is a strong brute-force signal.

The detection

// filter to failed logons → extract the attacked account from the
// event text → count failures per host in 5-minute windows
Event
| where EventLog == "Security"
| where EventID == 4625
| extend TargetAccount = extract(@"Account For Which Logon Failed:[\s\S]*?Account Name:\s+(\S+)", 1, RenderedDescription)
| where isnotempty(TargetAccount) and TargetAccount != "-"
| summarize FailedAttempts = count(), TargetedAccounts = make_set(TargetAccount) by Computer, bin(TimeGenerated, 5m)
| where FailedAttempts >= 5

Validation

Simulated a brute-force burst on the lab VM via repeated runas failures. The detection returned a single row: 25 failed attempts in one 5-minute window, attacker usernames captured. The scheduled rule raised an incident automatically (Credential Access category).

Detection firing — 25 failed attempts, attacker accounts captured

Incident raised automatically (Credential Access)

Tuning notes / lessons

• The target account lives inside RenderedDescription text, not a dedicated field — extracted via regex.
• A 4625 event contains two "Account Name:" lines. The naive regex grabbed the Subject (process owner) instead of the attacked account — fixed by anchoring on "Account For Which Logon Failed:" first.
• Manual testing produced sparse, slow attempts that didn't trip a tight window. The >= 5 threshold reflects real attack tempo, not test tempo.

The threat

Attackers frequently launch PowerShell with flags legitimate users rarely combine: encoded commands, hidden windows, execution-policy bypass, download cradles. Sysmon logs every process launch as Event ID 1 with the full command line.

The detection

Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 1
| extend Image = extract(@"Image:\s+(\S+)", 1, RenderedDescription)
| extend CommandLine = extract(@"CommandLine:\s+(.+?)\s+CurrentDirectory:", 1, RenderedDescription)
| where Image has "powershell" or Image has "pwsh"
| where CommandLine has_any ("-enc", "-EncodedCommand", "-nop", "-noprofile",
    "-w hidden", "-windowstyle hidden", "-exec bypass", "-executionpolicy bypass",
    "downloadstring", "iex", "invoke-expression", "frombase64string")
| project TimeGenerated, Computer, Image, CommandLine

Validation

Ran benign-but-suspicious-looking PowerShell (harmless — carries the flags attackers use, does nothing damaging). The detection returned all four launches with command lines correctly matched.

Flagged command lines

Incidents raised (Execution category)

Tuning notes / lessons

• Unlike Detection 1 (volume threshold), this fires on a single match — a known-bad flag is itself the signal, no aggregation needed.
• No malicious PowerShell existed in the logs to begin with — test data had to be generated before validation was possible.

Known false positives

• -nop and -ExecutionPolicy Bypass are occasionally used by legitimate admin scripts. Production tuning: require 2+ suspicious flags together, or exclude known-good signed scripts by hash/path.

The threat

To survive reboots, malware commonly writes itself into a registry autostart location — CurrentVersion\Run, RunOnce, or Winlogon shell keys. Sysmon logs registry modifications as Event ID 13.

The false positive — and the tuning

The naive version fired on real, legitimate activity: userinit.exe writing ctfmon.exe (Windows' own text/input service) to a Run key. The rule wasn't wrong — it correctly matched "a write to an autostart location" — it was too broad. A rule that fires on benign activity is worse than useless: it trains analysts to dismiss the alert, so a real attack tripping the same rule gets ignored too.

The detection (tuned)

Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 13
| extend TargetObject = extract(@"TargetObject:\s+(\S+)", 1, RenderedDescription)
| extend Details = extract(@"Details:\s+(.+?)\s+(?:User:|Image:)", 1, RenderedDescription)
| extend Image = extract(@"Image:\s+(\S+)", 1, RenderedDescription)
| where TargetObject has_any (@"CurrentVersion\Run", @"CurrentVersion\RunOnce",
    @"Winlogon\Shell", @"Winlogon\Userinit")
// narrow allowlist — excludes only the exact benign combination,
// not userinit.exe wholesale (a broad exclusion would let an
// attacker abuse userinit.exe slip straight through)
| where not(Image endswith "userinit.exe" and Details has "ctfmon.exe")
| project TimeGenerated, Computer, TargetObject, Details, Image

Validation (both sides)

True positive — planted a fake persistence entry via New-ItemProperty: caught. False positive — the legitimate ctfmon.exe write: correctly did not fire after tuning. The scheduled rule raised a High-severity incident with an attack-story graph.

Catching the planted entry, ignoring the ctfmon write

High-severity incident, T1547.001

The threat

When an attacker first lands on a host, they orient themselves — whoami, net user, systeminfo, ipconfig, tasklist, arp, and similar. No single command is malicious; every one runs during legitimate administration. The signal is variety — many different recon tools from one host in a short window — not any individual command.

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 in ("whoami.exe","net.exe","net1.exe","nltest.exe",
    "systeminfo.exe","ipconfig.exe","tasklist.exe","hostname.exe",
    "nslookup.exe","arp.exe","route.exe")
| summarize ReconCommands = make_set(ProcessName),
    DistinctReconCount = dcount(ProcessName) by Computer, bin(TimeGenerated, 10m)
| where DistinctReconCount >= 5

The key line is dcount(ProcessName) — distinct commands, not total. Ten runs of whoami alone isn't recon; whoami + net + nltest + systeminfo + ipconfig is. The detection measures variety, not volume.

Validation

Ran a 10-command recon burst. The detection returned a single row: distinct count of 9, full command set captured. Incident raised under Discovery category.

9 distinct recon commands clustered

Incident raised (Discovery)

Tuning notes / lessons

• Windows logs some process names uppercase (ARP.EXE), others lowercase. Without normalising case, dcount silently under-counted and the detection appeared broken when it wasn't — fixed with tolower(...).
• Unlike Detection 3 (fixed by narrowing), the false-positive risk here is a sysadmin legitimately running several commands during troubleshooting — so the tuning lever was the threshold (raised 4 → 5), not an exclusion. Different false-positive shape, different tool.

The threat

Once an attacker has a foothold on a credential, registering their own MFA method is one of the cleanest ways to keep access — the victim can reset their password and the attacker is still in. "User registered a new MFA method" looks completely normal in isolation; the signal isn't the registration itself, it's the registration happening shortly after a sign-in that doesn't look like the account owner.

Detection logic

Correlates two Entra ID signals within a 30-minute window: a sign-in from an untrusted IP, and a same-user AuditLogs entry for "User started security info registration."

let TrustedIPs = dynamic(["<office/home IP 1>", "<office/home IP 2>"]);
let UntrustedSignIns = SigninLogs
| where IPAddress !in (TrustedIPs)
| where ResultType == 0
| project SignInTime = TimeGenerated, UserPrincipalName, IPAddress, Location;
let MFARegistrations = AuditLogs
| where ActivityDisplayName == "User started security info registration"
| extend UserPrincipalName = tostring(InitiatedBy.user.userPrincipalName)
| project RegTime = TimeGenerated, UserPrincipalName;
UntrustedSignIns
| join kind=inner MFARegistrations on UserPrincipalName
| where RegTime between (SignInTime .. (SignInTime + 30m))
| summarize arg_min(SignInTime, *) by UserPrincipalName, IPAddress
| project SignInTime, RegTime, UserPrincipalName, IPAddress, Location

Simulating the attack

Baseline sign-in from my real AU IP → connected via Proton VPN (Seattle, US exit node), signed in again from the untrusted IP → registered a new MFA method from that same VPN session, the actual T1556.006 action.

Untrusted-IP sign-in correlated with registration

Deduped correlation result

Rule config — High severity, T1556.006, entity mapping

Closing the loop: automated response

Every other detection in this lab stops at "incident created." This one doesn't. A Sentinel automation rule fires on incident creation, runs an Azure Logic App, and posts a triage comment recommending the first containment step — revoking active sessions — referencing the IR playbook.

The original plan had the playbook write to a Sentinel watchlist (auto-blocking the flagged IP). The watchlist UI in Defender XDR was broken at build time, making watchlist writes from Logic Apps unreliable. I scoped the automation down to "add comment to incident" — a smaller, reliable action — rather than ship something flaky for a better demo.

Logic App: trigger → add-comment action

Automation rule wiring

Incident raised with the automated triage comment already attached

What I'd tune next

• Cross-run deduplication — current summarize dedup only protects within a single run's lookback window.
• Externalise the trusted-IP list to a proper watchlist once the UI issue resolves.
• Layer in real risk scoring if/when P2 is available — Variant B is a substitute, not a replacement.

Full IR playbook for this detection ↓

The threat

Employees running local or desktop AI tooling — LLM runners, AI coding assistants, desktop chatbot clients — outside any sanctioned IT process. Not inherently malicious; it's a visibility gap, since unsanctioned AI tools can move data through model context without enterprise DLP or logging.

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

Validation

True positive: installed real Ollama on the lab VM, confirmed the process running, queried Sentinel — 5 matching rows with a clean full path.

False-positive side: not yet tested. Only one validation pass has been run. Stated plainly rather than implying a clean bill of health.

Rule configured and enabled

Incident — captured ollama.exe execution

What broke the original design

Not a tuning exercise in the usual sense — two real telemetry limitations forced a redesign. CDN-edge hostnames break domain matching: even confirmed real connections showed DestinationHostname as a CDN edge name or blank, never the literal domain. Browser traffic is invisible to this telemetry entirely: a systematic check showed zero msedge.exe rows despite multiple tabs open, because the SwiftOnSecurity Sysmon baseline config excludes browser processes from network-connection logging by design.

This means the rule, as built, cannot detect browser-based AI usage — e.g. pasting data into a web chat UI — only non-browser, direct-process egress. Documented as an open, known gap, not silently worked around.

The detection (redesigned)

Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 3
| extend Image = extract(@"Image:\s+(\S+)", 1, RenderedDescription)
| extend ProcessName = tolower(tostring(split(Image, "\\")[-1]))
| extend DestinationPort = extract(@"DestinationPort:\s+(\S+)", 1, RenderedDescription)
| where ProcessName has_any ("ollama.exe", "llamafile.exe", "lmstudio.exe", "python.exe", "node.exe")
   and DestinationPort in ("443", "80")
| project TimeGenerated, Computer, Image, DestinationPort

Validation

True positive: Ollama on the VM was making real outbound calls to Google-hosted infrastructure on port 443 — observed organically, confirming the rule catches real egress from known AI tooling. 8 matching rows.

The browser-exclusion limitation is written directly into the rule description in Sentinel. No incident screenshot for this one by design — the writeup documents a telemetry-scope finding and rule configuration, not an incident walkthrough.

Rule configuration with the browser-exclusion limitation documented in the description

The threat

AI agent frameworks that autonomously execute commands by spawning a shell as a child process — LangChain-style agents, AI coding assistants, local LLM tools. Not inherently malicious — this is how agentic tools legitimately operate — but a meaningfully different risk profile from a human typing commands.

The detection

Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 1
| extend Image = extract(@"Image:\s+(\S+)", 1, RenderedDescription)
| extend ParentImage = extract(@"ParentImage:\s+(\S+)", 1, RenderedDescription)
| extend ProcessName = tolower(tostring(split(Image, "\\")[-1]))
| extend ParentProcessName = tolower(tostring(split(ParentImage, "\\")[-1]))
| where ParentProcessName has_any (
    "ollama.exe", "llamafile.exe", "lmstudio.exe",
    "claude.exe", "chatgpt.exe", "cursor.exe", "aider.exe",
    "python.exe", "node.exe"
  )
| where ProcessName has_any ("cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe","bash.exe")
| project TimeGenerated, Computer, ParentImage, Image

Known false-positive risk

python.exe and node.exe as parent processes is broad — almost any script that legitimately shells out for build tools, package managers, or CI would trigger this. Only one validation data point exists (a synthetic test), so this hasn't been exercised against real-world usage patterns yet. Stated as an open tuning item, not pretended away.

Validation

True positive: a 2-line Python script calling subprocess.run("cmd.exe /c echo agentic_test", shell=True) created a real python.exe → cmd.exe event, caught on the first attempt.

Rule config with FP-risk caveat in the description

python.exe → cmd.exe spawn caught