MFA (Multi-Factor-Authentication) requires not just one factor (e.g. a password) but two – or even several – factors for user authentication. Common examples are OTP (One Time Passwords) generated by a token, or smart cards. Generally, we speak of authentication in two forms:
- Password: Something I know
- Smart card / token: Something I own
This combination generally makes authentication processes more secure because it is less likely that someone would obtain both a password and a (physical) hardware token. Side note: How MFA leaves the “login” itself open to attacks (especially with regard to the resulting session) is described in this article by Roger Grimes: 11 ways to hack 2FA
Assume the following IT landscape:
- There is a helpdesk agent (DOMAIN\agent-helpdesk with UPN firstname.lastname@example.org) responsible for handling user objects in the Active Directory, for which he has the relevant access rights. However, these rights are limited to certain OUs. Our agent is not the domain admin.
- Then, there is an administrator (DOMAIN\adm-domain with UPN email@example.com), who is responsible for managing all global aspects of the Active Directory. Therefore, he is the domain admin.
To increase security, 2FA has been implemented, with smart cards. The smart cards (and keys) are assigned using the user UPNs. The helpdesk agent now proceeds as follows:
- He changes his own UPN to firstname.lastname@example.org. He can do this because he has the rights to administer user objects in the Active Directory, which sometimes requires UPNs to be changed, for instance when somebody gets married or divorced. It is a simple routine task.
- He then changes the admin’s UPN to email@example.com.
- He then restarts his workstation and logs back on with his user name and password. He inserts his own smart card, which is assigned to the admin account because of the UPN. The login is now done using the administrator account and the user has rights as domain admin.
- This means our agent could now perform malicious operations as domain admin and then just change both UPNs back.
This type of attack often goes unnoticed, because:
- All malicious operations are performed under the user name “adm-domain” and there are no traces leading back to the attacker.
- Since the UPN change is a routine activity, it will most likely go unnoticed in the logs.
- The procedure does not require any password changes or additional group memberships. These would be noticed in the logs and trigger an alert.
Ideas for Improvement
What can you do to avoid such attacks? The following measures will immediately lower the risk of an attack as outlined above:
- Always be aware of logs of important attributes like UPNs for all admin accounts.
- Save admin accounts in OUs where helpdesk staff do not have modification rights.
Limit Management Rights
In order to prevent scenarios like the one described above – or other possible attack patterns aimed to increase admin privileges – it is advisable to only allow a very small group of people (e.g. power admins) to directly manage AD objects. Helpdesk, user services and other similar teams should only be given very limited rights and possibilities to change users, groups and computer accounts in the Active Directory. With tenfold, you can set admin rights granularly and apply more restrictions than you could when setting them directly in the Active Directory. Many of the settings can constitute the company’s best practices. tenfold automatically forces these settings and thus leaves helpdesk staff no room for following their own agenda, which is key to increasing IT security.