The CrowdStrike Incident Response (IR) team often assists organisations dealing with active computer security incidents involving a nation-state or an e-crime threat actor. These incidents range from lock-and-leak ransomware activity to long-term covert persistent access for surveillance and espionage purposes.

All too often, the method of access used in these incidents involves authorised remote access being exploited by an unauthorised party, leading to substantial financial loss and organisational damage. Often, the root cause is the valid credentials, such as usernames and passwords, being misused by the threat actor to access the victim network.

In terms of frequency, the devices most targeted for unauthorised access are:

• VPNs to gain access to the network
• Remote Desktop Protocol on an Internet-facing Windows system (including the cloud)
• SSH servers on Internet-facing Linux systems (including the cloud)

The vulnerability of SFA

Many times, these systems are protected with only static usernames and passwords, referred to as single-factor authentication (SFA), resulting in breaches that severely impact companies. There have been investigations where threat actors devised ways to bypass improperly configured multifactor authentication (MFA) mechanisms, but these instances are relatively small in number.

Why focus on SFA? Based on our experience, SFA is often identified as the root cause of unauthorised system access.

As part of responding to incidents on behalf of a customer, we “triage” the situation to be in the best place to help the business get back up and running quickly. If the client says they’re using SFA, we often recommend deploying MFA immediately and properly to minimise continued risk.

Case studies and bypassing MFA

CrowdStrike IR worked on an investigation where an e-crime threat actor was able to bypass the MFA implemented by an organisation, as it had a self-enrollment capability in which the initial login for MFA enrollment was protected through Active Directory username and passwords (i.e., SFA). The user was then required to enrol their mobile phone to receive the SMS that would act as the second factor for authentication.

The threat actor was able to figure this out, likely by performing a successful credential stuffing attack (i.e., using stolen username and password pairs to gain fraudulent access to systems) to target an unused account, and then registering a mobile number that they control to receive an SMS for the second-factor authentication. They were then able to access the internal network of the victim organisation over the VPN using these credentials.

Another aspect to highlight is the damage that can be caused by “exceptions” for individuals that “do not need MFA.” This can be to improve usability or to ensure administrators have access to the environment in case the MFA service is unavailable.

We have responded to multiple incidents where one of the “MFA bypass” accounts was compromised. These incidents may happen through the reuse of compromised credentials at another site that was then breached, or through a vulnerability in a VPN device where SFA credentials were captured by the threat actor. These incidents have caused millions of dollars of damage to the victim organisations.

In another investigation, we saw a nation-state threat actor review the Active Directory configuration looking for user groups that had MFA exceptions configured and then add accounts under their control to the MFA exemptions group.

Another common way we’ve seen threat actors bypass MFA is by spamming users with authentication push notifications. In such cases, the threat actor keeps prompting users to approve an authentication by sending them multiple mobile push notifications in a short period of time until the push notification is approved.

Understanding the role and limitations of MFA

While MFA is not perfect, if configured judiciously, it raises the bar to an acceptable level to help organisations minimise the risk of falling victim to one of these damaging attacks. MFA should be considered a cost of doing business on the internet and should be enforced universally and without favour to anyone.

However, MFA should not stand alone as the panacea for all security woes. It should instead complement a comprehensive security program that includes a well-trained security team, robust and regularly tested processes, and technology with full threat visibility across the IT estate.

Having MFA in place is a good start, but like most security failures, the devil can be in the details. Some factors to consider include:

1. How secure is the backing infrastructure for MFA and VPN? Is there an exploitable vulnerability in either the VPN, MFA or host infrastructure? Sophisticated threat actors will commonly add their own accounts to MFA or directly to the VPN by exploiting a vulnerability in the infrastructure. These vulnerabilities are most commonly exploited from inside the network. Having their own accounts will allow them to maintain access should they be discovered, and to blend into the day-to-day activities of the victim organisation. We have seen nation-state and e-crime threat actors both use these techniques.
   
2. Another VPN/MFA process failure that we see commonly exploited is the “MFA bypass” Active Directory group. Many organisations will set up a robust and secure MFA infrastructure for VPNs and other remote access technologies, but then have an “MFA bypass” group in Active Directory. As the name suggests, the accounts in these groups likely do not require MFA to authenticate. If the threat actor has credentials for one of these accounts, they can log on without using an MFA device.
   
3. Another way threat actors perform the same attack is to find credentials insecurely stored on an administrator’s workstation. In a recent red team engagement CrowdStrike conducted, the team gained remote access to the client’s network by finding insecurely stored credentials that the administrator had made for “Emergency Use.” The CrowdStrike IR team has seen another variation of this attack in which an unpatched VPN vulnerability was exploited to expose an “Emergency Use” account that lacked MFA and was being used for day-to-day access (to the surprise of the administrators).
   
4. Yet another way we have seen threat actors use SFA is with an unknown VPN. For one of our clients with a large network, we identified multiple compromised SFA accounts on the VPN. The client did a rapid deployment and enforcement of MFA to this VPN but a business unit had set up a separate VPN without the IT department’s knowledge. The threat actor knew about this device and started logging in to the client network over this shadow IT VPN once MFA was enforced on the authorised device. Thankfully, the client was able to get the situation under control. We also performed a network scan of the perimeter and found two more VPN devices set up by other shadow IT groups and had the client get those under control as well. Do not assume that there is just one VPN — it is always a good idea to validate the situation. We strongly recommend that you use a reputable red team to validate your assumptions before an attacker proves them wrong for you. Some of the most damaging security incidents have a flawed belief as the root cause. If you believe the remote access infrastructure is secure, get it tested by a reputable red team and validate your beliefs.. 

Conclusion

The days of SFA being able to effectively protect anything are long gone. However, MFA is not a panacea. You must ensure the software, underlying infrastructure, processes, and people are also secure. There are a number of gotchas as well, with the most prolific being the “MFA bypass” AD group. Lastly, we recommend that your assumptions are validated — we often see incredulous IR clients that cannot believe what we’re telling them about their own environment.