Data breaches and other security incidents over the last few years have caused vulnerabilities such as “Pass the Hash” to resurface. It has been said before but bears repeating that perimeter security alone is no longer sufficient to secure our highly dynamic, connected and mobile enterprises. Instead, organizations must focus on protecting the enterprise at the identity—or the user level. With insider threats on the rise, it’s important that any organization maintain an active insider threat program to protect these identities—most critically, privileged or administrative identities. Because 99% of enterprises rely heavily on Active Directory (AD) as their primary user authentication mechanism, AD has remained the most popular target among bad actors and is a critical component to any insider threat program.
The AD Compromise & Privileged Account Abuse
The legacy NTLM hashes generated by AD are specifically a primary focus of nefarious actors. If you’re not familiar with the common “Pass the Hash” attack, here’s a brief synopsis of how it often works:
- A user’s workstation is compromised, for example, by a phishing attack.
- The bad actor gains administrative permissions to the user’s workstation and may create a problem with the workstation that will require someone with elevated permissions to fix it.
- An administrator logs onto the workstation to remedy the issue, leaving the administrator’s hash stored in memory.
- The bad actor executes software to extract the hash and makes network connections from the workstation to resources, data stores, databases and more sensitive systems and data as the perceived privileged user.
The need to protect the privileged accounts applies to AD just as it would in any system. The accounts, passwords and credentials will always be a primary target regardless of the system being protected or the guards that have been implemented. To provide an additional level of assurance, Microsoft has submitted the Enhanced Security Administrative Environment (ESAE), which is also known as the “Red Forest” AD architecture.
Breaking down the Red Forest Architecture
The basic forest design of the ESAE environment looks something like this:
In this ESAE design, the user and resource and application forests trust the authentication from the Red (or administrative) Forest through a one-way trust relationship. The administration is then separated into tiers.
- Tier 0: Administrator accounts and groups that live in the Red Forest and have control of enterprise identities.
- Tier 1: Administrator accounts that live in the Resource (or application) Forest and should only does interactively to systems in that forest.
- Tier 2: Administrator accounts that control user workstations and other devices that live in the User Forest.
Segmenting administration in this way provides the ability to isolate a compromise. For instance, if a Tier 2 administrator account is compromised, then the potential chain of compromise will be limited to the assets in the Users Forest. As we move up (or down) the tiers to Tier 0 accounts, the protections and policies around the use of these accounts must be drastically more restrictive.
The ESAE provides some risk management for AD and the Windows operating systems within the enterprise. If a compromise is detected, the entire enterprise doesn’t need to be rebuilt from the ground up. The design effectively creates “disposable” admin accounts or links that can be severed to limit the scope of the breach. The breached forest can then be removed from the trust relationship to protect the remaining enterprise assets.
Does Multifactor Authentication Help?
Multi-factor authentication (MFA) can add some value for administrators, particularly when it comes to phishing attacks, like the Pass The Hash example. But the reality is that the vulnerability the ESAE is designed to prevent do not involve passwords. While a user or administrator authenticates interactively using a password and in some cases MFA, the generated hash—not the credentials themselves—are a target of the bad actor.
Overcoming Common Red Forest Challenges with Automation
Implementing an ESAE design presents different challenges for many different sizes of enterprises. The extremely large enterprise, for example, will have many administrators at all levels (or tiers) and all of this administration must be managed very strictly. Any variation or “one-off” permission can create a vulnerability that will render the entire design vulnerable.
In midsize and smaller organizations, however, it is very common for administrators to perform duties at many different tiers, which may require several, separate accounts at different tiers. This administration must be compartmentalized and may prove difficult to separate. Any variation or combining of permissions can jeopardize the entire enterprise.
Due to ESAE being so complex to implement correctly, it can be more effective to use automated security tools to accomplish the same goals, without ESAE. Another important step is to simplify the security of the administrator hashes by cycling passwords with an automated solution, thereby making them irrelevant. These solutions allow enrollment of accounts to permit them to be checked out and cycled after each use, thus making any credential artifact that is left behind useless.
Automated solutions also provide the single point of administration for all of your platforms and provide the audit trail to show who used an account, where they went with it and even what actions were taken. These solutions are specifically designed to secure the enterprise without the overhead of the ESEA. The targeted admin accounts are enrolled in the solution, and vulnerabilities such as Pass the Hash are virtually eliminated. Some automated solutions also provide the functionality of session management, which adds the capability to replay admin sessions and audit the actions of administrators. While the session is in progress, the privileged analytics capability provides the ability to profile the admin sessions and track deviations from normal behavior such as location, screen resolution, systems accessed, commands run, time of day and keyboard and mouse patterns. If an anomaly is detected, action can be taken to alert security, suspend or even terminate the session.
Additionally, administrator roles should be controlled by automation, and those accounts should only be in the administrator groups while tasks are being accomplished. These solutions provide workflow approval, dynamic and temporal group memberships. With this functionality, admin accounts will be populated only to privileged groups when the permission is required to accomplish an administrative task. Then that group membership will only be valid for the specified period to complete the task, preventing the account from being a target for exploit and significantly reduces the attack surface of the directory.
Whether your organization is multinational with millions of users or has a single-forest architecture, it’s important to understand how privileged or administration tasks are performed, the permissions required to accomplish those tasks and to whom the permissions and access are granted. While complex, the ESAE architecture does provide greater security and resiliency than a single AD forest with native permissions and roles, but the complexity of the overall solution may prohibit a successful implementation exposing the organization vulnerabilities. Critical to any effective AD management is leveraging automation to employ effective controls—from administrative password cycling to session management—to protect the enterprise from growing privileged account attacks.