Why Multifactor Authentication Is So Important: A True Account of Digital Fraud

Our Senior Technical Consultant shares her experience working with a client whose organization suffered an email exploit, which could have been prevented if multifactor authentication had been in place. This attack resulted in significant financial loss. This case study has been fully anonymized to protect our client’s privacy. 

Recently, an organization approached us to help them deal with a suspected phishing attack that resulted in the loss of a large sum of money.  This sum was large enough to warrant reporting the incident to the authorities for further investigation. This attack could have been prevented if multifactor authentication was in place. 

I set out to review and determine the chain of events leading to the resultant fraud and theft. I found what turned out to be a very well-crafted exploit. 

Early on during my investigation, it appeared odd to me that the attacker knew our client’s credentials. Since the attack took place within a Microsoft 365 tenancy, I had several tools and reports I could use to review the details and events leading up to the ultimate “phishing” attack.  

The Attacker Accesses Our Client’s Mailbox

The user sign in logs in Microsoft indicated a specific IP address (from Oregon) logging into our client’s mailbox via proxy (Client=OWA;Action=ViaProxy). The attacker accessed the mailbox by exclusively using a browser to access Outlook online. With access to our client’s mailbox, the attacker was able to gain insight into our client’s upcoming events, like trips, and view other confidential information, such as flight itineraries and images of our client’s driver’s license. The attacker also found emails pertaining to financial transactions and payments with third-party organizations. 

The Attacker Successfully Carries Out a Phishing Attack

I conducted a detailed audit log search of our client’s mailbox to try and pinpoint specific key events that pertained to the attacker’s IP. At this point, I found a second IP address (from Tokyo) that took the reins and continued with the planned exploit. It was this second IP that executed the actual “phishing” attack. The attacker sent a request for “new banking information,” posing as the client to an unsuspecting company that our client regularly did business with. They deposited a considerable sum of funds into the new account because of this “phishing attack.” 

It is likely that the two IPs were a single attacker, and the locations were endpoints from a VPN connection to hide the trail and conceal the attacker’s actual location. 

But…how Did the Attacker Get the User’s Credentials?

In reviewing our client’s mailbox, I came across numerous emails referring to “password update notifications.”  It is possible the attacker may have gotten our client’s email address from their company website. The attacker then went on to set up a personal Microsoft Live account, using the same email address already connected to our client’s “work or school” account. In this case, it was a “work” account. By having access to the new personal email address, the attacker crafted a “phishing” email, notifying our client that their password was about to expire and that they should either change it or keep the same. 

The password reset email, while appearing to come from Microsoft, was sent by a non-Microsoft entity named Portal Helpdesk from gmx.net domain. Believing this was a legitimate email, it looks like our client clicked on the links and entered their credentials. It is believed that the attacker used the personal (same) email address to gain access to the work account which then provided the attacker access to all Microsoft 365 services, including email.  

Additionally, the attacker set up inbox rules to route certain messages from contacts that would be involved in the exploit to random folders. This was done to prevent the client from seeing any email transactions during this exploit. 

So – Why Is Multifactor Authentication So Important?

This entire exploit could have been avoided if our client’s work account was configured for MFA. The attacker could not have gained access to the account with only a password. In fact, Microsoft 365/Azure AD MFA offer multiple means to authenticate that do not even require a password. In the case just described above, our client could have authenticated via text to phone, MS Authenticator app, hardware Oath token or biometrics (facial recognition). 

In addition to MFA, configuring Exchange Online threat protection policies for “phishing” and coaching users to detect anomalies in emails can help prevent this type of exploit from occurring. 

Is your organization fully protected against an attack like this? At Regroove, we take the security of our clients and their data very seriously. If you would like an audit of your current security configuration, please complete the form below and our team of specialists will be in touch!