u/ridgelinecyber

Every detection program starts with LSASS dump detection. Most stop there.

The problem: an attacker who hits ASR LSASS protection, PPL, or Credential Guard pivots to techniques that never touch LSASS. Kerberoasting, DCSync, SAM hive extraction, and DPAPI abuse each target a different credential store, generate different telemetry, and need a different rule. If you only detect LSASS access, you detect only the attacker who didn't adapt.

I wrote up the 5 credential access techniques we see most often in real environments, with the actual KQL and Sigma rules for each:

1. LSASS memory access — filtering on GrantedAccess mask (0x1010 vs 0x1000) instead of process name. Process name exclusions break on renamed binaries. The access mask doesn't lie.

2. Kerberoasting — Event ID 4769 with encryption type 0x17 (RC4). Legitimate Kerberos uses AES. A burst of RC4 TGS requests from one source = Kerberoasting. Threshold: >3 unique services in 5 minutes.

3. DCSync — Event ID 4662 with the three replication GUIDs, from a non-DC. This is near-zero false positive if you maintain a DC allowlist. Any non-DC requesting DS-Replication-Get-Changes is a confirmed incident.

4. SAM/NTDS extraction — command-line patterns: reg save targeting SAM/SECURITY/SYSTEM hives, ntdsutil IFM creation, vssadmin create shadow, esentutl copying ntds.dit. DeviceProcessEvents with ProcessCommandLine matching.

5. DPAPI secrets — the one nobody covers. Browser passwords, WiFi creds, RDP saved passwords are all DPAPI-protected and all extractable without touching LSASS. Credential Guard doesn't protect DPAPI. Monitor access to %APPDATA%\Microsoft\Protect\ by non-system processes.

Full writeup with copy-paste KQL, a Sigma rule for Kerberoasting, MDE IdentityQueryEvents alternatives (for environments without DC log forwarding), and false positive analysis for each:

https://training.ridgelinecyber.com/blog/credential-access-detection-beyond-lsass/

Happy to answer questions on any of the rules or tuning approaches.

Silverfort published research two weeks ago showing the Agent ID Administrator role could take over any service principal in a tenant. Microsoft patched the specific flaw. But the underlying primitive is unchanged: if you own a service principal, you own its permissions.

The attack is simple. Gain ownership of a service principal that holds a directory role. Add a client secret. Authenticate as that service principal. Inherit every permission it holds. If the target has a Global Administrator, that's a full tenant takeover.

99% of tenants have at least one privileged service principal. Most organizations don't audit who owns them.

Here's what most environments look like:

→ Service principals created by developers who left 12+ months ago

→ Ownership assigned at creation time, never reviewed

→ Credentials that haven't been rotated since the application was registered

→ Application-level permissions that bypass every user-scoped control

→ No alert when someone changes ownership or adds credentials

We wrote a post covering:

1. The attack chain — how ownership becomes takeover in four steps

2. Where to check in the Entra admin center — the portal paths most admins never open

3. Three PowerShell audit queries you can run in 30 minutes

4. Two KQL detection rules for Sentinel — ownership changes and credential additions

5. The consolidated audit script you can hand to your security lead

The organizations that get compromised through service principal abuse aren't the ones that failed to patch a specific vulnerability. They're the ones that never governed the primitive.

Full post with all queries and detection rules: https://training.ridgelinecyber.com/blog/service-principal-ownership-attack-path/

We just open-sourced VanGuard — a self-contained IR toolkit that bundles Velociraptor, Hayabusa, Chainsaw, Loki, and YARA into a single binary with a terminal UI.

Built it because we were tired of the 45-minute tooling setup at the start of every engagement. Download KAPE, remember the flags, set up Velociraptor, manually hash evidence, and track the chain of custody in a spreadsheet.

What it does:

• Quick triage (20+ Windows, 15+ Linux artifact categories using native commands)
• Velociraptor server lifecycle + agent deployment from the TUI
• Threat hunting with Hayabusa, Chainsaw, Loki, YARA + live anomaly detection
• Memory capture + Volatility 3 analysis
• 28 pre-built use cases (ransomware, BEC, credential theft, lateral movement, rootkits) with MITRE ATT&CK mapping
• Evidence dual-hashed (MD5 + SHA256), HMAC chain of custody
• Runs from USB, works fully offline

Cross-platform (Windows + Linux), Apache 2.0, no dependencies.

GitHub: https://github.com/ridgelinecyberdefence/vanguard

It's provided as-is — every environment is different, especially with remote ops (WinRM/SSH auth varies by config). Test in a lab first. Issues and suggestions welcome on GitHub.

After an attacker gets initial access — phishing, AiTM, whatever — the next 30 minutes are your best detection opportunity. Here's why most SOCs miss it.

The attacker has to do discovery. They have no choice. They just landed on a machine they've never seen before and need to answer basic questions: who am I, where am I, what can I reach, and who has admin. That means running commands. In sequence. Fast.

The discovery pattern looks like this (from real campaign telemetry):

   T+0s    whoami /all
    T+3s    hostname
    T+8s    ipconfig /all
    T+15s   systeminfo
    T+45s   net user /domain
    T+52s   net group "Domain Admins" /domain
    T+60s   nltest /dclist:contoso.com
    T+68s   net share
    T+75s   tasklist /svc
    T+82s   netstat -ano

10 commands in 82 seconds. Every one of these commands is legitimate on its own. Your L1 analyst sees "net user /domain" and closes it — admin doing admin things.

But the sequence is the signal. No human admin runs whoami → hostname → ipconfig → systeminfo → net user → net group in that order at that speed. That's either a scripted sequence or a human operator working through a checklist. Both are attacker behaviour.

The detection that catches this isn't complicated:

DeviceProcessEvents
| where Timestamp > ago(1h)
| where ProcessCommandLine has_any ("whoami", "ipconfig", "systeminfo",
"net user", "net group", "nltest", "netstat", “hostname2, “tasklist”, “net share”)
| summarize
   CommandCount = count(),
   Commands = make_set(ProcessCommandLine)
   by DeviceName, InitiatingProcessId, bin(Timestamp, 5m)
 | where CommandCount >= 5

5+ recon commands from the same parent process within a 5-minute window. That's the detection. It's behavioural — it catches the pattern regardless of which specific commands the attacker runs.

Why most SOCs miss it:

1. Each command is triaged independently. The alert for "net group Domain Admins" fires. L1 sees a user account, sees the command is legitimate, and closes it. They never see the other 9 commands that ran in the same 82-second window.

2. No campaign-level correlation. The SOC's detection rules fire per-event. Nothing ties the PowerShell execution from 2 hours earlier (the phishing payload) to the discovery sequence happening now. They're separate alerts in separate queues.

3. The window closes fast. After discovery, the attacker has what they need. They move to credential harvesting (Kerberoasting, LSASS dump, token theft) and lateral movement. The noisy phase is over. From here, they blend with legitimate traffic.

The fix: detect the sequence, not the individual command. Aggregate by parent process and time window. If you see a burst of reconnaissance commands from a single process in under 5 minutes, that's your alert — and it should be high severity, not informational.

This is from a course I built on offensive security for defenders (Ridgeline Cyber). The free modules (M0-M1) walk through campaign-level thinking and lab setup if you want to dig deeper: training.ridgelinecyber.com/courses/offensive-security-for-defenders/

Happy to answer questions on the detection logic or the campaign patterns behind it.

Full disclosure: I built the Offensive Operations course at Ridgeline Cyber

The easiest way to diagnose whether you're running security operations or compliance operations:

Ask what causes your team to change something.

Compliance-driven triggers: audit findings, contract renewals, framework updates, and regulatory changes. The team acts when an external authority requires it.

Threat-driven triggers: an incident revealed a gap; a purple-team exercise showed a rule didn't fire; threat intel identified a new technique; and a coverage assessment found an empty ATT&CK tactic. The team acts because the adversary's behaviour demands it.

If your program changes primarily in response to audit cycles, you're running a compliance operation. That's a diagnostic, not a judgement — and it's fixable.

Full post: https://ridgelinecyber.com/blog/security-operation-or-compliance-operation/