Active Directory Security: Preventing noPac Exploitation

The Criticality of Active Directory Security in Modern Cyber Defense

Active Directory (AD) stands as the bedrock of identity and access management for the vast majority of enterprise networks worldwide. Its central role in authenticating users, authorizing access to resources, and managing configurations makes it an irresistible target for adversaries. A compromised AD environment can lead to complete network takeover, data exfiltration, and significant operational disruption. In the evolving landscape of cybersecurity threats, safeguarding AD is not merely a best practice; it is a fundamental pillar of any robust cyber defense strategy.

Organizations face a constant barrage of attacks, ranging from sophisticated state-sponsored groups to financially motivated cybercriminals. Many of these attacks inevitably pivot towards compromising Active Directory once an initial foothold is established. From credential theft (T1003) to lateral movement (T1021) and privilege escalation (T1068), AD provides a fertile ground for attackers to achieve their objectives. Understanding the intricacies of AD security, staying abreast of emerging vulnerabilities, and implementing proactive threat detection and incident response measures are paramount for effective endpoint security and overall organizational resilience.

Unpacking noPac: A Deep Dive into CVE-2022-37967

The discovery of the "noPac" vulnerability (CVE-2022-37967) by several independent researchers, including SCM RedTeam and DSecurity, sent ripples through the cybersecurity community. This critical privilege escalation flaw within Active Directory Domain Services (AD DS) allowed attackers to forge a valid Kerberos Privilege Attribute Certificate (PAC) signature, effectively granting themselves administrative privileges within the domain. Its severity stems from the fact that it could be exploited by any authenticated user, regardless of their initial privileges, leading directly to domain administrator compromise.

What is noPac and How Does It Work?

At its core, noPac exploits a weakness in how Active Directory Domain Controllers (DCs) validate the integrity of the Privilege Attribute Certificate (PAC) embedded within Kerberos service tickets. The PAC is a critical component that contains authorization data, including group memberships and user rights, which the DC uses to determine a user's access levels to resources.

The attack leverages a legitimate Kerberos extension called Service for User to Self (S4U2self) and Service for User to Proxy (S4U2proxy), also known as constrained delegation. These extensions allow a service to obtain a service ticket on behalf of a user to access another service. The normal process involves the DC signing the PAC with a cryptographic key, usually the DC's own NTLM hash, to prevent tampering.

The noPac vulnerability arises from a logic error in how the DC performs this signing. Specifically, it involves the use of the older, weaker RC4-HMAC algorithm for PAC signing when it should have been using AES. Attackers could manipulate this process:

1. Impersonation Setup: An attacker, as a low-privileged user, requests a Kerberos service ticket using S4U2self for any user (including themselves or a target user) to a service account they control.
2. PAC Forgery: The DC issues a service ticket containing a PAC for the impersonated user. The critical flaw was that if the requesting service account's msDS-AllowedToDelegateTo attribute (used for constrained delegation) was configured in a specific way, the DC would sign the PAC with a keyed hash derived from the service account's own NTLM hash, using RC4-HMAC. This is where the vulnerability lies.
3. Signature Bypass: Attackers discovered that by setting specific flags in the Kerberos ticket request (e.g., KERB_NON_KERB_PRINCIPAL and KERB_FORWARDABLE), they could force the DC to issue a service ticket where the PAC signature was computed using a weak algorithm (RC4-HMAC) and a key that the attacker could predict or control. The flaw was not in RC4-HMAC itself, but how the DC was deriving the key for the PAC signature using it, effectively making the signature bypassable.
4. Admin Privilege Grant: With a bypassable PAC signature, the attacker could then craft their own PAC, injecting the Security Identifier (SID) for Domain Admins (S-1-5-21-DOMAIN-512) or other high-privileged groups, and sign it with a key they could reproduce. This forged PAC, when presented to a DC, would be validated as legitimate, granting the attacker domain administrator privileges.

This attack chain did not require any prior knowledge of valid credentials beyond the initial low-privileged user's access. The core issue was the incorrect cryptographic handling within the Kerberos authentication process, specifically related to the PAC signing algorithm choice and key derivation.

The Impact of noPac Exploitation

The potential impact of noPac exploitation is catastrophic. An attacker leveraging this vulnerability could:

• Achieve Domain Administrator Privileges: The primary outcome, leading to complete control over the Active Directory domain.
• Persistent Access: Establish backdoors, create new privileged accounts, or modify existing ones to maintain access even after initial detection and remediation efforts.
• Data Exfiltration: Access sensitive data stored on file shares, databases, and other domain-joined resources.
• Systemic Disruption: Deploy malware (e.g., ransomware, wipers), disable security controls, or disrupt critical business operations.
• Lateral Movement: Utilize domain admin privileges to move freely across the network, compromising additional systems and escalating the breach's scope.

For organizations relying on Active Directory for their entire infrastructure, a successful noPac exploit is tantamount to a total compromise, highlighting the critical importance of robust cyber defense and rapid incident response capabilities.

Exploitation Walkthrough (Conceptual)

While detailed exploitation steps are beyond the scope of this article for ethical reasons, understanding the conceptual flow is crucial for effective prevention and detection.

An attacker would typically use a tool (like a modified Kerberos client or a dedicated exploit framework) to:

1. Identify a Target Service Account: Find an existing service account (SvcAccount) in the domain with the msDS-AllowedToDelegateTo attribute set. This account will be used as a proxy for the PAC forging.
2. Request a TGS for S4U2self: As a low-privileged user (AttackerUser), request a Kerberos Ticket Granting Service (TGS) ticket for a target user (e.g., any user, or even krbtgt) to the SvcAccount using S4U2self. This initial request sets the stage.
3. Modify and Forge PAC: Intercept the generated TGS ticket, extract the PAC, and modify it to include the SID of the Domain Admins group. Then, recalculate the PAC signature using the flawed RC4-HMAC key derivation method (which the attacker can replicate).
4. Present Forged Ticket: Present this newly forged TGS ticket, containing the manipulated PAC, to a Domain Controller when requesting access to a service. The DC, due to the vulnerability, would validate the signature and grant access based on the forged PAC, effectively treating the attacker as a Domain Administrator.
5. Execute Arbitrary Commands: With domain admin privileges, the attacker can then perform actions like DCSync (T1003.006) to extract NTLM hashes for all domain users, execute commands remotely using tools like PsExec (T1021.002), or modify Group Policy Objects (GPOs) to deploy malware or establish persistence (T1484.001).

This attack underscores the need for continuous threat detection and monitoring, as well as proactive vulnerability scanning, which can be facilitated by services like Secably to identify misconfigurations or unpatched systems that could lead to such exploitation.

Detection Strategies for noPac Exploitation

Detecting noPac exploitation requires a multi-layered approach, combining network-level analysis, host-based logging, and effective endpoint detection and response (EDR) solutions. Given that the vulnerability involves manipulating Kerberos tickets, monitoring Kerberos-related events is paramount.

Network-Level Detection

Monitoring Kerberos traffic can reveal anomalous behavior. While identifying the specific PAC signature bypass might be challenging without deep packet inspection and cryptographic analysis, suspicious Kerberos ticket requests or responses can serve as strong indicators.

• Unusual S4U2self/S4U2proxy Requests: Monitor for KRB_TGS_REQ messages with specific flags or unusual principals in S4U2self/S4U2proxy requests, especially if initiated by low-privileged accounts targeting sensitive services.
• High Volume of Kerberos Errors: An attacker might trigger Kerberos errors during their attempts, which could be an indicator of suspicious activity.
• RC4-HMAC Ticket Usage Post-Patch: After patching, if RC4-HMAC tickets are still being issued in contexts where AES should be enforced, it could indicate an attempt to bypass or a misconfiguration.

Host-Based Detection (Event Logs)

Windows Event Logs are a goldmine for detecting Active Directory attacks. For noPac, key events to monitor include:

• Event ID 4769 (A Kerberos service ticket was requested): This event is critical. Look for tickets issued with Ticket Options including 0x40810000 (FORWARDABLE and NON_KERB_PRINCIPAL) or 0x60810000 (which includes PROXIABLE) that resolve to a service account with msDS-AllowedToDelegateTo attributes, especially if the Client Address is suspicious or the Client Name is a low-privileged user.
  • Specifically, post-patch, look for tickets issued with RC4-HMAC encryption (Encryption Type 0x17) where it shouldn't be, combined with specific flags.
• Event ID 4768 (A Kerberos authentication ticket (TGT) was requested): Monitor for suspicious TGT requests, especially from unprivileged accounts that suddenly request tickets with high-privilege SIDs in the PAC.
• Event ID 4624 (An account was successfully logged on): Look for logon events where a low-privileged account suddenly authenticates as a domain administrator. Pay close attention to Logon Type 3 (Network logon) or Logon Type 10 (RemoteInteractive) from unexpected sources.
• Event ID 4771 (Kerberos pre-authentication failed): While indicative of brute-force or password spraying (T1110.001), a high volume of these from a single source could also be part of an attacker's reconnaissance phase before attempting noPac.
• Event ID 5136 (A directory service object was modified): Monitor for modifications to sensitive AD objects, especially msDS-AllowedToDelegateTo attributes on service accounts, which could be a precursor to the attack.

Sigma Rule Example for noPac Indicators

A Sigma rule can help generalize these detection patterns across various SIEM solutions. This example focuses on suspicious TGS requests.

title: Potential noPac Kerberos Ticket Forgery Attempt
id: 5a8a6b7c-d0e9-4e5f-b1a2-c3d4e5f6g7h8
status: experimental
description: Detects suspicious Kerberos TGS requests that might indicate an attempt to exploit noPac (CVE-2022-37967).
author: SAFE Cyberdefense
date: 2023/10/26
references:
    - https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-37967
    - https://www.microsoft.com/security/blog/2022/10/11/cve-2022-37967-a-deep-dive-into-the-nopac-rc4-related-vulnerability-in-windows-kerberos/
logsource:
    product: windows
    service: security
detection:
    selection_event_id:
        EventID: 4769 # A Kerberos service ticket was requested.
    selection_ticket_options:
        # These options (FORWARDABLE | NON_KERB_PRINCIPAL) are suspicious when combined with other indicators
        # Note: Actual exploitation involves more specific conditions related to RC4 and PAC signing
        # This rule acts as a high-level indicator for further investigation.
        TicketOptions|contains:
            - '0x40810000' # FORWARDABLE | NON_KERB_PRINCIPAL (combined flags)
            - '0x60810000' # PROXIABLE | FORWARDABLE | NON_KERB_PRINCIPAL
    selection_encryption_type:
        # Post-patch, RC4-HMAC (0x17) tickets issued in this context are highly suspicious
        # if the domain is fully patched and configured for AES.
        EncryptionType: '0x17'
    selection_service_account:
        # If the Service Name is a service account that could be targeted for delegation abuse.
        # This part might require tuning based on your environment's known service accounts.
        # Example: ServiceName|endswith: '$' (for machine accounts often used as service principals)
        # ServiceName: '*' # Wildcard to capture all, then filter for specific SvcAccts in rule logic
    condition: selection_event_id and selection_ticket_options and selection_encryption_type
falsepositives:
    - Legitimate constrained delegation configurations that use RC4 (should be rare post-patch).
    - Other Kerberos misconfigurations.
level: high

This rule is a starting point. Real-world implementation requires tailoring to specific environments, especially regarding ServiceName and understanding what "normal" Kerberos behavior looks like post-patch. For a broader threat surface mapping and identification of exposed services that might be leveraged as initial access points for such attacks, tools like Zondex can provide invaluable insights by scanning internet-wide assets for vulnerabilities and misconfigurations.

Endpoint Detection and Response (EDR)

Modern EDR solutions are crucial for detecting the execution phase of noPac. They can monitor:

• Process Creation: Look for unusual processes being spawned by lsass.exe or other critical system processes (T1059), especially those initiating network connections or accessing sensitive files.
• PowerShell Activity: Attackers often use PowerShell (T1059.001) for reconnaissance, privilege escalation, and lateral movement post-exploitation. Look for suspicious script execution, encoded commands, or direct interaction with AD objects.
• lsass.exe Memory Dumps: Any attempt to dump the memory of lsass.exe (T1003.001) is a critical alert, as this is how attackers often extract credentials. While noPac itself doesn't require this, post-exploitation actions often do.
• Unusual Network Connections: Monitor for outbound connections from Domain Controllers to unknown external IPs or internal systems that DCs typically do not communicate with.
• File Modifications: Look for modifications to system files or creation of new suspicious files by highly privileged accounts.

Prevention Strategies for noPac Exploitation

Preventing noPac and similar Active Directory vulnerabilities requires a comprehensive strategy that encompasses patching, configuration hardening, least privilege principles, and continuous monitoring.

1. Immediate Patching and Updates

The most critical step to prevent noPac exploitation is to apply the security updates released by Microsoft. CVE-2022-37967 was addressed by Microsoft in their September 2022 Patch Tuesday release (KB5017028 for Windows Server 2022, KB5017163 for Windows Server 2019, etc.). These patches introduce a new Privilege Attribute Certificate (PAC) signature and change the key derivation for the old PAC signature to mitigate the vulnerability.

Deployment Phases: Microsoft rolled out the fix in phases, requiring administrators to transition from a "Deployment" phase to an "Enforcement" phase:

• Initial Deployment Phase (September 2022): DCs are patched but backward compatibility is maintained. DCs start logging events for non-compliant PACs (Event ID 16, 17, 18 for Kerberos-Key-Distribution-Center). This is crucial for identifying legacy systems or misconfigurations that might break when enforcement is enabled.
• Enforcement Phase (October 2022 onwards): DCs are updated to enforce the new PAC signature. Tickets with the old, vulnerable PAC signature are rejected. This phase is typically activated via a registry setting or Group Policy.

Actionable Steps: * Ensure all Domain Controllers are fully patched with the latest cumulative updates. * Monitor event logs (Event ID 16-18) during the deployment phase to identify any Kerberos-related issues before transitioning to enforcement. * Once confident that all systems are compatible, enable the enforcement mode through the registry: reg add HKLM\SYSTEM\CurrentControlSet\Services\Kdc /v PacSignatureBypassEnforcement /t REG_DWORD /d 1 /f A reboot of the DC is required for the change to take effect. * Consider deploying the fix to all member servers and workstations, as they may also process Kerberos tickets.

2. Active Directory Configuration Hardening

Beyond patching, several hardening measures can reduce the attack surface for Kerberos-related exploits:

• Restrict Constrained Delegation:

  • Review all service accounts and computer accounts configured for msDS-AllowedToDelegateTo (constrained delegation).
  • Limit delegation to only necessary services and ensure the delegating service accounts have the minimum required privileges.
  • Prefer Resource-Based Constrained Delegation (RBCD) over traditional constrained delegation where possible, as RBCD gives control to the resource owner, making it harder for an attacker to abuse.
  • Regularly audit delegated accounts.

• Disable RC4-HMAC Where Possible:

  • While the noPac fix addresses the specific PAC signature bypass, using stronger encryption algorithms (AES256_HMAC_SHA1, AES128_HMAC_SHA1) for Kerberos is a general best practice.
  • Configure Group Policy to prioritize AES:
    • Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.
    • Enable Network security: Configure encryption types allowed for Kerberos.
    • Select AES256_HMAC_SHA1, AES128_HMAC_SHA1, and potentially Future encryption types. Deselect RC4-HMAC.
  • Be cautious when doing this in older environments, as it can break compatibility with legacy systems that only support RC4. Test thoroughly.

• Implement Tiered Administration Model:

  • Separate administrative accounts and workstations into different security tiers. Domain Admin accounts should only log on from highly secured, dedicated administrative workstations (Tier 0).
  • This limits the exposure of high-privilege credentials to less secure environments.

• Strong Password Policies and Credential Hygiene:

  • Enforce strong, unique passwords for all service accounts and user accounts.
  • Implement regular password rotation.
  • Avoid using the same service account for multiple services.
  • Protect the krbtgt account hash, as it's the master key for the domain.

3. Identity and Access Management (IAM) Best Practices

Effective IAM is foundational to AD security:

• Least Privilege Principle: Grant users and service accounts only the minimum permissions required to perform their functions. Avoid granting excessive privileges like Domain Admin to non-administrative accounts.
• Just-in-Time (JIT) and Just-Enough-Administration (JEA): Implement JIT access for privileged accounts, where permissions are granted only when needed and for a limited duration. JEA restricts administrators to specific tasks.
• Multi-Factor Authentication (MFA): While not directly preventing noPac, MFA significantly enhances the security of privileged accounts, making it harder for attackers to use stolen credentials post-exploitation.
• Privileged Access Workstations (PAWs): Deploy dedicated, hardened workstations for administrative tasks to prevent credential compromise.

4. Continuous Monitoring and Threat Hunting

Even with patches and hardening, continuous monitoring is essential for identifying potential exploitation attempts or post-exploitation activities.

• SIEM Integration: Centralize Windows Event Logs, network flow data, and EDR alerts into a Security Information and Event Management (SIEM) system.
• Custom Alerting: Create custom alerts based on the detection rules outlined above (Event IDs 4769, 4768, 4624, etc.) with specific filtering for suspicious Kerberos ticket parameters.
• Behavioral Analysis: Look for deviations from baseline behavior, such as a low-privileged user suddenly accessing domain controller shares, running administrative commands, or unusual network traffic patterns.
• Regular Security Audits: Conduct periodic security audits of your Active Directory environment. This includes reviewing group memberships, delegated permissions, GPO settings, and stale accounts. Automated security testing and vulnerability scanning, like that offered by Secably, can help identify misconfigurations or unpatched systems before they are exploited.
• Threat Hunting: Proactively search for indicators of compromise (IOCs) and tactics, techniques, and procedures (TTPs) related to AD attacks, rather than waiting for alerts. Look for anomalies that might indicate initial access (T1078), privilege escalation (T1068), or credential access (T1003).

5. Network Segmentation

• Isolate critical infrastructure, including Domain Controllers, through network segmentation. This limits an attacker's ability to move laterally even if they gain a foothold in a less critical part of the network.
• Implement strict firewall rules to restrict communication to/from Domain Controllers to only necessary services and hosts.

6. Incident Response Planning

Even with the best prevention, breaches can occur. A well-defined incident response plan is crucial for minimizing damage from a noPac exploit:

• Detection and Containment: Rapidly detect exploitation, identify compromised accounts and systems, and isolate them to prevent further spread.
• Eradication and Recovery: Remove malicious artifacts, restore systems from clean backups, and reset compromised credentials.
• Post-Incident Analysis: Conduct a thorough root cause analysis to understand how the compromise occurred and refine prevention strategies.

By implementing these comprehensive cyber defense measures, organizations can significantly reduce their exposure to vulnerabilities like noPac and bolster their overall endpoint security posture. Furthermore, understanding your external attack surface is key to preventing initial compromise; services like Zondex can help identify internet-facing assets and misconfigurations that might lead to an attacker gaining initial access to your network, which could then be leveraged for AD attacks.

Key Takeaways

Active Directory remains the crown jewel for attackers, and vulnerabilities like noPac underscore the continuous need for vigilance and robust security practices. Protecting AD is an ongoing process that demands a multi-faceted approach.

1. Patch Immediately and Fully: Ensure all Domain Controllers and critical systems are updated with the latest security patches addressing CVE-2022-37967. Transition to the enforcement phase after careful testing.
2. Harden Active Directory Configurations:
   • Strictly limit and audit constrained delegation, preferring Resource-Based Constrained Delegation (RBCD).
   • Prioritize AES encryption for Kerberos, disabling RC4-HMAC where possible and compatible.
   • Implement strong password policies and regularly audit service accounts.
3. Embrace Least Privilege: Grant only necessary permissions to users and service accounts. Utilize Just-in-Time (JIT) and Just-Enough-Administration (JEA) for privileged access.
4. Enhance Monitoring and Detection:
   • Centralize logs in a SIEM and implement specific detection rules for Kerberos events (Event IDs 4769, 4768, 4624) that indicate suspicious activity.
   • Leverage EDR solutions for behavioral analysis, process monitoring, and detection of post-exploitation techniques (e.g., lsass.exe access, PowerShell abuse).
   • Regularly perform threat hunting for AD-specific TTPs (MITRE ATT&CK T1558.003, T1078.002, T1068).
5. Segment Your Network: Isolate Domain Controllers and other critical infrastructure to limit lateral movement potential.
6. Conduct Regular Security Audits: Continuously assess your AD environment for misconfigurations, weak points, and compliance with security baselines. Tools like Secably can automate this process.
7. Have a Robust Incident Response Plan: Prepare for the inevitable. A well-rehearsed incident response plan is vital for rapid detection, containment, eradication, and recovery from AD compromises.