Azure MFA Loophole: Why am I still under attack?

I was approached by the Head of IT for a 70-something person company via LinkedIn, wanting an independent review of their environment. I thought sure, let's schedule a call to go over the details. This guy's company had an IT infrastructure of the future; the most well-prepared lead I had ever dealt with! Everyone in the company worked from home, connecting through a remote desktop, multi-factor authentication (MFA) was turned on for everyone, and they were all managed by Azure Active Directory (AD). On top of all that they already had tools to monitor their environment. This was going to be the quickest and easiest penetration test we had ever done! 😁

Once they gave us an instance of their remote desktop, we logged into their Azure portal, checking sign-in logs via Azure Active Directory. Holy cow, the Head of IT's account was under attack every 17 seconds!!! A brute force attack was swiftly underway in Indonesia, attempting a breach on all of the company's users. 

But how could this happen? How could, with all the right tools, the Head of IT not even know this was going on? They even had an IT vendor supposedly taking care of them.

If this was a brute force attack and users had MFA, then why weren't accounts automatically being locked-out after the 3rd failed attempt? Expanding the sign-in details from the Azure portal exposed a glaring, but simple mistake. The client was under an IMAP protocol attack. This attack bypasses MFA because IMAP doesn't support multi-factor authentication. This also includes the POP3 and SMTP protocols. 

What's wrong with IMAP, SMTP, and POP3 protocols?

Internet Message Access Protocol (IMAP), Simple Mail Transfer Protocol (SMTP), and Post Office Protocol version 3 (POP3) are communication protocols created between 1981 and 1988, so its pretty old technology. These protocols don't support the multi-factor authentication (MFA) technology we have today and are now considered 'legacy authentication' measures. 

Because this company enabled MFA but didn't disable IMAP, SMTP, and POP3 protocols, they left a loophole and created a false sense of security. To offer an analogy, it's like the Head of IT locked the front door but left the sliding-glass door in the backyard open. Why would I go through a locked door when I can just walk around the house?

That being said, many applications and old software still run on those protocols, meaning companies have to upgrade their other software to allow MFA. For some companies who are still using old email servers, enterprise resource planning (ERP) software, accounting software, and/or customer relationship management (CRM) software, this could pose major capital investment. But because IMAP, SMTP, and POP3 attacks are so easy to execute, they just about as common as email phishing attacks!

How could this have been prevented?

First, various notification rules could have been created. Considering they already had Active Directory Premium P1, they could have created a conditional access rule to block any sign-in attempts from outside the US. They could have also upgraded to apps that don't use the IMAP, POP, or SMTP protocols and then closed the ports associated with those protocols. Lastly, they could have had a rule to send the global admin a notification of an attempted breach.

Curious how your cybersecurity stacks up? Take or 5-minute quiz to find out:

Questions? Schedule a meeting below: