Enumerate Domain Data (EDD): Powerview’s .NET Cousin

By Jason Downey
June 11, 2026

EDD: PowerView’s .NET Cousin

If you’ve done any Active Directory enumeration, you’ve probably used PowerView. It for a bunch of years was the gold standard, so much so that PowerShell is getting watched more closely every year. AMSI, script block logging, constrained language mode. The walls are closing in.

EDD, or Enumerate Domain Data, is a .NET implementation that covers similar ground. Built as a C# assembly, it can run through execute-assembly in Cobalt Strike without touching PowerShell at all. Think of it as PowerView’s cousin who went to .NET school and came back with fewer detection signatures.

What It Covers

The function list is honestly pretty stacked. You’ve got your forest and domain info pulls, computer enumeration, domain controller discovery, share enumeration, user and group queries, DACL inspection, SPN hunting, and custom LDAP filtering. If you’ve used PowerView, the concepts translate directly. EDD just does them in C# instead.

Where it gets really useful is the chained functions that tie multiple queries together across the entire domain. These are the ones I keep coming back to on engagements.

The Queries That Pay Off

The tool has a number of functions, specified with -f, that we use to tell the executable what to do.

GetReadableDomainShares
GetReadableDomainShares enumerates every share across the domain and tests whether your current account can actually read them. Not just lists them, actually checks access. Here is an example command:

EDD.exe -f GetReadableDomainShares -t 10

On a large domain this can take a while, so crank the thread count up with -t…but don’t get too carried away, especially if you’re trying to not get detected. What you get back is a filtered list of shares you can access with your current token. No more guessing, no more access denied messages one share at a time. I run this as one of the first things after getting a foothold because it immediately tells you where to start digging. Pair it with FindInterestingDomainShareFile from PowerView (be aware that this script is heavily signature) once you know which shares are readable and you’ve got a targeted hunt instead of spraying queries at shares you can’t even open.

FindDomainUser
FindDomainUser searches every domain-joined system for active sessions of a specific user or group. Run it with no arguments and it defaults to hunting for Domain Admins. Here are some ways the tool and function are used:

EDD.exe -f FindDomainUser
EDD.exe -f FindDomainUser -g “Enterprise Admins”

The -g is used to look for logged in users who are members of the specified group. This is your lateral movement roadmap. You need to know where high-value accounts are logged in so you can target those systems for credential harvesting or token impersonation. On a recent engagement we ran this, found a Domain Admin session on a workstation where we already had local admin, and the path to domain compromise basically drew itself. Alternatively, you can also use -u to look for a specific account instead of a whole group.

Note: The above technique isn’t as effective as it once was. A patch released by Microsoft in late 2023 prevents non-admin accounts from listing the users/accounts currently logged in to a system. So for this to work these days you need elevated access or to find a system where this patch has not been applied.

GetUsersWithSpns
GetUsersWithSpns queries the Domain Controller via LDAP to get a list of every domain account that has an associated Service Principal Name (SPN). This is the first step in Kerberoasting. Here is the usage:

EDD.exe -f GetUsersWithSpns

For every SPN that you identify you can request a TGS ticket (also known as a Service Ticket or ST) and crack offline. The real finds are the ones with weak passwords on high-privilege service accounts. I’ve seen organizations where the SQL service account was a Domain Admin with a password that Hackcat cracked in under a minute. The tool supports multi-threading across all of its functions, so if you’re querying a large domain you’re not sitting there watching a single thread crawl through thousands of objects.

Why It Matters on Engagements

We’ve been on assessments where PowerShell was locked down tight. Constrained language mode, aggressive script block logging, AMSI+AV/EDR cranked to eleven. Running PowerView in that environment is basically announcing yourself. Switching to EDD through execute-assembly (a feature that allows you to run .NET assemblies directly from memory without touching disk) gave us the same AD enumeration capability through a completely different execution path that the defensive tooling wasn’t keyed in on.

Every EDR vendor on the planet has signatures for PowerView. Running a .NET assembly through Beacon’s execute-assembly doesn’t trip those same detections because it’s a fundamentally different approach to doing the same thing. Same data, different delivery mechanism, way less noise.

For the Blue Team

If your detection strategy for AD enumeration is built entirely around catching PowerShell-based tooling, tools like EDD are going to sail right past you. Make sure you’re also monitoring for unusual LDAP query patterns and high-volume directory lookups from workstations that normally don’t make them. PowerShell isn’t the only way to enumerate Active Directory anymore, and your detections need to reflect that.

About Jason Downey, Security Consultant

Jason Downey has over ten years of professional experience in IT and information security ranging in a variety of roles in network security roles with additional experience in systems administration. Jason has spoken in front of various audiences ranging from youth initiatives to major security conferences, while creating informational content on SiegeCasts and forward-facing marketing channels. Jason excels at a variety of penetration testing tactics and is well known for his vishing and social engineering expertise.

Certifications:
CRTO, GPEN, GCIH, CCNA R&S, CCNA Security, CEH, CHFI