Multi-factor authentication (MFA) long ago became a standard security practice. With widespread consensus on its ability to defend against over 99% of account takeover attacks, it’s no wonder security architects consider it a must-have in their environments. What seems lesser known, however, is the coverage limitations inherent in his traditional MFA solution. While supporting RDP connections and local desktop logins, It does not protect remote command line access tools such as PsExec or Remote PowerShell.
The reality is that workstations and servers, despite having a fully functional MFA solution, remain vulnerable to lateral movement, ransomware spread, and other identity threats. I mean For an attacker, simply use the command line path instead of RDP to log in as if no protection was installed at all. In this article, we explore this blind spot, understand its root causes and implications, and review the various options security teams can overcome to keep their environments protected.
Primary purpose of MFA: prevent adversaries from accessing resources using compromised credentials
MFA is the most effective security measure against account takeovers. The reason we use MFA in the first place is to prevent adversaries from accessing our resources using compromised credentials. is a plausible scenario) and they cannot be exploited for malicious access on our behalf. intended to make a profit.
Blind spot: MFA is not supported by command line access tools in Active Directory environments
MFA can fully cover access to SaaS and web apps, but it is severely limited when it comes to Active Directory managed environments. This is because the primary authentication protocols used in this environment, NTLM and Kerberos, were created long before MFA existed and do not have native support. This means that not all authentication methods implementing these protocols can be secured with MFA. This includes all CMD and PowerShell based remote access tools, the most famous of which are PsExec and Remote PowerShell. These are the default tools used by administrators to remotely connect to user machines for troubleshooting and maintenance purposes, and are used in virtually all AD environments.
Cybersecurity implications: No resistance to lateral movement and ransomware attacks.
This mainstream remote connection path is by definition unprotected from credential compromise scenarios and is used in almost all lateral movement and ransomware spreading attacks. It doesn’t matter that you have an MFA solution that protects your RDP connection and prevents abuse. For an attacker, using PsExec or remote PowerShell to move from the patient zero machine to any other workstation in the environment is as easy as using RDP. It’s just a matter of substituting one door for the other.
Are you as protected as you need to be? Maybe it’s time to re-evaluate MFA. As a follow-up, Learn with this eBook 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.
Hard Truth: Partial MFA Protection Doesn’t Protect At All
So if you go through the pain of installing MFA agents on all your critical servers and workstations, most of the time you are doing very little to actually protect them from identity threats. This is one of those cases where you can’t go halfway. Either protected or unprotected. Having a hole in the bottom of the boat makes little difference that all the rest is solid wood. Similarly, securing RDP and desktop logins with her MFA is no longer an issue if an attacker can move laterally in the environment by providing compromised credentials to command line access tools.
MFA restrictions in on-premises environments also put cloud resources at risk
Despite the move to the cloud, over 90% of organizations maintain hybrid identity infrastructures with AD-managed workstations and servers, and both SaaS apps and cloud workloads. As such, not only core on-premises resources such as legacy applications and file shares are exposed to compromised credential usage due to lack of MFA protection, but SaaS apps as well.
A common practice today is to synchronize passwords across all these resources. So the same username and password is used to access both her servers on-premises and her SaaS apps in the organization. This means that an on-premises attack involving compromise and use of user credentials can easily access SaaS resources directly from the attacked machine.
A Paradigm Shift: From Traditional MFA to Federated Identity Protection
The gaps described here result from traditional MFA design and implementation practices. The main limitation is that current MFA solutions are built into the authentication process of individual resources. So if the software performing this authentication doesn’t support MFA (such as the AD command line access tool), the protection point will never be blank.
But now there is a new approach to overcome these barriers once and for all, shifting the focus from placing MFA on individual resources to the directory.
Silverfort pioneered the first unified identity protection platform that can extend MFA to any resource, regardless of whether it natively supports MFA. Leveraging agentless and proxyless technology, Silverfort integrates directly with AD. With this integration, whenever AD receives an access request, AD waits for the decision and he forwards it to Silverfort. Silverfort then analyzes the access request and asks the user for her MFA if necessary. Based on the user’s response, Silverfort decides whether to trust the user and passes a verdict to allow or deny access, respectively, to AD.
The innovation of this approach is that it no longer matters whether this access request is made via RDP or the command line and supports MFA. As long as it was created in AD, AD can pass it to Silverfort. So moving from MFA protection at the resource level to MFA protection at the directory level finally solves and protects against the blind spots that attackers have been exploiting for years.
Want to learn more about enforcing MFA on all your resources? Visit https://www.silverfort.com/.
