Understanding Credential Guard
Logging In Created Valuable Material Inside Windows
Authentication does not end the moment Windows accepts a username and password.
After a successful sign-in, the operating system may need authentication information again so the user can reach network resources without entering credentials repeatedly. Kerberos tickets, NTLM-related credentials, and other authentication material can therefore remain available while the session is active.
That convenience also creates something attackers want.
Single Sign-On Requires Something Windows Can Reuse
When a user opens another authorized network resource without typing the password again, Windows needs an authentication mechanism capable of representing that user’s identity during the existing session.
The Authentication Process Could Hold More Than Attackers Needed
The Local Security Authority Subsystem Service plays a central role in Windows authentication.
Among its responsibilities, LSASS participates in maintaining authentication state associated with active sessions. That made the process extremely interesting to attackers who had already gained substantial access to a computer.
The next objective could be stealing credentials from memory.
Compromising One Computer Could Reveal Credentials for Somewhere Else
Authentication material recovered from a Windows session can potentially become useful against other computers and network services where the same identity has permission.
Power Over the Operating System Could Become Power Over Its Secrets
Windows administrators legitimately require extensive control over a computer.
They can install software, manage services, alter system configuration, and perform maintenance ordinary users cannot perform. Malware that obtains equivalent privileges inherits much of that power.
Historically, sensitive authentication data inside the operating system could therefore become exposed after a sufficiently privileged compromise.
Administrator Is a Powerful Security Boundary to Lose
Once malicious software obtains high privileges, ordinary permissions inside the same operating-system environment may provide much less protection against that malware.
A Hash Could Sometimes Be Valuable Enough
Attackers do not always need to recover a user’s original readable password.
Some authentication protocols use values derived from that password. If an attacker obtains the appropriate credential material, certain attacks can reuse it without first converting it back into the original password.
This helped make pass-the-hash attacks particularly important in Windows environments.
Not Knowing the Password Does Not Always Prevent Impersonation
A credential derivative can still have authentication value, so protecting only the human-readable password is not sufficient when other reusable authentication material remains exposed.
Stealing the Authentication Material Could Be Faster Than Cracking It
Password cracking attempts to discover the original secret.
Pass-the-hash attacks can take another route. When a compatible NTLM credential is obtained, the attacker may attempt to authenticate using that credential material directly rather than spending time recovering the user’s plaintext password.
The stolen representation becomes the prize.
The Attack Can Skip the Password-Recovery Step
If an authentication system accepts a credential derivative that an attacker has successfully stolen, discovering the original password may be unnecessary for that particular attack path.
A Ticket Could Also Represent a User
Domain environments commonly use Kerberos authentication.
After authentication, Kerberos uses tickets so users can reach authorized resources without repeatedly transmitting their passwords. Those tickets are intentionally useful because they represent authenticated access.
That usefulness also makes them attractive to attackers.
Anything That Can Prove Identity Deserves Protection
A password is only one form of authentication material. Tickets, hashes, keys, and other credentials may also permit access and therefore require strong protection.
The Attacker Could Attempt to Reuse a Stolen Kerberos Ticket
Kerberos tickets are intended to provide controlled access within the authentication system.
If useful ticket material is stolen from a compromised computer, an attacker may attempt to reuse it to impersonate the corresponding identity or reach network resources.
The problem again becomes credential theft rather than password guessing.
A Strong Password Cannot Protect a Ticket That Has Already Been Stolen
Password complexity helps resist password attacks, but it does not undo the theft of valid authentication material that was obtained after the legitimate user had already signed in.
Credential Guard Moved Valuable Secrets Away From the Normal Operating System
Credential Guard used virtualization-based security to change where selected Windows authentication secrets were protected.
Instead of relying only on ordinary process isolation inside the main Windows environment, sensitive credential operations could occur within an isolated environment protected by the hypervisor.
The operating system gained another security boundary inside the same computer.
The Secret Could Be Present Without Being Present in the Same Security World
Virtualization-based security allows Windows to isolate selected sensitive information from the normal operating-system environment even though both environments operate on the same physical computer.
The Hypervisor Could Protect Windows From Parts of Windows
Virtualization is commonly associated with running several operating systems on one physical computer.
Windows 10 also used virtualization technology as a security mechanism. The hypervisor could establish an isolated execution environment with stronger separation from the ordinary Windows kernel and applications.
Virtualization became a security primitive.
Isolation Does Not Require a Second Desktop
A virtualization-protected security environment can operate behind the scenes without behaving like a conventional virtual machine that the user opens and interacts with directly.
Windows Could Request Authentication Without Receiving the Protected Secret
Applications and Windows components still needed authentication services.
Credential Guard therefore did not simply disconnect credential processing from the operating system. The normal LSA could communicate with the isolated LSA component through controlled mechanisms when authentication operations were required.
The service remained available while the secret remained separated.
Use the Credential Without Handing Out the Credential
The ordinary Windows environment can request supported authentication operations without requiring unrestricted direct access to the protected credential material itself.
An Isolated LSA Process Could Hold What Ordinary LSASS Should Not Expose
With Credential Guard enabled, Windows uses an isolated LSA process commonly associated with LSAIso.
This isolated component operates within the virtualization-protected environment and participates in protecting sensitive authentication information that should not remain freely accessible to the ordinary operating system.
The security-sensitive portion gains a different home.
LSASS and LSAIso Have Different Security Positions
The ordinary LSA environment communicates with the isolated component when required, while virtualization-based security prevents the protected secrets from simply becoming ordinary readable memory in the normal operating system.
Owning the Normal Operating System Did Not Automatically Open the Isolated Environment
This was one of Credential Guard’s most important changes.
Traditional operating-system permissions are less useful once malicious code reaches sufficiently high privilege. Virtualization-based security creates separation enforced outside the ordinary Windows kernel’s normal privilege model.
Administrator access therefore no longer has to imply unrestricted access to every protected credential.
Higher Privilege Did Not Necessarily Cross the Hypervisor Boundary
Credential Guard was designed so malware operating with administrator-level privileges in normal Windows could still be prevented from directly extracting authentication secrets protected by virtualization-based security.
A Compromised Kernel Could Face Something Above It
The Windows kernel normally occupies one of the most privileged positions in the operating system.
Virtualization-based security places the hypervisor beneath the normal Windows environment and uses it to establish protected memory and execution boundaries. Sensitive security components can therefore be isolated from code that controls the ordinary kernel.
The trust hierarchy changes.
Security Can Be Stronger When the Protector Lives Outside the Protected System
A boundary enforced by the hypervisor does not depend entirely on the ordinary Windows kernel continuing to police itself correctly after that kernel has been compromised.
Credential Guard Directly Addressed Pass-the-Hash Risk
NTLM authentication can involve password-derived credential material valuable to attackers.
Credential Guard protects supported NTLM credentials using the isolated environment, making the classic strategy of dumping those protected secrets from ordinary Windows memory substantially more difficult.
The attack loses easy access to one of its most useful ingredients.
The Goal Was Not to Make the Hash Stronger
Credential Guard focuses on preventing protected credential material from being exposed to the compromised operating-system environment rather than changing the mathematical properties of the user’s password hash.
The Domain’s Single Sign-On Material Could Be Isolated
Kerberos ticket-granting information is valuable because it participates in obtaining access to additional domain resources.
Credential Guard protects supported Kerberos secrets within the virtualization-based environment, reducing the ability of malware in normal Windows to extract and reuse them.
Pass-the-ticket attacks lose another convenient source.
Protecting the Password Alone Would Leave Too Much Behind
Credential Guard targets multiple forms of reusable authentication material because attackers can exploit whichever credential representation gives them a workable path to another system.
Some Stored Domain Credentials Could Receive the Same Isolation
Windows Credential Manager can store credentials used by applications and services.
Credential Guard extends protection to supported credentials stored as domain credentials, reducing their exposure to credential-dumping techniques operating from the normal Windows environment.
The protected boundary covers more than one authentication protocol.
Credential Theft Is a Category of Attack
Protecting only one credential type leaves attackers free to pursue another, so Credential Guard was designed around isolating several important forms of reusable Windows authentication material.
The Stolen Credential Could Turn One Compromised PC Into Several
Credential theft becomes particularly dangerous in managed networks because identities often have access to more than one computer.
An attacker who compromises a workstation may search for credentials belonging to administrators or other users who have authenticated there. Those credentials can then be tested against additional systems.
The original infection becomes a stepping stone.
The Most Valuable Credential May Belong to Someone Who Logged In Earlier
A compromised workstation can become attractive because of the privileged identities that have used it, not merely because of the permissions belonging to the person currently sitting at the computer.
Repairing One Machine Could Accidentally Expose a Powerful Account
Administrators routinely connect to computers to troubleshoot problems and perform maintenance.
If a workstation is already compromised, using a highly privileged domain identity on that machine can create an opportunity for credential theft. The attacker may care much more about the administrator’s network identity than the original workstation.
Credential Guard was designed to reduce that risk for protected credentials.
Administrative Hygiene Still Matters
Credential isolation should complement practices such as limiting where privileged accounts sign in, separating administrative identities, and avoiding unnecessary exposure of powerful credentials on ordinary workstations.
Twenty Random Characters Were Still Vulnerable After Authentication
Password complexity is valuable against guessing and cracking.
But once a legitimate user authenticates, Windows may create or receive credential material needed for subsequent access. If malware steals that material directly, the strength of the original password may become irrelevant to that particular attack.
The defense has to protect the authenticated state too.
Authentication Security Continues After the Password Is Accepted
Protecting credentials in memory addresses a different stage of the attack than password complexity because the attacker is attempting to steal the result of successful authentication rather than guess the original secret.
A New Credential-Dumping Tool Might Not Have a Familiar Signature
Antimalware software remains important, but Credential Guard approaches the problem from another direction.
Instead of requiring every credential-stealing program to be recognized individually, virtualization-based isolation restricts what protected secrets ordinary software can reach.
The architecture itself denies access.
Block the Capability Instead of Identifying Every Tool
A security boundary can protect against multiple credential-dumping techniques because the attacker encounters the same isolation even when the malicious program or exploit being used is new.
Some Authentication Scenarios Remained Outside Its Protection
No security feature protects every credential in every situation.
Credential Guard specifically protects supported Windows authentication secrets. Credentials supplied directly to applications, credentials stored through unsupported mechanisms, and authentication scenarios requiring delegation can behave differently.
The boundary has defined limits.
Protected Credentials and All Credentials Are Not the Same Thing
Enabling Credential Guard does not justify assuming that every password, token, browser session, application secret, or authentication method on the computer has become inaccessible to malware.
Some Older Authentication Behaviors Depended on Access Credential Guard Restricted
Security improvements can expose assumptions built into older applications and protocols.
Software that expects to retrieve reusable credentials or depends on authentication behaviors incompatible with credential isolation may stop working normally when Credential Guard is enabled.
Organizations therefore need compatibility testing.
Test Before Broad Deployment
Enterprise authentication changes should be validated against VPN clients, wireless authentication, remote-access tools, legacy applications, and other systems that may depend on credential behaviors affected by Credential Guard.
Secure Boot and Virtualization Support Helped Establish Trust Earlier
Virtualization-based security depends on platform capabilities that operate beneath ordinary applications.
Modern processors provide virtualization extensions, while UEFI Secure Boot can help establish that trusted components participate in the startup process. Supported hardware therefore contributes directly to the strength of the security architecture.
Credential protection begins before the desktop appears.
Security Could Depend on the Platform Below Windows
Credential Guard demonstrates why operating-system security increasingly relies on processor, firmware, boot, and virtualization capabilities rather than treating hardware merely as something on which software happens to run.
A Remote Administrator Could Be Prevented From Quietly Turning the Protection Off
Credential Guard can be configured with a UEFI lock.
That configuration persists security state in firmware variables so disabling the feature requires more than changing an ordinary Windows setting remotely. The additional barrier helps protect the security configuration after an attacker obtains control of the operating system.
The protection can defend its own configuration.
A Security Feature Is Weaker if Malware Can Simply Disable It
Persisting Credential Guard configuration through UEFI can make unauthorized remote removal more difficult by moving an important part of the configuration outside ordinary operating-system control.
Hardware Could Help Protect Keys Used by Virtualization-Based Security
A Trusted Platform Module can provide hardware-backed protection for cryptographic material associated with platform security.
When used with virtualization-based security, the TPM can strengthen protection of keys that need to remain trustworthy across system startup and changing operating-system conditions.
The credential boundary can therefore depend on several layers working together.
Clearing the TPM Is Not a Harmless Troubleshooting Step
On systems using virtualization-based protections, clearing the TPM can destroy protected key material and affect data or credentials that depend on those keys. Recovery planning should come before the reset.
The Workstation Boundary Could Not Replace Domain Controller Security
Credential Guard protects selected authentication material on the Windows device where the feature operates.
It does not transform the Active Directory database or the local Security Accounts Manager database into virtualization-isolated credential stores. Those systems have their own security requirements and attack surfaces.
Endpoint isolation is one part of credential security.
Protecting a Credential in Memory Does Not Protect Every Copy Everywhere
The same identity may be represented by information stored or processed elsewhere in the authentication infrastructure, so organizations still need strong protection for domain controllers and account databases.
The SAM Was Not What Credential Guard Was Built to Isolate
Credential Guard primarily addresses valuable domain authentication material used by mechanisms such as Kerberos and NTLM.
Local account credentials stored in the Security Accounts Manager have different storage and protection characteristics and should not be assumed to receive the same Credential Guard protections.
The name can otherwise create an overly broad expectation.
Credential Guard Does Not Mean Every Credential Is Guarded
Understanding exactly which authentication secrets a security feature protects is essential before relying on it as a defense against credential theft.
Blocking Credential Dumping Did Not End Post-Compromise Activity
Attackers adapt when a profitable technique becomes less reliable.
If protected hashes and Kerberos secrets cannot be extracted conveniently, malware may target browser sessions, prompt users for credentials, capture information before it reaches the protected boundary, abuse existing authenticated sessions, or seek other ways to move through the network.
Mitigation changes the battlefield rather than eliminating it.
Successful Defense Forces More Expensive Attacks
Credential Guard is valuable even though attackers can pursue other techniques because removing easy credential extraction increases the difficulty and complexity of expanding a compromise.
Users Did Not Need to Operate Inside a Visible Virtual Machine
The isolation occurs beneath the ordinary Windows experience.
Users continue opening applications, accessing network resources, and signing in through familiar interfaces while the operating system handles protected credential operations across the virtualization boundary.
Strong isolation does not have to create a second desktop.
The Security Boundary Could Be Invisible to the User
Credential Guard demonstrates how substantial architectural security changes can operate underneath normal workflows rather than requiring users to understand or manually interact with the isolated environment.
Breaking Into the Computer Did Not Have to Reveal Everything the Computer Knew
Before strong isolation, obtaining high privilege on an endpoint could provide a direct route toward sensitive authentication material stored within that same operating-system environment.
Credential Guard challenged that assumption by placing selected secrets behind a virtualization boundary that the compromised normal environment was not supposed to cross.
One security failure no longer had to guarantee the next.
Containment Begins by Separating Valuable Things
Security architecture becomes more resilient when compromising one component does not automatically grant access to every sensitive asset the computer needs in order to operate.
Windows Needed Authentication Services More Than It Needed to Expose the Secret
The fundamental design principle behind Credential Guard is straightforward.
The operating system needs to perform authentication, but ordinary processes do not need unrestricted access to the underlying protected secrets. Controlled communication across an isolation boundary can provide the required service while withholding direct access to the credential material.
Functionality and secrecy can coexist.
The computer can use a credential without giving every powerful process permission to read it.
Credential Guard Put Valuable Authentication Secrets Behind Another Wall
Credential Guard changed an important assumption about a compromised Windows computer.
Using virtualization-based security, Windows could isolate selected NTLM credentials, Kerberos secrets, and supported domain credentials from the normal operating-system environment. The regular LSA could request the authentication operations it needed while the isolated LSA component protected sensitive material behind a hypervisor-enforced boundary.
Administrator access remained extremely powerful and a fully compromised computer remained a serious security incident. But Windows 10 introduced a meaningful new distinction: controlling the operating system no longer had to mean that every valuable credential used by that operating system was automatically available for the attacker to take.
