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
The post Impacket for Pentester: Net appeared first on Hacking Articles.
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@[email protected] 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@[email protected] 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@[email protected] 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@[email protected] 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@[email protected] 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@[email protected] 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@[email protected] 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@[email protected] 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@[email protected] 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@[email protected] 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@[email protected] 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@[email protected] 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.