Do you remember the SolarWinds cyberattack back in March 2020? There was a lot going on in the world back then, so you’ll be forgiven if this one slipped under your radar. SolarWinds software is used by over 30,000 public and private organizations, including several branches of the US government. The attackers were able to insert their malware into the SolarWinds source code. When SolarWinds distributed its “factory sealed” software in a regular software update, it also delivered the malware and the attackers had access to all the organizations that installed the SolarWinds update.
While the techniques used to insert the malware into the source code were so sophisticated it is assumed the attack was coordinated by a nation-state, the method the attackers used to gain initial access to SolarWind’s internal network was far more mundane: bypassing the multi-factor authentication (MFA) on Outlook Web Access.
You’re probably thinking, “Wait a minute! I thought MFA was the latest and greatest security technology. In fact, our insurance company is requiring us to deploy MFA. What gives?”
The simple answer is that some MFA implementations are better than others. Attackers studied the early MFA implementations and adapted their techniques to take advantage of certain limitations inherent in the process. More often than not, those limitations are the users themselves that respond to MFA requests.
First, let’s review the MFA process.
- A user attempts to log into a service.
- The system sends an MFA request to the cell phone registered in the user’s profile.
- Once the user accepts the MFA request, access is granted.
The theory is that without physical access to the cell phone, an attacker can’t log in. That works as long as users never approve MFA requests that they themselves didn’t initiate.
But what if attackers can manipulate a user into approving a request that the user didn’t initiate? Once the user approves the request, the attackers are logged in and can then change the registered cell phone to a different number, allowing the attackers to then accept all future MFA requests themselves. Uh-oh.
Attackers have indeed figured out how to manipulate users into approving MFA requests. There are several different methods that they use, are they are collectively referred to as MFA Bombing. Let’s review three methods that pose the biggest risk to your company.
The Nighttime Flood
In this technique, the attacker uses automation to try logging in incessantly, flooding the user with authentication requests. If the user gets frustrated and accepts the request to make the notifications stop, the attacker gains access. These attacks are often launched during the night when the user is sleeping and likely to click anything to make the noise stop.
The Daytime Drip
Using automation, the attackers try logging in infrequently, maybe only once or twice a day, so as to not draw attention to their attack. All it takes is for the user to inadvertently approve one of these requests and the attackers are in.
The Tech Support Spill
In this technique, the attackers call the user while pretending to be tech support. They tell the user that as part of confirming their identity they will send an MFA request for them to approve. Once the user approves the MFA request, the attackers have gained access to the account.
Whose Fault Is It?
The initial reaction could be the blame the user. After all, they are the ones that approved a request that they didn’t initiate. While employee training is critical, it’s insufficient. MFA Bombing is a social engineering attack that is based on human psychology.
When our sleep is disrupted repeatedly, we’ll do anything to make it stop. Ask yourself how many nighttime interruptions would you tolerate before finally giving in? 10? 50? 100? During the busy workday, all it takes is one moment of inattention to inadvertently approve a random request. Does your phone ever interrupt you during a meeting and you continue talking while instinctively clicking the screen? When someone calls saying they are from tech support and they even can initiate an MFA request, we tend to believe them. These are all scenarios that could catch every employee, from top to bottom, off guard.
There are simple steps your company can take above and beyond employee training to reduce your exposure to these techniques.
- Limit the number of MFA requests over a specific time frame. There is likely no legitimate need for twenty MFA requests within a one-hour period – so why allow it? After a few unsuccessful MFA requests, restrict the frequency of new requests. The passcodes on our mobile phones have been doing this for years. It’s something users are already accustomed to and it is an easy and effective deterrent to these types of attacks.
- When appropriate, limit the times during which MFA requests can be initiated. If there is no legitimate business need for employees to be logging into systems at 3:00 AM, configure the system to not send out MFA requests during that time period. Not only will your employees sleep better, but you’ll sleep better knowing you’ve blocked criminals from taking advantage of this exploit to disrupt your business.
- Use geo-location to scrutinize login attempts. If a login is initiated in Russia, but the MFA request is approved in California, it’s probably not a legitimate login. Your MFA solution should automatically detect this discrepancy and prevent an MFA request from ever being presented to the user in this scenario.
How you implement MFA matters
Due to the risks of MFA Bombing, it is insufficient to simply click a box in your software to turn on MFA. It’s necessary to have security experts familiar with the latest exploits configure any MFA implementation to include these three limitations among others. An improperly configured MFA implementation can give you a false sense of security that won’t become obvious until it’s too late.
If you don’t have in-house MFA expertise, bring in outside experts to make sure it’s done right. Not only have the attackers noticed a weak MFA implementation can be easily circumvented, but insurance companies are also realizing this and are increasing their MFA implementation requirements when renewing policies. Whether you do it yourself or bring in outside help, properly configuring your MFA implementation is something you can’t afford to procrastinate
