Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
Can you export Chrome passwords offline just by having the user's NTLM hash?
No, it is not possible to decrypt Chrome passwords using only the user's NTLM hash. DPAPI uses the SHA1 algorithm for protecting the Master Key, while NTLM hashes are generated with the weaker MD4 algorithm, so they are incompatible. The Master Key must be decrypted with the plaintext login password or extracted from the lsass process. This conclusion is explained in the referenced article [Penetration Techniques - Offline Export of Passwords Saved in Chrome Browser](/news/penetration-techniques-offline-export-of-passwords-saved-in-chrome-browser).
What is DPAPI and how is it used in Chrome's password storage?
DPAPI (Data Protection Application Programming Interface) is a Windows data protection interface used to securely encrypt sensitive data like Chrome passwords. Chrome encrypts saved passwords into a DPAPI blob stored in the 'Login Data' SQLite file. Decryption requires the user's Master Key, which is protected by the user's login password. For more details on the overall process, see [Penetration Techniques - Offline Export of Passwords Saved in Chrome Browser](/news/penetration-techniques-offline-export-of-passwords-saved-in-chrome-browser).
What are the recommended defenses against tscon-based remote desktop hijacking?
First, users should always **log off** remote desktop sessions instead of disconnecting, as disconnected sessions remain hijackable. Second, monitor system login logs to detect unauthorized remote access, since attackers typically need an initial foothold. Finally, secure the system against privilege escalation and backdoors (like the utility manager or magnifier backdoor) that grant System privileges. These measures help prevent the exploitation chain described in [Penetration Technique - Using tscon to Achieve Unauthorized Remote Desktop Login](/news/penetration-technique-using-tscon-to-achieve-unauthorized-remote-desktop-login).
How can attackers combine the utility manager backdoor with tscon to bypass the Windows login screen?
By modifying the registry for `utilman.exe` (Image File Execution Options), an attacker can replace it with `cmd.exe`. Clicking the Ease of Access icon at the login screen then spawns a command prompt with System privileges. From there, they can run `tscon` to switch to any existing user session without authentication. This backdoor technique is a powerful way to bypass the login screen entirely.
Are disconnected remote desktop sessions still vulnerable to tscon hijacking?
Yes, if a remote user simply disconnects (closes the RDP window without logging off), the session remains active in a 'Disconnected' state. An attacker with System privileges can still use `tscon` to connect to that session without a password, as demonstrated in the article. This highlights why users should always log off instead of disconnecting.
How can tscon be abused to achieve unauthorized remote desktop login?
Normally, `tscon` requires a password to switch remote desktop sessions. However, if an attacker first escalates to **System privileges** using methods like creating a service or token duplication, they can run `tscon <sessionid>` without a password. This technique, detailed in [Penetration Technique - Using tscon to Achieve Unauthorized Remote Desktop Login](/news/penetration-technique-using-tscon-to-achieve-unauthorized-remote-desktop-login), effectively bypasses authentication and hijacks any existing session.
What command-line steps are needed to enable remote desktop on a Windows system from a penetration testing perspective?
First, check the current state with `REG QUERY "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections`. If disabled (value 1), enable it via `REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f`. Also add a firewall rule: `netsh advfirewall firewall add rule name="Remote Desktop" protocol=TCP dir=in localport=3389 action=allow`. For multi-user support on non-server systems, additional techniques like [mimikatz](/news/penetration-techniques-multi-user-login-for-windows-remote-desktop) or [tscon](/news/penetration-technique-using-tscon-to-achieve-unauthorized-remote-desktop-login) may be needed.
What is rdpwrap and how does it enable multi-user RDP without modifying system files?
rdpwrap is a tool from GitHub (stascorp/rdpwrap) that supports multi-user remote desktop on Windows Vista through 10 without altering `termsrv.dll`. It works by injecting its own `rdpwrap.dll` into the same process, passing different parameters to the service. To install, run `RDPWInst.exe -i`; to uninstall, use `-u`. This method is ideal for penetration testing where you want to avoid permanent system changes. Learn more about this and related techniques in the full article.
How can I permanently enable multi-user remote desktop on a Windows system by modifying the termsrv.dll file?
First, stop the Remote Desktop Services (`net stop TermService /y`), then replace the original `c:\windows\system32\termsrv.dll` with a modified version. Use a hex editor (like CFF Explorer) to locate the pattern (e.g., for Win7 x64 find `39873C0600000F84`) and replace it with `C7873C060000FFFFFF7F9090`. Restart the service and you'll have permanent multi-user support. Note that the exact pattern varies by OS version, as detailed in the article [Penetration Techniques - Multi-user Login for Windows Remote Desktop](/news/penetration-techniques-multi-user-login-for-windows-remote-desktop).
What limitation do non-server versions of Windows have regarding remote desktop, and how can I work around it?
Non-server Windows (like Windows 7, 8, 10) by default allow only one user to be logged in remotely; if a different user attempts to connect, it prompts to disconnect the existing session. To bypass this, you can use methods like mimikatz memory patching, permanently modifying `termsrv.dll`, or using the [rdpwrap](/news/penetration-techniques-multi-user-login-for-windows-remote-desktop) tool. These techniques are commonly used in penetration testing to maintain access without disrupting existing sessions.
How can I enable multi-user remote desktop on a non-server Windows system using mimikatz?
You can use the mimikatz tool with the commands `privilege::debug` then `ts::multirdp` to enable multi-user login by modifying the termsrv.dll in memory. This allows different accounts to log in simultaneously, but the change is lost after reboot. For more context, see the original article on [Penetration Techniques - Multi-user Login for Windows Remote Desktop](/news/penetration-techniques-multi-user-login-for-windows-remote-desktop).
What are typical exploitation scenarios where RID hijacking is used?
Common scenarios include enabling the Guest account (RID 501) and modifying its RID to 500 (Administrator), then logging in to gain full administrative privileges. Another approach is to find an existing low-privilege user, change the user's RID to that of a high-privilege domain or local account (e.g., Domain Admins RID 512 in a domain environment), and log in to inherit those permissions. The technique can also combine with [remote registry access](/news/penetration-techniques-remote-registry-in-windows) for targeting other machines on the network.
What are the limitations and detection risks of using RID hijacking in a penetration test?
RID hijacking has several shortcomings: the modified account must log in again to take effect, environment variables point to the impersonated user (causing profile confusion), the username display may show as `username.machine` or the original account name in some functions, and impersonating the Administrator creates a new user folder. These anomalies make the technique easily detectable. Defenders should regularly audit the registry under `HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account` for unexpected RID changes and check if the [guest account](/news/penetration-techniques-enabling-anonymous-access-shares-on-windows-systems-via-command-line) has been enabled without authorization.
How can an attacker perform RID hijacking on a Windows system?
First, the attacker must obtain SYSTEM privileges. Then they navigate to `HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users` and locate the registry key corresponding to the low-privilege account (e.g., `000003E9` for RID 1001). They edit the F key, setting the little-endian values at offsets 0x30f and 0x31f to the hexadecimal representation of the target RID (e.g., `01F4` for the built-in Administrator RID 500). After logging out and back in, the account inherits the target's privileges. The [Metasploit module `windows/manage/rid_hijack`](https://www.rapid7.com/db/modules/post/windows/manage/rid_hijack/) automates this process.
What is RID hijacking and how does it differ from account cloning?
RID hijacking is a privilege escalation technique that modifies the Relative Identifier (RID) portion of an account's Security Identifier (SID) in the Windows registry, allowing a low-privilege account to inherit the permissions of another account. Unlike [account cloning](/news/penetration-techniques-account-hiding-in-windows-systems), which copies the entire F key registry entry, RID hijacking overwrites only the RID values at offsets 0x30f and 0x31f in the target account's F key, granting the same privileges upon next login.
What are the recommended defense strategies against Net-NTLM hash theft via HTTP?
Defenses include preventing the user authentication method from being set to "Automatic logon with current user name and password" and blocking registry modifications that set value `1A00` to `0`. Administrators can query the registry with `REG QUERY "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3" /v 1A00` to audit settings. Additionally, using strong passwords and enabling multi-factor authentication can reduce the impact of hash cracking.
What registry key controls the user authentication method for HTTP NTLM in Internet Explorer, and how can it be exploited?
The registry key is `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3` with value `1A00`. Setting it to `0` enables automatic logon with the current username and password, while `10000`, `20000`, and `30000` correspond to prompt, Intranet zone only (default), and anonymous logon. An attacker with client access can modify this key to force the client to send its Net-NTLM hash when visiting any HTTP site requiring authentication.
How can an attacker exploit the HTTP protocol to capture Net-NTLM hashes in a domain environment?
An attacker can use tools like Responder or Inveigh within the Intranet zone to intercept NTLM authentication requests. When the client automatically sends its credentials (under the right settings), the attacker captures the Net-NTLM hash, which can then be cracked offline using tools like Hashcat. In a workgroup environment, however, the current user's hash is not automatically sent unless the registry is modified to enable automatic logon.
What are the prerequisites for obtaining a client's Net-NTLM hash via the HTTP protocol?
The client's user authentication method must be set to "Automatic logon with current user name and password" (registry value `1A00` set to `0`), or the client and server must be in the same Intranet zone with the default setting. Without these conditions, the client will prompt for credentials instead of automatically sending the hash. These constraints also apply to tools like Responder and Inveigh when capturing HTTP-based hashes.
How does the NTLM authentication process work over the HTTP protocol?
The client sends a GET request, and the server returns a 401 status requesting NTLM authentication. The client then sends a negotiation message, the server responds with a 16-byte random challenge, and the client encrypts this challenge using the user's password hash to generate a response. The server compares the response to authenticate the user. This process is similar to the SMB-based NTLM flow, as detailed in the [article](/news/penetration-techniques-obtaining-net-ntlm-hash-via-http-protocol).