Dr. Active Directory vs. Mr. Exposed Attack Surface: Who Will Win This Battle?
Active Directory (AD) is one of the oldest pieces of software still being used in production environments and can be found in most organizations today. This is despite the fact that its historical security loopholes have never been modified. For example, because of its inability to implement any security measures beyond checking password and username matches, AD (and the resources it manages) is at risk of using compromised credentials. In addition, this exposure is not limited to the on-site environment. The common practice of syncing passwords between AD and a cloud identity provider means any AD breach is also a potential risk to the SaaS environment.
In this article, we will explore AD’s inherent security flaws and examine their scope and potential impact. We’ll then explore how Silverfort’s Unified Identity Protection platform can address these weaknesses at their roots and give organizations using AD the resilience they need to thwart identity threats and reduce the risk of user accounts being compromised.
What clouds? Why AD Will Continue to Be Part of Hybrid Environments
While cloud computing has sparked a tectonic shift in IT, it has not completely replaced the on-premises environment but coexists with it. The pragmatic route that most organizations choose is to maintain a hybrid environment, where user access to SaaS and web resources is managed by a dedicated identity provider while AD still manages on-premises resources.
From an operations standpoint, this strategy makes sense because there are a lot of resources that can be migrated to the cloud or exchanged for SaaS applications. However, it’s important to note that this approach means many long-ignored AD security vulnerabilities still exist.
To learn more about how Silverfort addresses weaknesses in your identity security posture, check out our resources, Silverfort MFA: Protect the Unprotected.
AD Weakness: Unable to Detect and Prevent Malicious Access Attempts Using Compromised Credentials
When a user initiates an access request, AD knows how to do only one thing: check that the username and password match. Otherwise, AD blocks access; if they do, access is granted. But what can AD do if the username and password match but are used by an adversary who got them? Unfortunately, the answer is absolutely no.
As strange as it may sound, from an AD point of view there is no difference between a legitimate user providing the correct username and password and a malicious adversary doing the same. Both are given the same access.
So Why Can’t Traditional MFA Solve This Problem?
At this point, you might be wondering why MFA can’t simply be added to the AD authentication process, as is done with SaaS applications. The answer, unfortunately, is not that simple. AD and its authentication protocols (NTLM and Kerberos) were created and designed more than two decades ago — long before MFA existed. Consequently, unlike the modern authentication protocols that SaaS applications use, they cannot support MFA at all. There are also no plans from Microsoft to open up this protocol and rewrite it so they have this capability.
This means we’re back to square one, where an attacker using compromised credentials in an AD environment can actually connect to any workstation, server, or application they want, without any security measures getting in their way.
AD Breach AD Opens the Enemy’s Path to Your Cloud Resources
What many security stakeholders often forget is that on-premises and cloud environments are intertwined. In fact, many attackers who want to access SaaS applications choose to access them through compromising the local environment, rather than attacking them directly through the browser. A common pattern of this kind of attack is to gain control of employee endpoints using social engineering and, once in place, attempt to compromise usernames and passwords to use them for malicious access to SaaS applications. Alternatively, if the federation server exists, adversaries can easily compromise it as they would any other local resource and gain SaaS access from there.
One way or another, it’s important to realize that when we talk about AD security holes, it doesn’t mean that only the AD managed environment is at risk, but rather the entire hybrid environment with all its users and resources.
Silverfort Unified Identity Protection: Address the AD Gap with Real-Time Protection
Silverfort has pioneered the first platform purpose-built to protect against identity threats – in real time – leveraging compromised credentials to access targeted resources. Silverfort provides ongoing monitoring, risk analysis, and active policy enforcement on every incoming authentication and access request made by any user to any resource, whether on-premises or in the cloud.
In this way, Silverfort can address AD security flaws at its root through integration with AD’s native authentication flow, thereby taking on the role of deciding whether users can be fully trusted when accessing resources or not.
Silverfort AD Protection: A Threat Protection Layer Natively Integrated into AD Authentication Flow
Here’s how it works:
- A user wants to access a resource and initiates an access request to AD.
- AD, instead of deciding for itself whether to grant or deny access based on a matching password, forward this access request to Silverfort.
- Silverfort receives access requests and analyzes them using a layered AI engine while evaluating requests against pre-configured access policies.
- If the analysis uncovers a suspected intrusion, Silverfort connects to the MFA service to challenge users to verify their identity.
- The MFA service sends messages to users and passes their responses back to Silverfort.
- Based on the MFA response, Silverfort instructs AD to block or allow access.
- AD blocks or allows access per Silverfort’s instructions.
Agentless and Proxyless Technology, Agnostic to All Access Protocols and Methods
As you can see, this unique ability to receive every access attempt in real time from AD allows Silverfort to add missing risk analysis and MFA capabilities to the AD authentication flow. Also, because Silverfort is behind AD and gets 100% of its authentication requests, it eliminates the need to install MFA agents on individual resources or proxy them in front of them. This also means that it makes no difference what protocol is used or whether it supports MFA. As long as authentication to AD is performed, AD will pass this on to Silverfort and protection will be available.
Want to learn more about Silverfort AD Protection? Schedule a call with one of our experts.
