Listen to this Post
Introduction:
A new wave of credential dump techniques is successfully evading Microsoft’s Credential Guard, a critical defense mechanism designed to protect derived credentials in Windows environments. This advancement by threat actors necessitates a shift in defensive strategies, forcing security professionals to hunt for novel artifacts left behind during these attacks, with Service Principal Name (SPN) logons from workstations being a primary indicator of compromise.
Learning Objectives:
- Understand the critical link between SPN logons from non-standard systems and credential dumping activities.
- Master the use of KQL for hunting and detecting suspicious authentication patterns in Azure/Microsoft Sentinel.
- Learn immediate hardening techniques to protect service accounts and limit attacker movement.
You Should Know:
1. The Core KQL Query for SPN Hunt
The following Kusto Query Language (KQL) script is designed to run in Microsoft Sentinel or Azure Log Analytics to identify SPN logons from workstation-level operating systems, a key signal of potential Kerberoasting or service account misuse.
SecurityEvent | where TimeGenerated >= ago(24h) | where EventID == 4624 // Successful Logon | where AccountType == "User" // Filters out machine logons | where LogonType == 3 // Network Logon, common for service tickets | where AuthenticationPackageName == "Kerberos" // Filter for accounts with an SPN set (likely service accounts) | where Account contains "$" or (Account contains "svc" or Account contains "sql" or Account contains "web") // Customize with your service account naming conventions // Critical: Filtering for logons TO a workstation | where Computer contains "WRK" or Computer contains "WS" or Computer contains "LAPTOP" or Computer endswith "-PC" // Customize for your workstation naming schema | project TimeGenerated, Account, Computer, SourceNetworkAddress, LogonProcessName, WorkstationName | summarize AttemptCount = count() by Account, Computer, bin(TimeGenerated, 1h) | sort by AttemptCount desc
Step-by-step guide:
- Purpose: This query hunts for successful logon events where a user account, typically a service account, authenticates to a workstation computer. This is anomalous because service accounts should only be logging into servers to run specific services. A logon to a workstation strongly suggests an attacker has compromised the service account password and is using it to move laterally or extract the account’s Kerberos ticket.
- Execution: Paste this query into your Microsoft Sentinel Logs blade or Azure Log Analytics workspace connected to your domain controllers and workstations.
- Customization: You MUST customize the `Account` and `Computer` filters to align with your corporate naming standards. The `Account` filter looks for common service account prefixes, while the `Computer` filter identifies workstation hostnames.
- Analysis: Results from this query should be investigated immediately. Correlate the source IP (
SourceNetworkAddress) with other activity and check the service account for any unauthorized changes or access.
2. Enforcing Service Account Logon Rights via GPO
To proactively mitigate this attack vector, you can enforce where service accounts are permitted to log on using Group Policy. This is a critical hardening control.
Windows Command (to verify current policy):
Check the current "Log on as a service" policy secedit /export /cfg C:\temp\secpol.cfg /areas USER_RIGHTS findstr "SeServiceLogonRight" C:\temp\secpol.cfg
Step-by-step guide:
- Purpose: This control prevents a service account from being used interactively or over the network on any computer not explicitly defined in the policy, effectively blocking an attacker from using a stolen service account password to log into a workstation.
2. Implementation:
a. Open the Group Policy Management Console (GPMC.MSC).
b. Edit the Group Policy Object (GPO) linked to your servers (e.g., “Server Baseline Policy”).
c. Navigate to: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.
d. Find the policy “Log on as a service” and/or “Deny log on locally” / “Deny log on through Remote Desktop Services”.
e. Define the policy and add the specific service accounts or security groups containing them. For “Log on as a service,” add the accounts to the allowed list on relevant servers. For the “Deny” policies, consider applying them to workstations.
3. Verification: After the GPO is applied, use the `secedit` command above on a target machine to confirm the policy has been successfully applied and the service account is correctly listed.
3. Detecting Kerberoasting Activity with KQL
Kerberoasting is a common attack that leverages SPN requests. This KQL query specifically hunts for the tell-tale signs of this technique, which often precedes or accompanies the suspicious logons we are hunting.
SecurityEvent
| where TimeGenerated >= ago(12h)
| where EventID == 4769 // A Kerberos service ticket was requested
| where TicketEncryptionType in (0x17, 0x18) // RC4 or AES256, but focus on RC4 for weaker encryption
| where ServiceName !has "krbtgt" // Filter out TGT requests
| where ServiceName !contains "MicrosoftVirtual" // Filter out noise
| where TicketOptions in ("0x40810000", "0x40810010") // Ticket requested without pre-auth
| project TimeGenerated, Account, ClientAddress, ServiceName, TicketEncryptionType, TicketOptions
| summarize TicketRequests = count() by Account, ClientAddress, bin(TimeGenerated, 15m)
| where TicketRequests > 5 // Threshold for alerting
Step-by-step guide:
- Purpose: This query identifies accounts that are requesting an unusually high number of Kerberos service tickets, particularly those using weaker encryption (RC4), which is a hallmark of the Kerberoasting attack.
- Execution: Run this in your SIEM. The focus is on Event ID 4769 from domain controllers.
- Analysis: A single account requesting tickets for multiple different services (
ServiceName) in a short period is a high-fidelity alert. Investigate the client IP and the account immediately.
4. PowerShell: Enforcing AES Kerberos Encryption
Attackers often target accounts still using the legacy RC4 encryption. You can use PowerShell to find and remediate these accounts.
PowerShell Commands:
FIND accounts using RC4 for Kerberos pre-authentication
Get-ADUser -Filter -Properties SamAccountName, UserPrincipalName, KerberosEncryptionType | Where-Object {$<em>.KerberosEncryptionType -ne "0" -and $</em>.KerberosEncryptionType -contains "RC4"} | Select-Object SamAccountName, UserPrincipalName, KerberosEncryptionType
REMEDY: Set a specific user to use AES256
Set-ADAccountControl -Identity "svc_sqlreporting" -KerberosEncryptionType AES256
REMEDY (Domain-wide via Group Policy): Set the supported encryption types in a GPO
Path: Computer Config -> Policies -> Admin Templates -> System -> Kerberos -> "Supported encryption types..."
Enable and check only AES256 and AES128.
Step-by-step guide:
- Purpose: To identify and reconfigure user and service accounts to use strong AES encryption for Kerberos, making them resistant to offline cracking if their ticket is stolen.
- Execution: Run the `Get-ADUser` command from a machine with the Active Directory PowerShell module to generate a list of vulnerable accounts. Use the `Set-ADAccountControl` command to upgrade individual critical service accounts.
- Domain-Wide Hardening: For a comprehensive fix, use the Group Policy setting to define the supported encryption types for all computers in the domain, forcing the use of AES.
5. Windows Command Line: Analyzing Logon Sessions
If you have access to a potentially compromised workstation, you can quickly enumerate current logon sessions to see if a service account is active.
Windows Command:
List all logon sessions on the local machine query user For more detail, use Sysinternals PsLoggedOn (download separately) PsLoggedOn.exe -l -x \%COMPUTERNAME%
Step-by-step guide:
- Purpose: To perform rapid triage on a suspect workstation to identify active sessions from service accounts or other unauthorized users.
- Execution: Open a command prompt as Administrator. The built-in `query user` command will show active sessions. For more robust information, download `PsLoggedOn` from Microsoft Sysinternals and run it.
- Analysis: Look for any account names that match your corporate service account naming convention (e.g.,
svc_,sqladmin). If found, this is a direct confirmation of compromise and requires immediate incident response actions.
What Undercode Say:
- The bypass of Credential Guard is a paradigm shift, not just a new exploit. Defenders can no longer rely on it as a silver bullet and must return to foundational detective controls.
- The artifact of an SPN-equipped account logging into a workstation is a high-fidelity alert that should be automated and prioritized in any mature SOC.
- Proactive hardening, such as restricting service account logon rights and enforcing AES Kerberos encryption, provides a more resilient defense than chasing individual detection queries.
The emergence of techniques that bypass Credential Guard signals a critical evolution in the attacker-playbook, forcing a defensive pivot from pure prevention to deep-cycle detection and hardening. While the specific vulnerability may be patched, the underlying attack pattern—abusing legitimate authentication mechanisms for lateral movement—is perennial. The hunting methodology outlined here, focusing on logon anomalies and weak encryption, will remain relevant long after this specific bypass is mitigated. Organizations that institutionalize these hunting practices and hardening steps will be resilient not just to this threat, but to the next inevitable bypass.
Prediction:
The successful bypass of Credential Guard will catalyze a new wave of offensive research focused on other “protected” security subsystems in Windows, such as LSA (Local Security Authority) isolates. We predict a rise in fileless, memory-resident attacks that leverage these techniques to operate entirely below the radar of traditional AV/EDR file scanning. This will accelerate the industry’s mandatory adoption of more advanced behavioral detection and memory analysis techniques, making runtime application self-protection (RASP) and more sophisticated EDR capabilities a baseline requirement for enterprise security within the next 18-24 months.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Bluraven Kql – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
