Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What is the difference between port forwarding and proxying in penetration testing?
Port forwarding simply forwards traffic from one network port to another node, useful for hiding a real server or tunneling into an internal network. Proxying, on the other hand, allows a single configuration to handle multiple destinations or ports efficiently—tools like EarthWorm can act as both a forwarder and a proxy. For detailed methods, see the [original article](/news/penetration-basics-port-forwarding-and-proxying).
What defenses can organizations implement to detect or prevent hidden folder abuse in Exchange?
Organizations should monitor for unusual EWS activity, such as bulk folder creation or extended property changes, and enable mailbox auditing to track folder modifications. Regularly scanning mailboxes for folders with `PidTagAttributeHidden` set to `true` can also help. Additionally, restricting EWS access to only trusted applications and users reduces the attack surface, complementing techniques like those described in [Penetration Techniques - Accessing Internal File Shares via Exchange ActiveSync](/news/penetration-techniques-accessing-internal-file-shares-via-exchange-activesync).
How can I programmatically interact with hidden folders using EWS?
You can use the EWS Managed API or send SOAP XML messages to create, list, read, and delete hidden folders. The key steps involve creating a folder, setting its extended property `PidTagAttributeHidden` to `true` via `ExtendedPropertyDefinition`, and using `FolderTraversal.Deep` with a search filter to retrieve hidden folders. For detailed code examples, refer to the implementation sections of [this article](/news/penetration-basics-hidden-folders-in-exchange-user-mailboxes).
How can hidden folders be abused in penetration testing?
From a penetration testing perspective, hidden folders can serve as a data channel for C2 (command and control) communication. Since the folder and its contents (emails, attachments) are invisible to the user, an attacker can store exfiltrated data or receive commands programmatically. This technique resembles other persistent access methods covered in articles like [Penetration Basics - Usage of WMIC](/news/penetration-basics-usage-of-wmic), but operates entirely within Exchange.
What are hidden folders in Exchange user mailboxes and how are they created?
Hidden folders are folders where the extended property `PidTagAttributeHidden` (0x10F4000B) is set to `true`. They remain invisible to users when accessing mailboxes via OWA or Outlook. You can create a folder under any mailbox folder (like Inbox) and set this property using [EWS Managed API or SOAP XML](/news/penetration-basics-hidden-folders-in-exchange-user-mailboxes) to hide it from normal views.
Which tools or libraries does the article mention for executing Exchange PowerShell commands via NTLM authentication?
The article mentions `requests_ntlm` for NTLM authentication, and either `pypsrp` or `Flask` as a web proxy for command execution. It also provides a rewritten Python3 version of a Gist that simulates normal Exchange PowerShell communication data. For details on ProxyShell exploitation, refer to [Penetration Technique: Remote Access to Exchange PowerShell](/news/penetration-technique-remote-access-to-exchange-powershell).
What is the purpose of the XML file format in the Exchange PowerShell implementation, and how are command parameters structured?
The XML defines the PowerShell command and its parameters, with the attribute `Cmd` specifying the command name (e.g., `Get-Mailbox`). Parameters are passed as `<N>` elements for parameter names and `<V>` for values; if no parameter name is needed, only `<V_data>` is used. This structure allows flexible command execution. Related GPO execution techniques are covered in [Domain Penetration - Remote Execution via Scheduled Tasks in GPO](/news/domain-penetration-remote-execution-via-scheduled-tasks-in-gpo-command-line-implementation-principles-and-script-details).
How does the Python code need to be adapted from Python2 to Python3 for this Exchange PowerShell implementation?
Key adaptations include converting string concatenation to byte concatenation (e.g., using `+` with `struct.pack`), and decoding base64 streams with `ISO-8859-1` instead of `utf-8` to avoid invisible character issues. The article also notes returning `base64.b64encode(output).decode('utf-8')` for Python3 compatibility. For more on webshell techniques, see [Penetration Basics - Implementation of Webshell Supporting NTLM Over HTTP Protocol](/news/penetration-basics-implementation-of-webshell-supporting-ntlm-over-http-protocol).
What is the conventional restriction for accessing Exchange PowerShell, and how does the article's method bypass it?
Conventionally, Exchange PowerShell requires a domain-joined host and uses FQDN, blocking external access. The article's method bypasses this by leveraging NTLM authentication after the ProxyShell patch (CVE-2022–41040), allowing remote command execution without domain membership. For more on ProxyShell exploitation, see [Penetration Techniques - Remote Access to Exchange PowerShell](/news/penetration-techniques-remote-access-to-exchange-powershell).
Is the SilentCleanup UAC bypass technique applicable to Windows 7 or Windows 8?
The technique works on Windows 10 (up to RS2) and Windows 8, but not on Windows 7 because that OS lacks the `SilentCleanup` scheduled task entirely. The article notes that Microsoft planned to patch it in Windows 10 RS3. This method is a refinement of earlier UAC bypasses, such as the one using Disk Cleanup described by Matt Nelson, which has since been patched.
How can defenders mitigate or detect the SilentCleanup UAC bypass?
Defenders can modify the scheduled task to use an absolute path instead of `%windir%` by running PowerShell commands like `Set-ScheduledTask SilentCleanup -Action $action` with a hardcoded `c:\Windows\System32\cleanmgr.exe`. For detection, administrators can use PowerShell to list scheduled tasks with high run levels and executable actions (e.g., `Get-ScheduledTask | Where-Object { $_.Principal.RunLevel -ne "Limited" ... }`). This proactive hunting helps identify similar vulnerabilities in other tasks.
What makes SilentCleanup a good target for UAC bypass?
SilentCleanup is a scheduled task that can be launched by standard users (Authenticated Users) but automatically elevates to high privileges (`RunLevel = Highest`). This lax permission control, combined with its use of the `%windir%` environment variable in the startup path, provides a hijacking opportunity. Similar to the [sdclt.exe bypass](/news/study-notes-of-using-sdclt-exe-to-bypass-uac), it fits the pattern of finding high-integrity programs that are triggerable by low-integrity users and whose startup process can be altered.
How does the SilentCleanup UAC bypass exploit work?
The exploit modifies the user-level environment variable `%windir%` to point to a controlled path (e.g., `cmd /K`). When the `SilentCleanup` scheduled task runs, it launches `%windir%\system32\cleanmgr.exe` with high integrity, but due to the hijacked variable, the attacker's payload (like a cmd.exe) executes instead, bypassing UAC. A one-liner such as `reg add hkcu\Environment /v windir /d "cmd /K ..." && schtasks /Run /TN ...` performs the attack silently.
What is the underlying principle behind extracting hashes from the SAM database?
The process involves two steps: first, read the syskey from `HKLM\SYSTEM` by concatenating values from specific registry keys. Second, use that syskey to decrypt the encrypted hash data stored in the `F` and `V` registry values under `HKLM\SAM\SAM\Domains\Account\Users` for each user. This decryption chain ensures that only someone with access to both hives can recover plaintext hashes. The full cryptographic logic is referenced in the code of tools like mimikatz and quarkspwdump, as outlined in [Penetration Techniques - Obtaining Local User Hashes via SAM Database](/news/penetration-techniques-obtaining-local-user-hashes-via-sam-database).
Why do both the SYSTEM and SAM registry hives need to be obtained to decrypt user hashes?
The SAM hive stores encrypted user hashes, while the SYSTEM hive contains the boot key (syskey) needed for decryption. The syskey is derived from registry values under `HKLM\SYSTEM\CurrentControlSet\Control\Lsa` (keys JD, Skew1, GBG, Data). Without the SYSTEM hive, the encryption key cannot be reconstructed, making the SAM data useless. This principle is explained in depth in [Penetration Techniques - Obtaining Local User Hashes via SAM Database](/news/penetration-techniques-obtaining-local-user-hashes-via-sam-database).
Which tools can be used to read the SAM database online, and what privilege level is required?
Common online tools include mimikatz (using `privilege::debug`, `token::elevate`, `lsadump::sam`), pwdump7, and PowerShell scripts like Invoke-PowerDump. All require administrator privileges, and some may fail on Windows 7 (e.g., pwdump7 and Cain). For switching from admin to system privileges, refer to the related article [Penetration Techniques - Switching from Admin Privileges to System Privileges](https://example.com/placeholder) (link placeholder for the referenced previous article). These methods are detailed in [Penetration Techniques - Obtaining Local User Hashes via SAM Database](/news/penetration-techniques-obtaining-local-user-hashes-via-sam-database).
What are the steps to perform an offline extraction of local user hashes from a Windows system?
First, export the SAM and SYSTEM registry hives using `reg save HKLM\SYSTEM SystemBkup.hiv` and `reg save HKLM\SAM SamBkup.hiv` with administrative privileges. Then, on another system, use mimikatz with the command `lsadump::sam /sam:SamBkup.hiv /system:SystemBkup.hiv` to extract the hashes. Note that the official mimikatz documentation may contain an erroneous syntax; the correct command uses the `/sam:` and `/system:` parameters. The same technique is described in [Penetration Techniques - Obtaining Local User Hashes via SAM Database](/news/penetration-techniques-obtaining-local-user-hashes-via-sam-database).
Why is it necessary to extract hashes from the SAM database during a penetration test, even after using sekurlsa::logonpasswords?
While `sekurlsa::logonpasswords` retrieves credentials of currently logged-in users by reading lsass process memory, it does not cover all local accounts. To comprehensively obtain password hashes for every local user, you must extract data from the SAM database. This is covered in detail in [Penetration Techniques - Obtaining Local User Hashes via SAM Database](/news/penetration-techniques-obtaining-local-user-hashes-via-sam-database). Both online and offline methods can be used to dump these hashes.
How can a penetration tester enumerate RDP connection history for users currently logged into the system using PowerShell?
First, retrieve all user SIDs with `Get-WmiObject -Class Win32_UserAccount`. Then for each SID, query the registry path `Registry::HKEY_USERS\SID\Software\Microsoft\Terminal Server Client\Servers`. Use a `foreach` loop with a try-catch block to handle missing keys. The PowerShell script in the article demonstrates this and also displays the account status. This method only works for users who have an active session, similar to accessing [multi-user login](/news/penetration-techniques-multi-user-login-for-windows-remote-desktop) scenarios where multiple users are logged in simultaneously.
Which registry path stores the Remote Desktop connection history, and what information does each key contain?
The Remote Desktop connection history is stored under `Software\Microsoft\Terminal Server Client\Servers` within each user's registry hive. For the current user, the full path is `HKCU:\Software\Microsoft\Terminal Server Client\Servers`. Each subkey is named after the target server's IP address or hostname, and it contains a value called `UsernameHint` that holds the username used for that connection. The [article](/news/penetration-techniques-obtaining-remote-desktop-connection-history-on-windows-systems) shows how to enumerate these keys for both logged-in and all users.