Ethical Threat Insights

Active Directory is finally dead

Spencer Alessi — Mon, 19 Oct 2026 13:00:00 +0000

This is a flawed statement that couldn’t be further from the truth.

Active Directory has survived basically every technology trend that was supposed to make it irrelevant.

The directory wars. Novell NDS/eDirectory was the serious competitor when AD launched. AD won that one outright. OpenLDAP and later FreeIPA found their niches, but neither became the enterprise default for Windows environments.

“The PC is dead.” First thin clients and Citrix, then mobile and BYOD. Phones don’t domain-join. Most Macs don’t either. But AD often still owns the Windows estate those users sit in front of, plus much of the infrastructure behind the VDI session.

Federation was going to make the directory less important. Instead, AD FS became another layer attached to Active Directory. Then cloud identity arrived, and Okta, Ping, and Azure AD/Entra often federated with AD or synchronized identities from it. The authentication experience changed. The directory underneath it often didn’t.

Cloud was going to empty the traditional enterprise datacenter. In 2018, Gartner’s Dave Cappuccio predicted that 80% of enterprises would shut down their traditional datacenters by 2025. Yet on-prem infrastructure is still everywhere. A 2025 poll of 246 IT pros conducted by a principal engineer on Microsoft’s AD team, and later reported by IS Decisions, found 93% describing their environments as hybrid, 54% still running on-prem workloads on AD, and 36% saying they would never be cloud-only.

Azure AD / Entra was going to replace AD. Instead, Entra became Microsoft’s modern cloud identity platform. It did not simply move Active Directory to the cloud. It doesn’t replace Kerberos, NTLM, LDAP, Group Policy, domain join, or machine accounts. Microsoft literally has a separate product—Entra Domain Services—to provide those traditional capabilities for workloads that still need them.

Zero Trust and “identity is the new perimeter.” That didn’t kill AD either. It layered modern controls like MFA, Conditional Access, device trust, and identity protection around increasingly hybrid identity environments. Meanwhile, AD often remained underneath, handling Windows authentication and authorization.

Security failures were supposed to force a rip-and-replace. Mimikatz. Golden Tickets. NotPetya. Years of ransomware crews abusing Active Directory.

And yet Active Directory still hasn’t been retired.

Instead we moved to implement: tiering, PAWs, LAPS, protected users group, fine-grained password policies, logon restrictions, restricting/removing legacy protocols like RC4 and LLMNR and NTLMv1, adding better/additional monitoring, and much more.

As recently as December 2025, Microsoft was still describing AD DS as “central to enterprise identity.”

Containers and “servers don’t need a domain anymore.” And that’s true for a lot of new workloads. But plenty of ERP systems, file servers, SQL deployments using Windows authentication, print infrastructure, NPS, AD CS, and legacy applications still depend on Active Directory.

Those dependencies are what many organizations continue to rely on.

Now we’re entering the AI era.

This one will be incredibly difficult for Active Directory to contend with too. AI agents, non-human identities, autonomous workflows, SaaS everywhere, and entirely new ways of thinking about authentication and authorization will put enormous pressure on a directory designed in the 1990s.

Maybe this is finally the thing that kills it.

But if the last 26 years tell us anything, betting on the next technology trend finally killing Active Directory has been a losing bet.

Long live Active Directory! 🖖

All the best
Spencer

Find these hidden Active Directory attack paths

Spencer Alessi — Mon, 12 Oct 2026 13:00:00 +0000

After 1,000’s of hours inside internal networks I’ve developed a “spidey sense” for finding Active Directory attack paths. Here’s 4 attack paths to look for in your environment and how to find them.

1. Help Desk with control over Tier-0 accounts: this is actually one of the more common issues I see. It’s not always exactly help desk. Sometimes it’s “database admins” or “service desk” or “application admins” or similar.

What to look for: Check your IT administrative groups, ones where the members should not be domain admins or equivalent, and look for where they have elevated permissions on tier-0 resources.

This topic is exactly what we’re going to be talking about on the upcoming IS Decisions webinar. They’ve sponsored me to be a guest and I’m super excited to share what I know about AD security and making your environment harder to attack.

It’s this Wednesday at 11am Eastern. Click here to save your spot.

2. Finance group members of local admins: on more than one internal pentest I’ve seen low-privilege non-admin groups, such as finance, be members of a group that’s then added to local administrators on all workstations.

What to look for: check your non-admin groups to ensure they are not members of administrative or privileged groups, like local admin groups.

3. Domain Users/Computers with certificate abuse potential: this is a catch all for both ESC1 and ESC4, both of which can result in privilege escalation to Domain Admin by either directly requesting a vulnerable certificate template or by modifying the settings of a template.

What to look for: check your certificate templates for those that low privilege users can enroll in, that allow supplying an alternate SAN, are enabled for client authentication and don’t require manager approval. That’s ESC1. Then check the permissions on each template to ensure low privilege users don’t have FullControl or modify rights.

4. SQL credentials on shares & SQL running as Domain Admin: this is a multipart issue where SQL credentials are found in web.config files on shares. Then it turns out, more often than not, that the SQL service is running as a Domain Admin. This is unfortunately very common to see.

What to look for: audit file shares looking for credential files, like web.config. These often have plaintext credentials in them and are a prime target for attackers. Then check your SQL accounts to make sure they are not domain admins, if at all possible.

This is really just scratching the surface. This list doesn’t even include some of the wildest attack paths I’ve seen, like that one time when the Everyone group had FullControl at the root of the domain!

Run through this list in your own environment and even if you don’t find these exact issues, I bet you at least find mistakes you can fix.

Go make your environment harder to attack.

All the best
Spencer

By the way, you should absolutely register for the upcoming IS Decisions webinar I am a guest on. Here’s the link. It’s gonna be fun! See you there!

What “doing basic security well” means

Spencer Alessi — Mon, 28 Sep 2026 13:00:00 +0000

It’s no surprise to anyone that AI is making it easier and faster to attack organizations. That means that doing “basic” security well has never been more important.

The first time organizations got caught not doing the basics well was when ransomware hit the scene. If you were not enforcing strong passwords and MFA and your internal network was swiss cheese, you got caught, and it hurt, badly.

The next big shift is thanks to AI.

Threat actors are empowered more than ever to attack faster and against more targets, at the same time. This is made evident when we hear of attacks like this.

But “do the basics” is frustrating advice when you’re the person responsible for actually doing them.

So let’s make it useful.

We can think about doing the basics in the context of coverage, verification, and upkeep.

Does the control cover the systems that matter?

Can you prove it works?

Will you notice when something changes?

Here’s what it may look like in practice:

Least privilege: Check tier-0 resources, like Domain Controllers or the Domain Admins group, to ensure there’s no unnecessary or dangerous permissions. If any are found, determine why, then remove/restrict what you can. Then document the rest and monitor for future changes.
Credential management: Look for exposed passwords on file shares, document management systems, wikis, ticketing systems, SharePoint, etc. For those found, identify the owner and educate them on the risks. Then purge/restrict access. Potentially rotate credentials if risk of compromise was present.
Attack surface reduction: Disable legacy SMBv1/NTLMv1 protocols in the domain. Then setup additional monitoring to catch when those protocols resurface. Monitoring should catch both attempted legacy usage and settings being re-enabled.

AI can help an attacker move faster, but it doesn’t make a recently changed password valid or a removed permission usable.

That’s why this hardening work matters.

You’re reducing the opportunities an attacker can take advantage of, and how much depends on your team reacting in time.

Making your environment harder to attack makes it harder for both humans and AI.

Do the work. Stop attacks. Sleep well at night.

All the best
Spencer

PS - If you’re curious if your defenses would hold up against a real attacker, that’s literally my day job. I’ve performed 1,000s of hours of internal pentesting and I’d love to help you strengthen your Active Directory environment. If you’d like to see if your organization is a fit for how we do internal pentest, book a 30-min call here.

7 ways to harden Active Directory

Spencer Alessi — Mon, 21 Sep 2026 13:00:00 +0000

For all the the IT admins asking, how do I make Active Directory MORE defensible. This is how…

Remove SMBv1: Check older NAS devices, scanners, and applications for SMBv1 dependencies so you know what needs updating before removing it.
Enforce SMB signing: Start with your file servers and NAS devices and verify that they support signing and whether they actually require it.
Enforce LDAP signing: Identify applications making unsigned LDAP connections to your domain controllers and work with their owners to secure those connections.
Enforce LDAP channel binding: Check applications using LDAP over TLS, such as LDAPS, for channel binding support before enforcing it on domain controllers.
Implement least privilege: Admin rights and delegated AD permissions for accounts with more access than their jobs require. Pay close attention to tier-0 resources.
Enforce AES for Kerberos: Investigate accounts still using RC4 and confirm they have usable AES keys and compatible applications before disabling RC4.
Disable NTLMv1: Look for legacy devices and applications using NTLMv1, resolve those dependencies, then configure policy to refuse LM and NTLMv1.

I’ve loosely ordered this in terms of difficulty to implement, however, your experience and results will vary.

By the way this comes straight from the Active Directory hardening series by Jerry Devore.

These changes help reduce opportunities for attackers. That’s what hardening is all about. Reducing attack surface.

Now that you know what to harden, the question becomes how do you operationalize this.

First, pick one item on the list. Identify the requirements to do that thing.

For example, before removing SMBv1, check whether an old NAS, scanner, or application still uses it. Address that dependency, test with a small group, then expand the rollout.

It would be a big mistake to try and tackle all seven at once. You can make a lot of progress by working on these little by little, consistently, over time.

Reply and tell me: Which of these would be hardest in your environment?

Long live Active Directory!

All the best
Spencer

By the way - I’m speaking at Workplace Ninjas US in January. It’s in Scottsdale Arizona January 11-13th. I’ll be debating Merill Fernando on the topic of, “Is Active Directory defensible?” If you do anything with the Microsoft ecosystem including Security, this event is perfect for you. You should totally come. Check out the full agenda and speaker list here.

This attack path should not be possible

Spencer Alessi — Mon, 14 Sep 2026 13:00:00 +0000

It should NOT be possible for a threat actor to social engineer a user, to run quick assist, to execute malicious PowerShell, here’s why.

If you don’t use Quick Assist, this initial access attack path should be 100% avoidable.

How?

By removing and restricting the tools and capabilities the threat actor relies on for this to work.

Here’s what to do:

Uninstall/disable Quick Assist via GPO or Intune

GPO	Computer Configuration > Administrative Templates > Windows Components > App Package Deployment > Remove Default Microsoft Store packages from the system. Enable it and select Quick Assist only.
Intune	Settings catalog > Administrative Templates > Windows Components > App Package Deployment. Enable Remove Microsoft Store apps with dynamic lis or the older Remove Default Microsoft Store packages from the system setting and set Quick Assist to True. Leave other apps unselected.

Block Quick Assist via Application Control product, AppLocker, or WDAC (ps, block all other RMMs found in https://LolRMM.io)
Restrict PowerShell to only users/accounts that need it. A majority of end users at most orgs don’t ever need it.

This is such a high value move for defenders.

Every client I’ve recommended this to, who’s acted on this advice, has thanked me later.

You get double and sometimes triple the benefit by restricting PowerShell because it’s used by threat actors to:

Download additional malware and tools
Perform recon
Execute their lateral movement & privilege escalation techniques

This makes my life (as an internal pentester) super miserable and makes attacking your network very difficult.

Simulating real-life threat attacker TTPs is what my team and I do day in and day out. We live and breathe it.

If you’d like my team’s help finding out what could happen if one of your users gets compromised, book a free discovery call and we’ll see if our approach is a fit.

Block RMMs, restrict PowerShell, defend attacks, sleep well at night.

All the best

Spencer

By the way - If you use Applocker, this tool I made, called ApplockerInspector, can help you find dangerous and misconfigured rules. Hope you find it useful.

Mitigate cyber attacks with this one tool

Spencer Alessi — Mon, 07 Sep 2026 13:00:00 +0000

If your users can download or install software, then they can get infected with malware.

This report by Microsoft (Counterfeit installers to system compromise: Tracking a deceptive software download campaign) is a great example of why Application Control can be such a strong defensive control.

In the report, threat actors created counterfeit software-download websites in order to impersonate trusted vendors and distribute malicious installers. The campaign has targeted users looking to download popular software like Microsoft Edge.

The thing I want to stress is this is completely defendable, with the right controls.

What should you use to defend against this?

If you use Microsoft Defender, use this ASR Rule:

Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Prevalence in this rule means, has this executable ever been seen before on any of your endpoints where MDE is installed.

This has blocked me from running my “malicious” tools many times during internal pentests.

Of course, I also recommend not relying on EDR alone.

Invest in a solid Application Control product that’s purpose built for this.

I am personally fond of MagicSword (not sponsored but they are friends and their threat-driven approach is really neat) and ThreatLocker.

Of course it takes time to implement these and there’s a right way and a wrong way to do this. But that’s a topic for another newsletter.

What can you do today?

Search the last 30 days for executables & MSIs launched from Downloads, Temp, and user profile paths
Identify unknown installers and programs
Validate if those installers and programs are legitimate and required
If they are required add exceptions in your application control software (if you have one). If they are not needed or are found to be suspicious, block them and investigate as needed

Unmanaged software and lack of application control is a big risk to organizations.

And with AI agents now in the mix it’s only going to get harder.

And that’s just one of a dozen endpoint risks we commonly see during internal pentests.

It’s also why we start our internals pentests on your endpoint, with a standard user account. So we can find out what an attacker could actually do once they get in.

If you’d like to see if the way we do internal pentests is a fit for you, fill out this form and we will be in touch to schedule a free discovery call.

SEE IF WE’RE A FIT

If you can stop unmanaged software from running on your endpoints, you can stop a majority of malware infections.

All the best
Spencer

PS - I’ve seen Application Control projects completely bomb. Start small, test small, have a super easy exception workflow and communicate with your users as much as possible.

Eliminating Active Directory attack paths

Spencer Alessi — Mon, 31 Aug 2026 13:00:00 +0000

Attack paths don’t appear by accident. Does this sound familiar?

"We'll fix it later"
"It hasn't cause any problems yet"
"Tom does it this way, but I prefer my way"
"We don't have time to fully implement that right now"

It all adds up quietly. Until one day, an attacker finds the needle in the hay stack.

That one permission, one group, one account, that one "little" mistake, that was not supposed to be there, but was.

It's not because IT admins, despite the stereotypes, are lazy. It's because of inconsistent operational discipline.

Inconsistent operational discipline has a compounding affect. That’s what really creates technical debt.

Much like financial debt, it's rare to pay off this debt in one fell swoop.

What you need is consistent operational discipline. A topic that's too out of scope for this conversation.

So instead, here's my recommended (& practical) recommendations for eliminating attack paths in Active Directory, in realistic time frames.

One Day

You're trying to prevent the "Domain Admin by Lunch" situations...

Remove non-essential users from tier-0 groups (Domain Admins, Enterprise Admins, etc.)
Disable unused accounts (especially service accounts)
Fix DCSync permissions on anything that isn’t true Tier-0
Rotate passwords for service accounts (make them as long as possible)
Check for insecure permissions on the root of the domain (and all other tier-0 users, computers, groups and OUs)

One Week

Focus on key attacker phases, like lateral movement and privilege escalation...

Deploy LAPS to all workstations & servers
Implement fine-grained password policies (why not, it's free)
Lock down GPO logon rights so Domain Admins can’t touch workstations
Clean up unconstrained delegation
Fix dangerous ACLs (Use ADeleginator and make sure to check Domain Users, Authenticated Users & Everyone)
Identify dangerous certificate templates & document a plan to address them (Fix ESC1, ESC4, ESC5 ASAP)

One Month

Now you're getting into reducing attack surface and "blast radius"...

Begin separating admin accounts (especially from daily use accounts)
Restrict PowerShell Remoting to/from admin subnets only
Review all Security Groups for unnecessary users (privilege creep)
Ensure the built-in Firewall is enabled on all workstations and servers
Document everything else you have found but can't fix yet

One Year

Now you're getting into reducing attack surface and "blast radius"...

Begin separating admin accounts (especially from daily use accounts)
Restrict PowerShell Remoting to/from admin subnets only
Review all Security Groups for unnecessary users (privilege creep)
Ensure the built-in Firewall is enabled on all workstations and servers
Document everything else you have found but can't fix yet

These are obviously not complete lists, but they sure are some heavy hitters.

Let's be honest for a minute, as you're going through this list, how many can you say you've done?

If you're in the "most of them" boat, then you're seriously doing an awesome job. Keep the progress going.

If you're not in that boat, why not? What do you think is holding you back?

Fear of breaking things?
Don't know how?
Lack of clarity?
No time?
No buy-in or support?

I know it's not because you don't care. You might be the only one who does.

I've pentested a lot of organizations.

I was a sysadmin for 10+ years before that.

I've seen a lot of issues, I've fixed a lot of issues.

It's almost never a technical problem.

It's a:

People problem
Process problem
Resource problem
Skill problem
Leadership problem

You don't have to know everything in IT and security. It's knowing what matters most, removing blockers and making progress anyways.

Save this list of recommendations. Come back to it after a day, a week, a month, a year and more....and see just how far you've come.

I'm rooting for you. You got this. 💪

All the best
Spencer

PS - If you want even more quick wins to secure Active Directory, check out this podcast I did back in 2023. Yes, it’s all still relevant today.

Assume one employee gets hacked. Now what?

Spencer Alessi — Mon, 24 Aug 2026 13:00:00 +0000

After 150+ pentests and thousands of hours inside internal networks, I’ve realized that after an employee or endpoint is compromised, post-compromise risk comes down to three questions.

These three questions form a framework I created to help think through these risks.

It’s called PAC, which stands for Privileges, Access, and Control.

Privileges - What can they do?

Start with what rights and permissions does the compromised identity already have?

Things to consider:

Local administrator rights
AD group memberships
Delegated AD permissions
Entra/Cloud roles
File/share permissions
Application privileges

Keep in mind that what seems benign to you may not be so for a threat actor. Remember they are trying to inflict harm in exchange for money (most of the time).

Access - Where can they go?

What systems, services, data, networks, applications, and identities can the attacker reach from that starting point?

Think of:

Servers
Workstations
Network segments/VLANs
Administrative interfaces
File shares
Internal applications
Databases
SaaS applications
SharePoint
Document management systems

This is effectively the “blast radius” of the initial compromise.

Control - What can they Control?

What can an attacker ultimately impersonate, manipulate, take ownership of, or otherwise abuse?

Things like:

Another user’s account
An administrator account
Security groups
Group Policies
Logon scripts
Certificate templates
Remote access protocols (WinRM, SMB)
Authentication protocols (LLMNR, NTLM)

This is where the first two parts of the framework (Privileges & Access) are combined into post-exploitation compromise.

A real life example starting from a compromised user on a domain joined windows computer:

The threat actor dumped the SAM database (Domain Users were in local admins
The password was sprayed against all hosts and found the local admin password was being reused on multiple servers
The threat actor logged into to the server as a local admin via RDP
The threat actor abused a scheduled task running as a Domain Admin, to add the original compromised user to Domain Admins. (No Alert)
The threat actor performed a DCSync from the original compromised host, stealing all domain credentials and essentially, fully compromised the domain

These issues were discovered over the course of a work week, but only took minutes to fully abuse end-to-end.

This example was not from a threat report.

This is how one of my recent internal pentest engagements went.

Fortunately we found and fixed these issues together with the client before anything bad could happen.

If you’re not sure what would happen in your environment after a user or endpoint becomes compromised, you’d get great value from an internal pentest.

That’s what I do week-in and week-out. If you want help making your environment more secure, book a free discovery call and we’ll talk about how I can help.

DISCUSS MY NEXT PENTEST

Remember these 3 simple questions:

What can they do? —> Where can they go? —> What can they control?

All the best
Spencer

PS - smart IT teams know the goal isn’t to make compromise impossible. It’s to make sure one compromised employee doesn’t become the thing that takes you out.

The best ways harden Active Directory

Spencer Alessi — Mon, 17 Aug 2026 13:00:00 +0000

Most people get Active Directory hardening wrong. They think they need to add security controls and tools. Do this instead...

I was a sysadmin for 10 years, I’ve pentesting hundreds of internal networks (thousands of hours), and the one common trait among organizations who do hardening well is, first they delete.

Hardening is the process of reducing opportunities for attackers.

In other words, deleting or removing unnecessary features, permissions, and attack paths.

Ex. Disabling the Print Spooler on Domain Controllers because it can be easily abused in coerced authentication attacks.

What should you delete to harden Active Directory?

Legacy Authentication Extinction — Remove outdated authentication protocols that attackers commonly exploit to steal credentials and move laterally.
- Example: Disable NTLMv1 across the domain
Kerberos Service Trust Reduction — Reduce unnecessary Kerberos trust relationships and service account exposures that can be abused for privilege escalation.
- Example: Remove unused SPNs from service accounts
Directory Credential Exposure Elimination — Eliminate stored credentials and other sensitive secrets that attackers can extract from Active Directory environments.
- Example: Remove passwords stored in Group Policy Preferences (GPP) & file shares
Authentication Relay Erasure — Remove conditions that allow attackers to relay authentication requests and gain unauthorized access.
- Example: Enable LDAP Signing & Channel Binding on domain controllers
Quick note…In a recent internal pentest I was able to validate the organization had properly enabled these controls such that all my attempts at relaying attacks failed. I would have fully compromised their domain. But I was stopped cold.
Privileged Identity Mobility Restriction — Limit where privileged accounts can log on and operate to reduce opportunities for credential theft.
- Example: Prevent Domain Admins from logging into workstations
Directory Replication Path Elimination — Prevent unauthorized accounts from accessing Active Directory replication capabilities that can expose password data.
- Example: Remove Replicating Directory Changes permissions from non-admin accounts
Certificate Trust Path Reduction — Remove insecure Active Directory Certificate Services configurations that enable certificate-based attacks.
- Example: Fix exploitable certificate templates, like ESC1, ESC2, etc.
Domain Controller Surface Area Pruning — Reduce the number of services, features, and applications running on domain controllers to minimize attack opportunities.
- Example: Disable the Print Spooler service on domain controllers
Directory Network Segmentation — Restrict network access to Active Directory systems so only authorized users and systems can communicate with them.
- Example: Allow RDP to domain controllers only from designated admin jump servers/PAWs
AD Data Exposure Reduction — Limit unnecessary access to Active Directory information that attackers use for reconnaissance and attack path discovery.
- Example: Follow the principle of least privilege to restrict access for users where it’s not needed

Some of these are quicker wins than others.

Removing credential files from shares is easier than restricting NTLM across your domain.

Every environment is different.

So how do you know what to remove and in what order?

By focusing on exploitability, in your unique environment.

That’s one of the questions we help answer for organizations with our internal pentesting engagements.

What can be exploited and how bad would it be…

Book a discovery call with me to see how we can help harden your Active Directory environment through pentesting.

Book a discovery call

The key to hardening is identifying what’s a prime target for attackers, then eliminating, reducing or restricting that thing.

Do this and you make your environment harder to attack.

All the best
Spencer Alessi

PS - OWASP recently created a Top 10 Subtractive Hardening list for Active Directory, which aligns perfectly to what I’ve always been preaching. It was the inspiration for this weeks newsletter. Hallelujah!

PPS - Long live Active Directory! ✌️

Use these tools to secure Active Directory

Spencer Alessi — Mon, 10 Aug 2026 13:25:53 +0000

Tools are a means to an end. If you only have a hammer, everything looks like a nail. Pick the right tool for the job.

As you know my day job is pentesting. Internal pentesting specifically with a passion for Active Directory and the Microsoft stack.

So when it comes to securing Active Directory you might think I would be recommending that you use “offensive” tools like BloodHound and Certify and others.

But I’m also a former sysadmin. I did IT for 10+ years. So I know what it’s like to be pulled in 100 different directions, working on 7 projects at a time, putting out fires and having to patch and fix pentest findings and do everything else that comes with a IT job.

While those “offensive” tools are great, they don’t come without some drawbacks. Namely, they are harder to use when you’re getting started. Bloodhound for example is more difficult to get setup and running and then to learn how to use it.

And when you’re already stressed and on the clock you need tools that are going to provide you value quicker and easier.

That’s not to say there’s anything wrong with BloodHound or other more complex tools. They are great and necessary and I’d encourage you to learn them in time.

But if you’re after quick-wins, low hanging fruit and security hygiene-related items, these are some great tools to start with.

PingCastle - 170+ rules related to Active Directory security misconfigurations and hygiene issues. They call it a “health check.” Free & commercial. Used to be a solo business made by Vincent Le Toux but is now owned by Netwrix.

PurpleKnight - Similar to PingCastle. AD security health check and hygiene. Free & commercial but it goes by a different name I believe. Made by Semperis, who has an all star team of Microsoft MVPs. Some I even call friends.

Locksmith - hands down the best AD CS auditing tool there is. It shows you what’s wrong and gives you powershell snippets to fix the issues. Free. Made by Jake Hildreth.

ADeleginator - a wrapper around a tool called ADeleg, a AD delegation management tool. Use this to find where unsafe groups and unsafe permissions. Like Everyone with FullControl over the root of the domain. Free. Made by me.

NetTools - The AD Swiss Army knife. Can do a ton of things. But it can be used to audit permissions extremely well. It highlights dangerous permissions so you know exactly what to review. Free. Made by Gary Reynolds.

There are no silver bullets in security, no one tool to rule them all. Every tool has its place. Every tool has pros and cons. Tools only get you so far.

It’s still up to you to read and internet and fix the issues you find, which as you know, is why security is so hard.

Lastly, I want this to serve as a reminder to myself and to all of us that many if not all of these tools would not exist without the countless hours and research and effort of those who have created and shared open source tools. Now and in the past.

We all stand on the shoulders of giants. Recommending one tool doesn’t in any way invalidate the effectiveness of any other tool.

Use the right tool for the job.

All the best
Spencer

PS - I did a webinar on how to harden Active Directory. If you haven’t seen it, I think you’d really get value from it. Watch it here.

Why EDR isn't enough anymore

Spencer Alessi — Mon, 03 Aug 2026 13:55:41 +0000

EDR is one of the best investments you can make. But after performing thousands of hours of internal pentests I’ve come to realize, it’s just not enough.

It doesn’t matter what EDR is in place or who you have for SOC/MDR, blind spots are inevitable because they are features of those capabilities.

EDR is great for detection malicious activity on endpoints. But what if an attacker is not on one of your corporate-controlled endpoints?

MDR is great and there some really good providers out there, but unfortunatly they don’t know your environment very well.

Suzie running PowerShell? Maybe that’s normal…

Because EDR is not perfect (no product can be) and because MDR providers are not continuously tuning per-client/per-environment, it’s not unreasonable to remain undetected for several days during an internal pentest.

During that time, I’m normally making quite a bit of noise on the network. Stuff like, enumerating shares, making a bunch of LDAP requests, etc.

That’s where NDR shines and why it’s so needed. NDR will detect recon activity well before EDR captures suspicious endpoint activity.

I’ve also seen first hand where incidents were detected by NDR well before anything “malicious” happened on an endpoint. This happens because EDR is not looking at the telemetry needed to identify this activity.

So what do you do?

Well, if you’ve dismissed NDR because the ROI didn’t seem compelling, I’d encourage you to take another look. Keep in mind that it’s not a replacement for EDR. It actually compliments it really well.

I’ve see two products in action, and I can say they appear to be really solid:

Corelight and Darktrace.

This is not an ad, just my opinion and a place to start looking if you’re new to this.

Implement NDR, detect threats sooner, keep your environment safe.

All the best
Spencer

PS - NDR can be expensive and take significant time and investment and tuning. Don’t let that deter you. It’s worth it. Hard work matters.

3 App Control Rules To Never Break

Spencer Alessi — Mon, 27 Jul 2026 13:00:00 +0000

Application control is a powerful technique…but only if you use it wisely. A single weak or misconfigured rule can open the door for attackers.

I’ve seen this first hand during internal pentests.

One time, the client had locked down their endpoint really well. I was struggling to find any way to get my tools running.

But then I noticed they had a rule that allowed a specific binary by name. This binary no longer existed on the system. So guess what I did?

I ran all my tools as oldbinary.exe.

It takes time and effort to continuously tune and maintain your application control tools, but I promise you it’s worth it.

Here are the 3 application control rules you should never break:

1) Avoid drive roots (like C:\), user-writable folders, wildcards (*), or UNC paths. Attackers look to drop malware where your rules are weakest.

2) If you allow “any binary” from a publisher or forget to set an upper version bound, you’re letting attackers have the upper hand, by allowing any version of the software.

3) Avoid assigning rules to Domain Users, Everyone, Authenticated Users, or BUILTIN\Users. You might as well not use application control if that’s the case.

This is just a starting point really. These are three of the most dangerous mistakes, but there are certainly many others.

By the way, these rules apply no matter tool what you’re using: AppLocker, WDAC, MagicSword, ThreatLocker.

Now I want to leave you with some free resources.

AppLocker Inspector, written by me, can be used to audit policies for weak, misconfigured and dangerous settings.

AppLockerGen, written by the awesome Michael Haag, simplifies the process of generating AppLocker XML policies, providing a user-friendly interface to create, merge, and manage rules effectively.

LOLBASLine, again by Michael Haag, is cool because it can be used to assess the presence and execution capabilities of Living Off The Land Binaries and Scripts (LOLBAS) on Windows systems.

I see misconfigured application control products all the time during internal pentests. I’ve become quite good at testing and evaluating the effectiveness of those tools. If you’d like help, book a call and lets chat about it.

All the best
Spencer

PS - Remember, attackers don’t need all your rules to fail…just one. Audit your application control rules.

Windows Misconfigs Keeping Hackers Employed in 2026

Spencer Alessi — Mon, 20 Jul 2026 13:00:00 +0000

“Ransomware Threat Actors are very good at the basics, and this shows against companies that aren’t.”

- SANS DFIR Aug 2023

Ethical Threat Insight: Windows Misconfigs That Shouldn’t Exist in 2026

I still find these in well-managed environments, and yes, attackers know it.

I’ve spent countless hours pentesting Windows and Active Directory environments, and these are some of the biggest and most recurring issues I see.

Weak Local Admin Control – Shared local admin passwords and no LAPS? That’s pretty much guaranteed lateral movement for threat actors. But that’s not all…
Insecurely Installed/Configured Software - Where software gets installed at the root of C:\ which then gives that folder insecure permissions, for example.
Lack of Patching 3rd Party Software - Like when you have Adobe, Java, and a bunch of other non-Microsoft software on your endpoints, but you don’t patch them regularly.
Weak Endpoint Security - Having EDR is great, but it’s not the saving grace we all hoped it would be. Sharp IT teams know about this…
Insecure services & Tasks - This is where software gets installed, sets up a scheduled task or a service but does so insecurely. Like giving everyone the ability to modify the service binary of the script that’s running from the scheduled task.
Unrestricted PowerShell – Constrained Language Mode and Application Control are very strong defenses against ransomware gangs. But audit mode is not enough…
MFA on RDP but PSRemoting Not Restricted - I know this is a bit of a curveball, but I see this often. By default on Windows Server PSRemoting is enabled and IT admins who are not aware may miss restricting this.

Now that you know what these common Windows misconfigs are you, the task becomes identifying them in your environment.

Which is actually quite easy, once you know what to look for.

I did a webinar last year where I walked through these seven misconfigs, showed real-world attack paths they enable, and gave practical fixes you can roll out immediately.

If you’re an IT admin or work with Windows in any way, I’d definitely check it out.

You can watch it here.

All the best
Spencer

PS - These are not issues that your typical vulnerability scanners will find. You’ve got to hunt for them yourself.

The fastest way to find your detection gaps

Spencer Alessi — Mon, 13 Jul 2026 13:00:00 +0000

I’ve been doing internal network security, (traditional Active Directory environments), for 15 years. The difference between a mature security program and those who get breached, is how well they detect threats.

One of the best ways to improve at this is by doing Purple Teaming.

Purple Teaming can mean different things for different people. To me it’s to answer the question, “if something goes bump on my network, will I know about it.”

If you’ve never done a Purple Team, here’s my framework for getting started.

1-Start with goals

What do you want to accomplish by purple teaming?

What attack techniques do you want to test?

Are there specific attack techniques you’re concerned about?

The most important thing is to have a plan and have goals in mind that you want to work towards.

For example, maybe you had a recent incident and the lateral movement done by the threat actor was not alerted on. It would be a great idea to run those techniques in your environment again. Then build new detections for the things you missed.

2-Identify TTPs

Next is to look at your business, verticals, industry, where you do business, with who. All that stuff. Then compare it to the threat groups that may likely target you.

Then you look up their playbooks and TTPs, and document the stuff they do. Then you can replicate them in your next purple team.

If you still can’t find much or don’t know where to start, I encourage you to check out Atomic Red Team. It’s an open source (free) library of tests designed to test your organization's security controls.

For example, on a recent purple team engagement I did, the client wanted to see TTPs from INC ransomware. So we researched that group, identified their common tactics and integrated them into the purple team engagement. This was a huge success for the client.

3-Run them in your environment

This should go without saying but you of course want to know what it is you’re running. That’s why test frameworks like Atomic Red Team are so nice. They are pre-vetted by some great security researchers. And there are hundreds upon hundreds of techniques pre-built for you to test.

In order to generate traffic and telemetry and potentially alerts, you need to run these techniques in your environment.

Run them on a typical end-user endpoint, where all your typical security products are installed.

Take your time here. Don’t rush through this process.

It takes time for logs and events to make it to your EDR and SIEM.

The last thing you want to do is blow through a bunch of techniques and not know exactly what is what on the backend in your monitoring systems.

4-Document!

Make sure to keep good notes of what techniques you ran, capturing specific commands. This is important for reproducing them later once you’ve created alerts.

You should also document:

the time you ran the thing
the time it finished
if it was blocked
if there was an alert
which security product alerted on it
what the severity was when the alert was generated

This is super important for tracking progress. Ideally, as you mature and improve you want to be alerting on a higher percentage of techniques, faster.

5-Don’t stop after you’re done

What I mean by that is, after you’ve run all your tests you should have a bunch of data.

Some techniques will have been blocked and alerted on.

Some techniques will not.

The next step is to identify what techniques should have been blocked and/or alerted on.

Your task now is to develop rules for those in your EDR/SIEM. Then re-test those techniques.

Purple team engagements can and should be something you do on a recurring basis. There’s always things to test. Once is never done.

We only do a few purple team engagements per quarter, to keep the value high. If you’re curious if they can help you, I’d love to chat.

Book a call see if it’s a fit » First come first serve

PS - Organizations who do purple team engagements, catch threat actors more than those who don’t. Do a purple team.

How to identify attack paths in Active Directory without BloodHound

Spencer Alessi — Mon, 06 Jul 2026 13:00:00 +0000

I’ved logged more than 1,000 hours of internal pentesting in 2025 alone. I promise you, attack paths are everywhere. And attackers are counting on you not caring enough to find and fix them.

And you know, someone is going to find them, sooner or later.

It might be a pentester, it might be you, or it might unfortunately be a threat actor with initial access to your environment.

I think we both agree it’s probably better that you (or someone like me ;) ) find them.

The problem though is that running tools like BloodHound can be a bit confusing. It’s also a bit of a learning curve.

And waiting for your annual pentest isn’t always the best option either.

So here’s how to find attack paths in Active Directory without BloodHound, without waiting until your next pentest.

When you boil this down to it’s smallest components, in order to identify attack paths you have to know two things: 1) where to look, and 2) what to look for.

1) Where to look

The first and most important places to look for attack paths are your critical and privileged resources. Think, Domain Controllers, Domain Admins, Enterprise Admins, etc. What we typically refer to as tier 0 or wherever you have critical processes or sensitive data.

You want to look here first because misconfigurations related to these resources are the most impactful.

When I say look at your Domain Controllers, I’m saying look at the Computer object itself in Active Directory. The permissions, the Organizational Units, group membership, etc. More on this in the next section.

This is what I refer to as inbound control. You want to enumerate all the possible actions that can be taken upon that critical/privileged resource.

Then, you want to investigate what I call “unsafe groups.”

The initial list for those are: Authentication Users, Domain Users, Domain Computers, Everyone.

These are unsafe because they generally involve a large number of low-privileged users.

The thing you want to look for here is outbound control. In other words, what are the possible actions that these resources can take on other objects/resources.

Example:

The unsafe group, Everyone, has “FullControl” (more on this in a minute) over the root of the domain. If you’re like “holy crap how?!” My thoughts exactly.

But I’ve seen this on two separate internal pentests. Crazy right…

2) What to look for

A large number of Active Directory attack paths rely on misconfigured or dangerous permissions in some way. Not all of them, but a lot of them. So let’s focus on that.

What permissions you might be asking?

Here’s a good starting point. I call these “unsafe permissions.”

By the way, this is not an exhaustive list.

Writeallproperties
Genericall
FullControl
WriteDACL
ReplicateDirectoryChanges & ReplicateDirectoryChangsAll (DCSync)
ResetPassword

Of course, context matters a lot here. It’s not dangerous for Enterprise Admins to own and have FullControl over certificate templates.

However, if the “Everyone” group has FullControl over the root of the domain, that’s really bad.

Now that we know where to look and what to look for we need to know how to actually find these issues that create attack paths.

First and foremost you can obviously use Active Directory Users and Computers (ADUC). From there, make sure to enable “Advanced Features.”

Then you can inspect the permissions of objects in Active Directory. You can view group membership and Organizational Unit structure.

The next way to identify these issues that lead to attack paths is with one of my favorite tools, ADeleginator.

It’s a tool I wrote, which is a wrapper around ADeleg, that finds many common misconfigured delegated permissions in Active Directory.

I also wrote a detailed guide for using ADeleg/ADeleginator.

Finding these issues I mentioned above is as simple as downloading a file and running a PowerShell script.

Here’s the steps:

Copy Invoke-ADeleginator.ps1 to your system or git clone >
Download ADeleg.exe and place it in the same folder as Invoke-ADeleginator
Open PowerShell, navigate to the location of Invoke-ADeleginator.ps1 and dot source it using: . .\Invoke-ADeleginator.ps1
Run with: Invoke-ADeleginator

Now just review the resulting CSV files.

It’s literally that simple.

`What now?`

Now you block some time off on your calendar, maybe an hour or two, and try this in your environment. Best case, you don’t find anything. Win!

Worst case, you do find things. Also a win!

I’ve done A LOT of internal pentesting. I know how this can seem daunting and intimidating and time consuming.

But I promise you, it’s worth it.

All the best Spencer Alessi

PS - This is quite literally my day job, so if you want help finding attack paths in your environment, you can book a discovery call with me here. I’d love to help.


Powered by beehiiv



Hackers hate this...
Spencer Alessi — Mon, 29 Jun 2026 13:00:00 +0000

    If you’re serious about detecting threat actors in your network BEFORE they do real harm, you need this.
Ethical Threat Insights: Deception, the best ROI in Security
There is a misconception that more security alerts == safer environment.
That’s so not true
Better alerts == more actionable evidence.
That means you’re responding to what matters most, not when your server goes haywire because of a benign scheduled task.
Out of the box EDR is a false positive mess. Because of that SOC teams end up sending you alerts that have been generated without context.
It’s just a single alert in a sea of event logs and noise.
There’s a better way to catch threat actors. That’s with deception.
Deception is the best ROI in security because:
It’s inexpensive (especially compared to “traditional” security products: EDR, Email Gateways, Firewalls, etc.)
It can be deployed places traditional security cannot (ICS networks, slack, ticketing systems, sharepoint, file shares, web sites, aws, github, entra, etc.)
Most security tools nowadays spit out hundreds of alerts daily, if not more.
That’s costing someone time and resources to triage.
What we really need is the alerts have to be:
Accurate
Actionable
Otherwise, you’re spending money just to be distracted.
Too many IT teams are sleeping on deception because they don't see the "ROI."
The ROI is in the data and telemetry. It's the high-fidelity, low false positive nature of it that makes it so useful.
So what if you go 364 days without an alert from it.
That 1 time when you do get an alert is WAY MORE meaningful than all those false positives your EDR generates.
Lastly, there was a study done that indicated that even announcing or letting attackers discover the presence of deception may be enough to alter their behaviors in your environment.
What that means is they make change up their tactics, perform more actions, make mistakes, get caught which affords you the ability to kick their tail right out of your network…
If you need more convincing or just want to learn how to make hackers hate their lives if they are to ever land in your environment, check out the recording of my recent deception webinar.
https://youtu.be/BJ2ORyPEkiQ?si=58sVu0rUUpxTxHjU
All the best 
Spencer Alessi
PS - if you want to deploy deception in your environment but don’t know where to start, reply to this email and I’ll help you get started.

Powered by beehiiv
  


Mythos hacked the NSA in a few hours, so what?
Spencer Alessi — Mon, 22 Jun 2026 13:00:00 +0000

    Mark Warner, the vice-chair of the Senate Intelligence Committee was quoted on June 11th saying this about Mythos:
“When the head of the NSA and Cyber Command came and said, this tool broke into almost all of our classified systems. Not in weeks but in hours”
This went mega viral on the internet this weekend thanks to an article in the Economist where the Mark Warner quote was cited.
Is Mythos really that capable?!
First of all no. This is here say and speculative at best.
There’s also the fact that there’s always an agenda with these types of things. You have to consider WHY someone in a political position (independent of party) is saying what they are saying.
I’m not going to get into that here, but just keep in mind that there are tremendous forces of money, power and greed at play here.
This Mythos "hacked the NSA" hype is peak AI theater. It's like someone announcing they've invented a revolutionary new nail gun, then when pointing it at a piece of plywood that's been sitting in the rain for decades and full of rot, are completely shocked when it drives a nail straight through. "Look at this incredible technology!"
We would be surprise if it didn't. But I don’t believe that’s what happened.
Let’s assume though, there is some sliver of truth to this statement.
What does it mean to those of you reading this, and to me.
Little to nothing. Here’s why…
If you’re reading this, than I know you’re part of the proactive crowd. You’re the type of person who’s staying up-to-date on current events as much as threat actor TTPs.
You follow folks on social, subscribe to newsletters and advisories and you generally know way more in advance when “stuff” happens than a majority of people.
That means you also know that “Mythos” or “Opus 4.8” or  is not hacking anyone or anything.
Of course I mean by itself.
These AI systems and models, currently, must be driven and guided by human operators, in order to carry out sophisticated cybersecurity tasks.
Of course we know that many environments are literally Swiss cheese, but even still, the presence of an attack path in Active Directory doesn’t mean an organization will be compromised or that a compromise of such nature would bring that organization down, or that that attack path would even be abused in the first place.
And while the government is slow and doesn’t innovate quickly, they sure as heck have solid cyber operators.
The kind of operators that “hack” our adversaries. This isn’t a small feat.
So naturally it’s not too much to think that with the awesome capabilities of AI, they would be able to be even more effective.
That’s what’s happening here.
Well-resources, capable human operators have used a tool to be more effective.
We are not at the point yet where you can tell Claude to hack a target and it can complete any kind of sophisticated attack in series with zero involvement from a human. We’re just not there yet.
But, take a capable and smart pentester, red teamer, security researcher, malware developer, reverse engineer, threat hunter, etc. and give them money and powerful tools and they will be able to do amazing things with it.
This AI thing that’s happening right now is a an arms race but not in the way you might think. It’s an arms race for humans to equip themselves with knowledge and understanding and skills on how to use these tools more effectively.
There will be better models year after year for what I think will be many years to come.
Get used to the marketing hype and the news cycles around this.
Keep a level head and focus on doing the foundational things well, and you’ll be just fine.
Hack the planet! 🤘
All the best 
Spencer Alessi
PS - If you get value from my newsletter, the best way to “give back” is to refer your friends, colleagues, teammates, etc. to subscribe. Super duper appreciate you!!🙏🙏

Powered by beehiiv
  


Security Alerts No One Sets Up (But Should)
Spencer Alessi — Wed, 17 Jun 2026 13:00:00 +0000

    What you don’t watch for could be exactly what attackers exploit.
Most orgs watch for malware, phishing, account compromise and a whole host of other attacks.
But so often I see, what I would consider low-hanging fruit detections, missed by security teams.
Here’s a few high value alerts not enough orgs have implemented:
Active Directory enumeration - especially when privileged (tier 0) resources are touched, like Domain Admins. But also, looking at volume of LDAP traffic from a single host can also be a great indicator of recon activity. By the way, according to a recent CrowdStrike report, 50% of TTPs they see are recon activities.
Adding users to local admins on workstations - this one should be obvious, but in reality, I’ve almost never seen orgs alerting on this. The telemetry is there in your EDR waiting for you to use it.
Lateral movement with RDP, PSRemoting, SMB - if you’ve done the work to understand your environment, then writing rules to detect when an admin is attempting to RDP to a domain controller from Susie’s workstation should be easy. But most don’t do the upfront work to get to this point.
Hosts without EDR installed - I suspect this should be fairly easy for most orgs. If there are hosts in your network, that you control, that support EDR and it’s not installed, you should know it immediately.
Here’s a few other ideas for alerts that not enough folks have turned on:
Service Account Logins (outside expected systems/times)
New Domain Admins being added
Disabling Security Tools (AV, EDR, logging)
Mass File Access (precursor to data theft or ransomware)
Too many organizations rely too much on out of the box configurations of their security tools.
It’s especially evident with EDR.
There are few tools that are truly set it and forget it.
If you don’t create any custom alerts and you don’t review your existing alerts for effectiveness and completeness, you’re leaving room for attackers.
And by the way, one of the best things you can do from a security monitoring perspective, is to setup deception assets.
Whether you’re trying to better detect enumeration/recon, lateral movement, privilege escalation or even credential access…
Deception can be used very effectively for all those use cases.
If you want to see how deception can be used at various stages of an attack, watch the recording of my deception webinar.
Deceptively Defensive: What Kevin McAllister Can Teach Us About Cyber Defense
All the best 
Spencer Alessi

Powered by beehiiv
  


Why Active Directory Attack Paths Matter
Spencer Alessi — Mon, 08 Jun 2026 13:00:00 +0000

    Active Directory is still the control plane for identity in many organizations. If AD falls, everything connected to it becomes easier to compromise.
Active Directory (AD) has been "dead" for many years. Much to the industries chagrin, it continues to be the present in a majority of organization, from small business to large enterprises.
Just look at the stats:
_¹_{The stats below are from a conversation on the}_{hybrid identity protection podcast}_by_Semperis_{with guest}_{Cliff Fisher}_.
86% of organizational workloads STILL touch Active Directory in some way.
Only 53% of organizations expect to get to 50-50 (Active Directory - Entra ID) within the next 5 years.
19% of organizations expect getting to 50-50 (Active Directory - Entra ID) will take 10-20+ years.
Now let's look at how many businesses there are, just in the United States, with lets say over 10 employees.
NAIC census data showing businesses of each employee count category as of December 3, 2024:
Employee Count Number of Businesses
10–19 809,398
20–49 409,391
50–99 151,979
100–249 89,573
250–499 33,612
500–999 19,380
1,000+ 24,399
That's roughly 1.5 million businesses with 10+ employees. Statistically speaking, that’s a lot of organizations who still use Active Directory.
The numbers are hard to ignore. Active Directory is alive and well and continues to be a major infrastructure component for many, many organizations.
That means that Active Directory will continue to be attacked.
That also means that learning to defend Active Directory will continue to be important.
What is an Active Directory Attack Path?
In Active Directory, an attack path is the route an attacker can take from an initial compromised user or machine to a high-impact target by abusing credentials, permissions, group membership, misconfigurations, and vulnerabilities.
They can be as simple as compromising Suzie in Accounting's workstation, dumping credentials, and moving laterally to a Domain Controller.
Or they can be as complex as compromising a standard user, identifying an Active Directory misconfiguration that allows access to a server, which then allows a threat actor access to another forest, that then leads to additional misconfigurations, that then leads to full domain compromise.
Here's how it looks from the attackers perspective:
Compromise Suzie in Accounting’s workstation
See that a domain admin previously logged into that workstation
Steal that admin's Kerberos ticket from memory
Reuse that domain admin ticket to access a domain controller
Perform a DCSync attack and compromise the entire domain
As a defender, it's our job to make sure that doesn't happen, by breaking the attack path.
Attack Path Pre-requisites
In order to have a complete attack path, an attacker typically needs:
1) Access: The threat actor first has to get into the environment
2) Credentials: They need credential material for privileged accounts
3) Targets: They need somewhere to use the credentials they have obtained
4) Weak or Missing Defensive Controls: They need hardening/mitigation controls to NOT be in place
What Defenders Should Do
This is not news to you but AD is old. It’s a collection of inherited configurations. And unfortunately, most organizations do not have a clear picture of who can control what.
If you want to get a clearer picture of how an attacker would go after your environment, I recommend creating an attack path kill list.
An Attack Path Kill List is just a fancy saying for identifying where potential attack paths exist in your environment, then mitigating or eliminating them with defensive controls.
Identify Attack Paths
Prioritize Remediations
Fix, Re-test
Repeat
This all sounds daunting, I know. But you do not secure AD by fixing random findings forever. And in fact, you don’t even need to fix everything. 
You secure AD by understanding how an attacker would move, then removing the paths that let them succeed.
Once you understand how the attacker wins, you can start breaking the chain.
All the best 
Spencer Alessi
PS - This is quite literally my day job, so if you want help finding attack paths in your environment, you can book a discovery call me with here, and I can show you how I can help. I’d love to work with you.

Powered by beehiiv
  


The Active Directory permissions no one checks
Spencer Alessi — Tue, 02 Jun 2026 13:00:00 +0000

    Attackers love shortcuts. Hidden insecure permissions are their express lane to Domain Admin.
Ethical Threat Insight: Finding Hidden Insecure Permissions in Active Directory
Delegated permissions in Active Directory are specific access rights that are granted without requiring that user be a member of a security group.
It’s a way of assigning more granular permissions.
However, it’s all too easy to make mistakes when delegating permissions.
What are the risks of insecure delegations?
Privilege Escalation
Lateral Movement
Service Abuse
Increased Attack Surface
How does insecure permission normally happen? Take this for example…
You want to give the Help Desk group permissions to reset passwords for end users, so you give them “FullControl” of the default Users OU.
Well, you’ve now inadvertently given out more control than you intended to.
FullControl includes way more rights than just resetting passwords and now any user within the Users OU can be compromised by an attacker whose able to obtain a Help Desk account.
Or maybe worse, Help Desk can now make even bigger, more costly mistakes.
How do we find these hidden insecure permissions?
One of my favorite ways is with the free tools, ADeleg and ADeleginator. 
ADeleg is a super awesome, simple Active Directory delegation management tool. Use this to find insecure permissions.
ADeleginator is a tool I created to automate finding common insecure delegations. It’s a wrapper around ADeleg, and also a super simple awesome tool.
Here’s what you do:
Download and open ADeleg
Once ADeleg is open click View -> Index view by -> Trustees
That puts the trustees on the left hand side and the resources on the right. That way we can click on a trustee and see the permissions it has on a given resource.
Then on the left hand side, open up the Global dropdown and look for several key trustees. You can consider these “unsafe users/groups”.
Everyone
Authenticated Users
Domain Users
Any other user/group you want to look for, like Help Desk
Review the permissions granted on the resources in the window on the right and look for permissions that may be dangerous. We want to look for things like:
Write all properties
Create/delete child objects
Ownership of a resource
Add/delete delegations
Write attribute
Validated write
Change the owner
Change password
Reset password
Action today: My challenge for you today. Pick one OU that holds sensitive accounts (like IT staff or executives). Run a permissions check with ADeleg. If you find “Everyone” or “Authenticated Users” anywhere in the list, tighten it up.
☕ If you would like to learn more about this. I walk through real examples of hidden AD permission risks in this webinar.
Watch it here 👇
📹The Stinky Truth About Active Directory Permissions
All the best 
Spencer Alessi
PS - I’m giving a talk + hands on workshop (with a full AD lab) for ContinuumCon! It’s called Killing Active Directory Attack Paths Once and For All. In it, I am going to show how you can use Authentication Policies & Silos to completely eliminate lateral movement attack paths in AD. Hope you come check it out! The conference is streamed for FREE online but if you want to play with the labs you have to buy a ticket. But it’s super affordable. I honestly don’t know how they do it.

Powered by beehiiv

Employee Count	Number of Businesses
10–19	809,398
20–49	409,391
50–99	151,979
100–249	89,573
250–499	33,612
500–999	19,380
1,000+	24,399