Because of the role that Active Directory plays in cybersecurity, companies are scrutinizing their Active Directory configurations to reduce the likelihood of a damaging cyber intrusion. The threat landscape around the globe continues to evolve, and sudden geopolitical events can make almost any organization on the internet a potential target.
Active Directory (AD) is so prevalent worldwide that it is a prime target for bad actors looking for ways to hijack authentication and authorization. Large enterprises can defend themselves by turning to teams of Active Directory experts, but small-to-medium businesses face similar risk of intrusion with far fewer resources for defense.
In this post, I will cover best practices and share real-world insights into how Active Directory configurations can help to harden your cybersecurity defenses.
How tier 0 security relates to Active Directory configurations
The tier model of privileged access management (PAM) aims to thwart illicit privilege escalation in an environment like Active Directory. Segregating administrators according to the resources they manage denies bad actors an easy path to escalation within Active Directory. You can use Group Policy Objects, for example, to prevent your domain admins (tier 0) from logging on to enterprise servers (tier 1) and standard user workstations (tier 2).
According to the tier model, domain administrators are treated differently, depending on the resources they manage. Microsoft has spent years ensuring that we all understand the priority of tier 0 — our domain controllers. By that criterion, tier 0 also includes the following:
- Systems that manage, control and have administrator rights to the domain controller
- Systems that run any agent on a domain controller
- Public Key Infrastructure (PKI)
- VMware administration, which controls Active Directory in most environments
- Cloud administration of your Azure Active Directory configuration and environment
- Mainframe controls
- Active Directory Federation Services (ADFS)
Stepping back to examine things more broadly, think about any organization’s most sensitive systems and what attackers are really after: their data. Most attacks pull email data and files off of shares. Ransomware works so effectively because it encrypts data, with the result that the company either loses data or loses access to its data.
The connections among tier 0 systems may surprise you:
- Active Directory domain controllers are typically virtualized on VMware.
- Your VMware admins are often in a group in Active Directory.
- Active Directory connects to Azure AD through Azure AD Connect.
- Global admins can jump from Azure AD to control Azure.
- Azure itself often hosts virtual domain controllers, especially in companies that use Azure or Amazon Web Services (AWS) as their cloud data center for infrastructure as a service (IaaS).
That adds up to multiple discrete components that were never meant to interconnect and integrate so closely. Pretty much anything that manages identity and authentication falls under tier zero and is subject to jumping from one to another.
The significance of tier 0 and cloud infrastructures
Gone are the days when we had one monolithic block of on-premises infrastructure to secure. Companies are going multi-cloud — Azure, AWS and Google Cloud Platform (GCP) — because they don’t want to have all their eggs in one basket, which makes sense. But the interconnections become even more complex because each provider handles security differently.
You can liken Azure to a kit of LEGO blocks. They provide instructions that enable you to put together pre-fabricated solutions pretty quickly. AWS is more like the Tinkertoy of IT, enabling you to create whatever you want, including identity and access management (IAM) roles. But it’s easy to create IAM roles in AWS that cause problems. To use Google Cloud tools, you have to authenticate with a Google identity, so deploying Active Directory on GCP is not a replacement for federating your existing Active Directory with Google Cloud.
You can find yourself with not only an Active Directory configuration on premises, but also an Azure-managed AD, an AWS-managed AD and a GCP-managed AD, each with its own rules. A compromise of any user account that has management or the ability to run a command makes you vulnerable. An attacker could compromise your on-premises environment without ever jumping from cloud to your premises in the traditional sense.
Active Directory configurations: Which reduce the likelihood of an intrusion?
When it comes to checking the configurations of your Active Directory environment, the first step is to examine the baseline security policy settings for the workstations, servers and domain controllers (DCs). That and configuring appropriate auditing for Active Directory are good ways to ensure that you’re handling the first-line security items, according to guidance from Microsoft.
Next, it’s critical to think about ransomware. One of the most effective ways to frustrate ransomware is to make lateral movements on your network more difficult. That means enabling host base firewalls, especially for filtering out server message block (SMB) traffic. In essence, all workstations can accept traffic from one another, but there’s no good reason why they should — except for hosting, say, a printer in a small organization. There’s some work involved in figuring out how to deploy host-based firewalls successfully, but combining that with Microsoft Local Administrator Password Solution (LAPS) will frustrate ransomware and attackers.
Why is Active Directory the primary target for an attack?
While Active Directory is often the primary target, it isn’t always the first target. Devious attacks start elsewhere, then jump to Active Directory. Log4j, for example, does not target Active Directory configuration per se, but by affecting anything connected to the network, it has an into Active Directory.
The key is to get your house in order on different levels, which is one of the virtues of the NIST Cybersecurity Framework: identify, protect, detect, respond and recover. Do what you can to protect or secure your Active Directory environment. Then, make sure you have all the appropriate mechanisms to detect when something is going on. And be prepared to respond at different levels with different solutions for everything that’s running within your network.
Which attack vectors are most worrisome?
Vulnerability management against zero-day exploits is important. But even if you deploy a patch within two days of it becoming available, it won’t save you from a zero-day. And anyway, it’s not always the zero-days that get exploited, but the advanced persistent threats that lurk for years and allow attackers to jump among systems in your network.
From the perspective of Active Directory configuration, you can turn on any auditing and deploy any solution you want. But all it takes is one misconfigured Group Policy Object that’s writable and you can be compromised.
Cloud-based applications introduce an attack vector in the form of new features, especially for widely used productivity and collaboration tools. This has security professionals on their toes following up on changes and new features that Microsoft, for example, likes to enable by default. Of course, software vendors enable the features because if they disable them by default, users have to turn them on and adoption remains low.
Consider the security impact of a feature like the one that allows general Teams users to talk to professional Teams users, or to corporate accounts. On one side of the coin, it’s just people chatting, but on the other side of the coin, it’s a phishing channel.
How can you secure your backups?
Returning to the NIST Cybersecurity Framework, the recover step is where a secure backup comes into play.
The essence of a secure backup is that it pre-dates the compromises from which you’re trying to recover; otherwise, you’re just restoring already-infected versions of your files. Attackers are now breaching organizations, then lying low during the backup retention window: two weeks, a month, two months, etc. They want to make sure that the back door they’ve installed on your network has made it into your backups. Then, when they’re sure that you can’t restore a version that isn’t infected with their back door anymore, they launch an attack. If you try to restore from backup, you’ll just restore their back door and grant them access again.
One solution are the so-called scrubs, or scrutinized backups. The provider takes a series of backups over time and based on ever-evolving intelligence, scans them regularly for new vulnerabilities and back doors. Scrubs and immutable backups are critical measures you can take to ensure that you can recover from a breach. However, having a third-party recovery solution in place is ideal to assist and ensure success, as they can provide advanced controls, granular recovery options, automation, and the ability to span on-premises and cloud environments.
Keep in mind that your data recovery plan is as important as your recovery tool. If all of your systems were suddenly unavailable because of ransomware, which ones would you need to recover within the shortest possible timeframe? If you plan on being ready for end-to-end recovery all at one time, without setting those priorities, you’re going to spend a lot of money on constant, widespread vigilance.
An overlooked area of backup security is in controlling access to where your backups are stored. When you back up your domain controllers, who has access to the storage in that backup system? Anyone who has access — legitimate or not — can see and edit all the backups you’ve retained. Even if you’ve moved to a newer main backup system and relegated the old one to backing up Active Directory configurations and domain controllers, they’re still exposed. Attackers could breach that storage and access or infect your Active Directory backups.
Why is a system state backup useful for data recovery?
Without a reliable backup of your Active Directory configuration, you can’t recover the system that controls everything else, so you’re in trouble.
Many companies think that they’re prepared to recover from anything because they have a data protection product. But recovery from a devastating attack like ransomware goes much more slowly if you don’t have a system state backup that includes your AD. Recovery is not impossible, but it can take significantly more time and effort on your part — plus intervention from the likes of your backup vendor and Microsoft — to boot your network again.
The reason is that some backup systems rely on SQL Server, which in turn relies on Active Directory. Active Directory needs to be restored to perform your full recovery.
What is the best way to test Active Directory backup and recovery?
How often do you test your recovery? You can run your backup routines religiously and store them securely, but if you’re not testing them, then you’re not proving anything. The same goes for backing up and recovering your Active Directory configurations.
Plenty of traditional backup vendors advertise a checkbox indicating that they back up Active Directory. However, it can turn out that they’re able to restore some of AD, but not all of it.
Ransomware sets a particularly high bar for recovery. There is a series of automated steps you must follow to ensure that your recovery doesn’t cause more havoc and rollback problems later on. That’s why testing for the ransomware scenario is so important. We break down much more on ransomware recovery here: What you need to know about ransomware recovery.
It’s not sufficient to simply take an offline copy of the domain controller, put it into your lab environment, start it up and then test your other applications. To truly see where your limitations are, test for the event that all DCs are down at the same time. In a real-world scenario, attackers access a tier 0 GPO, deploy their payload and shut down your entire corporate environment, including Active Directory and all associated systems, at once. Only by testing and practicing to that extreme can you attain the comfort level you’ll need in such a stressful situation.
What about backing up the cloud environment?
If you’re backing up your Active Directory configurations and testing recovery successfully, are you also backing up the cloud environment that contains your Office 365 data? Are you backing up SharePoint online, where you host OneDrive for Business and most likely host all of your users’ home drives? What about Teams, and all the data you store there?
Working in the cloud is no guarantee that your data is being backed up, and most organizations relying on cloud computing are not backing up their cloud environment. If the focus of ransomware starts shifting from on-premises data to cloud data, it won’t be pretty. All the programmatic resources like APIs are there, so it’s not inconceivable for threat actors to start encrypting cloud-based data and holding it hostage.
The thing about cloud computing, of course, is that any time your internet connection is interrupted, your data is unavailable. An attack or breach could be so disruptive that you would have no choice but to disconnect your organization and start afresh. Or it could be the result of circumstances outside of your control. In either case, if all of your backups are in the cloud, then there goes your data recovery plan. You’ll have to send someone home or to another city to connect to your cloud storage and start downloading your data to portable storage media.
So, to complement the prevailing wisdom of cloud computing and cloud backups, you should maintain local, physical backups as well, because your internet connection isn’t always guaranteed. That applies to your business-critical applications and data at least. Make encrypted, physical backups, then have an archive service store them offsite or have somebody in IT take them home every night.
The Cyber and Infrastructure Security Agency (CISA) of the US Department of Homeland Security makes the importance of backup and recovery clear in their Shield’s Up initiative: “Test backup procedures to ensure that critical data can be rapidly restored if the organization is impacted by ransomware or a destructive cyberattack; ensure that backups are isolated from network connections.”
To summarize my data backup recommendations:
- Store your backups in three places — local server, offline, remote — at a minimum.
- Perform that system state backup at least once a week. More frequently is better.
- Only tier 0 AD admins should have access to the backups of your domain controllers.
For more insight, you can check out the webcast below that covers additional ways to protect your on prem and Azure AD environments from cyberattacks.