Directory Insights in 10 Minutes

In this episode, Craig Birch breaks down how Scattered Spider, also known as Octo Tempest, is exploiting a built-in trust relationship between Active Directory and VMware ESXi to escalate privileges and deploy ransomware — all without triggering traditional security tools.Learn how the ESX Admins group becomes an unintentional backdoor to root access on every ESXi host in your environment, and why this attack path — warned about in CVE-2024-37085 — is being actively exploited in the wild.You’ll also get a quick PowerShell walkthrough to detect the ESX Admins group and hear how Cayosoft Guardian can proactively detect and block this behavior before it causes damage.Who is Scattered Spider and what makes their attacks uniqueHow Active Directory and VMware vSphere integration can expose your hypervisorsThe role of the ESX Admins AD group in privilege escalationLive PowerShell examples to detect group presence and abuseHow Cayosoft Guardian detects and stops unauthorized privilege pathsCVE-2024-37085 and its relevance to real-world breachesCheck if the ESX Admins group exists:List group members:Search for changes to group membership:Real-time detection of suspicious AD group membership changesCustom Change Roles to block group creation like ESX Admins200+ identity misconfigurations covered across AD, Entra ID, Microsoft 365, and IntuneRollback and audit features for fast response and recovery“If you’ve got domain-joined ESXi hosts and an ESX Admins group in AD — you’ve got a direct path to root. And attackers like Scattered Spider know it.”Until next time stay guarded, stay informed, and be the guardian of your directory.

Welcome to Directory Insights in 10 Minutes, a bite-sized cybersecurity briefing from Guardians of the Directory. I’m your host, Craig Birch—Principal Security Engineer and Identity Security Enthusiast.In this episode, we dive into a critical misconfiguration that still lurks in many AD environments: DNS zones allowing unsecure dynamic updates.🔍 Here’s what we cover:What dynamic updates are and how they work in AD-integrated DNSThe three update modes—Secure Only, Nonsecure and Secure, and NoneWhy nonsecure dynamic updates are a serious attack surfaceReal-world DNS attack tactics using spoofed records and tools like ResponderA simple PowerShell script to detect vulnerable DNS zonesHow to fix your zones using DNS ManagerAnd why Cayosoft Guardian is your best defense against configuration drift🛡️ In Active Directory, trust starts with DNS—make sure that trust isn’t anonymous.PowerShell Detection Script:Learn more about Cayosoft Guardian: https://www.cayosoft.com/guardianIf you found this episode helpful, don’t forget to:Subscribe on YouTube, Spotify, or your favorite podcast platformDrop a comment with your AD security questions—we may feature it in a future episode!Share with your IT team or security peers🔗 LinkedIn🌐 Focus on Identity🧰 Resources Mentioned:powershellCopyEditGet-DnsServerZone | Where-Object { $_.DynamicUpdate -ne "Secure" }🔔 Subscribe & Follow:📢 Connect with Craig Birch:

Welcome to Guardians of the Directory, the podcast where we break down real-world threats, best practices, and insights in Active Directory, Entra ID, and Microsoft identity security.In today’s episode, Craig Birch dives into one of Active Directory’s oldest — and most quietly dangerous — features: the primaryGroupID. While originally designed for POSIX compatibility and legacy systems, this attribute can now be misused to grant hidden privileges, bypass group auditing, and create stealth admin access.🔍 In this episode, you'll learn:What the primaryGroupID attribute is and why it still existsWhy anything other than 513 (Domain Users) should raise red flagsHow attackers can leverage this setting to hide elevated privilegesHow to detect non-standard values using PowerShellHow to safely remediate misconfigured accountsWhy real-time detection with Cayosoft Guardians is a smarter defenseCraig walks you through not just how to fix the problem — but how to prevent it entirely with intelligent alerting, automation, and policy enforcement.

Shadow admins might not wear capes—but they can bring down your Active Directory if left unchecked. In this episode of Directory Insights in 10 Minutes, Craig Birch takes a sharp dive into AD delegations that slip through the cracks—commonly misconfigured permissions that give users dangerous access without being in official admin groups.You'll learn:What shadow admins are and why they’re so often missedKey permissions that signal elevated access riskWhere to look inside your AD to find hidden privilege pathsPowerShell tools and techniques to surface these threatsPractical next steps to verify and remediate accessWhether you're managing AD or auditing security posture, this is the 10-minute hit you need to guard your directory from internal elevation risks.Episode Highlights:(00:00) Introduction to shadow admins and delegated permissions(01:15) Deep dive into risky permissions: GenericAll, WriteOwner, ReplicateDirectoryChanges(03:42) Where to find shadow admins: domain root, Domain Controllers OU, Sync OUs(06:05) PowerShell tools to uncover hidden delegations(07:30) Tips for reviewing and remediating shadow admin rights(09:00) Final thoughts: stay vigilant, stay guarded📌 Show Notes (YouTube / Podcast Website)

🎙️ In This Episode of Directory Insights in 10 MinutesCraig Birch breaks down the misunderstood AdminSDHolder object and the SDProp process in Active Directory—why they exist, how they protect privileged groups, and how attackers exploit misconfigurations to maintain persistence.🔍 What You’ll Learn:• What AdminSDHolder and SDProp actually do• Why they matter for Tier 0 group protection• How attackers abuse them for persistent elevated access• Which ACLs and inherited permissions to look for• PowerShell methods to quickly audit for dangerous ACEs🛠️ PowerShell Script – AdminSDHolder ACL Audit# Get AdminSDHolder ACL and filter for dangerous ACEs$domainNC = (Get-ADDomain).DistinguishedName$adminSDHolderDN = "CN=AdminSDHolder,CN=System,$domainNC"$acl = (Get-ADObject -Identity $adminSDHolderDN -Properties nTSecurityDescriptor).nTSecurityDescriptor$dangerousACEs = $acl.Access | Where-Object { $_.AccessControlType -eq "Allow" -and $_.ActiveDirectoryRights -match "GenericAll|GenericWrite|WriteDacl|WriteOwner"}$dangerousACEs | Format-Table IdentityReference, ActiveDirectoryRights✅ Run this to find potentially exploitable permissions in protected AD groups.📌 Brought to you by Guardians of the Directory

🎙️ In this episode, Craig Birch breaks down one of Active Directory’s most overlooked threats: Kerberoasting via privileged accounts with Service Principal Names (SPNs).You’ll learn how attackers exploit this common misconfiguration to extract service tickets and crack credentials offline — and how to identify and fix these accounts without breaking critical apps.• What SPNs are — and why they matter for security• How attackers Kerberoast high-value accounts• Why ADUC won’t give you full visibility• PowerShell + LDAP filters for fast SPN discovery• How SDProp flags privileged accounts• Why auto-remediation can backfire• Safer alternatives: gMSAs, strong passwords, role reviews🔍 What You’ll Learn:• What SPNs are — and why they matter for security• How attackers Kerberoast high-value accounts• Why ADUC won’t give you full visibility• PowerShell + LDAP filters for fast SPN discovery• How SDProp flags privileged accounts• Why auto-remediation can backfire• Safer alternatives: gMSAs, strong passwords, role reviews🛠️ PowerShell Spotlight:Get-ADUser -LDAPFilter "(&(admincount=1)(servicePrincipalName=*))" ` -Properties servicePrincipalName | Select-Object Name, servicePrincipalName✅ Use this to find privileged accounts with SPNs — the ones most at risk of Kerberoasting.Script it — don’t rely on ADUCNever auto-remove SPNs without reviewing impactTalk to app owners before making changesHarden service accounts or move to gMSAsMonitor SDProp-marked accounts to shrink attack surface💬 Found this helpful? Like, share, or comment. Got a topic for a future 10-minute breakdown? Drop it below — we’re listening.📌 Powered by Guardians of the Directory

🎙️ In this episode, Craig Birch exposes one of the most overlooked Active Directory misconfigurations: the “Do not require Kerberos pre-authentication” setting.Attackers love it — it enables AS-REP Roasting, silent user enumeration, and offline password cracking — and it often flies under the radar of SIEMs and detection tools.• What Kerberos pre-auth actually does• How disabling it creates an AS-REP Roasting risk• Why this setting leads to silent user enumeration• How attackers extract TGTs for cracking with Hashcat/John• PowerShell steps to detect and remediate it safely🔍 What You’ll Learn:• What Kerberos pre-auth actually does• How disabling it creates an AS-REP Roasting risk• Why this setting leads to silent user enumeration• How attackers extract TGTs for cracking with Hashcat/John Ripper• PowerShell steps to detect and remediate it safely🛠️ PowerShell Spotlight:# Import the AD moduleImport-Module ActiveDirectory# Find accounts vulnerable to AS-REP Roasting$users = Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth# Output affected accounts$users | Select-Object Name, SamAccountName, UserPrincipalName# Optional: Remediation (confirmation step)Read-Host -Prompt "Press Enter to remediate these accounts"foreach ($user in $users) { Set-ADAccountControl -Identity $user -DoesNotRequirePreAuth $false}✅ Use this to detect and fix accounts vulnerable to offline ticket cracking.✅ Quick Takeaways:AS-REP Roasting bypasses standard authentication failure loggingPre-auth disabled = easy ticket extraction and brute-force attemptsThis setting is often set by legacy apps or weak GPOsAlways confirm account function before remediationAdd detection logic to your SIEM or use scheduled PowerShell audits💬 Found this helpful? Like, share, or comment. Got a topic for a future 10-minute breakdown? Drop it below — we’re listening.📌 Powered by Guardians of the Directory

🎙️ In this episode of Directory Insights in 10 Minutes, powered by Guardians of the Directory, Craig Birch walks you through detecting and remediating a legacy misconfiguration that still haunts many AD environments: accounts limited to DES-only Kerberos encryption.DES is weak, deprecated, and easily cracked — yet it's still lurking in environments where older configurations or forgotten accounts persist.🔍 What You’ll Learn:• Why DES-only encryption is dangerous in modern AD environments• How attackers exploit this weakness in Kerberos ticket exchanges• PowerShell techniques to find accounts with DES enabled• How to upgrade users to AES encryption using Set-ADUser• GUI vs. script-based remediation — what’s faster and safer🛠️ PowerShell Spotlight:# Find users with DES-only encryption enabledGet-ADUser -Filter {UserAccountControl -band 0x200000} -Properties UserAccountControl | Select-Object Name, SamAccountName# Remediate: Remove DES-only flag and enable AESSet-ADUser username -KerberosEncryptionType AES128,AES256✅ This helps ensure your accounts are no longer relying on crackable encryption standards.✅ Quick Takeaways:DES is deprecated and no longer secureMany legacy accounts still silently rely on DESUse PowerShell or GUI to detect and remediate fastAlways test before changing encryption settings on service accountsEnforce stronger Kerberos encryption org-wide via GPO💬 Found this helpful? Like, comment, or share. Got a topic for a future 10-minute breakdown? Drop it below — we’re listening.📌 Powered by Guardians of the Directory

🎙️ In this episode, Craig Birch dives into a critical but often overlooked AD misconfiguration: accounts that allow password storage with reversible encryption.This setting can bypass your domain password policies and expose credentials to plaintext extraction by tools like Mimikatz or DCSync.🔍 What You’ll Learn:• Why reversible password encryption is still found in AD environments• How it allows attackers to dump plaintext passwords• How to find accounts with this setting using PowerShell• Steps to remediate and eliminate this risky configuration• Why this setting defeats complexity, length, and hashing protections🛠️ PowerShell Spotlight:# Find users with reversible encryption enabledGet-ADUser -Filter {AllowReversiblePasswordEncryption -eq $true} ` -Properties AllowReversiblePasswordEncryption | Select-Object Name, SamAccountName# Optional: Remediate the settingSet-ADUser username -AllowReversiblePasswordEncryption $false✅ Use this to eliminate one of the most easily exploitable password risks in AD.✅ Quick Takeaways:Reversible encryption = plaintext storage riskBypasses password complexity and policy protectionsVulnerable to Mimikatz, DCSync, and backup extractionUse PowerShell to quickly find and fix weak accountsAudit user provisioning workflows to prevent reintroduction💬 Like what you heard? Give us a thumbs-up, comment, or drop a topic you’d like covered in 10 minutes or less.📌 Powered by Guardians of the Directory

🎙️ In this episode, Craig Birch exposes one of the most dangerous and overlooked misconfigurations in Active Directory: the PasswordNotRequired attribute.Most AD admins assume password policies apply to all accounts — but this hidden flag allows accounts to exist with blank passwords, silently bypassing domain-wide protections. Attackers know it. Many admins don’t.🔍 What You’ll Learn:• What the PasswordNotRequired attribute really does• How it overrides password length, complexity, and history policies• Which accounts are most at risk (including service and trust accounts)• Why this setting leads to instant compromise with no brute-force required• How to identify and fix vulnerable accounts with PowerShell🛠️ PowerShell Spotlight:# Detect accounts with PasswordNotRequired flag setGet-ADUser -Filter * -Properties userAccountControl |Where-Object { ($_.userAccountControl -band 0x0020) } |Select-Object Name, SamAccountName# Optional: Clear the flag (example)Set-ADUser username -PasswordNotRequired $false✅ Use this to find and lock down accounts silently skipping your password policy.✅ Quick Takeaways:This setting bypasses all domain password policy enforcementCommon on legacy accounts, service accounts, or through bad provisioningEasy path to account compromise and privilege escalationMost AD auditing tools don’t flag it — but attackers know it’s thereFix it fast using PowerShell and GPO cleanup💬 Found this helpful? Like, share, or comment. Want a specific AD risk explained in 10 minutes or less? Drop your request below — we’re listening.📌 Powered by Guardians of the Directory

Directory Insights in 10 Minutes – Episode 1Welcome to the very first episode of Directory Insights in 10 Minutes, brought to you by Guardians of the Directory.This series cuts through the noise — no fluff, no filler — just real-world, actionable insights for securing Active Directory and Entra ID.In this kickoff episode, Craig Birch reveals the #1 most overlooked AD misconfiguration — one that ships insecure by default, is present in nearly every environment, and continues to provide attackers with a clear path to domain dominance.🔍 What You’ll Learn:• Why the built-in Administrator account (RID 500) is vulnerable out of the box• How attackers abuse Kerberos delegation to impersonate high-privilege accounts• Why Microsoft’s guidance is buried in 2,000+ pages of documentation• The one checkbox that shuts down this attack path instantly• Why putting accounts in the Protected Users group isn’t enough🛠️ Quick Fix:1️⃣ Open the RID 500 account properties2️⃣ Under the Account tab, check:    ✅ “Account is sensitive and cannot be delegated”3️⃣ Apply this setting to all privileged accounts4️⃣ Include this check in your AD hardening baseline✅ Quick Takeaways:The built-in Administrator account is a default privilege escalation pathKerberos delegation + RID 500 = full impersonationA single setting can eliminate this risk — but most admins miss itMake this part of your secure provisioning process for every admin account💬 Join the Conversation:Have you seen this in your AD environment? Drop us a comment. Let’s talk about closing one of the oldest open doors in AD.📌 Powered by Guardians of the Directory