Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What makes Net-NTLMv1 more vulnerable than Net-NTLMv2?
Net-NTLMv1's encryption is weaker because it splits the user's [NTLM hash](/news/introduction-to-windows-password-hashes-ntlm-hash-and-net-ntlm-hash) into three 7‑byte keys used for 3DES encryption of an 8‑byte Challenge. This structure allows attackers who can control the Challenge (e.g., via a man‑in‑the‑middle tool) to recover the NTLM hash in seconds using precomputed rainbow tables, as described in [the original article](/news/introduction-to-net-ntlmv1-password-hash-in-windows). Net‑NTLMv2 uses stronger HMAC‑MD5 and a variable Challenge, making such attacks infeasible.
What makes the TelemetryController backdoor stealthy compared to other persistence mechanisms?
This backdoor is particularly stealthy because it abuses a legitimate Microsoft process (`CompatTelRunner.exe`) and a default enabled scheduled task, so it does not raise red flags in most autoruns or startup inspections. Additionally, it works even in a disconnected network state and executes with **System** privileges, allowing full control over the host. Unlike many persistence methods, it does not require adding new scheduled tasks or services—it simply modifies a registry key that is infrequently checked. For analogous techniques that abuse trusted components, see discussions on [Backdoor Implementation Using VMware Tools](/news/penetration-basics-backdoor-implementation-using-vmware-tools) or [Transport Agent as an Exchange Backdoor](/news/penetration-techniques-using-transport-agent-as-an-exchange-backdoor).
How can security defenders detect or prevent the TelemetryController backdoor?
Defenders should regularly check the registry key `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\TelemetryController` for unauthorized `Command` values. The default `Command` under the `Appraiser` subkey should be `%windir%\system32\CompatTelRunner.exe -m:appraiser.dll -f:DoScheduledTelemetryRun`. Any deviation, especially a command pointing to an executable like `cmd.exe` or a script, indicates compromise. Additionally, monitor for unusual child processes of `CompatTelRunner.exe` and consider disabling the **Microsoft Compatibility Appraiser** scheduled task if not needed. This technique bypasses many autoruns scanners, so proactive registry auditing is essential.
What are the exact steps to deploy a TelemetryController backdoor on Windows 10?
First, ensure the scheduled task **Microsoft Compatibility Appraiser** is enabled (it is by default). Next, add a registry key under `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\TelemetryController` with a name like `fun`. Create two values: a `Command` REG_SZ pointing to your payload (e.g., `C:\Windows\system32\notepad.exe`) and a `Nightly` REG_DWORD set to `1`. Finally, trigger the backdoor by running `schtasks /run /tn "\Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser"`. This launches `CompatTelRunner.exe` which spawns your payload with System privileges. For more tailored methods on older Windows versions, see the stable exploit approach discussed in the article.
Why does the TelemetryController backdoor fail on Windows 7 and Server 2012 R2, and how can it be stabilized?
On Windows 7 and Server 2012 R2, the `CompatTelRunner.exe` process may block the execution of the attacker's command while it performs a compatibility check that can take a long time or never finish. To stabilize the exploit, modify the `Command` registry value under `TelemetryController\Appraiser` to bypass the check—for example, set it to `C:\WINDOWS\system32\cmd.exe /c notepad.exe` or empty the original `-f:DoScheduledTelemetryRun` parameter. This forces `CompatTelRunner.exe` to immediately launch the backdoor with System privileges, as described in the original article’s troubleshooting section.
What is the TelemetryController backdoor technique and how does it achieve persistence?
The TelemetryController backdoor technique abuses the Windows Compatibility Telemetry service, which runs the `CompatTelRunner.exe` process via the scheduled task **Microsoft Compatibility Appraiser**. An attacker modifies the registry key `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\TelemetryController` by adding a `Command` value pointing to malicious code (e.g., `notepad.exe`). When the scheduled task triggers, `CompatTelRunner.exe` executes the attacker's command with **System** privileges, achieving persistence without detection by many autoruns tools. This method is analyzed in detail in [Analysis of Backdoor Implementation Using TelemetryController](/news/analysis-of-backdoor-implementation-using-telemetrycontroller).
How can I generate the correct XPath query for Event ID 4624 without writing it manually?
You can use Event Viewer (eventvwr.msc) to create a custom view with the desired filters (e.g., Event ID 4624 and username), then switch to the XML tab to automatically generate the XPath statement. The query can then be used in wevtutil or PowerShell. This method is described in the article under the wevtutil section: [Analysis of SharpSniper Exploitation](/news/analysis-of-sharpsniper-exploitation).
Can I achieve the same functionality as SharpSniper using built-in Windows tools?
Yes, you can use wevtutil.exe or PowerShell scripts. For example, with wevtutil you can run 'wevtutil qe security /format:text /q:"Event[System[(EventID=4624)] and EventData[Data[@Name='TargetUserName']='testb']]"|find "Source Network Address"' to extract IPs. Similarly, PowerShell cmdlets like Get-WinEvent can be used with FilterXPath or -FilterXml. The article [Analysis of SharpSniper Exploitation](/news/analysis-of-sharpsniper-exploitation) provides detailed commands and examples.
How does SharpSniper find the IP address used by a domain user?
SharpSniper queries the domain controller's security logs for Event ID 4624 and filters by the target username using an XPath query like 'Event[System[(EventID=4624)] and EventData[Data[@Name='TargetUserName']='username']]'. It then extracts the IP address from the log using a regular expression for IPv4 addresses. This process is detailed in the [Analysis of SharpSniper Exploitation](/news/analysis-of-sharpsniper-exploitation).
What is SharpSniper and what prerequisite is needed to use it?
SharpSniper is a tool that locates the IP address of a specified domain user in a domain environment. It requires permissions to read domain controller logs, as it queries Event ID 4624 (login) events. For more details, see the [Analysis of SharpSniper Exploitation](/news/analysis-of-sharpsniper-exploitation).
How does the ModuleMonitor detection tool identify CLR injection, and why is it relevant for defenders?
`ModuleMonitor` uses the WMI event `Win32_ModuleLoadTrace` to monitor all module loads in real time. It flags a process as having CLR injection if the process loads CLR‑related DLLs (e.g., `mscoree.dll`, `mscoreei.dll`, `mscorlib.dll`—names starting with `msco*`) but is not itself a .NET application. This is relevant for defenders because it can detect Donut‑style injections that load .NET into non‑.NET processes. A simpler equivalent is `tasklist /m msco*`. For more on bypassing CLR detection, see [Analysis of Bypassing AppLocker Using Assembly Load](/news/analysis-and-summary-of-bypassing-applocker-using-assembly-load-loadfile).
What subprojects are included in the Donut source code, and what role does each play in testing or generating shellcode?
The Donut v0.9 source includes several key subprojects: `DemoCreateProcess` produces a test DLL (ClassLibrary.dll) that launches a process; `DonutTest` injects shellcode into a target process using `CreateRemoteThread`; `rundotnet.cpp` loads .NET assemblies from memory via CLR for testing; `ModuleMonitor` detects CLR injection using WMI events; and `ProcessManager` enumerates processes and checks for CLR presence. The main `donut.c` assembly converts .NET assemblies into shellcode. These components together enable end‑to‑end testing and validation, as described in the [article](/news/shellcode-generation-tool-donut-testing-and-analysis).
How does Donut load a .NET assembly from memory without relying on traditional DLL loading?
Donut uses the `ICLRMetaHost::GetRuntime` and `ICorRuntimeHost` interfaces to load the CLR directly from memory. It calls `Load_3(...)` on the raw byte array of the .NET assembly, bypassing the need for a file‑system DLL. It also attempts to disable AMSI and WLDP to avoid detection. This approach avoids writing to disk and uses manual definitions instead of `mscorlib.tlb`. For more on CLR injection, see [Analysis of Exploitation Techniques for Loading .NET Assemblies from Memory](/news/analysis-of-exploitation-techniques-for-loading-net-assemblies-from-memory-assembly-load).
What is Donut and how does it enhance the stealth and extensibility of execute-assembly?
Donut is a shellcode generation tool that converts .NET assemblies into position-independent shellcode. Unlike [execute-assembly](/news/analysis-of-exploitation-techniques-for-loading-net-assemblies-from-memory-assembly-load), which injects DLLs via reflection, Donut eliminates the DLL footprint by generating raw shellcode that can be injected into any process. This makes it more stealthy (no PE artifacts) and more extensible—any method capable of executing shellcode (e.g., via `CreateRemoteThread`) can use Donut, and it simplifies secondary development. For details, see the [Shellcode Generation Tool Donut Testing and Analysis](/news/shellcode-generation-tool-donut-testing-and-analysis) article.
What are the limitations or bypass techniques related to blockdlls? Can it be bypassed using signature forgery?
Blockdlls cannot be bypassed using 'Authenticode Signature Forgery' or 'Catalog Signature Forgery—Long UNC Filename Spoofing' techniques. Additionally, you cannot use `NtSetInformationProcess()` to modify the security policy of a remote process, as it returns error code `c000000d` (STATUS_ILLEGAL_INSTRUCTION). The feature is primarily a defense against third-party DLL injection but does not prevent all exploitation methods, such as [loading .NET assemblies from memory](/news/analysis-of-net-assembly-loading-from-memory-execute-assembly-exploitation) or [executing shellcode via Boolang language](/news/exploitation-analysis-of-executing-shellcode-via-boolang-language).
Can you enable blockdlls on the current process rather than only on child processes? How does the API differ between Windows 8 and Windows 10?
Yes, you can enable blockdlls on the current process by modifying its `ProcessSignaturePolicy` to enable `MicrosoftSignedOnly`. On Windows 10, this is done using `SetProcessMitigationPolicy()`. On Windows 8, that API fails, so you must use `NtSetInformationProcess()` instead. The implementation details are covered in the [blockdlls exploitation analysis](/news/analysis-of-cobalt-strikes-blockdlls-exploitation), which provides separate code for each OS version.
How can you check if a running process has blockdlls enabled, especially on different Windows versions?
On Windows 10, you can use the `GetProcessMitigationPolicy()` API with the `ProcessSignaturePolicy` structure to query whether `MicrosoftSignedOnly` is enabled. However, Windows 8 does not support this API for that policy; instead, you must use `NtQueryInformationProcess()` to retrieve the mitigation flags. The same approach is demonstrated in the [analysis article](/news/analysis-of-cobalt-strikes-blockdlls-exploitation) with open-source C code for both versions.
What is the purpose of Cobalt Strike's blockdlls feature and how does it protect child processes?
Cobalt Strike's blockdlls feature restricts child processes to only load DLLs signed by Microsoft, preventing third-party security software from injecting DLLs and disabling hooks. As detailed in [Analysis of Cobalt Strike's blockdlls Exploitation](/news/analysis-of-cobalt-strikes-blockdlls-exploitation), it uses the `PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON` policy via the `STARTUPINFOEX` structure to enforce this restriction at process creation.
What privileges does the ExpiredPassword.aspx webshell run with, and why is that significant?
The ExpiredPassword.aspx webshell runs with System privileges on the Exchange server because it is placed in the `C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\` directory, which defaults to System-level access. This allows attackers to execute arbitrary commands at the highest privilege level, making it a potent tool for lateral movement or persistence within a domain, as discussed in [Analysis of APT34 Leaked Tools - HighShell and HyperShell](/news/analysis-of-apt34-leaked-tools-highshell-and-hypershell).
What additional functions does HyperShell include besides the Exchange webshell?
HyperShell contains multiple components, including the `simple.aspx` webshell (password `MkRg5dm8MOk`), a stable version folder with `HighShellLocal` (a powerful multifunction webshell), and supporting libraries like `Newtonsoft.Json.dll` for JSON parsing. The `HighShellLocal` variant requires proper bin folder placement and supports various file and command operations, as outlined in the [analysis](/news/analysis-of-apt34-leaked-tools-highshell-and-hypershell).