Using smartcards in a Microsoft Active Directory environment makes them vulnerable to this privilege escalation attack. Credit: Getty Images I can change an email address and steal your most privileged credentials.One of the most consistent IT security best practice recommendations is to require that admins use multi-factor authentication (MFA). In many corporate environments, this means using smartcards. Most smartcard environments don’t know that using smartcards (in an Active Directory environment) makes privilege escalation incredibly easy.The hack I will discuss isn’t new. I learned it from someone else about 15 years ago. I can’t remember who, and they didn’t invent it. When I show this hack, it still seems to surprise everyone, especially smartcard administrators. I’m showing this smartcard hack demo for the first time here and as part of my RSA 2019 12 Ways to Hack MFA presentation on March 8.Multi-factor authentication basicsEvery MFA solution is tied to a specific “subject.” The subject is an identifier for a particular identity. The identity can be a random label, a name, email address, LDAP address, DNS address, IP address…almost anything as long as it is unique in a particular namespace (e.g., DNS, Active Directory, LDAP directory or authentication database). Multiple instances of an authentication device can have the same subject label, but the subject name must be unique in the namespace. In most cases, the authentication device is tied, often cryptographically, to the subject label it is representing. For example, when a digital certificate is created, many of the included fields are cryptographically “protected” (meaning verifiable) to the private and public entity that makes the digital certificate. Changing the subject name would immediately render the digital certificate invalid. This makes sense, because the user providing the authentication device is saying, “This is who I am.” Then providing a password, PIN or biometric attribute proves they own the subject attested to by the authentication device.Proof of owning the submitted subject/identity successfully authenticates you. The authenticated identity is then usually associated with a subject-specific access control cookie or token. This token can then be presented to the access control checking components of the (operating) system when the identity tries to access protected information. The cookie or token is associated with the assigned permissions, privileges and other authorization attributes (such as group membership). If a hacker can take control of a subject’s access control cookie or token, they are usually treated as if they are the real user/subject. The (operating) system often has no way of knowing whether the subject presenting the access control cookie or token really is the legitimate user. It takes any submitted access control cookie or token as valid and being used correctly by the previously validated user.How a subject hijack attack worksIt’s important to understand the significance of the subject label to the overall authentication process to understand this class of hack. The overall hack can be summarized like this: If I can steal the subject label attached to your authentication method, I might be able to steal your identity even if you use otherwise very secure and trusted MFA.As a demonstration, let me show you an example involving Active Directory and AD-integrated smartcards. Tens of millions of Active Directory users and admins secure their logons using this configuration. In this particular hack demo, the attacker is a low-privileged valid user (named HelpDesk). The target of the identity theft attack is a highly privileged user (named SuperAdmin) who belongs to every elevated group in Active Directory (schema admins, enterprise admins and domain admins).The only elevated privilege HelpDesk has beyond a regular user is the ability to change a user’s Active Directory user principal name (UPN). This sort of permission is often granted to low-level admins. A user’s UPN is often identical to the user’s email address, although they do not have to be. The only requirement for the UPN is that it is unique within the same Active Directory forest.Here’s a summary of the hack:Low-privileged HelpDesk admin switches UPNs with SuperAdminHelpDesk admin logs in using their own HelpDesk smartcard and PINViola! HelpDesk admin becomes SuperAdmin, including all group membershipsHelpDesk performs malicious actionsSystem tracks all actions as SuperAdminWhen HelpDesk is finished, they log out and switch UPNs back. No one knows the differenceAsk yourself how many people in your Active Directory environment have the ability to change a user’s UPN. Would your event logging system detect and alert on a UPN change? My guess is no for most environments. Step-by-step smartcard hack demoHere’s a description of the demo I’m presenting at the RSA conference:1. Verify SuperAdmin’s UPN (which is represented as “User logon name” in Active Directory). Roger GrimesSuperAdmin’s UPN is “SuperAdmin”2. Verify that SuperAdmin belongs to elevated groups. Roger GrimesElevated groups to which SuperAdmin belongs3. Verify that SuperAdmin’s UPN is tied to the SuperAdmin’s smartcard, including the unique digital certificate thumbprint related to SuperAdmin’s smartcard. Roger GrimesSuperAdmin’s smartcard UPN and digital certificate thumbprint4. Log on as SuperAdmin using SuperAdmin’s smartcard and PIN. Roger GrimesSuperAdmin login5. Verify that SuperAdmin has successfully logged on using SuperAdmin’s smartcard and PIN. Roger GrimesRunning the Whoami command verifies SuperAdmin logged in as “SuperAdmin”6. Verify SuperAdmin has elevated group memberships. Roger GrimesWhoami /groups verifies SuperAdmin’s elevated groups7. The less privileged HelpDesk user logs on using their own smartcard and PIN (before the hack is accomplished to show current state). Roger GrimesHelpDesk user login8. HelpDesk’s smartcard information shows helpdesk@victim.com UPN and HelpDesk’s unique digital certificate thumbprint. Roger GrimesHelpDesk’s smartcard UPN and digital certificate thumbprint Roger GrimesWhoami shows HelpDesk logged onto victim.com domain Roger GrimesWhoami /groups shows lower-privilege groups HelpDesk belongs to9. The lower-privileged HelpDesk user swaps its UPN with the SuperAdmin user using Active Directory Users and Computers. To do this, the HelpDesk user must first change to their UPN with any other value because Active Directory will not let two accounts share the same UPN at the same time.10. The HelpDesk user updates the SuperAdmin’s UPN to read helpdesk@victim.com, to be the same as the UPN it holds on its own smartcard. Roger GrimesHelpDesk changes its UPN and updates the SuperAdmin UPN to the UPN stored and validated on the HelpDesk smartcard11. The HelpDesk User logs out, waits a few minutes for Active Directory replication to occur, and then logs backs in. Roger GrimesHelpDesk logs back in using its validated smartcard and UPN Roger GrimesDetails of HelpDesk smartcard used to log back in to verify that only HelpDesk smartcard and PIN are being used12. Although the HelpDesk user logged on using their associated HelpDesk smartcard and PIN, Active Directory has now associated them with the SuperAdmin user because SuperAdmin now has the helpdesk@victim.com Roger GrimesRoger GrimesWhoami verifies that Active Directory now sees HelpDesk as SuperAdmin Roger GrimesWhoami /groups shows that HelpDesk now has group memberships of SuperAdminAt this point, the HelpDesk user can do anything SuperAdmin could currently do, and Microsoft Windows and Active Directory would track all Windows events as if they were occurring from SuperAdmin, not HelpDesk. After committing other unauthorized actions, such as confirming they can always elevate their security credentials, the HelpDesk user could swap back the UPNs, and unless UPN updates are being logged and the importance of those particular actions were noticed, it would be difficult to see what actually happened.Some logon events are registered at the domain controllers, such as Event ID 4768, which would include each supplied smartcard’s thumbprint. That could be reviewed to reveal that the HelpDesk user’s smartcard was now somehow associated with the SuperAdmin account, but forensics investigators would have to be aware of and seek to validate this particular hack scenario. It would not be easy to discover when trying to discuss what really happened.Interesting hack, yes?You might say that the attack requiring a previously validated user account that can change another user’s UPN is a high starting bar, and I agree. This is just a representative example of the possible outcome of a subject hijack attack. Other similar attacks using other solutions might not have as high prerequisites.Even in this Active Directory hack type, I can use any other valid and trusted smartcard identity, even if that identity does not exist in the victim’s Active Directory. I can make up a new smartcard with the subject of frog@victim.com (which does not exist as a user in Active Directory), change SuperAdmin’s UPN to frog@victim.com, login as frog@victim.com with its valid associated PIN, and Active Directory will not care that frog@victim.com does not exist anywhere but as the UPN under SuperAdmin’s account.Smartcard lessons to be learnedLet me be clear. This isn’t a Microsoft or Active Directory bug. This is an “as-designed” operation of smartcards. No fix is coming. If you allow the subject of a smartcard to be hijacked, you can expect this sort of mischievousness to occur. Similar attacks are likely to be executed against other MFA solutions if the subject can be hijacked.The lesson is that any attribute that is used in an authentication consideration should be treated like a password. We obviously have all sorts of logging and protection surrounding preventing passwords from being viewed or stolen, but not around all the other authentication attributes, and there should be. Related content feature Top cybersecurity M&A deals for 2023 Fears of recession, rising interest rates, mass tech layoffs, and conservative spending trends are likely to make dealmakers cautious, but an ever-increasing need to defend against bigger and faster attacks will likely keep M&A activity steady in By CSO Staff Sep 22, 2023 24 mins Mergers and Acquisitions Mergers and Acquisitions Mergers and Acquisitions brandpost Unmasking ransomware threat clusters: Why it matters to defenders Similar patterns of behavior among ransomware treat groups can help security teams better understand and prepare for attacks By Joan Goodchild Sep 21, 2023 3 mins Cybercrime news analysis China’s offensive cyber operations support “soft power” agenda in Africa Researchers track Chinese cyber espionage intrusions targeting African industrial sectors. By Michael Hill Sep 21, 2023 5 mins Advanced Persistent Threats Cyberattacks Critical Infrastructure brandpost Proactive OT security requires visibility + prevention You cannot protect your operation by simply watching and waiting. It is essential to have a defense-in-depth approach. By Austen Byers Sep 21, 2023 4 mins Security Podcasts Videos Resources Events SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe