Multi-factor authentication: Not always the silver bullet

Multi-factor authentication (MFA) is one of the best cybersecurity controls all organisations can implement to prevent breaches, regardless of size, industry and budget. As veteran incident responders, we have reflected upon many an instance where a breach likely could have been prevented if MFA had been in place. However, we are often also asked by breached clients “How did we get breached even with MFA in place?”. Unfortunately, MFA suffers from a number of human and technical weaknesses which means that organisations should not just assume it’s a silver bullet.

Recap on Multi-factor authentication (MFA)

For modern organisations, the importance of MFA cannot be overstated. It should form a crucial element of any defence-in-depth design by protecting against remote access to networks or against access to sensitive emails and communications. McGrathNicol has responded to numerous incidents in the last 12 months, where the root cause is ultimately failed to protect user access with MFA.

The foundation of MFA is that it requires a combination of two or more of the following factors to authenticate a user. Logging on with just a username and password does not count as MFA.

• What you know – e.g. a password.

• What you have – e.g. a user’s mobile number, a software token authenticator (e.g. Google Authenticator, Microsoft Authenticator), hardware token.

• What you are – e.g. a user’s enrolled fingerprint or iris scan, voice.
  

The human fallacy

As many CIOs, CISOs, IT and security teams are no doubt painfully aware, properly implementing MFA requires a bit more than just turning on a single setting. A successful MFA deployment requires adequate consideration to user acceptance but leaving users to self-enrol themselves to MFA for too long can introduce new risks.

At the end of the day, MFA is reliant on humans correctly identifying authorised requests. Particularly in larger enterprises where there are a higher number of systems that continuously push out MFA requests, users may suffer from ‘MFA fatigue’ whereby they no longer scrutinise each MFA request and instead provide the MFA code, push the approve button or approve the phone call request to stop their phone constantly ringing..

Another similar situation is when a user falls for a threat actor’s phishing link. When clicking a phishing link and entering their credentials, a user is more likely to accept the MFA prompt as they knowingly “requested” access.

Source: https://techcommunity.microsoft.com/t5/image/serverpage/image-id/46445i5B6135FF6EC4585A

It is also important to highlight the differences between one-time passcodes (OTPs) and push-notification MFA methods. Some one-time passcodes suffer from unique weaknesses (e.g. SIMjacking) and are more inconvenient for users. In contrast, push-notifications are more streamlined and quicker for users to approve MFA requests, which may lead to users accidentally approving a phishing MFA.

These phishing attacks can be highly sophisticated. One famous example is of a Microsoft 365 protocol that would inadvertently grant the threat actor OAuth access to the user’s entire Microsoft 365 account. The worrying factor is that these malicious apps, once granted by the user, would bypass MFA altogether.

Legacy authentication – leave it in the history books

Over the years, Microsoft has heavily pushed all organisations to move away from legacy authentication protocols (e.g. SMTP, IMAP, POP – list found here) and adopt modern authentication standards. The reason is simple: many legacy protocols simply cannot support MFA.

Having legacy authentication protocols still enabled in your external-facing infrastructure is akin to having your front door secured like Fort Knox and your back door wide open. Organisations may have a false sense of security, whereby they believe MFA will protect them, when in fact threat actors can utilise these legacy authentication methods to gain access.

In our experience responding to cyber incidents, failing to block blocking legacy authentication can result in the following:

• Threat actors connecting with Legacy Outlook/mail clients, e.g. Outlook 2013 or later, Outlook for iOS and Android, Mail for iOS 11.3.1 or later which default to legacy authentication, resulting in a copy of the compromised users’ data being created within the threat actors possession.

• Legacy mail protocols e.g. IMAP4 and POP3 email clients being available for threat actors to utilise.
  

So how can organisations ensure they do not fall victim?

Having experience in responding to many cyber incidents involving ransomware, business email compromise, data exfiltration and other general compromise scenarios, we have put together the following recommendations to help tighten your own organisation’s MFA implementation:

1. Include MFA in your ongoing cybersecurity awareness strategy for your organisational users. Ensure all organisational users are aware of the importance of MFA and being vigilant in scrutinising any potential unsolicited MFA prompts.

2. When introducing MFA into your organisation, be strict in the period which users are required to enrol themselves. Do not allow users to delay the enrolment for too long.

3. Review your current authentication mechanisms against the Microsoft’s legacy authentication list and consider whether you can deprecate some, if not all, legacy authentication mechanisms. Where there are business requirements to keep legacy mechanisms in place, consider the mitigating controls and weigh up the risk for these mechanisms that do not support MFA.

4. Regularly review your enterprise app/OAuth consents in your Microsoft 365 tenancy. Check not only the name of the applications being granted, but also the permissions the applications have been granted and the validity of the application author. Additionally, consider establishing control over whether users can give to consent to OAuth applications at all.

5. Lastly but most importantly, routinely review and test your MFA implementation to ensure no holes exist on the ship. More broadly, if you operate an MS365 cloud tenancy or hybrid tenancy, consider an independent review of your security configurations aligned to an industry-accepted framework (e.g. CIS benchmarks) to ensure a piece of mind that you have appropriate cyber resilience in place.