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\u2019t know that using smartcards (in an Active Directory environment) makes privilege escalation incredibly easy.The hack I will discuss isn\u2019t new. I learned it from someone else about 15 years ago. I can\u2019t remember who, and they didn\u2019t invent it. When I show this hack, it still seems to surprise everyone, especially smartcard administrators. I\u2019m 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 \u201csubject.\u201d 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\u2026almost 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 \u201cprotected\u201d (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, \u201cThis is who I am.\u201d 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\u2019s 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\u2019s 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\u2019s Active Directory user principal name (UPN). This sort of permission is often granted to low-level admins. A user\u2019s UPN is often identical to the user\u2019s 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\u2019s 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\u2019s 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\u2019s a description of the demo I\u2019m presenting at the RSA conference:1. Verify SuperAdmin\u2019s UPN (which is represented as \u201cUser logon name\u201d 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\u2019s UPN is tied to the SuperAdmin\u2019s smartcard, including the unique digital certificate thumbprint related to SuperAdmin\u2019s smartcard. Roger GrimesSuperAdmin's smartcard UPN and digital certificate thumbprint4. Log on as SuperAdmin using SuperAdmin\u2019s smartcard and PIN. Roger GrimesSuperAdmin login5. Verify that SuperAdmin has successfully logged on using SuperAdmin\u2019s 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\u2019s smartcard information shows email@example.com UPN and HelpDesk\u2019s 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\u2019s UPN to read firstname.lastname@example.org, 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 email@example.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\u2019s thumbprint. That could be reviewed to reveal that the HelpDesk user\u2019s 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\u2019s 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\u2019s Active Directory. I can make up a new smartcard with the subject of firstname.lastname@example.org (which does not exist as a user in Active Directory), change SuperAdmin\u2019s UPN to email@example.com, login as firstname.lastname@example.org with its valid associated PIN, and Active Directory will not care that email@example.com does not exist anywhere but as the UPN under SuperAdmin\u2019s account.Smartcard lessons to be learnedLet me be clear. This isn\u2019t a Microsoft or Active Directory bug. This is an \u201cas-designed\u201d 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.