This article walks through three authentication paths that impacket-net supports — NTLM hash (Pass-the-Hash), Kerberos ticket, and AES key — and demonstrates how each one enumerates Active Directory objects against a domain controller in the ignite.local lab environment.

Table of Contents

• Impacket-Net: A Red Team Utility
• Lab Environment
• Enumerating Domain Users
• Retrieving Detailed User Information
• Creating a Domain User
• Deleting a Domain User
• Disabling a Domain User
• Enabling a Domain User
• Enumerating Domain Groups
• Listing Members of a Specific Group
• Adding a User to a Privileged Group
• Removing a User from a Group
• Enumerating Domain Computers
• Retrieving Detailed Computer Information
• Creating a Computer Account
• Disabling a Computer Account
• Deleting a Computer Account
• Enumerating Built-in Local Groups
• Listing Members of a Built-in Group
• Adding a User to a Built-in Local Group
• Removing a User from a Built-in Local Group
• Authenticating with an NTLM Hash (Pass-the-Hash)
• Enumeration via Kerberos Ticket
• Enumeration via AES Key
• Mitigation Strategies
  • Infrastructure Hardening
  • Detection and Response
• Final analysis

Impacket-Net: Red Team Utility

The Impacket framework—a suite of Python classes maintained by Fortra—serves as an industry-standard “Swiss Army knife” for offensive security research and network protocol manipulation. By providing programmatic, low-level access to SMB, MSRPC, Kerberos, and NTLM, it enables red teams to conduct reconnaissance, credential harvesting, and post-exploitation without relying on native Windows binaries.

Within this ecosystem, impacket-net functions as the Linux-native equivalent to the legacy Windows net.exe utility. It abstracts the complexities of SAMR pipes, LDAP binds, and Kerberos tickets, allowing operators to interface directly with Domain Controllers from a Kali shell. By supporting diverse credential material—ranging from NTLM hashes and ticket caches to AES keys—the tool facilitates high-fidelity Active Directory enumeration and full read-write management of domain principals. Its dual utility enables both stealthy, low-privileged reconnaissance and comprehensive administrative control, making it an essential component for navigating Active Directory environments and executing complex, multi-stage attack chains against targets such as the ignite.local infrastructure.

Lab Environment

The walkthrough below targets a domain controller named dc.ignite.local at 192.168.1.8 inside the ignite.local Active Directory domain. The attacker operates from a Kali Linux box with Impacket v0.14.0.dev0 installed. The credentials harvested earlier in the engagement consist of an NTLM hash for a low-privileged user (raj), a TGT cached for the domain administrator, and an AES key recovered from a Kerberos exchange.

Enumerating Domain Users

The simplest use case retrieves all user accounts in the domain via the SAMR interface. Even an unprivileged account, such as raj, returns the complete list by using the following command:

impacket-net ignite.local/raj:Password@1@192.168.1.8 user

The output lists every user from Administrator and the built-in krbtgt account through to the ordinary employee’s raj, sanjeet, komal, and so on. The numbered format makes the output trivial to parse for downstream tools — a one-liner can extract the username column and feed it directly into password sprays, kerberoasting, or AS-REP roasting attacks.

Retrieving Detailed User Information

Adding the -name flag to the following command drills down to a single user and returns its complete SAM record — a far richer dataset than enumeration alone provides.

impacket-net ignite.local/raj:Password@1@192.168.1.8 user -name sanjeet

The output reveals operationally critical details: the comment field tags sanjeet as a GMSA-related account, the password was last changed on 03/19/2026, the account is active and never expires, and the user belongs to both gmsa_group and Domain Users. An attacker reads this single record and immediately knows the account’s age, privilege, and value.

Creating a Domain User

Once Domain Admin credentials are in hand, impacket-net pivots from enumeration into directory modification. The -create flag provisions are used in the following command to create a new user account remotely, with the -newPasswd flag setting the initial password.

impacket-net ignite.local/administrator:Ignite@987@192.168.1.8 user -create anubhav -newPasswd Password@987

The success message confirms the account exists in the directory. This is a textbook persistence move — an attacker who has temporarily compromised Domain Admin can plant a long-lived backdoor account that survives password resets of the original credential.

Deleting a Domain User

The -remove flag used in the following command deletes the user from the directory entirely, useful for cleanup or for sabotaging legitimate accounts.

impacket-net ignite.local/administrator:Ignite@987@192.168.1.8 user -remove anubhav

A defender confronted with a sudden disappearance of an administrator account should treat this as a high-confidence indicator of a compromised privileged session — legitimate account removal rarely happens through an RPC client invoked from a Linux host.

Disabling a Domain User

Rather than delete an account outright, attackers often prefer to disable it temporarily. The -disable flag sets the ACCOUNTDISABLE flag inside the userAccountControl.

impacket-net ignite.local/administrator:Ignite@987@192.168.1.8 user -disable sanjeet

Disabling rather than deleting offers two tactical advantages: legitimate users are locked out without leaving a deletion event, and the attacker can restore the account later with no trace of the modification beyond a userAccountControl change.

Enabling a Domain User

The -enable flag reverses the disabled operation, useful for re-activating dormant accounts as backdoor identities with the following command:

impacket-net ignite.local/administrator:Ignite@987@192.168.1.8 user -enable sanjeet

Re-enabling a long-disabled account is a classic persistence trick — the account already exists in the directory, has historical group memberships intact, and reactivation does not generate the noisy 4720 (account creation) event that a fresh user would.

Enumerating Domain Groups

The group subcommand pivots from users to groups, returning every global and universal security group inside the domain.

impacket-net ignite.local/raj:Password@1@192.168.1.8 group

The list immediately exposes the high-value targets: Domain Admins, Schema Admins, Enterprise Admins, Group Policy Creator Owners, and any custom groups the organisation has created. Identifying these groups is the necessary precursor to enumerating their memberships and planning lateral movement.

Listing Members of a Specific Group

Combining the group subcommand with the -name flag, as shown in the command below, returns every member of a named group — a direct path to identifying privileged accounts worth targeting.

impacket-net ignite.local/raj:Password@1@192.168.1.8 group -name "Domain Admins"

This single query identifies the four highest-value accounts in the entire environment. Administrator is the obvious target, but the presence of krishna, raaz, and ankur as Domain Admins reveals that compromising any of those three leads directly to total domain ownership — a far softer set of targets than the well-monitored Administrator account.

Adding a User to a Privileged Group

The -join flag in the following command adds an arbitrary user to a named group. With Domain Admin rights, this is the single fastest path to privilege escalation.

impacket-net ignite.local/administrator:Ignite@987@192.168.1.8 group -name "Domain Admins" -join sanjeet

The success message confirms sanjeet now wields full domain authority. Defenders should treat any 4728 event (member added to security-enabled global group) referencing Domain Admins, Enterprise Admins, or Schema Admins as an immediate priority alert — exactly the technique covered in the EVENmonitor article series.

Removing a User from a Group

The -unjoin flag in the command given below will reverse the membership change, removing a user from a group, either to clean up the attack chain or to lock out legitimate administrators.

impacket-net ignite.local/administrator:Ignite@987@192.168.1.8 group -name "Domain Admins" -unjoin sanjeet

Pairing -join and -unjoin lets an attacker temporarily elevate, perform a privileged action (such as a DCSync), and de-escalate within seconds. The defender’s only window of detection is the matched 4728 and 4729 event pair — and missing the correlation entirely loses the entire timeline.

Enumerating Domain Computers

The computer subcommand given below returns every machine account joined to the domain — Domain Controllers, member servers, workstations, and Group Managed Service Accounts.

impacket-net ignite.local/raj:Password@1@192.168.1.8 computer

The output reveals the entire infrastructure topology in a single command. Two entries — fakepc$ and fakecomp$ — stand out as suspicious, with names that suggest prior offensive tooling (likely Resource-Based Constrained Delegation abuse or noPac exploitation). Defenders running this command on their own environments should investigate any unexpected machine accounts as priority items.

Retrieving Detailed Computer Information

Adding -name flag to the computer subcommand given below drills into a specific machine account and returns its complete SAM record.

impacket-net ignite.local/raj:Password@1@192.168.1.8 computer -name MSEDGEWIN10$

The output shows the workstation has logged on 36 times and last connected on 03/30/2026, which makes it a live host worth pivoting through. Notably, MSEDGEWIN10$ also belongs to the gmsa_group, which strongly suggests a Group Managed Service Account is bound to this machine — a juicy target for credential theft.

Creating a Computer Account

impacket-net ignite.local/administrator:Ignite@987@192.168.1.8 computer -create ironman -enable ironman -newPasswd Password@987

Computer accounts created this way are the cornerstone of multiple attack primitives — Resource-Based Constrained Delegation, the noPac vulnerability, and Shadow Credentials all start with a controlled machine account. The fact that the operation succeeds with ordinary domain user privileges (not just Domain Admin) makes it especially dangerous.

Disabling a Computer Account

The -disable flag sets the ACCOUNTDISABLE flag on a machine account, blocking it from authenticating to the domain by using the following command:

impacket-net ignite.local/administrator:Ignite@987@192.168.1.8 computer -disable ironman

Disabling computer accounts is a destructive technique sometimes used to take a host offline without immediately tipping off administrators that a deletion has occurred. The host will fail to authenticate at next reboot, prompting troubleshooting that buys the attacker time.

Deleting a Computer Account

The -remove flag deletes the machine account entirely, completing the cleanup phase of an attack chain with the help of following command:

impacket-net ignite.local/administrator:Ignite@987@192.168.1.8 computer -remove ironman

Enumerating Built-in Local Groups

The localgroup subcommand, as seen below, will return the built-in groups defined on the Domain Controller itself — a different and equally valuable set of high-privilege containers.

impacket-net ignite.local/raj:Password@1@192.168.1.8 localgroup

These built-in groups are often overlooked but carry extreme privilege. Backup Operators can read every file on the DC, including the NTDS.dit hash database; Server Operators can restart services; Account Operators can create and modify any non-administrative account. Targeting membership in these groups is frequently easier than targeting Domain Admins directly.

Listing Members of a Built-in Group

Adding -name to the localgroup subcommand returns the members of a specific built-in group.

impacket-net ignite.local/raj:Password@1@192.168.1.8 localgroup -name "Backup Operators"

Discovering that ram is the sole Backup Operator tells the attacker exactly who to compromise next. Backup Operators’ rights are functionally equivalent to Domain Admin for credential extraction purposes — the user can dump the NTDS.dit through volume shadow copy operations.

Adding a User to a Built-in Local Group

The -join flag, as used in the following command, works on local groups exactly as it does on domain groups, letting an attacker elevate any account into Administrators, Backup Operators, or any other built-in container.

impacket-net ignite.local/administrator:'Ignite@987'@192.168.1.8 localgroup -name Administrators -join 'IGNITE\raj'

The verification query in the second part of the screenshot confirms raj now sits alongside Administrator, Enterprise Admins, Domain Admins, and aaru in the Administrators group — granting raj effective control of the Domain Controller. This single command turns a low-privileged user into a fully privileged operator on the DC itself.

Removing a User from a Built-in Local Group

The -unjoin flag completes the cleanup, removing the user from the local group and erasing the visible privilege escalation.

impacket-net ignite.local/administrator:'Ignite@987'@192.168.1.8 localgroup -name Administrators -unjoin 'IGNITE\raj'

Pairing the -join and -unjoin operations gives an attacker the same temporary-elevation pattern available with domain groups. Detecting this technique requires monitoring built-in local group membership changes on the Domain Controller — Event IDs 4732 (member added) and 4733 (member removed).

Authenticating with an NTLM Hash (Pass-the-Hash)

When a cleartext password is unavailable, impacket-net accepts the NTLM hash directly through the -hashes flag. The format is :NTHASH (the empty LM portion before the colon is mandatory).

impacket-net ignite.local/raj@192.168.1.8 -hashes :64FBAE31CC352FC26AF97CBDEF151E03 user

The DC accepted the hash, processed the SAMR query, and returned the full user roster, which confirms that the captured credential is valid and that the user object is the queried object class. From here, the operator can feed the list into Kerberoasting, ASREProasting, or password-spraying workflows.

Enumeration via Kerberos Ticket

Pass-the-Hash leaves loud SAMR fingerprints. Kerberos authentication blends seamlessly with domain traffic, enabling richer LDAP queries beyond SAMR limits. Impacket-net leverages operator ccache tickets via -k --no-pass flags, as in:

impacket-net ignite.local/administrator@dc.ignite.local -k -no-pass user

The flags -k and -no-pass instruct Impacket to skip password prompting and rely entirely on the cached TGT. Administrator tickets deliver equivalent directory visibility with minimal footprint: DCs log a single Kerberos service ticket request versus noisy SAMR sessions from non-domain hosts.

Enumeration via AES Key

Modern Active Directory deployments default to AES128 and AES256 Kerberos encryption types. Impacket-net enables direct AES key authentication—extracted via krbtgt dumps, LSASS harvesting, or NTDS extraction—bypassing manual TGT requests entirely. And to do so, use the following command:

impacket-net ignite.local/administrator@dc.ignite.local -aesKey e1182a9a34827cabac57a635ae47ce2b2945b4e9397d369b07d4d714c6c525b7 computer

GMSA (MyGMSA$) exposes high-value targets; attacker accounts (fakepc$, fakecomp$) exploit the default MachineAccountQuota=10 amid legit hosts. Both findings feed directly into resource-based constrained delegation attack chains.

Mitigation Strategies

Detecting and mitigating impacket-net operations requires a multi-layered defence that correlates network-layer activity with directory and authentication logs. By hardening the environment and implementing proactive monitoring, defenders can break the tool’s workflow at multiple stages.

Infrastructure Hardening

Disable Machine Account Creation

Set ms-DS-MachineAccountQuota to 0 to neutralise automated computer account creation, a prerequisite for Resource-Based Constrained Delegation and Shadow Credentials attacks.

Enforce Protocol Security

Require LDAP signing and channel binding across all Domain Controllers, while disabling weak encryption types (RC4/DES) and legacy cleartext LDAP binds to prevent credential relay.

Implement Protected Users

Enrol high-privilege accounts in the “Protected Users” security group to disable vulnerable authentication mechanisms like NTLM and long-term TGTs.

Apply the Principle of Least Privilege

Audit and prune sensitive built-in groups (e.g., Account/Server/Backup Operators) monthly and restrict Directory read permissions to prevent unauthorised enumeration.

Detection and Response

Monitor Directory Changes: Centralize and alert on Event IDs related to group membership changes (e.g., 4728/4732/4756) and account lifecycle events (4720/4722/4741).

Identify Protocol Fingerprints: Develop SIEM detections for impacket-net telemetry, such as anomalous SAMR calls from non-management hosts, atypical SMB client OS strings, and unauthorized LDAP TGT requests.

Deploy Deception Assets: Create “Honey” accounts (e.g., svc_backup_admin) in monitored OUs; any interaction with these objects via SAMR or LDAP should trigger a high-confidence, immediate incident response.

Automate Incident Playbooks: Integrate SIEM alerts with automated orchestration to roll back unauthorised directory modifications—such as group additions or account privilege escalation—within minutes of detection.

Final Analysis

Impacket-net supercharges red teams by consolidating AD exploitation—from reconnaissance to domain dominance—into a scriptable, Linux-native binary. Abstracting SAMR, LDAP, and Kerberos protocols, it enables directory mastery from minimal footholds without Windows endpoints.

However, this utility is inherently noisy. Every Impacket-net operation leaves a traceable footprint, mapping directly to standard Windows event logs. Defensive victory is therefore not a matter of discovery, but of discipline and telemetry coverage. Organisations enforcing rigorous hygiene—zeroing MachineAccountQuota, rotating krbtgt keys, and monitoring sensitive group changes—effectively invalidate BloodHound’s core primitives. While offensive operations prioritise speed, the defender’s true advantage lies in visibility. Treating anomalous directory activity as high-priority incidents enables defenders to systematically neutralise BloodHound’s impact and reclaim environment control.