Manual Enumeration - PowerView

PowerView is a PowerShell script that contains a large collection of functions designed to make Active Directory enumeration easier and more effective from a red team perspective. It is part of the PowerSploit framework and can be downloaded from here.

Since PowerView is a script and not a compiled binary, we typically load it directly into memory. This helps reduce disk artifacts and is closer to how real attackers operate.

To explore all available PowerView commands, the official documentation is a useful reference.


From an offensive (red team) perspective, this sequence is usually one of the first steps after gaining domain access. It helps you quickly answer key questions:

• What domain am I in?
  
• Which users exist?
  
• What groups are defined?
  
• Who belongs to sensitive or business-critical groups?

Finding Interesting User Attributes

During AD enumeration, some user attributes are especially valuable for follow-up attacks such as password spraying or credential harvesting.

For example, dormant or inactive accounts often have weaker passwords. We can identify them by checking:

• The last logon time
• The last password change time

If a user has not changed their password since before a password policy update, it may indicate a weak or legacy password.

Knowing which operating systems are in use helps us tailor exploits and choose appropriate attack paths.

This immediately tells us where the servers are and which hosts are likely user workstations.

At this point, we have lists of users, computers, and groups. The next step is understanding relationships between them.

One of the most valuable questions is:

On which machines do we have local administrator access?

PowerView provides the Find-LocalAdminAccess function for this purpose:

This function attempts to connect to the Service Control Manager (SCM) on each host using the OpenServiceW API. Access to the SCM database requires SC_MANAGER_ALL_ACCESS, which is only granted to administrators.

If the connection succeeds, it means our current user has local admin privileges on that system.

Knowing who is logged into which system can directly lead to credential theft opportunities.

PowerView uses the Windows APIs NetWkstaUserEnum and NetSessionEnum to enumerate sessions:

This failure is expected in modern Windows environments.

Why Access Is Denied

Enumerating sessions remotely requires administrative privileges. The permissions are controlled by the registry key:

We can inspect its permissions with:

The output shows that only Administrators and SYSTEM have full control. In older versions of Windows, Authenticated Users were allowed to read this information, but this was removed to follow the principle of least privilege.

Despite this limitation, these techniques are still worth knowing because older systems are common in real-world environments.

Another useful tool is PsLoggedOn, part of the Sysinternals Suite. It shows which users are logged on to a system using two methods:

• Local logins: It enumerates registry keys under HKEY_USERS, extracts user SIDs, and converts them into usernames.
  
• Remote sessions: It uses the NetSessionEnum API to identify users connected via network resource shares (such as SMB).
  

Important Limitation: Remote Registry Dependency

PsLoggedOn depends on the Remote Registry service to enumerate local logon information remotely. This service is disabled by default on most Windows workstations and is typically only enabled manually by administrators or on newer Windows Server systems. If Remote Registry is not running, PsLoggedOn cannot retrieve local user session data remotely.

Example usage

Here we see:

• davidadmin is logged on locally
• john is connected via a resource share

If john has local admin access on this system, we may be able to dump credentials belonging to davidadmin, who likely has higher privileges.

From a red team perspective, understanding service accounts and Service Principal Names (SPNs) is one of the most valuable reconnaissance techniques in an Active Directory (AD) environment. SPN enumeration often reveals critical services, their locations, and accounts that may have elevated privileges—all without generating noisy network traffic.

Service Accounts and Execution Context

Every application running on Windows must execute within the security context of an operating system user.

• If a regular user launches an application, it runs under that user’s account.
• If the application is launched automatically by the operating system (for example, as a service), it runs under a service account.

Windows includes several predefined service accounts designed for isolation and limited access:

• LocalSystem
• LocalService
• NetworkService

These built-in accounts are commonly used for simple or isolated services that do not require access to domain resources.

Domain Service Accounts and Active Directory Integration

More complex applications—such as Microsoft Exchange, Microsoft SQL Server, or Internet Information Services (IIS)—often need to access resources within the domain. In these cases, organizations use domain user accounts as service accounts.

When a service is integrated with Active Directory, it is associated with a unique identifier called a Service Principal Name (SPN). An SPN links:

• A specific service (for example, HTTP or MSSQL)
• Running on a specific host and port
• To a specific service account in Active Directory

This association allows Kerberos authentication to work correctly, but it also creates a valuable source of information for attackers.

Managed Service Accounts vs. Legacy Service Accounts

To improve security, Microsoft introduced Managed Service Accounts (MSAs). These accounts automatically manage passwords and reduce administrative overhead. However, MSAs could only be used on a single server, making them unsuitable for large or distributed applications.

To solve this, Group Managed Service Accounts (gMSAs) were introduced in newer versions of Windows Server. gMSAs can be used across multiple servers but require modern Domain Controllers.

Because not all organizations meet these requirements, many environments still rely on traditional domain service accounts with manually managed passwords. These legacy accounts are often:

• Over-privileged
• Poorly monitored
• Long-lived

From an offensive standpoint, they are prime targets.

Why Enumerate SPNs?

SPNs can reveal:

• Which services are running in the domain
• On which servers and ports
• Which accounts are used to run them

Instead of performing noisy port scans, an attacker can simply enumerate SPNs in Active Directory to identify active services and their configurations.

Enumerating SPNs with setspn.exe

Windows includes a built-in tool called setspn.exe, which is available by default.

Example:

The -L switch lists all SPNs registered to a specific account. In this case, we can clearly see that:

• The iis_service account is linked to an HTTP service
• The service is running on web04
• Port 80 is in use

This confirms that the SPN is directly associated with the iis_service domain account.

Enumerating SPNs with PowerView

Another powerful method is using PowerView, a popular PowerShell toolkit for Active Directory reconnaissance.

Example:

This command enumerates all domain accounts that have SPNs registered. From this output, we immediately identify a web service running under the iis_service account.

Resolving the Target Server

Once a hostname is identified, finding the IP address is trivial:

At this point, we know:

• The service type (HTTP)
• The server hostname
• The port (80)
• The service account
• The server IP address

All without scanning the network.

One of the most valuable skills for an attacker inside an Active Directory (AD) environment is understanding who has access to what. This process is known as enumerating object permissions. Misconfigured permissions are extremely common in real-world domains and often lead directly to privilege escalation.

How Permissions Work in Active Directory

In Active Directory, everything is an object: users, groups, computers, shares, organizational units (OUs), and more.
Each object can have multiple permissions applied to it.

These permissions are defined using:

• Access Control Entries (ACE) – Individual rules that allow or deny specific actions.
• Access Control List (ACL) – A collection of ACEs attached to an object.

Each ACE answers a simple question:

Is this security principal allowed or denied a specific action on this object?

How Access Is Evaluated

Imagine a user in the domain tries to access a domain file share.

1. Access Token Creation: When the user attempts access, Windows creates an Access Token. This token contains:
   • The user’s SID
   • The SIDs of all groups the user belongs to
   • Privileges assigned to the user

1. ACL Comparison: The target object (the share) compares the user’s access token against its ACL.
   • If an ACE allows the requested action → access is granted
   • If no matching permission exists → access is denied

From an attacker’s point of view, this means:

If we can control or influence ACLs, we can control access.

ACE Types That Matter to Attackers

Active Directory supports many permission types, but only some are truly interesting for offensive operations. The following rights are especially valuable:

Among these, GenericAll is the most dangerous.

Enumerating ACEs for a Specific User

Let’s enumerate the permissions applied to the user john.

Two important fields immediately stand out:

• ActiveDirectoryRights
• SecurityIdentifier (SID)

Resolving SIDs to Readable Names

SIDs are unique identifiers for AD objects, but attackers prefer readable names.
We can resolve them using PowerView:

Now the result becomes clear:

The RAS and IAS Servers group has ReadProperty permissions on the user john.

What Information Is Most Valuable?

From an attacker’s perspective, the most important fields are:

• SecurityIdentifier → Who has access
• ActiveDirectoryRights → What level of access they have

Since GenericAll represents full control, it is usually the first permission we search for.

Identifying Who Has GenericAll Permissions

Next, we check which accounts have GenericAll access. After resolving relevant SIDs, we get:

The presence of CORP\john in this list means:

The user john has GenericAll permissions on a sensitive object.

This is a serious misconfiguration.

With GenericAll, john effectively has full control and can perform actions such as:

• Modifying group memberships
• Changing sensitive attributes
• Escalating privileges

Abusing GenericAll: Privilege Escalation

As an attacker, we can now abuse this permission.
For example, adding a user to a privileged group like Management Department:

Verifying the Attack

To confirm that john has been successfully added:

The attack was successful.

From a red team perspective, enumerating domain shares is one of the simplest and most effective ways to uncover sensitive information inside an Active Directory (AD) environment. File shares often contain configuration files, scripts, backups, and sometimes even clear-text credentials. Many of these shares are readable by regular domain users, making them a valuable target during internal reconnaissance.

Enumerating Domain Shares with PowerView

To discover available file shares across the domain, we can use the Find-DomainShare function from the PowerView toolkit. This command queries domain computers and lists the shared resources they expose.

At first glance, this may look like routine infrastructure, but every listed share is a potential source of valuable data. As attackers, we should assume that anything readable by a domain user is worth inspecting.

Identifying Interesting Shares

Not all shares are equally valuable. Default administrative shares such as C$ and ADMIN$ usually require elevated privileges. However, custom or misconfigured shares like backup, docshare, Tools, or sharing are often accessible to low-privileged users and may contain sensitive files.

Our goal is to manually review each accessible share and look for:

• Configuration files
• Backup archives
• Scripts and automation files
• Hardcoded credentials
• Password reuse hints
• Network or system documentation

Even a single text file can reveal usernames, service accounts, or passwords.

SYSVOL: A High-Value Target

One of the most interesting and commonly overlooked shares is SYSVOL.

Why SYSVOL Matters

• SYSVOL is hosted on Domain Controllers
• It stores Group Policy Objects (GPOs) and logon scripts
• By default, all authenticated domain users can read SYSVOL
• It is mapped internally to %SystemRoot%\SYSVOL\sysvol\<domain_name>\

Because of its permissions and content, SYSVOL is a frequent source of credential exposure.

Exploring the SYSVOL Share

We can browse SYSVOL directly from any domain-joined system:

Key Directories to Inspect

• Policies: Contains Group Policy configurations. In some environments, these may include:
  • Embedded credentials
  • Passwords stored in XML files
  • Legacy Group Policy Preferences (GPP)
• Scripts: Often contains:
  • Logon and logoff scripts
  • Startup scripts
  • PowerShell or batch files with hardcoded credentials

This article demonstrated how manual Active Directory enumeration with PowerView provides a reliable, stealthy foundation for internal red team operations. By systematically identifying users, groups, computers, sessions, SPNs, permissions, and domain shares, we gain the visibility needed to understand trust relationships and uncover real-world misconfigurations. Mastering these techniques is essential for turning initial domain access into meaningful attack paths without resorting to noisy scanning or guesswork.

Key Takeaways

• PowerView enables comprehensive, in-memory Active Directory enumeration with minimal artifacts.
  
• User, group, and computer reconnaissance reveals privilege boundaries and lateral movement opportunities.
  
• SPN enumeration is a stealthy and effective way to identify high-value services and service accounts.
  
• ACL and permission analysis often exposes direct privilege escalation paths such as GenericAll abuse.
  
• Domain share and SYSVOL enumeration frequently leads to sensitive data and credential exposure.
  

In practice, these techniques become most powerful when chained together thoughtfully—linking enumeration results to lateral movement, credential access, and privilege escalation workflows covered earlier. Focus on mastering them in controlled lab environments, refine your operational security to remain stealthy, and always operate ethically by practicing only in authorized and legal environments.