Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
Why is privilege reduction necessary in penetration testing when operating from SYSTEM privileges?
When running with SYSTEM privileges, you may encounter issues like being unable to access the current user's file content (e.g., for screen capture), differences in environment variables (e.g., %APPDATA% points to C:\Windows\system32\config\systemprofile\AppData\Roaming instead of the user's folder), and registry redirection where operations on HKCU are redirected to HKEY_USERS\.DEFAULT. Dropping to ordinary user privileges allows proper interaction with the logged-on user's profile and resources. For more context, see [Penetration Techniques - Program Privilege Reduction Startup](/news/penetration-techniques-program-privilege-reduction-startup).
Why does changing the transmission path (e.g., copying a file into a virtual machine) bypass the Attachment Manager?
When a file is copied via a trusted method (such as dragging into a virtual machine), the original ADS (`Zone.Identifier`) is not preserved. The new copy therefore appears as a local file without any mark of untrusted origin, so Windows does not show a warning. This method exploits the fact that ADS streams are not transferred across certain operations. See [An interesting way of bypassing Windows Attachment Manager](/news/an-interesting-way-of-bypassing-windows-attachment-manager) for a practical example with `python-2.7.12.msi`.
What interesting behavior was discovered when combining .lnk files with .cab archives?
When a `.lnk` file is packed into a `.cab` and extracted, then saved, a warning appears. However, if you right‑click the extracted `.lnk` to view its properties and then open it again, the warning disappears and the ADS is cleared. This bug exists in Win10 Build 10586 and earlier, and was fixed in Build 14393 (1607). The `.lnk` itself can also be obfuscated by hiding its arguments with spaces, as detailed in the linked article [An interesting way of bypassing Windows Attachment Manager](/news/an-interesting-way-of-bypassing-windows-attachment-manager).
How can one bypass the Windows Attachment Manager warning using compressed files?
The article shows that .rar and .cab files created with `makecab` can bypass the warning under certain conditions. For example, packing an `.exe` into a `.cab` using `makecab /d compressiontype=lzx file.exe file.cab`, then saving the file after extraction by dragging it to a different path avoids the ADS addition. This bypass works on Win10 Build 14393 (1607) and earlier, but was fixed in Build 15063 (1703). Third‑party compressors like WinRAR also avoid the warning when used to extract. Refer to [An interesting way of bypassing Windows Attachment Manager](/news/an-interesting-way-of-bypassing-windows-attachment-manager) for the full testing procedure.
What is Windows Attachment Manager and how does it mark downloaded files as untrusted?
Windows Attachment Manager is a security feature introduced in Windows XP SP2 that blocks or warns before executing files from untrusted sources like the internet or email. It tags such files with an Alternate Data Stream (ADS) named `Zone.Identifier:$DATA`, which contains `[ZoneTransfer] ZoneId=3`. When you try to open a file with this ADS, a confirmation dialog appears. For more details, see [An interesting way of bypassing Windows Attachment Manager](/news/an-interesting-way-of-bypassing-windows-attachment-manager).
Why does APC injection succeed in evading Sysmon compared to CreateRemoteThread?
Sysmon specifically monitors for the `CreateRemoteThread` API call (Event ID 8), which is the classic method to start a remote thread in another process. APC injection, however, uses `QueueUserAPC` to attach code to an existing thread's asynchronous procedure call queue. No new thread is spawned, so the event is never generated. This technique is a practical example of how attackers adapt to monitoring tools, similar to bypass strategies in [Windows Shellcode Study Notes - Bypassing DEP with VirtualAlloc](/news/windows-shellcode-study-notes-bypassing-dep-with-virtualalloc) or [Penetration Basics - Bypassing SSH Logs](/news/penetration-basics-bypassing-ssh-logs).
What tools did Casey Smith share to execute APC injection and avoid Sysmon?
Casey Smith shared C# implementations that leverage `QueueUserAPC` for shellcode injection, designed to run under `InstallUtil.exe` and `Msbuild.exe`. These utilities are trusted by Windows and often allowed through application whitelisting solutions. The code, available on GitHub, executes the injection without creating a remote thread, thus bypassing Sysmon's CreateRemoteThread monitoring, similar to [Testing and Analysis of Bypassing AppLocker Using LUA Scripts](/news/testing-and-analysis-of-bypassing-applocker-using-lua-scripts).
How can you implement APC-based DLL injection in C++?
The C++ implementation uses `QueueUserAPC` to add a function (like `LoadLibraryA`) to the APC queue of a target thread. The code opens the target process, allocates memory for the DLL path, writes it, then calls `QueueUserAPC` to execute the load. No remote thread is created, so Sysmon's Event ID 8 is not logged. A full example is referenced in the article's C++ section, which successfully injects `testdll` into `calc.exe` without triggering alerts.
What Sysmon event does APC injection bypass and how?
APC injection bypasses Sysmon's Event ID 8, which logs `CreateRemoteThread` calls. Instead of using `CreateRemoteThread`, the technique relies on `QueueUserAPC` to insert a DLL or shellcode into an existing thread's APC queue. Since Sysmon does not monitor `QueueUserAPC`, no Event ID 8 is generated, effectively evading detection. This method is detailed in [DLL Injection via APC - Bypassing Sysmon Monitoring](/news/dll-injection-via-apc-bypassing-sysmon-monitoring).
Does bypassing Windows Event Log affect all logging, and what are its limitations?
No, the bypass only disables the Windows Event Log (the classic event logs under Application, Security, Setup, System, and Forwarded Events). Other logs such as Application and Service Logs (e.g., Windows PowerShell logs) remain active because they are managed by separate services. The article also notes that installing Sysmon can extend logging, and bypasses for Sysmon exist separately. For more on evading SSH logs, see [Penetration Basics - Bypassing SSH Logs](/news/penetration-basics-bypassing-ssh-logs).
What tools are used in bypass method two to locate and terminate log-related threads?
Method two uses `Get-WmiObject` in PowerShell to find the eventlog service’s PID, then `PsList` from Sysinternals to enumerate all threads in that process. The `ScTagQuery` tool (or Process Explorer) identifies which threads belong to the eventlog service by checking the Service Tag. Finally, a custom C++ program calls `OpenThread` and `TerminateThread` to end the eligible threads. The full code is available on GitHub. For a PowerShell-based alternative, see the original article’s reference to [Penetration Techniques - Deletion and Bypass of Windows Logs](/news/penetration-techniques-deletion-and-bypass-of-windows-logs).
What is the principle behind bypassing Windows Event Log by terminating threads?
The method targets the `svchost.exe` process that hosts the `eventlog` service. It identifies threads calling `wevtsvc.dll` (the DLL responsible for logging) and uses `TerminateThread` to end those threads. This stops log writing while keeping the service status 'running'. The article references Halil Dalabasmaz's technique and a PowerShell implementation called Invoke-Phant0m. Recovery requires restarting the service or terminating the svchost process.
How can I clear all Windows event logs using built-in tools?
You can use `wevtutil.exe`, which is included by default in Windows 7 and later. Running `wevtutil cl {LogName}` (e.g., `wevtutil cl Application`) deletes all entries in that log category. For more advanced clearing options, you can also use tools like NSA DanderSpiritz, which offers commands like `eventlogclear -log Application`. For details on deleting single entries, see [Penetration Techniques - Deleting Single Windows Log Entries](/news/penetration-techniques-deleting-single-windows-log-entries).
What are the two methods to set the AppDomainManager for hijacking a .NET program?
The two methods are: (1) Setting environment variables via `set APPDOMAIN_MANAGER_ASM` and `set APPDOMAIN_MANAGER_TYPE` in cmd, which affects only the current session. (2) Creating a configuration file named `<executable>.config` (e.g., `program.exe.config`) with the appropriate `appDomainManagerAssembly` and `appDomainManagerType` values. The config file method is more universal and persistent, as it does not depend on environment variables. Both methods are covered in [Use AppDomainManager to maintain persistence](/news/use-appdomainmanager-to-maintain-persistence).
How can defenders detect AppDomainManager hijacking attempts on .NET programs?
Defenders should monitor for unusual `.config` files (e.g., `program.exe.config` or `powershell_ise.exe.config`) in the same directories as .NET executables, especially system paths or common application directories. These config files often contain `appDomainManagerAssembly` and `appDomainManagerType` entries. Additionally, watch for unexpected DLL loading during the startup of managed applications. The article [Use AppDomainManager to maintain persistence](/news/use-appdomainmanager-to-maintain-persistence) emphasizes that the primary detection point is the config file in the executable's directory.
What is the exploitation approach targeting Visual Studio using AppDomainManager?
Visual Studio C# projects include a default `App.config` file. By modifying this config to add `appDomainManagerAssembly` and `appDomainManagerType` elements, the corresponding `bin` directory config file will be updated during compilation. If a malicious `DomainManager.dll` is also placed in the `bin` folder, every time the compiled program starts, the payload executes. This allows attackers to backdoor development environments or any .NET projects built with Visual Studio. For more details, see [Use AppDomainManager to maintain persistence](/news/use-appdomainmanager-to-maintain-persistence).
How can an attacker hijack a system .NET program like powershell_ise.exe using AppDomainManager?
An attacker can hijack `powershell_ise.exe` by placing a malicious `AppDomainManager` DLL (e.g., `DomainManager.dll`) and a config file (`powershell_ise.exe.config`) in the same directory as the executable. The config file specifies the assembly and type of the custom `AppDomainManager`. For system paths like `C:\Windows\System32\WindowsPowerShell\v1.0`, administrator privileges are required. Once configured, every launch of `powershell_ise.exe` will execute the attacker's payload before the main application runs. This technique is demonstrated in [Use AppDomainManager to maintain persistence](/news/use-appdomainmanager-to-maintain-persistence).
What is the AppDomainManager hijacking technique for maintaining persistence in .NET applications?
The AppDomainManager hijacking technique leverages the CLR initialization process to load a custom DLL before a .NET application starts. By setting environment variables (`APPDOMAIN_MANAGER_ASM` and `APPDOMAIN_MANAGER_TYPE`) or using a config file (e.g., `program.exe.config`), attackers can force any managed .NET executable to run a malicious `AppDomainManager` class. This provides a passive backdoor that triggers every time the hijacked program runs, as detailed in [Use AppDomainManager to maintain persistence](/news/use-appdomainmanager-to-maintain-persistence). The technique is similar to other CLR-based persistence methods like [Use CLR to maintain persistence](/news/use-clr-to-maintain-persistence).
What are some ways to defend against process hiding via global API hooks?
On Windows 7 and earlier systems, check the registry keys `AppInit_DLLs` under both the standard and Wow6432Node paths for any suspicious DLL paths. Also use Process Explorer (with administrator privileges) to inspect loaded DLLs in all processes. Enabling `RequireSignedAppInit_DLLs` can also block unsigned hook DLLs. These defensive measures are outlined in [Using global API hooks to hide processes on Windows 7 systems](/news/using-global-api-hooks-to-hide-processes-on-windows-7-systems).
Does the global API hook method work on Windows 8 or later systems?
No, this method only works on Windows 7 and Windows Server 2008 R2. Starting with Windows 8, Microsoft disables AppInit_DLLs when Secure Boot is enabled, which is the default. Even if the DLL is loaded, the process hiding fails due to these restrictions. The [Using global API hooks to hide processes on Windows 7 systems](/news/using-global-api-hooks-to-hide-processes-on-windows-7-systems) article references the MSDN documentation explaining this limitation.