gMSA AES Key Extraction: Understanding Kerberos Key Derivation in Active Directory
Category: Active Directory Security
Focus: gMSA, Kerberos, AES-256, Windows Identity Security
Reading time: Approximately 14–18 minutes
Repository: gmsa-aes-key-extractor on GitHub
Research disclaimer: This article discusses an offensive-security research utility intended for authorized penetration testing, controlled lab environments, and defensive security engineering. Access to managed service-account password material and authentication keys must be explicitly authorized. Do not test against systems outside your approved scope.
Introduction
Active Directory security is not limited to ordinary user accounts, domain administrator privileges, or misconfigured access-control lists. Service identities are another important part of the identity and authentication infrastructure that keeps enterprise Windows environments operating.
Applications, scheduled tasks, web services, database integrations, and other workloads frequently require accounts that can authenticate to domain resources without depending on an employee's interactive login. Managing the credentials associated with these services creates a security challenge: credentials must be reliable enough for automated workloads, but sufficiently protected to prevent an attacker from turning a compromised service identity into broader access.
Group Managed Service Accounts (gMSAs) help address this operational problem. They allow Windows to manage service-account passwords automatically, reducing the need for administrators to create, distribute, and periodically change static credentials manually.
However, automated password management does not eliminate the need for access control. A gMSA's managed-password information is sensitive authentication material, and the ability to retrieve it should be restricted to the computers and principals that genuinely require it.
This is where Active Directory security assessment becomes particularly interesting.
In a properly scoped penetration test, a researcher may need to understand how managed-password data is represented, how Kerberos encryption keys are derived, and how configuration or permission weaknesses could affect an organization's security boundary.
To explore this technical area, I developed gmsa-aes-key-extractor, a Python utility focused on deriving an AES-256 Kerberos key from a gMSA msDS-ManagedPassword blob using Impacket.
This article explains the underlying concepts, the purpose of the utility, the components involved, and the defensive lessons that security teams should take away from this research.
1. What Is a Group Managed Service Account?
A Group Managed Service Account is a special type of Active Directory account designed for services that need a domain identity.
Unlike a traditional user account that may be configured for service use, a gMSA has its password managed by Windows. Depending on the deployment, it can support a service operating on one computer or across multiple compatible servers.
For example, an organization might use a gMSA to run:
- An IIS application pool.
- A Windows service that communicates with other domain systems.
- A scheduled task that accesses internal resources.
- A multi-server application requiring a shared service identity.
- An application that authenticates to SQL Server or another domain-integrated resource.
The main operational advantage is reduced manual credential handling. Administrators do not have to rely on a human-selected service password and remember to rotate it themselves.
Microsoft documents gMSA administration, configuration, and security considerations in its Secure group managed service accounts guidance.
Why gMSAs matter for security
A gMSA is still an identity with permissions. Its security depends on the resources it can access, its group memberships, its service configuration, and the systems permitted to retrieve its managed password.
A gMSA running an application does not automatically have administrator privileges. Similarly, compromising a system that uses a gMSA does not automatically grant access to that account's managed password.
An important distinction is the difference between:
- A computer that runs a service using a gMSA.
- A principal authorized to retrieve that gMSA's managed password.
- A user or computer with administrative rights over the gMSA object.
- The resources and privileges available to the gMSA after authentication.
These relationships must be examined separately during an assessment. Treating them as interchangeable can lead to incorrect conclusions about the actual attack surface.
Security takeaway: gMSAs reduce routine password-management overhead, but their password-retrieval permissions and downstream privileges still require careful control.
2. Understanding msDS-ManagedPassword
The Active Directory attribute msDS-ManagedPassword contains a binary structure with managed-password information for a group Managed Service Account.
It is not simply a human-readable password stored as an ordinary text attribute. The returned data follows a documented Microsoft structure named MSDS-MANAGEDPASSWORD_BLOB.
Microsoft's technical specifications describe the structure and the logic used to construct the attribute:
What is inside the blob?
The structure contains fields identifying its version, total length, and offsets to different portions of the managed-password information. It can also contain the previous password and timing information associated with password retrieval and password changes.
At a high level, the important components are:
| Component | Purpose |
|---|---|
| Version | Identifies the blob format version. |
| Length | Records the total size of the structure. |
| Current password offset | Locates the current managed-password data. |
| Previous password offset | Locates previous-password data when present. |
| Password interval offsets | Locate the relevant password timing information. |
| Password data | Contains the managed-password material in its defined binary representation. |
These fields are not interchangeable with individual Kerberos keys. Parsing the blob and deriving a Kerberos key are separate operations.
Why binary parsing matters
Security tools often receive information in formats that are not immediately usable by higher-level authentication libraries.
A tool may need to identify offsets, interpret fields, preserve the correct byte sequence, and avoid assumptions about the encoding of the data.
For gMSA research, this distinction is important because the password material is represented as binary data. An implementation that treats it as ordinary text too early could corrupt the input and produce an incorrect result.
Microsoft's specification should be treated as the source of truth for the blob layout rather than assumptions based on how a tool displays its output.
Access control is the first security boundary
A request for msDS-ManagedPassword is subject to Active Directory's permission model. The msDS-GroupMSAMembership security descriptor is relevant to determining which principals can retrieve a gMSA's password.
This means that an attacker cannot be assumed to retrieve a managed password merely because the account name is known or because LDAP is reachable.
The actual permissions, effective group memberships, delegation settings, directory configuration, and request context matter.
For defenders, this leads to a direct assessment question:
Which users and computer accounts are authorized to retrieve each gMSA's managed password, and does every one of them still need that access?
3. Kerberos and the Role of AES Keys
Kerberos is a network authentication protocol that allows clients and services to authenticate through a trusted Key Distribution Center (KDC). In a typical Active Directory domain, domain controllers provide the KDC functionality.
A simplified authentication exchange involves a client obtaining a Ticket Granting Ticket, using it to request service tickets, and presenting an appropriate service ticket when accessing a resource.
Long-term account keys and ticket-related session keys have different roles in this process. It is important not to confuse them.
Where AES enters the picture
Kerberos supports multiple encryption types. AES-based Kerberos encryption provides mechanisms for protecting authentication data using cryptographic keys of defined lengths.
AES-256 uses a 256-bit key, equivalent to 32 bytes. The key is not the same thing as the original text representation of an account password.
When a Kerberos AES key is derived from password material, the encryption type's string-to-key procedure takes the password, a salt, and applicable parameters into account.
The process is specified in RFC 3962: Advanced Encryption Standard (AES) Encryption for Kerberos 5.
At a conceptual level:
- The original password material is interpreted in the format required by the implementation.
- The relevant Kerberos salt is supplied.
- The string-to-key function applies the appropriate derivation parameters.
- The resulting key is represented in the required key format.
A correct password alone is not enough to guarantee that an independently derived Kerberos key is correct. The account identity, salt convention, encoding, and derivation parameters must also match the intended Kerberos principal.
Passwords, keys, and tickets are different objects
These concepts are frequently mixed together in security discussions.
| Term | Meaning |
|---|---|
| Managed password | Password material maintained for a service account. |
| Salt | Context supplied to the key-derivation operation. |
| AES-256 Kerberos key | A 256-bit key used by the relevant Kerberos encryption type. |
| Ticket Granting Ticket | A Kerberos ticket used to request service tickets. |
| Service ticket | A ticket associated with access to a particular service. |
| Session key | A key used for a particular authentication session or exchange. |
A gMSA password blob is therefore not already an AES-256 key. The tool described here focuses on the processing needed to move from the documented managed-password representation to a derived key.
4. Introducing gmsa-aes-key-extractor
The gmsa-aes-key-extractor repository is a focused Python project that investigates one specific part of this process: deriving a valid AES-256 Kerberos key from gMSA managed-password material.
Rather than attempting to be a complete Active Directory assessment framework, the utility concentrates on the data-handling and key-derivation boundary.
According to the project documentation, its workflow consists of obtaining the managed-password blob with an authorized directory principal, supplying the encoded blob and the relevant salt to the Python utility, and using Impacket for Kerberos key derivation.
Project goals
The utility is intended to support:
- Authorized Active Directory penetration tests.
- Red-team engagements with explicit scope and written authorization.
- Controlled Active Directory laboratory research.
- Security engineering investigations into identity and authentication weaknesses.
- Defensive understanding of gMSA-related exposure.
The project is deliberately narrow in scope. It is not a replacement for directory enumeration, permission analysis, Kerberos protocol analysis, or a comprehensive enterprise security assessment.
Technology stack
The repository documents the following dependencies and supporting components:
| Component | Role |
|---|---|
| Python 3.8+ | Runtime for the utility. |
| Impacket | Implements the relevant Kerberos cryptographic functionality. |
| bloodyAD | Provides a way to retrieve the managed-password attribute when the authenticated principal is authorized. |
| proxychains | Optional network-routing support for approved internal or pivoted test environments. |
Each component has a different responsibility.
Python provides the program's execution environment. Impacket supplies protocol and cryptographic functionality. bloodyAD interacts with Active Directory. proxychains can route supported connections through a configured proxy.
The exact tools and connection method used during an assessment should be selected according to the authorized environment and its network architecture.
Explore the source code
The project's source code and usage notes are available here:
Open gmsa-aes-key-extractor on GitHub
The repository is the appropriate place to review the implementation, inspect its dependencies, understand its current limitations, and follow future changes.
5. Understanding the Utility's Workflow
The tool's workflow is easiest to understand when separated into distinct stages. Each stage has its own inputs, assumptions, and validation requirements.
Stage 1: Establish the authorization boundary
Before interacting with Active Directory, identify the target domain, the gMSA object being assessed, the approved test account, and the permissions granted to that account.
The key question is whether the principal is legitimately authorized to retrieve the managed-password attribute.
For a formal engagement, the test should remain within the agreed scope. A successful connection to LDAP is not proof of permission to access a protected attribute.
Stage 2: Retrieve the managed-password data
The repository uses bloodyAD to retrieve msDS-ManagedPassword from the relevant gMSA object.
bloodyAD's documentation describes the get object command and explains that binary attribute values can be represented in Base64 output.
See the bloodyAD user guide.
Base64 is an encoding used to represent binary data as text. It does not encrypt or protect the data. Anyone who obtains the encoded value may be able to decode it, depending on the permissions and protections surrounding the data.
For this reason, managed-password output should be handled as sensitive credential material. Avoid copying production values into public issues, screenshots, external debugging services, or unprotected files.
Stage 3: Interpret the input correctly
The next stage concerns how the utility receives and processes the blob.
A robust implementation needs to distinguish between:
- The textual Base64 representation.
- The decoded binary structure.
- The password bytes represented in that structure.
- The salt expected by the key-derivation routine.
These are different representations of related data.
It is equally important to preserve the encoding expected by the cryptographic library. In Windows-related protocols, Unicode and UTF-16LE representations frequently appear, and a careless conversion can change the bytes supplied to a key-derivation function.
Stage 4: Derive the Kerberos key
The utility uses Impacket's Kerberos cryptographic functionality for the AES-256 string-to-key operation.
The relevant implementation can be examined in the Impacket Kerberos cryptography source.
The result should be treated as a derived cryptographic key, not as a password reset, a new account credential, or proof that authentication will succeed against every service associated with the account.
An independently derived value should be validated in a controlled environment before it is considered suitable evidence of a successful implementation.
Stage 5: Validate the result safely
A useful research workflow distinguishes a value that was successfully calculated from a value that has been validated against an expected test result.
In an authorized lab, validation should use an account and environment created specifically for testing. Preserve the known test inputs and expected result, and record the library versions and configuration.
Do not expose real managed passwords or production keys in public output. A test report can record the outcome, algorithm, relevant configuration, and redacted evidence without disclosing reusable authentication material.
This separation between calculation and validation is important in security tool development because plausible-looking hexadecimal output does not independently prove correctness.
6. Why the Kerberos Salt Matters
One of the more subtle parts of password-based Kerberos key derivation is the salt.
A salt is input to the derivation process. It is not a secret password, a network address, or an encryption key. The exact value used depends on the applicable Kerberos principal and its associated conventions.
RFC 4120 describes the Kerberos principal and authentication framework, while RFC 3962 defines the AES-based string-to-key procedure.
References:
Principal identity and salt construction
For password-based Kerberos keys, the salt convention is tied to the principal identity and can be provided or overridden through the protocol's supported mechanisms. Therefore, a researcher should not assume that a generic string constructed from a domain and account name is universally correct for every account configuration.
This distinction matters when testing gMSA-related implementations.
A key-derivation program may run without throwing an exception and still produce a key that does not match the account's expected Kerberos key. The reason may involve a wrong salt, an incorrect input representation, the wrong derivation parameters, or a misunderstanding of the principal type.
How to investigate a mismatch
When a derived test key does not match the independently established lab expectation, investigate the assumptions systematically:
- Confirm that the Base64 input represents the intended test blob.
- Confirm that the binary data is decoded and interpreted according to the Microsoft structure.
- Confirm that the password-byte encoding matches the implementation's documented expectations.
- Verify the applicable Kerberos principal and salt convention.
- Check the selected encryption type and key-derivation parameters.
- Compare the result with a known test vector or independently verified laboratory result.
This is a diagnostic process, not proof that any particular salt convention is universally correct for all gMSAs.
Research takeaway: a working cryptographic primitive cannot compensate for incorrect input assumptions. The password representation, principal context, and algorithm parameters all matter.
7. What Could Go Wrong in a Real Active Directory Environment?
The security significance of gMSA password exposure depends on the surrounding configuration. It is important to distinguish a weakness in access control from the downstream impact of obtaining a service credential.
Potential risks include:
Excessive password-retrieval permissions
A principal that does not need a gMSA's managed password should not retain the ability to retrieve it. Overly broad access increases the number of identities whose compromise might expose the service credential.
Compromise of a permitted computer
If a compromised computer is authorized to retrieve a gMSA password, the attacker may be able to investigate the access available through that machine's identity and execution context.
The exact outcome depends on the account's permissions and the technical conditions required for retrieval. Authorization should be reviewed based on effective access, not simply on a list of intended computers.
Overprivileged service accounts
Even when password retrieval is tightly controlled, a gMSA with excessive permissions can create unnecessary risk.
If a service identity has broad access to file shares, application data, sensitive databases, or administrative functions, credential exposure may have a greater impact than it would for an identity restricted to a single workload.
Poorly controlled delegation or service configuration
Kerberos delegation, service principal name configuration, and the privileges granted to applications can affect the security of an Active Directory environment. These should be assessed separately rather than assumed to follow automatically from gMSA use.
Inadequate monitoring
An organization may have the right permissions on paper but lack visibility into directory changes, abnormal authentication, or the compromise of computers trusted to use service identities.
Effective security requires both preventive controls and sufficient telemetry to investigate suspicious activity.
8. Defensive Recommendations for Blue Teams
gMSA security should be managed as part of a broader identity-security program. The following controls provide a practical starting point.
8.1 Audit which principals can retrieve each password
Review the security descriptor associated with msDS-GroupMSAMembership and determine which users, computers, and groups have effective access.
Confirm that each permitted principal still has a genuine operational requirement.
Remove stale computer accounts and obsolete groups from the access boundary. Investigate broad groups or unexpected principals rather than assuming that their presence is harmless.
8.2 Apply least privilege to the gMSA itself
Review the account's group memberships, directory permissions, resource access, and service-specific rights.
A gMSA normally needs only the privileges required by its workload. Avoid placing it in privileged administrative groups simply to resolve application-permission problems.
Microsoft's secure gMSA guidance discusses reviewing group memberships and permissions to reduce exposure.
8.3 Protect the computers authorized to use the identity
gMSA retrieval permissions should be evaluated together with the security of the computers that hold those permissions.
Use appropriate endpoint protection, patch management, application control, administrative-access restrictions, and monitoring. Limit interactive access to service hosts where practical, and investigate unauthorized changes to the systems permitted to use sensitive identities.
A gMSA's automatic password management cannot compensate for a compromised host that is legitimately trusted to retrieve the credential.
8.4 Review Kerberos configuration and compatibility
Inventory important service identities and their Service Principal Names. Review supported encryption types and investigate unexpected legacy configurations.
Where appropriate, validate Kerberos authentication behavior in a test environment and establish whether services use the intended encryption and principal configuration.
Changes should be tested for application compatibility before production rollout.
8.5 Monitor identity and directory changes
Security teams should monitor relevant events and changes, including:
- Modifications to gMSA objects and their security descriptors.
- Changes to groups and permissions that affect password retrieval.
- Unexpected changes to service principal names.
- Suspicious authentication activity involving service identities.
- Compromise indicators on computers authorized to use gMSAs.
- Unexpected privilege assignment to service identities.
The exact Windows events, directory auditing configuration, and telemetry sources depend on the environment. Establish a baseline first, then correlate anomalous activity with endpoint and authentication evidence.
8.6 Keep sensitive test material out of logs
Managed-password blobs and derived keys should be considered sensitive credentials for assessment purposes.
Use isolated lab accounts, restrictive file permissions, redacted evidence, and approved storage. Do not retain production credential material in screenshots, general-purpose debug logs, or public repositories.
Remove temporary artifacts according to the organization's evidence-handling policy after the assessment.
9. Limitations and Responsible Research
The existence of a tool that derives an AES key does not establish that a complete authentication or privilege-escalation path is possible.
Several independent conditions affect the outcome:
- The managed-password data must be obtained through an authorized and technically valid path.
- The blob must be interpreted correctly.
- The appropriate principal and key-derivation parameters must be selected.
- The account must support the relevant authentication behavior.
- Any subsequent access must be evaluated against the actual permissions and security controls of the target environment.
A tool should not claim universal compatibility merely because it works with one sample.
Similarly, a successful key derivation should not be represented as proof of lateral movement, domain compromise, or access to a specific service unless that behavior has been separately and safely validated in the approved test environment.
For this project, the most meaningful engineering improvements include clear input validation, useful error messages, reproducible test vectors, dependency documentation, and reliable handling of sensitive input and output.
When reporting findings, document the verified result, the affected security boundary, the business impact, the conditions required for exploitation, and the recommended remediation. Avoid exposing reusable passwords or keys in the report.
10. Project Design and Future Improvements
The current project has a focused objective: process a gMSA managed-password blob and use Impacket to derive an AES-256 Kerberos key.
That narrow scope is useful because it keeps attention on the correctness of data parsing and cryptographic handling.
Further engineering work could improve its reliability and usability without expanding it into an unnecessarily large framework.
Input validation
The program should reject malformed Base64 input, empty values, and data that cannot be interpreted according to the expected structure. Errors should explain the problem without dumping sensitive data.
Reproducible tests
A controlled test suite should use synthetic or laboratory-generated inputs, known expected results, and independent verification where possible.
Tests should explicitly cover binary input handling, password encoding, invalid input, and the assumptions used for salt selection.
Clear salt handling
Because Kerberos principal and salt conventions are context-dependent, the program's documentation should clearly explain the assumptions behind any default and how users should independently verify that those assumptions apply to their test account.
Sensitive-output handling
Derived keys should not be sent to telemetry, automatically copied to shared locations, or written to persistent files without explicit user intent. Redaction and careful handling of temporary material should be treated as part of the tool's security design.
Dependency maintenance
Impacket and supporting tools should be reviewed for compatibility and security updates. Documented version constraints and repeatable lab tests can help identify unexpected behavior after dependencies change.
These are practical areas for future development, not claims that every feature is already implemented.
11. Repository and Installation Information
The project's code, requirements, usage documentation, and license information are available in the GitHub repository:
gmsa-aes-key-extractor — View the source code
The documented installation prerequisites are Python 3.8 or newer and Impacket. bloodyAD is used for the authorized directory-data retrieval stage, while proxychains is optional for environments where approved traffic needs to traverse a configured proxy.
Consult the repository's current README for the exact installation and usage instructions. Validate the dependency versions in an isolated environment before relying on the utility for a formal assessment.
Use only synthetic data or managed-password material from systems for which you have explicit authorization.
12. References and Further Reading
The following primary sources provide the technical foundation for understanding gMSAs, Kerberos, and the project dependencies.
Microsoft Learn — Secure group managed service accounts
https://learn.microsoft.com/en-us/entra/architecture/service-accounts-group-managedMicrosoft Open Specifications — MSDS-MANAGEDPASSWORD_BLOB structure
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/a9019740-3d73-46ef-a9ae-3ea8eb86ac2eMicrosoft Open Specifications — msDS-ManagedPassword
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/9cd2fc5e-7305-4fb8-b233-2a60bc3eec68Microsoft Learn — ms-DS-GroupMSAMembership attribute
https://learn.microsoft.com/en-us/windows/win32/adschema/a-msds-groupmsamembershipRFC 3962 — Advanced Encryption Standard (AES) Encryption for Kerberos 5
https://www.rfc-editor.org/rfc/rfc3962RFC 4120 — The Kerberos Network Authentication Service (V5)
https://www.rfc-editor.org/rfc/rfc4120Impacket — Kerberos cryptography implementation
https://github.com/fortra/impacket/blob/master/impacket/krb5/crypto.pybloodyAD — User Guide
https://github.com/CravateRouge/bloodyAD/wiki/User-GuideProject repository — gmsa-aes-key-extractor
https://github.com/ben-slates/gmsa-aes-key-extractor
Conclusion
Group Managed Service Accounts improve credential management in Active Directory, but they do not remove the need to secure service identities, retrieval permissions, and the computers authorized to use them.
Understanding the relationship between msDS-ManagedPassword, binary data interpretation, Kerberos principal identity, and AES key derivation helps security professionals investigate this part of the Windows authentication model more accurately.
The gmsa-aes-key-extractor project focuses on one specific technical step in that process. Its value in security research depends on correct cryptographic assumptions, reproducible testing, responsible handling of sensitive material, and an understanding of the access controls surrounding the target account.
For defenders, the broader lesson is straightforward: restrict managed-password retrieval, minimize service-account privileges, secure permitted hosts, and monitor changes to identity and authentication configuration.
Explore the project: https://github.com/ben-slates/gmsa-aes-key-extractor
This article is intended for authorized security testing, controlled laboratory research, and defensive security engineering. Any assessment should comply with written authorization, agreed scope, and applicable laws.