Microsoft Blog for MSPs and IT Pros

Security

The strongest form of MFA? | Why your MFA may need an upgrade

Bymsp4msps

May 27, 2024 , , ,

MFA methods have evolved greatly over the years to accommodate shifts in the attack surface as well as new attack methods. In this article, I wanted to cover the evolution of MFA and highlight how different types of MFA can still leave your users exposed. This includes common attack methods and how to overcome them with authentication strengths in the Entra portal.

Evolution of MFA

Passwords

I won’t spend long on how NOT leveraging MFA leaves you incredibly exposed the most common phishing attempts but I still talk to many MSPs who do not have MFA coverage across their customers. Passwords have always had common flaws:
  • They are usually weak or easily crackable
  • They are not unique
  • They are stored insecurely
Many people tried to overcome this by leveraging a password manager which eliminated most of the concerns from the bullets above. What we also have to consider though is the following:
  • 3rd party databases get breached all the time and passwords are exposed. We have an extension of exposure to all of the vendors that don’t integration to our IDP (i.e. Entra)
  • Password Managers have been breached (Last Pass)
  • Users can easily be breached via phishing attempts
OTP/TOTP

One-Time passcodes and time-based passcodes were introduced that added MFA to our accounts. Some of the most common methods today are:
  • SMS/Phone
  • Email
  • Software Tokens/Push Notifications
It still blows my mind that some of the applications that contain very sensitive information (i.e. My bank account company, my credit card company) still use weaker forms of MFA such as an SMS text. These methods are still subject to having the data being intercepted as well as common attacks such as SIM swapping. Here are some of the common ways these methods are breached:
  • SMS/Phone
    • SIM Swapping
    • Social Engineering
    • Lost/Stolen devices
  • Email
    • Often, the 3rd party email we set up here to get the OTP does not have MFA enabled. (i.e. a personal Gmail account that gets added as the 2nd factor to our Microsoft account)
  • Software Tokens/Push Notifications
    • Social Engineering
    • MFA fatigue on Push notifications

While I would consider these to be weaker forms of MFA, they are still better than nothing. Remember that having any form of MFA will prevent over 90+% of the common attacks out there today.

Authenticator + Number Matching

Microsoft introduced number matching on the authenticator app to prevent MFA fatigue. While it does do a great job of preventing that type of attack it is still not considered phishing resistant given the user could still be subject to social engineering where they end up providing consent the request from someone tricking them over the phone with the number that the attack sees on their screen.
 
As we also saw from the Evilginx framework, users could still also be compromised by this Adversary in the middle (or man-in-the-middle) attack that allowed an attack to steal users credentials and session token to bypass MFA.
FIDO/FIDO2 => Passkeys

FIDO authentication has been around for a while now but has evolved over time. Instead of passwords FIDO authentication relies on passkeys which are cryptographic credentials securely stored on a user’s device. These passkeys provide a seamless way to authenticate users on websites and services. When FIDO1 was introduced, the primary second factor was a security key like a FOB that a user leveraged to plug into their device. On passkey-enabled websites, users don’t need to manually “enter” anything to sign in. Instead, they can simply present a biometric (like a fingerprint or face recognition) or use a hardware key to log in with their passkey. Behind the scenes, a cryptographic exchange takes place to verify the user’s identity, but the user doesn’t see any of this going on or things like their private key on their device. Windows hello is a form of a passkey that users can leverage. Yubikeys have become the most popular security key to use as well.

Passkeys are considered phishing resistant because of a variety of factors including:
  • They are passwordless
  • They require device-bound context meaning the user has to perform some gesture on the device where the passkey is located. (i.e. their laptop, authenticator app, yubikey, etc.). This includes faceID, thumbprint, pin, etc.
  • When registered, they include a “Registered Provider” or “origin” which can overcome fake or fictitious websites
    • If we look at this in the context of the Evilginx framework, users are directed to login as some website disguised as Microsoft. This could have the url of: login.microsoftonlline.com (it is subtle but I have to L’s in the “online” portion of that url)
    • When a passkey is established for Microsoft it will be registered with the origin of login.microsoft.com
Example of passkey on Windows 11:
  • Even if the user clicked on a malicious link bringing them to the fake website, the passkey would recognize the illegitimate website and not allow them to sign in, thus being phishing resistant.
Setting up Passkeys on Authenticator

Recently this year, Microsoft introduced support for Passkeys on your Authenticator app for both iOS and Android. This allows you to establish a passkey so that you can perform cross-device sign-ins which is a very cool feature supported by FIDO2. This means that you can sign into multiple devices, “roaming” with your mobile device acting as the source of truth.

 

Follow these steps to set this up in the Authentication Methods settings in Entra:

Passkeys => Thinking about the end-user impact
If users struggle with the Authenticator app, are they going to be capable of setting up passkeys? On one hand, they no longer need to keep up with passwords as this is a passwordless solution but setting this up also requires extra steps on their part. Here are some things to keep in mind:
  • Users will need to set up Passkeys in the “My Security Info Page”

If a user does not follow the instructions correctly, they could store the passkey on their keychain on iOS instead of authenticator:

If passkeys with authenticator are the only 2nd factor you enable through conditional access, users will get prompted to scan a QR code when signing in:

If you are enforcing Passkeys for all users, net new users who need to register will need a Temporary Access Pass to login to the security page where they can then add the Passkey.

NOTE: If you do not already have Temporary Access Pass enabled, you will want to let this propagate around 8 hours before attempting to use that to sign in with a user that does not have MFA set up yet and register for a passkey. In my experience, I got weird error messages and stuck in an infinite loop of hell before I just waiting for Microsoft to propagate (classic)

If a user loses their mobile device or gets a new one, they will need another Temporary Access Pass to re-establish a new Passkey. This is an easily flow in my opinion than if they lost their Yubikey.

Pass-the-Cookie Attack Considerations

Pass-the-cookie attack involves a malicious compromise of a users device where an attacker can harvest the session cookie from a users browser and leverage it to garner an authenticated session on their device. It requires no login or MFA prompt. This attack would still bypass passkeys as well. Microsoft has come out with a conditional access policies setting for token protection that would help to alleviate token based attacks which is bound to a users device. Learn more: Token protection in Microsoft Entra Conditional Access – Microsoft Entra ID | Microsoft Learn

They do state though that while this is in preview ” This preview doesn’t currently support access tokens or web cookies.”
So we cannot yet have further protections here by combining CAP with Passkeys but hopefully this is coming. Keep in mind though that with the pass-the-cookie attack, you really have this exposure from devices with active malware. There are steps you can take to help prevent this:
  • Ensure that users are not signing in from personal devices where your security protection are not in place
    • Pass-the-cookie attacks often use mimikatz which can be discovered and blocked by Microsoft Defender and other EDR/AV vendors
  • Have Safe Links and Safe attachments policies in place to help protect users in email/documents
  • You can leverage Strict location continuous access evaluation controls in conditional access policies to prevent this attack as well

Full Demo

Share with the Community
        

By msp4msps

Related Post

Security

My top policies for securing device registration in Microsoft 365

Nov 14, 2024 msp4msps
Security

Require managed devices in Microsoft 365

Nov 11, 2024 msp4msps
Security

Customer needs personal device access for Microsoft 365 | Secure Options

Nov 4, 2024 msp4msps