The Incident Response (IR) team is often asked to assist organizations in an active computer security incident involving a nation-state or an eCrime threat actor. These incidents include anything from lock-and-leak ransomware activity to long-term covert persistent access for surveillance and espionage.
All too often, the method of access used in these incidents is authorized remote access being co-opted by an unauthorized party, which can lead to millions of dollars of lost time and damage to the victim organization. The root cause is frequently valid credentials (i.e., username and password) used by the threat actor to gain access to the victim network.
In order of frequency, the devices most commonly targeted by threat actors for unauthorized access are
a) VPNs to gain access to the network
b) Remote Desktop Protocol on an Internet-facing Windows system (yes, this includes the cloud)
c) SSH servers on Internet-facing Linux systems (yes, it?s the cloud again)
The team has seen each system being protected with only static usernames and passwords – aka single factor authentication (SFA) – leading to breaches that knock companies to their knees. We?ve also worked on investigations where threat actors have devised ways to bypass improperly configured multifactor authentication (MFA) mechanisms when they have not been adequately enforced and configured, but by comparison, these are relatively small in number.
Why then pick on SFA? Because, in our experience, it?s widespread to identify SFA as the root cause of unauthorized access into a system.
As part of responding to incidents on behalf of a customer, the team?triage? the situation so they are in the best place to help the business get back up and running fast. One of our questions is about remote access methods, and if the client says they?re using SFA, and often recommend they deploy MFA immediately and adequately to minimize continued risk.
The IR worked on an investigation where an eCrime threat actor was able to bypass the MFA implemented by an organization, 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 enroll 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 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 organization over the VPN using these credentials.
Another aspect to highlight is the damage 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.
The team have responded to multiple incidents where one of the ?MFA bypass? accounts was compromised. These incidents may happen by reusing compromised credentials at another site that was then breached or through a vulnerability in a VPN device where the threat actor captured SFA credentials. These incidents have caused millions of dollars of damage to the victim organizations.
In another investigation, they saw a nation-state threat actor review the Active Directory configuration looking for user groups configured with MFA exceptions and then adding 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 quickly until the push notification is approved.
While MFA is not perfect, if configured judiciously, it raises the bar to an acceptable level to help organizations minimize 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 favor to anyone.
However, MFA should only be the panacea for some 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.
Some factors to consider include
1. How secure is the backing infrastructure for MFA and VPN? Is there an exploitable vulnerability in the VPN, MFA, or host infrastructure? These vulnerabilities are most commonly exploited from inside the network. Having their accounts will allow them to maintain access should they be discovered and blend into the victim organization’s day-to-day activities. The IR team have seen nation-state and eCrime threat actors both use these techniques.
2. Another VPN/MFA process failure commonly exploited is the ?MFA bypass? Active Directory group. Organizations will set up a robust and secure MFA infrastructure for VPNs and remote access technologies but then have an ?MFA bypass? group in Active Directory. These accounts 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. The 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 the team have seen threat actors use SFA is with an unknown VPN. They identified multiple compromised SFA accounts on the VPN for one of our clients with an extensive network. The client rapidly deployed and enforced 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 authorized device. Thankfully, the client was able to get the situation under control. They also performed a network scan of the perimeter, found two more VPN devices set up by other shadow IT groups, and had the client get those under control. Do not assume that there is just one VPN – validating the situation is always a good idea. The team strongly recommend using a reputable red team to validate your assumptions before an attacker proves them wrong. 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.
The days of SFA being able to protect anything effectively are long gone. However, MFA is not a panacea. You must ensure the software, underlying infrastructure, processes, and people are secure. There are also several gotchas, the most prolific being the ?MFA bypass? AD group. Lastly, the team recommend validating your assumptions – and often see incredulous IR clients who cannot believe what they tell them about their environment.
The author is a Director, Professional Services at CrowdStrike.
Image Source- Freepik