Today Active Directory Security is mission-critical to organizational security worldwide and thus mission-critical to Cyber Security worldwide. On this blog, former Microsoft Program Manager for Active Directory Security, and today, CEO of Paramount Defenses, shares valuable technical insights on Active Directory Security.


Monday, June 5, 2017

The Impact of an Active Directory Security Breach / Compromise (Day 3)

Dear Microsoft,

Today is Day 3 of our advanced Active Directory Security school for you. Today's post too is partly non-technical (since we're covering this over 30 days, and it builds up for subsequent posts) but it's vital and must be addressed because as we help you better understand this, along the way, the world learns too, and so many organizations clearly need help understanding this.

We are shocked to see just how many IT personnel, IT managers, CISOs, CIOs and CEOs still don't understand the importance of Active Directory, and thus don't understand the impact an Active Directory security breach could have on their business.

So let's address this once and for all so that it is unequivocally clear for everyone, and we can move on discussing technicals.


Impact on an Active Directory Compromise / Security Breach - It's Game Over



From this point on, let there be no doubt about one fact - if indeed the security of an organization's foundational Active Directory deployment has been breached/compromised, then technically speaking, it's GAME OVER, right then and there. Period.

(Any one who would like to challenge the validity of this simple purely technical fact, may do so by leaving a comment below.)

That's right. From the Active Directory Domain Admin to the CEO, it's time to pack up, go home, and find another job, because believe you me, until they completely re-build the forest from scratch, he who knows what to do will have them for ETERNITY.

Only organizations that do not know better will continue to operate on that Active Directory forest, because they'd be operating on a compromised foundation, and if they continue to do so, and their perpetrators truly understand Active Directory security, then, from that point on, for as long as they continue to do so, their perpetrators will know (and could divulge) everything there is to know about that organization, tamper with anything, destroy anything at will etc. etc.



Here's why -

You see, when the security of your Active Directory deployment is compromised, the very fabric of trust i.e. the very foundation upon which the security of all IT assets in the IT infrastructure (powered by that Active Directory) depends, is compromised.

Consequently from that point on, short of rebuilding the entire IT infrastructure from the ground up, there is no way to get back to a trustworthy (provably known to be secure) state, because that is the only sure-shot way to provably (re-)bootstrap trust.

To find out why, please keep reading.

(Now while some might say suggest, contend and argue that in such cases simply using an Active Directory backup to perform an authoritative restore would be sufficient to restore the Active Directory to a previously known good state, in reality, that is hardly sufficient, and no organization that cares about its security should rely solely on doing so. To find out why, keep reading.)

First, let me clarify what I mean by an Active Directory security breach/compromise - by that I mean any situation in which someone has been able to directly or indirectly obtain what is tantamount to administrative access over Active Directory.

[ Quick Digression: For many (novices), that list usually simply is whoever is a member of Domain Admins and Enterprise Admins groups. Those who know a little more take it to be all accounts whose admincount value is 1. Those who truly know Active Directory security know its a little more complicated than that, as described here. ]

In the interest of brevity and completeness, let me first share a few things such an individual can do WITHIN Active Directory -
1. He/she can completely control and manage all Active Directory domain accounts, including all privileged ones
2. He/she can completely control and manage all Active Directory domain groups, both security and distribution
3. He/she can completely control and manage the computer accounts of all Active Directory joined computers
4. He/she can completely control and manage all group policies being deployed to all computers in the domain
5. He/she can completely control and manage all trust relationships
6. He/she can completely control and manage all service connection points, print queues and any custom data
7. He/she can completely control and manage all Active Directory configuration partition data
8. He/she can completely control and manage the entire Active Directory Schema 
9. He/she can completely control and manage the domain security policy 
10. He/she can completely control and manage the domain controller's security policy

In other words, he/she can completely control the cyber security of your entire Active Directory based IT infrastructure!

In short, if your foundational Active Directory is compromised, you just lost control of your entire IT infrastructure.

(By the way, the most important point I want to make is after the following section, so please keep reading.)





Business Impact of an Active Directory Security Breach

For the CEOs, CFOs, CIOs and any and all non-technical stakeholders, perhaps I should translate this into business parlance.


Should the security of an organization's foundational Active Directory deployment be breached/compromised, here's what the perpetrator could do -
1. Completely own your entire IT infrastructure
2. Launch an internal denial-of-service (DoS) attack that would cripple your entire IT infrastructure  
2. Logon as anyone (e.g. C*O, Domain Admin, Attorney, Engineer, Security Guard etc.) in your IT infrastructure
3. Obtain access to, divulge and/or destroy the entirety of your organization's IT assets i.e. all your trade/business secrets, all your product blue prints and source-code, employee, customer, legal, financial and other data etc.
4. Use the power of automation to easily, swiftly and effortlessly destroy and/or render the entirety of your organization's IT infrastructure (i.e. all your accounts, computers and access) virtually useless and unusable  
I could share more, but I think that to the wise, even just these few points alone, and the profound ramifications on business, of even any single one of them materializing, need not be spelled out. In short, organizations that are powered by Active Directory are only as secure as are their foundational Active Directory deployments. It really is as simple and as factual as that. Period.







Why an Active Directory Restore Isn't Sufficient

Here's the most important point I wanted to make - Once an admin, forever an admin!


You see, given the above, as I mentioned above, some might say that in the event that an Active Directory breach occurs, even if the perpetrator changed something WITHIN Active Directory, we can always get back to a known trustworthy state by simply performing an authoritative restore. They could say that, but they would be (very) wrong.

Here's why...

Take #4 above i.e. He/she can completely control and manage all group policies being deployed to all computers in the domain, and consider that this could easily be used to obtain administrative control over any computer in the domain, and this is just ONE of many things that someone who has been able to obtain administrative access over Active Directory can do OUTSIDE of Active Directory - i.e. obtain admin access to and change just about everything on any machine joined to that Active Directory.

For a simple illustration, lets consider a situation wherein he/she exercises his/her administrative control over Active Directory to leverage group policy to gain administrative control over and subsequently make any one of the following subtle changes on just any one (of who knows how many) machine(s) used by just any one (of who knows how many) Domain Admin(s) -



1. Installs custom malware on the machine, that could do various things, from logging and transmitting keystrokes to allowing remote access to that machine from half way around the world to ... <use your imagination> etc. etc.
2. (Assuming the computer account of this computer is a member of Domain Admins,) Configures a service to be installed and run on that computer that at a set future date would make a single subtle change in Active Directory (e.g. reset the password of the default Active Directory Administrator account) that would effectively result in the perpetrator being in a position to (effortlessly) regain administrative privilege over Active Directory.
3. (Or, the most effective one) Leaves a simple PowerShell script designed to run in Domain Admin context, and when one (i.e. a Domain Admin) logs on, it will simply run as him/her and quietly make a single subtle change in Active Directory (e.g. change the ACL protecting the Domain Admins group) that would effectively result in the perpetrator being in a position to (effortlessly) regain administrative privilege over Active Directory.


Note that I'm just talking about someone doing this on any ONE domain-joined machine on which a Domain Admin is known to log on to, (or as is in the case of #2 above, a machine whose account is a member of the Domain Admins group to begin with).

A perpetrator who has obtained administrative access over Active Directory once could make numerous such changes and with hundreds/thousands of domain-joined machines in the network, it would be practically impossible to identify each such change.

Now, why is this important?!

The reason this is so important is that, even if the act of performing an authoritative restore could get the organization's Active Directory back to a previously known good state, from that point on, there would now (still) be who knows how many backdoors planted by the perpetrator in the IT infrastructure that he/she could use to regain administrative control of Active Directory!

That is the Billion dollar point that organizations worldwide need to comprehend i.e. should an organization's foundational Active Directory be compromised, performing an Active Directory restore is not sufficient at all. Strictly speaking, the only way to get back to a known provably reliable / trustworthy (secure) state is to rebuild the entire IT infrastructure from the ground-up.





In Summary

In summary, today I just wanted to make one point -


Considering that not only could an Active Directory security breach result in a colossal cyber security incident that could cost an organization (in some cases, hundreds of) millions of dollars, but also that recovering from it could in itself be a massive, time- and cost-intensive undertaking, it is so much better to do all that you can to prevent your Active Directory from being compromised in the first place, than it is to get breached, and then recover from it!

In light of the above you can be the judge of whether or not IT personnel, IT managers, CISOs, CIOs and CEOs should profoundly understand the importance of Active Directory and the consequences of an Active Directory security breach.

That's it for today. Tomorrow, I'll shed light on Active Directory's vast attack surface because reducing the attack surface is one of the most effective proactive measures organizations can enact to prevent an Active Directory security breach.

Best wishes,
Sanjay


PS: Humor -
Today's post was partly motivated by a scenario we amusingly encounter on a daily basis - a Domain Admin from a multi-billion dollar organization will request an eye-opening trial of our incredibly powerful and unique tooling, (which is most nominally priced and can do for them in minutes what could take them years to do assuming they know how to do it, and) then request a price quote, and upon its receipt, say - "Oh, that's way out of our budget!"
On a lighter note, if such a nominal amount (i.e. a few thousand dollars) is way outside a huge multi-billion dollar organization's budget, to acquire tooling that could help prevent an Active Directory Security breach by helping them identify and exponentially reduce their current attack surface, perhaps they could consider borrowing some from the CEO/CFO/CIO/CISOs (multi-)million dollar paychecks.
I'll tell you what - just frankly tell us that no one in your organization understands this well enough yet, and we'll graciously gift it to you, our compliments, if it'll help. That's the least we can do for small (billion dollar) companies.
On a serious note, such a statement from a Domain Admin only shows that neither its middle not its senior IT management or Executive management yet understand the profound impact that an Active Directory security breach could have on the organization's business (, so perhaps someone can share today's post with them.)

1 comment:

  1. First off all congratulation of an excellent site and bring the issue of AD security to the forefront. AD and security (AD security in particular) has been a passion of mine too over the years, nice to find some like-minded people , and I look forward to reading the rest of your blog posts.

    One thing not mentioned on this particular post (probably mentioned elsewhere on your site) is unfortunately it is all too easy for someone with admin rights to AD (there are various ways to try an obtain admin rights) to place a hidden user account in AD using standard Microsoft tools, then granting this hidden account total control over AD. The hidden account will not show up on any reports done by say a Domain Admin or Enterprise Admin user as these people will simply not have the rights to see and therefore report on this hidden user. The hidden user could be in the Enterprise Admins group, but when an Enterprise admin lists the members of the group it does not show the hidden user and the group membership count shows nothing out of the ordinary. So this comes back to the restore question you pose here, e.g. at what point was the AD compromised (6 months back) and are you simply restoring AD with an already hidden account (back door for future attacks from the bad actor), or the more classic case of does the bad actor already have the KRBTGT hash (change twice but that is another subject).

    Thanks
    Ernest Brant

    ReplyDelete