Coming Soon... How to Thwart Sneaky Persistence in Active Directory

Folks,

As I briefly mentioned earlier, a few weeks ago, at the Black Hat Conference 2017 (which we skipped) on Cyber Security, two fine gentlemen made an interesting presentation titled An ACE Up The Sleeve - Designing Active Directory DACL Backdoors.

In this presentation, a whitepaper on which can now be downloaded from here, its authors have presented what may seem like a ground-breaking revelation to those uninitiated to the subject, but what in reality is actually just Active Directory Security 101.

With full respect to its authors, I will say that for someone who may have been relatively new to this subject (which most cyber security pen testers, ethical hackers and hackers are these days) and coming from a mainstream pen-testing/attack background (i.e. generally focused on and employing local credential-theft attack-vectors) they got close to actual sneaky persistence in AD.


Incredulously and amazingly, perhaps because a majority of cyber security experts (both, defenders and attackers) and IT pros may not know Active Directory Security that well, this presentation has been garnering a lot of attention, including at Microsoft.

Here's proof - In the last ONE month alone, Microsoft's Advanced Threat Analytics (ATA) Team has published TWO blog posts in response to this presentation (on Sep 18 here and on Oct 11 here), so this clearly seems to have Microsoft's attention!

Speaking of which, here's a quote from Microsoft's latest blog post regarding this topic/presentation - "In general, this is a very important goal for an attacker and is a big part of a successful mission performed either by a nation state or by a hacker group."

Wow!   Hmm.    Keep reading ;-)





How to Easily Thwart Sneaky Persistence in Active Directory

I may no longer officially be an employee of Microsoft, but I am former Microsoft Program Manager for Active Directory Security, and just because I work for a different company now, that neither diminishes my knowledge nor my passion to help the world.


So, in a few days, right here, to help organizations worldwide, including to help my fine colleagues at Microsoft who seem to be struggling to figure out how to deal with this, I will share just how EASY it is to thwart sneaky persistence in Active Directory -

If you truly understand Active Directory Security, then you know that there are far greater challenges facing most organizations worldwide, so to help put this behind them, and to adequately address that whitepaper, I'll pen an insightful post on the subject.


BTW, in the whitepaper, regarding Defenses, the authors state - "Some defenders may believe the detection of these types of backdoors is a lost cause... ...the primary method for detection and investigation remains properly tuned event logs for DCs...  ... one interesting defensive tool is the use of AD replication metadata." etc. It appears these wonderful folks are trying too hard!

Oh, and the most amusing part is to see Microsoft try even harder, and I'm quoting this verbatim from here - "This does sound like an issue...  ...so, this made me think - Is there a way we can identify all the objects to which I don't have permissions?" ;-)


This one's actually quite simple.  The answer, coming up, in a few days...

Best,
Sanjay

CEO, Paramount Defenses



Update - October 24, 2017 > Here it is - How To Easily Identify & Thwart Sneaky Persistence in Active Directory

Did Microsoft Just Reveal How Little It May Seem to Know about Active Directory Security In Speaking of Access Control List Attacks & Defense?

Folks,

Three (3) days ago i.e. on September 18, 2017, Microsoft's Advanced Threat Analytics (ATA) Team posted a blog post titled -

Active Directory Access Control List - Attacks and Defense

If you haven't read it, I highly recommend that you read it, NOT because you'll learn anything at all, but only because it reveals volumes about just how little Microsoft may actually seem to know about Active Directory Security, ACLs, attacks and defense.

When you read it, it will likely be unequivocally clear to you as well as to just how little Microsoft seems to understand about not just the sheer depth and breadth of this monumental challenge, but about the impact it could have on organizations worldwide!


You see, if you understand the subject of Active Directory Security well enough, then you know that Active Directory access control lists (ACLs) today don't just impact organizational security worldwide, they likely impact national and global security !

That said, in that post, the best Microsoft could do is concede that this could be a problem, wonder why organizations might ever need to change AdminSDHolder, falsely assume that it may not impact privileged users, praise a massively inaccurate tool for shedding light on this attack vector, and end by saying - "If you find a path with no obstacles, it probably leads somewhere!"

Oh, and the very last thing they tell you that is their nascent ATA technology can detect multiple AD reconnaissance methods.


You really have to read it to get what I'm saying. Seriously, here's all this post mostly touched upon - a quick overview of Active Directory ACLs, an overview of AdminSDHolder protection in Active Directory, and a note on delegated permissions in AD.

Oh, and they thanked whoever made that massively inaccurate tool called Bloodhound for bringing ACLs to the front, literally!

By the way, that baby of a tool, Bloodhound just recently came out, and I've been saying this since for half a decade now, here. Maybe to learn a thing or two re AD Security, the good folks at Microsoft should Google "Active Directory Privilege Escalation"


Perhaps the one line that stood out most (of many lines that stand out) is -

"Why would you want to change AdminSDHolder manually? 

To date, our team hasn't found a solid reason!"

Microsoft, when you publicly ask such a question, you reveal how little your team may know about Active Directory Security.

(Dear Microsoft, FYI, and in case you didn't know, likely the number #1 thing most organizations need to do to secure/lockdown access to/on all their default privileged user accounts and security groups in Active Directory, is to change AdminSDHolder!)

Oh, and has it ever occurred to you that many mature organizations may choose to implement their own custom AD delegation models, in which case they may not even end up relying on default AD administrative accounts and groups, in which case your point concerning ACL based vulnerabilities not impacting privileged users and groups in Active Directory would be moot.

You see, here's what they should have said - "We care deeply about cyber security and we understand that left unaddressed, this could pose a serious cyber security risk to our customers. Be rest assured that Microsoft Active Directory is a highly robust and securable technology, and here's exactly how organizations can adequately and reliably identify and lock-down privileged access in their Active Directory deployments, leaving no room for perpetrators to identify and exploit any weaknesses."

The reason I say that should've been the response is because if you know enough about this problem, then you also know that it can actually be completely and sufficiently addressed, and that you don't need to rely on detection as a security measure.

Sadly, since they don't seem to have a clue as to this, you're likely not going to get that response from Microsoft.

BTW, to appreciate how little Microsoft seems to understand about this huge cyber security challenge, you'll want a yardstick to compare Microsoft's response with, so here it is (; you'll want to read the posts) - Active Directory Security School for Microsoft.



Finally, if this is how little Microsoft seems to understand about such a profoundly important cyber security challenge concerning your own technology, I cannot help but wonder how well their customers might actually be protected in its recent Cloud offering!

It is now abundantly clear that Microsoft may need help, so in days to come, I'm going to help them out.

Best wishes,
Sanjay