RootGuard Security @rootguardsec

An attacker flips one registry value, and your users' passwords are back in memory as cleartext. Check it isn't already set: Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" -Name UseLogonCredential -EA SilentlyContinue | Select-Object UseLogonCredential WDigest cached cleartext credentials in LSASS by default until Server 2008 R2. Since 2012 R2, it's off. But the toggle still exists, and setting UseLogonCredential to 1 turns it back on. It's a favourite post-exploitation move: flip it, wait for users to log in, read plaintext from LSASS. No cracking. Null or 0 is what you want. 1 on anything is the finding. Detection: 4657 on that value, or Sysmon 13.

Splunk for Security Analysts Learn SPL from your first search to mastery ridgelinecyber.com/training/cours…

Want to get better at Splunk? Whether you're writing your first search or you already know the basics and want to go further, Splunk for Security Analysts takes you from where you are to confident, defensible SPL. You'll learn with realistic security data, so you practise real sourcetypes and fields from the first lesson. What you'll get: → 10 modules that build your skills step by step, from first search to tstats, data models and optimization → Exercises in every lesson to complete, fix, and write from blank, graded as you go → Searches you can take straight back to your own Splunk work → A search-based exam and CPE credits when you finish New to SPL? Nothing is assumed. Already writing it? The later modules go well past the basics. The first module is free to preview, with no account needed. Link in replies. Where are you with Splunk right now: just starting, or levelling up?

The first 30 minutes of an incident decide whether you contain it or just create more noise. Triage checklist (condensed):

The most dangerous KQL query isn't the one that errors. It's the one that runs cleanly and answers wrong. A join that quietly drops rows. A parse that half-works. Nothing in the console warns you, and you find out after the incident report has been written. That's why we built KQL for Security Analysts the way we did, equipping you to investigate modern threats. What's inside: → 10 teaching modules, from your first query to graphs, time series and query optimization → Graded exercises in every lesson: complete, fix, and write from blank → A query-based exam: 20 tasks answered in KQL and checked on the server No KQL experience assumed. The first module is free to preview, with no account needed. Link in replies.

A scheduled task is how attackers survive a reboot. The task isn't the signal; who created it is. Pick your platform: Defender / Sentinel (KQL): DeviceEvents | where ActionType == "ScheduledTaskCreated" | where InitiatingProcessFileName in~ ("powershell.exe","cmd.exe","wscript.exe","mshta.exe") | project TimeGenerated, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName Splunk (SPL): index=windows EventCode=4698 | rex field=_raw "(?[^<]+)" | table _time, host, Account_Name, task_cmd, Task_Name Live host (PowerShell): Get-ScheduledTask | Where-Object { $_.Actions.Execute -match "AppData|\\Temp\\|powershell|cmd" } | Select-Object TaskName, @{n="Run";e={$_.Actions.Execute}}, @{n="Author";e={$_.Author}} A task created by a script, running as a user, from a user-writable path. That's the one to open.

Who can DCSync your domain? It's not a group, so no membership check finds it: $rootDSE = Get-ADRootDSE (Get-Acl "AD:$($rootDSE.defaultNamingContext)").Access | Where-Object { $_.ObjectType -in '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2','1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' } | Select-Object IdentityReference, ObjectType Those two GUIDs are Replicating Directory Changes and Replicating Directory Changes All. Hold both on the domain head, and you can pull every hash in the domain, krbtgt included, without touching a DC console. Expect to see the DCs, Domain Admins, Enterprise Admins and Administrators. Anything else is the finding: a service account from an old sync tool, a security product that over-asked, a user someone granted directly and forgot. Detection is 4662 with those GUIDs in the Properties field, where the account is not a DC.

Conditional Access is only as good as the questions you ask before you write the policy.

Most detection rules fail for one simple reason. They were written against a technique, not against the actual telemetry your environment produces.