I was motivated to write this post based on a vendor blog that I read recently, that talked about ways to maliciously perform what amounted to a denial of service attack on AD. Ostensibly the post was designed to sell software, which I don’t begrudge, but it got me thinking–how easy is this to do, really? I mean, there’s several ways to truly mangle AD, some easier than others. But the particular scenario I describe in this article got me thinking, because there was a Group Policy angle to it, which I find hard to resist :).

The Caveat

I think it’s important to point out at the beginning of this post, as I allude to above, that, if someone has Domain Admin access on your AD, there are a myriad ways for them to disrupt, destroy and otherwise bring AD down– I won’t share all of them here. The point here is that you, as a defender, need to be aware of these ways and monitor the activities that are occurring on your DCs. This particular article focuses on mass denial of user rights as one particular pathway, but it’s by no means the easiest and most destructive.  Also, there’s no magic elevation of rights going on in what I’m writing about here. This all assumes that user has the ability to log into DCs, which is typically granted to a variety of built-in groups, and also has the rights to modify security policy on the local DC, which is usually granted to Administrators members only. At the end of the article, I’ll talk about some ways you can detect/defend against this.

The Setup

The scenario is that you have a disgruntled IT admin, or maybe an attacker who’s gained significant access to your AD, who uses their powers to essentially keep all users from accessing AD. So while AD may be humming along just fine, no one is able to leverage it’s services. The principal attack path in this scenario, was to leverage built-in Windows user rights to deny access to domain controllers, servers, workstations, etc. Essentially rendering all the key pieces of a typical AD infrastructure unavailable for authentication, either over the network or locally.  Group Policy provides the tools, via the “User Rights Assignment” policies, to distribute user rights (or their denial) to any and all computers in AD, as shown here:

The Deny User Rights in Windows and Group Policy

These 5 user rights explicitly deny their 5 corresponding allow rights, and are described here:

• Deny access this computer from the network: Denies the ability to connect remotely to a Windows computer (e.g. mapping a remote share, remote WMI connections, etc.)
• Deny logon as a batch job: Denies the ability to run using a batch processing facility such as the Windows Task Scheduler. A user account who has been denied this right cannot run scheduled tasks in their user context
• Deny logon as a service: Denies the ability to run as a Windows service. A user account who has been denied this right (e.g. a service account) will not be able to successfully start a service with their logon account.
• Deny log on locally: Denies the ability to perform a interactive console login. For example, a user account who is denied this right would not be able to log onto their Windows desktop from the Windows logon screen.
• Deny log on through Remote Desktop Services: Denies the ability to access a computer over RDP (Remote Desktop Protocol) or more specifically prevents successful login to a computer via RDP.

In this scenario, the rogue administrator or attacker, essentially adds the “Authenticated Users” and even domain “Administrators” to these deny rights, and then applies them, at the very least, to domain controllers, or at the most, to all workstations and servers in the domain. The result—no one can login locally, remotely or via RDP, no services that use domain accounts will start on any systems that receive these rights, and no Scheduled Tasks will run that use domain user accounts, on systems that have received these rights. To be clear, at this point, you are hosed. However, how easy it really, to get to this state, even for someone with Domain Admin powers? You might assume it’s pretty easy, but.. that’s what I wanted to explore.

Easy… or Hard?

Again, if I’m an administrator with god-like powers over AD, I can do a lot of damage in a variety of ways. That’s acknowledged. I can delete the DIT off of my domain controllers, as an example. Doesn’t get more damaging than that. Or I can dump the DIT and do offline cracking of NTLM hashes–pretty bad. But how about this user rights Denial of Service scenario–how easy is that to achieve, even for a privileged admin? Well, at first I thought, “easy-peasy”. As a Domain Admin, I can just use Group Policy to deploy these denial rights to my domain controllers, or worse yet, to all computers in my domain and “Bobs your uncle”. But not so fast. As of at least Windows 7, the normal GP editing tools (i.e. GP Editor) actually block you from shooting yourself in the foot on at least one crucial deny right–Deny Logon Locally. For example, if I try to add “Authenticated Users” to the “Deny logon locally” right on the Default Domain Policy to prevent all users in the domain from being able to log into their workstations or servers, GP Editor will give me a big, fat “not so fast Mister”, as seen here:

Group Policy Editor prevents me from abusing Deny Logon Locally

However, no such restriction exists on the other 4 rights. So while my ability to log into the console of a server or workstation is protected, I CAN use Group Policy to distribute deny access rights for the other 4 user rights to my entire network. So, this means that my rogue administrator can cause a lot of damage, with the ability to modify GPOs that are linked at domain or domain controller OU levels.

But what about making that change outside of Group Policy? There’s nothing that says you HAVE to use Group Policy to distribute user rights changes. Group Policy happens to be a really easy way to do it because you can quickly distribute those changes to an entire domain without a few mouse clicks. But again, not the only way. For those of you that have been around a while, you know that there was a command-line tool in the Server 2003 Resource Kit called ntrights.exe that allowed you to assign user rights on a local machine. For example, to bypass the Group Policy restriction on “Deny Logon Locally”, I can simply run ntrights.exe on a given machine like this:

ntrights -u “authenticated users” +r SeDenyInteractiveLogonRight

Now, doing it on one machine, or even a few, is one thing. But the true goal of the troublemaker is to create widespread issues, and do it in a way that makes it hard to track. Even if a nefarious Domain Admin were using Group Policy to spread their evil, AD audit logs would see who was making the change (assuming they went through the normal tooling). What the bad actor wants is to stay under the radar and not create tracks back to them. And in this particular scenario, we can leverage a little known but potentially ugly method for getting this user right change out to all domain controllers without leaving those tracks. It does require admin access to a DC in the first place, so it’s not so compelling. But in an environment that has dozens or hundreds of DCs, the attacker need only log into one DC to get the change out to all, usually within 5 minutes of the change being made.

Ghost in the Machine

A while ago, I blogged about a particular behavior on domain controllers, where a change to certain local security policy settings on a given DC, will automatically propagate up to the “Default Domain Controllers Policy” (or Default Domain Policy in some cases) for the domain, ensuring that all domain controllers receive that setting. This technique can be used to propagate these Deny user rights changes without ever having to touch a GPO directly. Our bad actor simply need run ntrights.exe or secedit.exe on a given DC, and that change will propagate almost immediately to the Default Domain Controllers Policy. And, as an added bonus, if you look in the audit log on the DC that originated that change, it will show at the Default Domain Controllers GPO changed, but the change by information will appear as “LocalSystem” and not the user who initiated the change (as shown below). Fun!

Security changes initiated on a DC will not show the user who initiated them.

I’ll also note, although it’s somewhat unrelated to this article, that you can use this technique to propagate changes to the Default Domain Policy as well. The main difference is that the propagation will only happen for policy settings that NEED to be processed at the domain level. This really only includes the settings under Computer Configuration\Windows Settings\Security Settings\Account Policies, like password policy and Kerberos policy. That still presents some interesting scenarios. I could, for example, change minimum password length for all accounts in the domain to “14” by issuing the following command on a DC:

net accounts /minpwlen:14 /domain

That might cause some amount of disruption, if not total chaos, as users change their passwords. And again, when this change occurs on the Default Domain Policy, it shows up in the DC audit log from a source user of LocalSystem.

Defense

So, obviously the key to preventing this kind of bad behavior is to keep an eye on what your admins are doing on your DCs. Any operations on a DC that can change their local security configuration should be monitored. This means using a solution like Microsoft’s Sysmon tool for monitoring and alerting on processes executed on a Windows system. At the very least, keep an eye out on your DCs for one of these processes being run:

• ntrights.exe
• net.exe
• secedit.exe

There’s probably very few legitimate reasons why these commands should be run on a DC, so it’s worth knowing when they are. In addition, consider using a Privileged Access Management (PAM) solution to constrain what commands can be run on DCs. Microsoft PowerShell-based JEA solution is a cheap/free and relatively easy way to control this.

In addition, you should be, if you’re not already, logging and potentially even alerting every time a user logs onto a domain controller directly (via console or RDP). There are precious few legitimate reasons to log into a DC’s console in this age of remote administration and management, and so when it happens, you should know about it!

Finally, because I’m a Group Policy guy, you should always know when changes happen to your GPOs, what those changes are, and who is making them. GPO changes are infrequent enough that you should be notified as soon as a critical GPO is changed, and you should have the ability to roll that change back…quickly.

Summary

So, while it is not completely straightforward for a nefarious Domain Admin to use deny rights to completely take down your AD environment without you knowing about it, there are several paths that you should be aware of, that could cause plenty of mischief, if not a total denial of service. As always, anyone with the ability to log into domain controllers or edit Group Policy, has several paths to destruction at their disposal–this one I’ve highlighted being only of those. It’s another good reason why should only hand out these rights temporarily and only as needed to get a job done.