Authentication is the new entry point into our networks. Our users know this, and more importantly, attackers know this as well. We can no longer recommend changing passwords on a periodic basis and consider that an adequate security measure.
Additionally, merely using two-factor authentication can lead to approval fatigue where a user gets lulled into a false sense of security and approves a prompt even though it may be the attacker who is triggering the two-factor authentication prompt.
What about your MFA implementation?
Even if you have a working multifactor authentication or MFA implementation to your network or cloud resources, it’s time to reevaluate and see if you need to make further adjustments. Microsoft is tweaking their own recommendations for two-factor authentication.
In February of 2023, Microsoft will enable a new two-factor authentication methodology that is called number matching. With this method, a number is displayed to a user once they sign in and they have to confirm the exact number on the multifactor authentication device.
MFA implementation fatigue
Often when you sign in, you will receive a pop-up notification sent to your phone or to your iWatch. It’s quick and easy to approve these prompts. It’s also too easy, and attackers take advantage of our multifactor authentication notification fatigue to gain access to our systems.
Several recent intrusions into networks began when someone harvested the password and then spammed the user enough with a two-factor authentication prompt that the user accidentally and inappropriately approved the prompt. Thus, the attacker was able to gain access to the cloud resource by using the user’s (administrator) credentials and gain access as that user.
Recommendations for hardening security for MFA implementations
My recommendation is to set up groups and begin the process now to test the enforcement of two factor across your network. While Microsoft will be implementing better authentication techniques later on in early 2023, you want to be testing out these changes now. I, for one, am a fan of the geographic addition to the multifactor authentication. This gives an immediate indication of where the two-factor prompt is coming from and showcases to the end user to be aware of multifactor spamming attacks especially for your key personnel and highly sensitive accounts. Even the Cybersecurity and Infrastructure Security Agency (CISA) recommends enhancing MFA implementation techniques. They recently released guidance regarding phishing-resistant authentication.
Phishing-resistant MFA implementations
CISA recommends the gold standard, at least for now, is to deploy Phishing-resistant MFA implementation including FIDO/WebAuthn authentication and Public key infrastructure (PKI)-based. As noted in their documentation, “Separate physical tokens (called “roaming” authenticators) connected to a device via USB or near-field comms (NFC) or embedded into laptops or mobile devices as “platform” authenticators.” Tokens such as YubiKey ensure that multifactor can’t be spoofed. Implementation of tokens does take time, and it’s recommended to have more than one token as a backup.
Therefore, there is a cost and budget to consider when choosing this methodology. Furthermore, there is an issue of ease of implementation. Physical tokens demand that you remember to keep them with you, whereas for many of us, a phone is a more natural item to keep with you. Thus, you’ll need to also think about devices that help users keep tokens handy and make it easier for them to have them on hand when the need arises.
Then, you need to investigate your MFA implementation to see if the applications you wish to protect will support these enhanced multifactor implementations. Some will not support these additional tokens and instead will only rely on application tokens instead. There may also be a learning curve and implementation time. You may wish to use an application-based multi factor as a temporary measure to ensure that protection is in place and then later on deploy the token-based approach for additional protection.
Prioritizing deployments
Overall, you’ll want to prioritize deployment to key roles and cloud needs to ensure that these most
at-risk assets are protected. Prioritize the deployment to those roles and cloud applications that need the most protection. Review your risk analysis and what protections are needed based on actual threats you see in your endpoint protection and other indicators.
Using number matching
CISA has provided a white paper on using number matching-based, multi-factor authentication as additional protection to your cloud applications. As they point out, several vendors are including number matching in their two-factor implementations. While Microsoft is not mandating number-based multi-factor at this time, starting February 27, 2023, they will begin to roll out the mandate. Other vendors including Duo verified push, and Okta TOTP are just some of the vendors that are implementing these additional protection methodologies.
Administrators should periodically review the audit logs and review the failed multifactor authentications. Encourage staff to report any unusual MFA prompts they receive and have them be specific in the timing of when the events occur so that your forensic staff can review logs.
Updating defaults on Azure Active Directory
If you have not changed the defaults on Azure Active directory, your MFA implementation of the additional protections offered by the Microsoft authenticator application is set to “Microsoft managed.” That is, you are subject to their timing and roll out.
I recommend changing this to “enabled” and then choose the specific groups you want it implemented on. Having specific dates that the number matching will be enabled is a much better way to implement multifactor than relying on Microsoft. Often when you leave the timing to Microsoft, you won’t properly inform your users of the timing of the implementation. This may confuse your end users and cause more friction and frustration in your two-factor implementation.
Being mindful during migrations
Recently, I upgraded my iPhone and migrated the applications and two factor authentication applications from one phone to another. During the migration process, I became aware of how hard some of the migration paths were from an older phone to a newer one, let alone If you had plans to migrate to a different platform.
Reduce your AD attack surface.
I personally found that I had to ensure that I temporarily kept the old phone to provide me with two-factor access in order to set up the multifactor applications on the new phone. If I had immediately wiped my old phone, I would be unable to log into my applications. Thus, when deploying new iPhones, ensure that you keep the old phone for a short time in order to finalize the migration of the two-factor applications.
Ideally, you want to have the user reauthenticate their multifactor application in a trusted location and come into a physically secure location to reactivate the multifactor authentication applications. Alternatively, you can use a new feature called Temporary Access Pass that provides a short-term workaround while you plan for a long-term solution.
To do this, go to Azure AD, then to the Security option and then select “Authentication methods.” Click “Temporary Access Pass.” Be sure that the Temporary Access Pass is enabled for impacted users.
Conclusion
If you haven’t implemented multifactor authentication for your at-risk users, I highly recommend you do so immediately. But if you are like me where you have MFA implemented, it’s time to review your implementation and see if you have opportunities to enhance it. Attackers are no longer one step behind you, they are often one step ahead.
