Hardening Identities with Phish-Resistant MFA

istock 1164312110
istock/Nicola Katie

By Steve Faehl, Microsoft Federal Security CTO

Ask any cybersecurity professional what one thing should be done to increase the security of your environment and the most likely answer will be to “enable MFA.” For many years, multi-factor authentication has been a key approach to mitigating the risks associated with password usage. As utilization of MFA has increased, cybercriminals have had to adapt tactics for credential theft to compromise their intended targets.

On January 26, 2022, the Office of the Management and Budget (OMB) issued a memo, M-22-09 “Moving the U.S. Government Towards Zero Trust Cybersecurity Principles,” that has made significant progress raising awareness about the need for phish resistance in combination with MFA usage. The memo recommends that federal agencies move to passwordless MFA in an effort to modernize their authentication systems. While this memo is only directed towards federal agencies, the US Government’s intent as prescribed in President Biden’s Cyber Executive Order is to lead by example in raising the cybersecurity baseline and private sector organizations should also take notice. This article will explore the new tactics being employed and ways security teams can harden their identities utilizing many built-in security options already at their disposal. 

Pursuing Zero Trust

As digital transformation has helped organizations improve their value chains, it has also increased the value and criticality of digital systems that have enabled them to thrive. As a result, cyber-attacks on high-value digital assets have also become more prevalent. Zero trust is a strategy for security transformation that has emerged as an essential approach to securing the benefits of digital transformation.

In Microsoft’s 2021 Zero Trust Adoption Report, we found that at least 76% of organizations have at least started implementing their Zero Trust strategy. MFA features prominently in most organizations’ Zero Trust strategies, as having strong authentication for users is essential with identity not only being a pillar of Zero Trust in its own right, but serving as a key point of connection for the other pillars when creating Zero Trust policies.

As NIST states in SP 800-207, “If it were not for subjects requesting access to enterprise resources, there would be no need to create access policies.” NIST also states that “Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established.” As several new attack techniques have shown, all MFA approaches are not equal and extending an MFA strategy to include assurance of device identity as NIST recommends leads to more authentication confidence than multiple user identity factors alone can provide. Checking the box with a weak MFA configuration without pursuing a holistic Zero Trust approach to authentication can result in some blind spots that still leave organizations open to novel phishing attacks.

Examples of limitations of some MFA approaches

For the longest time, we’ve preached about creating strong passwords to reduce the risk of brute force attacks. As a result, most people can’t remember all of the complex passwords they have and end up recycling them across multiple accounts. Password reuse is a huge problem — in fact, the average person reuses their password 14 times and they often use the same password across both personal and organizational accounts. This creates a blind spot where an organizational account can be compromised by a phishing attack on a personal account – completely out of scope of the organization’s email protection capabilities.

Man-in-the-middle (MITM) phishing, SMS hijacking, and email hijacking are three attack methods that are increasing in frequency as cybercriminals look for ways to bypass weak MFA configurations. In a MITM attack, adversaries exploit second factors with out-of-band authentication paths such as app notification, email, or SMS. The user initiates a password authentication request that is intercepted by the adversary who creates a separate authentication request and accompanying out-of-band second-factor prompt that the user then approves since it is indistinguishable from their own. In an SMS hijacking attack the adversary redirects the SMS notification destination to their own device and then initiates an authentication request that can be approved without the knowledge of the user. In an email hijacking attack an adversary can use a compromised email mailbox to approve email-based second factors. Since email is also often used as a path for recovery of credentials to non-SSO services, a compromised mailbox can also lead to the compromise of a long chain of dependent services through third-party password resets.

Another possible blind spot is with phishing attacks that use illicit consent grants which can be much more difficult to detect than a traditional phishing attack. In a consent grant attack, an adversary tricks an end user into granting a malicious application consent to access their data on their behalf, usually via an email with a link. The link destination itself is not malicious as it is an OAuth grant to a legitimate service, it is only the application that is the subject of the grant that is malicious making effective link detonation/reputation challenging. After the malicious application has been granted consent, it uses application-level access to data without the need for the user’s credential. Unfortunately, typical mitigation steps like requiring MFA or resetting passwords for breached accounts for users are not effective against this type of attack since the attack takes place downstream of authentication and uses third-party applications external to the organization. In this type of attack, the adversary creates their own persistent access path outside of the organization.

How organizations can utilize phish-resistant authentication

For starters, organizations should seek to utilize solutions that they already have to the maximum extent possible. Having stronger means of authentication and more modern options such as FIDO2 and Windows Hello for Business available doesn’t mean organizations can roll them out overnight, so in most cases, it makes sense to continue down the path of ensuring that MFA is utilized everywhere. For example, government agencies can expand usage of personal identity verification (PIV) or common access cards (CAC) they already have to cover more applications and scenarios while reducing their identity attack surface area by using cloud-native certificate-based authentication (CBA). Likewise, organizations already using Microsoft Authenticator for MFA can layer in Conditional Access policies requiring usage of an organizational device to mitigate external phishing scenarios.

Here are some built-in Microsoft capabilities that can be used to improve phish resistance:

  • Azure AD Certificate-Based Authentication (CBA) Building on Azure AD cloud-native SSO, this recently introduced feature allows customers to use a high assurance authentication method while reducing the attack surface of their authentication infrastructure. This feature also reduces costs and complexity, enabling customers to configure their Azure AD tenants to allow or require users to authenticate with X.509 certificates verified against their Enterprise Public Key Infrastructure (PKI) for app and browser sign-in. Using an X.509 certificate instead of entering a password at sign-in provides a well-established path for phish-resistant authentication
  • Passwordless Authenticator App, Windows Hello for Business, and FIDO2 – Passwords are still a factor in many MFA implementations but the passwordless approach is gaining steam. The Microsoft Authenticator app can be used to sign in to any Azure AD account without using a password. Microsoft Authenticator uses key-based authentication to enable a user credential that is tied to a device, where the device uses a PIN or biometric. Windows Hello for Business uses a similar technology, replacing passwords with strong two-factor authentication on devices. Azure AD also supports the FIDO2 standard which provides in-band passwordless and phish-resistant capabilities through the use of security keys. As a member of the FIDO alliance, Microsoft partners closely on development of these capabilities and is committed to expanded support for this passwordless option.
  • Azure AD Conditional Access These policies built-in to Azure AD help to manage authentication profiles centrally and define how authentication takes place within an organization. Evolving authentication and authorization into more granular assessments of “known / trusted / allowed” provides opportunities for assigning risk tiers and the types of authentication and trust attributes required for low, medium, or high-risk applications. Requiring authentication requests to come from a managed device through a conditional access policy is a simple way improve existing defenses and provide phish-resistance mitigation for external threats.
  • Microsoft Defender for Cloud Apps When it comes to blocking and detecting illicit consent grant attacks (also known as OAuth attacks), end users should not be implicitly trusted to decide which apps are safe to use. At a minimum, security teams should set OAuth app permission policies to prevent grants to uncommon applications and to monitor for anomalous usage for OAuth apps connecting to Microsoft 365, Google Workspace, and Salesforce. The Microsoft 365 compliance program also helps to verify third-party apps and put them on a known good list pre-loaded for admins.
  • Microsoft Defender for Endpoint and Microsoft Intune – When utilized on Intune-enrolled devices, integration of Defender for Endpoint signal provides insights into device threat levels for use in Azure AD conditional access policies. If a device is compromised, the tokens acquired on those devices should no longer be considered trustworthy and new authentication requests should not be approved. This feature not only layers on additional protection beyond phish resistance but also meets the M-22-09 requirement for one device-level signal to be present in user authentication. One of the key benefits of using the Microsoft platform is the ability to natively aggregate risk levels of endpoints, users, and apps into a single authorization decision with continuous monitoring that extends beyond a point-in-time authentication request.

Phish resistance is an important objective that should be combined with objectives to maximize authentication strength, go passwordless by removing the user’s password as a factor, provide authentication options with broad applicability covering desktop and mobile scenarios, and assess device identity and health status prior to authorization. When designing a modern and phish-resistant authentication strategy, Identity and Security Architects should rely on Zero Trust principles to define an implementation roadmap that addresses all points in the authentication chain with a layered defense. Take steps to harden the authentication infrastructure itself, apply identity protection to users, identify and monitor applications for illicit grants, and identify devices explicitly during authentication while continually monitoring them after authorization as they use access tokens.

For Microsoft guidance on meeting the requirements of OMB M-22-09, please visit us here.

To learn more about Microsoft’s offerings to protect identities above and beyond typical MFA, please visit us here.

Related:

Copyright © 2022 IDG Communications, Inc.