Full Report
Introduction Recently, I encountered a fully password-less environment. Every employee in this company had their own smart card that they used to login into their computers, emails, internal applications and more. None of the employees at the company had a password at all – this sounded really cool. In this post I will detail a technique used to impersonate other users by modifying a User Principal Name (UPN) on an Active Directory domain that only uses smart cards.
Analysis Summary
# Tool/Technique: UPN Modification for Smart Card Impersonation
## Overview
This technique leverages how Active Directory correlates smart card authentication with user accounts by matching the certificate's Subject Alternative Name (SAN) to the User Principal Name (UPN) of an AD user object. By swapping UPNs between an attacker's user account (associated with their legitimate smart card) and a victim's user account, the attacker can successfully log in to resources using their smart card, but authenticate as the victim user.
## Technical Details
- Type: Technique
- Platform: Active Directory / Windows
- Capabilities: User impersonation, unauthorized access via certificate authentication redirection.
- First Seen: The article references an attack avenue mentioned in a KnowBe4 paper by Roger A. Grimes, suggesting the concept is not entirely new, although the post details its application in a specific smart card-only environment. (Specific initial discovery date unknown).
## MITRE ATT&CK Mapping
- T1098 - Account Manipulation: Account Modification
- T1098.003 - Change UPN Suffix
- **Note:** While the direct impact is Impersonation, the core action is modifying an AD attribute (UPN).
- T1557 - Adversary-in-the-Middle
- T1557.001 - Man-in-the-Middle: Active MITM (Implicitly, by presenting credentials/certificate that are validated against the wrong identity based on the manipulated metadata)
- T1078 - Valid Accounts
- T1078.004 - Cloud Accounts (While focused on on-prem AD, the underlying authentication path can lead to access to federated services)
## Functionality
### Core Capabilities
- **Impersonation via UPN Swap:** An attacker modifies their own AD user account UPN to a non-conflicting value, and then changes the victim user's UPN to match the SAN value found in the attacker's smart card certificate.
- **Authentication Redirection:** When the attacker logs in using their smart card, the Domain Controller matches the certificate SAN (now matching the victim's UPN) and returns the victim's security context details, granting the attacker access as the victim.
### Advanced Features
- **Password-less Environment Abuse:** This technique specifically targets environments where standard password-based attacks are impossible due to the mandatory use of smart cards, forcing reliance on the certificate correlation mechanism.
- **Temporary Modification:** The UPN attribute of the victim is restored after the attacker logs in to allow the legitimate user to resume normal authentication.
## Indicators of Compromise
- File Hashes: N/A (This is a configuration/attribute manipulation technique, not a specific piece of malware.)
- File Names: N/A
- Registry Keys: N/A
- Network Indicators: N/A (Authentication relies on legitimate Kerberos/NTLM exchange flow after certificate validation.)
- Behavioral Indicators:
- Sudden, unauthorized modification of the `userPrincipalName` attribute on Active Directory user objects (Event ID 4738: A user account was changed).
- Successful logon events (Event ID 4624) using a user account associated with a smart card whose associated proxy credentials (NTLM hash if queried) do not correlate with the user's known principal (as defined by the UPN/sAMAccountName combination *before* the swap).
## Associated Threat Actors
- Not explicitly attributed to a named APT group in the context provided; however, manipulation of Active Directory configuration attributes suggests an adversary with sufficient privileges (e.g., Domain Admins or delegated users) or one who has successfully exploited privilege escalation for configuration management. The technique is generally attributed to penetration testers or malicious insiders.
## Detection Methods
- Signature-based detection: N/A (No unique binary signature)
- Behavioral detection: Monitor for **AD attribute changes**, specifically modifications to the `userPrincipalName` attribute on target user objects.
- YARA rules if available: N/A
## Mitigation Strategies
- **Monitoring:** Actively monitor and immediately verify changes to **Event ID 4738** (A user account was changed), focusing on the `userPrincipalName` attribute.
- **Least Privilege:** Review and aggressively restrict which users/groups have the Write/Modify permission over critical attributes like UPN on high-value user accounts. Only necessary service accounts or IT administrators should have this permission.
- **Sensitive Attribute Handling:** Treat the UPN and Service Principal Name (SPN) attributes as sensitive values, similar to passwords, requiring strict audit and control over modifications.
- **Verification Policy:** If UPN changes occur, establish procedures to immediately verify the legitimacy of the change with the user or system owner.
## Related Tools/Techniques
- Tools used for Attribute Modification: `dsmod` (mentioned in the article for performing the modification), potentially PowerShell cmdlets (e.g., `Set-ADUser -Identity <Target> -UserPrincipalName <NewUPN>`), or graphical tools like **AD Users and Computers (dsa.msc)** or **AD Administrative Center (dsacls)**.
- General AD manipulation frameworks (e.g., BloodHound) can be used to discover users with permissions to change UPNs.