Multi-factor Authentication (MFA) has long ago become a standard security practice. With a wide consensus on its ability to fend off more than 99% percent of account takeover attacks, it’s no wonder why security architects regard it as a must-have in their environments. However, what seems to be less known are the inherent coverage limitations of traditional MFA solutions. While compatible with RDP connection and local desktop logins, they offer no protection to remote command line access tools like PsExec, Remote PowerShell and their likes.
In practice, it means that workstations and servers remain as vulnerable to lateral movement, ransomware spread and other identity threats despite having a fully functioning MFA solution on. For the adversary it’s just a matter of taking the command line path instead of the RDP to log in as if there was not protection installed at all. In this article we’ll explore this blind spot, understand its root cause and implications, and view the different options security teams can overcome it to maintain their environments protected.
The Core Purpose of MFA: Prevent Adversaries from Accessing your Resources with Compromised Credentials
MFA the most efficient security measure again account takeover. The reason that we have MFA in the first place to prevent adversaries from accessing our resources with compromised credentials. So even if an attacker would be able to take hold of our username and password – which is more than plausible scenario – it still won’t be able to leverage them for malicious access on our behalf. So, it’s the ultimate last line of defense against credential compromise, that aims to void this compromise form any gain.
The Blind Spot: MFA is not Supported by Command Line Access Tools in the Active Directory Environment
While MFA can fully cover access to SaaS and web apps it’s significantly more limited when it comes to the Active Directory managed environment. This is because the key authentication protocols that are used in this environment, NTLM and Kerberos, were written way before MFA existed and don’t natively support it. What it means is that every authentication method that implements these protocols cannot be protected with MFA. That includes every CMD and PowerShell-based remote access tools, of which the most prominent ones are PsExec and Remote PowerShell. These are the default tools admin use to connect remotely to users’ machines for troubleshooting and maintenance purposes, and hence are found in practically any AD environment.
The Cyber Security Implications: Lateral Movement and Ransomware Attacks Encounter no Resistance.
This mainstream remote connection path is, by definition, unprotected from a compromised credentials scenario and as a result is used in most to all lateral movement and ransomware spread attacks. It doesn’t matter that there is an MFA solution that guards the RDP connection and prevents them from being abused. For an attacker, moving from the patient-zero machine to other workstations in the environment with PsExec or Remote PowerShell is as easy as doing so with RDP. It’s just a matter of using one door instead of the other.
Are you as protected as you should be? Maybe it’s time for you to re-evaluate your MFA. As a follow-up, explore this eBook to learn more about Silverfort’s Unified Identity Protection approach to MFA and gain insight into how to assess your existing protections and relative risk exposure.
The Harsh Truth: Partial MFA Protection is No Protection at all
So, if you’ve gone through the pain of installing MFA agents on all your critical servers and workstations, most chances are that you’ve achieved little in actually securing them from identity threats. This is one of the cases where you can’t go halfway. It’s either you’re protected or you’re not. When there’s a hole in the bottom of the boat it makes little difference that all the rest of it is solid wood. And in the same manner, if attackers can move laterally in your environment by providing compromised credentials to command line access tools, it no longer matters that you have MFA protection for RDP and desktop login.
The MFA Limitations in the On-Prem Environment Puts your Cloud Resources in Risk As well
Despite the shift to the cloud, more than 90% of organizations maintain a hybrid identity infrastructure with both AD managed workstations and servers, as well as SaaS apps and cloud workloads. So not only core on-prem resources like legacy applications and file shares are exposed to the use of compromised credentials due to the lack of MFA protection, but also the SaaS apps as well.
The common practice today is to sync passwords between all these resources, so the same username and password are used to access both an on-prem file server as well an organizational SaaS app. This means that any attack on-prem that includes the compromise and use of users’ credentials can easily pivot to access SaaS resources directly from the attacked machines.
The Paradigm Shift: From Traditional MFA to Unified Identity Protection
The gap that we’ve described stems from how traditional MFA is designed and implemented. The key limitation is that MFA solutions today plug into the authentication process of each individual resource, so if the software that performs this authentication doesn’t support MFA – as in AD command line access tools – there can be no protection point blank.
However, there is a new approach today that shifts focus from placing MFA at each individual resource to the directory, overcoming thus barrier completely.
Silverfort pioneers the first Unified Identity Protection platform that can extend MFA to any resource, regardless of it natively supports MFA or not. Utilizing an agentless and proxyless technology, Silverfort integrates directly with AD. With this integration, whenever AD gets an access request, it awaits it verdict and forwards it to Silverfort. Silverfort then, analyzes the access request and if needed, challenges the user with MFA. Based on the user’s response, Silverfort determines whether to trust the user or not and passes the verdict to AD that grants or denies access, respectively.
The innovation in this approach is that it doesn’t matter anymore if this access request was made over RDP or command line and if it supports MFA or not. As long as it was made to AD, AD can pass it to Silverfort. So, by moving from MFA protection at the resource level to MFA protection on the directory level, the blind spot adversaries are abusing for years is finally resolved and secured.
Seeking to learn more on how to apply MFA to all of your resources? Visit us at https://www.silverfort.com/
