Is misconfiguration of Active Directory deadlier than a vulnerability?

(You can thank me now for the catchy blog title, and thank me later for the Latin lessons you're about to get in this blog but here goes...)

Active Directory (AD) and its cloud-based counterpart Azure Active Directory (AAD) are some of the most widely used technologies in the world. They’re complicated bits of kit. Literally holding the (public and private) keys to our entire organisation.

Is it any wonder then that they’re one of the most popular targets for malicious actors?

AD Fundum

(Latin for: back to basics…)

Our identities are now the entry point to the corporate network. Where previously we relied on a well-configured firewall to protect our organisations from attack, with the rise of the internet and the onslaught of digital transformation projects, we’ve been left with a higgledy-piggledy perimeter reliant on the security of our usernames and passwords.

But Active Directory isn’t just a list of credentials. We need these for initial entry but then we also need to understand what those credentials will give us access to. Once we get into the network, we find an intricate web of permissions and privileges which grant access to specific folders, files, applications, etc.

Those permissions can be granted in a number of ways:

• Individually, e.g. John Smith is given access to Finance Folder
• As a group, e.g. Anyone in the Finance Team AD Group is given access to Finance Folder, anyone in the Senior Management AD Group is given access to the Expenses application
• As a nested group, e.g. The Finance Team AD Group is added to the Domain Admin AD Group – this means that users in the Finance Group accumulate the higher privileges available as part of the Domain Admin AD Group.

So now we understand in simple terms how AD is constructed, let’s look at how it works in practice.

AD Absurdum

(Latin for: to the point of being nonsensical…)

Let’s think about how a company evolves over time. When you first start a business, you’re a jack of all trades so you set up your own Active Directory or Azure Active Directory and you muddle through until your team gets big enough for a technical bod to join and take over.

Then we start growing. Adding users. A lot of the time there’s little documentation. People don’t tend to document this kind of thing. So when Technical Tina moves on to another role and makes way for IT Manager Mike, naming conventions, group privileges, processes for allocating access… it all goes out the window and then gets reinvented.

When we get to 100 users, there could be groups created by multiple IT personnel, nested groups, ad hoc user permissions which are then copied over to new starters. It can easily get in to a very complex state.

Interesting fact. Since I started in cyber security back in 2019, I have worked with SEVERAL companies that have had more groups that actual users. Some of those were universities, with thousands of users. Imagine being the poor security team trying to unpick that mess.

AD Augusta per Angusta

(Latin for: Through difficulties to honours – i.e. rise to a high position by overcoming hardships… or privesc?)

So it makes sense that Active Directory is the first place our consultants look when they’re doing an internal network penetration test. It’s not that the service itself is weak, it’s that the setup is complex, and even slight misconfigurations can allow an attacker direct access from base user to domain administrator.

That’s usually what we’re looking for in an internal test – to see whether we can get from a bog standard user account like Carl the Customer Service Agent, Rita the Receptionist or Oscar the Office Admin and elevate our own privileges to get a Domain Admin account. Which would mean you’re royally screwed.

Domain Admin accounts have ALL of the permissions. They can switch off firewalls. Create new users. They have access to all of the folders. All of the files. PKI. The lot.

If you’ve got several layers of nested groups, a lack of group management, or if you’re blindly copying access roles for new starters, you could be unwittingly giving out a whole host of permissions to users that they just don’t need. And whilst Carl, Rita and Oscar may not know how to abuse those rights, you can bet that a malicious actor with access to their account definitely does.

AD Oculos

(Latin for: obvious to anyone who sees it)

So what can we do about all of this? We don’t really want to rebuild our Active Directory environment… that would be a huge undertaking.

Instead, wouldn’t it be great if there was an easy way to be able to see how an attacker could potentially elevate their own privileges? A way to work out which paths they might take to attack our organisation? And then be able to manage those attack paths?

That would be absolutely fantastic. And guess what… it actually does exist. At Cognisys, we call it Attack Path Management or APM. A service that allows you to see which routes an attacker might take through your Active Directory or Azure Active Directory environment to give them privileges they can use to further their attack on your organisation.

Surprisingly, considering all the complexity we’ve discussed here, APM is a really simple service. Kind of a vulnerability assessment for your identities. But instead of looking at vulnerabilities per se, it looks at misconfigurations in your identity environment to show clear paths to potential trouble.

Of course, APM can’t provide all of the answers, and is no replacement for a hands-on internal infrastructure test, but it’s a great way to dip your toe into the water.

Drop me a line if you're interested in discussing with myself or Shaun Whorton how a review of AD could benefit your organisation!