Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What detection and defense measures are recommended against the MSDTC backdoor?
Detection involves checking if a suspicious `oci.dll` exists in `%windir%\system32\`, as this DLL is not native to Windows. For defense, it is recommended to disable the MSDTC service on regular user hosts, as it is often unnecessary for typical workstations. Additionally, monitoring process creation and DLL loads by `msdtc.exe` can help identify malicious activity.
How can an administrator use MSDTC to launch a program with reduced privileges?
By running `msdtc -install` in an administrator command prompt, the MSDTC service loads `oci.dll` with administrator privileges instead of SYSTEM privileges, achieving privilege reduction startup. This technique is useful for running programs at a lower privilege level. For more methods of privilege reduction, refer to the article 'Penetration Techniques – Privilege Reduction Startup of Programs.'
Can the MSDTC backdoor be exploited in a workgroup environment or only in a domain?
The MSDTC service starts by default in both domain and workgroup environments, so the backdoor works regardless of whether the computer is joined to a domain. This expands its applicability beyond the initial domain-focused attack described by Trend Micro, making it a versatile persistence method.
How does the MSDTC service backdoor work for persistence?
The MSDTC service (Distributed Transaction Coordinator) automatically attempts to load three DLLs from the registry key `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\MTxOCI`, including `oci.dll` which is not present in Windows by default. Attackers place a malicious DLL named `oci.dll` in `%windir%\system32\`, and when the MSDTC service starts (by default in both domain and workgroup environments), it loads the DLL with SYSTEM privileges, achieving persistence. This technique was used by the Shadow Force group and bypasses Autoruns detection. For full details, see [Use msdtc to maintain persistence](/news/use-msdtc-to-maintain-persistence).
What are some exploitation approaches and defense recommendations for this bypass technique?
Exploitation can involve using `wmic.exe` to load malicious `.xsl` files, as referenced in previous research on bypassing AppLocker. To defend against this technique, note that it avoids typical puppet process indicators (no `VirtualAllocEx` or `SetThreadContext`), so traditional memory scans fail. However, monitoring for suspicious parent-child process relationships (e.g., an unexpected parent spawning cmd.exe) can help detect such attacks. The full analysis is in [Penetration Techniques - Bypassing Windows Command Line Process Auditing](/news/penetration-techniques-bypassing-windows-command-line-process-auditing).
How does the C++ implementation of SwampThing differ and what advantage does it offer?
The C++ implementation differs by not restoring the original command line after the process resumes, and by hiding the launched process's window via `STARTUPINFO` flags (`dwFlags` and `wShowWindow`). This allows it to work with commands that exit immediately, such as `cmd.exe /c start calc.exe`, where the logged command line shows a fake parameter (e.g., `cmd.exe /c start notepad.exe`). This extends the bypass capability to one-shot executions.
What is SwampThing and how do you use it to bypass command line auditing?
SwampThing is an open-source C# tool from the Sharp-Suite project that demonstrates bypassing command line process auditing. It takes three parameters: the target executable (`-l`), the fake command line (`-f`), and the real command line (`-r`). For example, `SwampThing.exe -l C:\Windows\System32\notepad.exe -f C:\aaa.txt -r C:\bbb.txt` launches notepad with `bbb.txt` but logs `aaa.txt` in Event ID 4688. The tool only works for processes that don't auto-exit, such as notepad.exe.
How does the technique to bypass Windows command line process auditing work?
The technique works by creating a suspended process using the `CreateProcess` API with the `CREATE_SUSPENDED` flag, then modifying its `CommandLine` parameter in memory via `ReadProcessMemory` and `WriteProcessMemory`. After modification, the process is resumed with `ResumeThread`, and if the process doesn't exit immediately, the command line is restored to hide the true parameters. This method, described in [Penetration Techniques - Bypassing Windows Command Line Process Auditing](/news/penetration-techniques-bypassing-windows-command-line-process-auditing), effectively bypasses Event ID 4688 logging.
How does the explorer.exe hijacking technique compare to other COM hijacking methods like CLR hijacking or CAccPropServicesClass hijacking?
CLR hijacking uses environment variables to intercept all .Net program startups, while CAccPropServicesClass hijacking only triggers when Internet Explorer is launched (a passive backdoor). Explorer.exe hijacking via MruPidlList is active because the desktop process starts automatically, making it reliable for system-wide persistence. Each method targets different COM objects but ultimately abuses same-class registry entries. For deeper details on CLR and CAccPropServicesClass methods, refer to the previous articles referenced in [Use COM Object hijacking to maintain persistence——Hijack explorer.exe](/news/use-com-object-hijacking-to-maintain-persistence-hijack-explorer-exe).
What defense strategies does the article recommend against COM object hijacking?
Defense focuses on monitoring registry modifications under `HKCU\Software\Classes\CLSID\` and specific keys like `{42aedc87-2188-41fd-b9a3-0c966feabec1}` and `{fbeb8a05-beee-4442-804e-409d6c4515e9}`. The article recommends using application whitelisting rules to block unauthorized DLLs and investigating write operations to these registry locations. Since COM hijacking can bypass Autoruns' startup item detection, these proactive measures are essential. For a broader view, see [Use COM Object hijacking to maintain persistence——Hijack CAccPropServicesClass and MMDeviceEnumerator](/news/use-com-object-hijacking-to-maintain-persistence-hijack-caccpropservicesclass-and-mmdeviceenumerator).
Which known malware families have exploited COM hijacking via MruPidlList or similar CLSIDs, according to the article?
The article mentions COMRAT (suspected to share origins with the advanced rootkits Uroburos and Agent.BTZ), the ZeroAccess rootkit (which infected over 9 million computers using CLSID `{fbeb8a05-beee-4442-804e-409d6c4515e9}`), and BBSRAT (linked to the Roaming Tiger campaign targeting Russian organizations). These examples demonstrate how real-world threats leverage COM hijacking for persistence, as discussed in [Use COM Object hijacking to maintain persistence——Hijack explorer.exe](/news/use-com-object-hijacking-to-maintain-persistence-hijack-explorer-exe).
What registry keys are commonly used for COM hijacking targeting explorer.exe, and why is this considered an active backdoor compared to other methods?
The primary keys are `HKCU\Software\Classes\CLSID\{42aedc87-2188-41fd-b9a3-0c966feabec1}` (MruPidlList) and `HKCU\Software\Classes\clsid\{fbeb8a05-beee-4442-804e-409d6c4515e9}` (used by ZeroAccess). Unlike passive backdoors such as hijacking CAccPropServicesClass (which only triggers when IE starts), hijacking explorer.exe is active because explorer.exe runs automatically at system boot, ensuring the backdoor executes on every startup. This method is covered in [Use COM Object hijacking to maintain persistence——Hijack CAccPropServicesClass and MMDeviceEnumerator](/news/use-com-object-hijacking-to-maintain-persistence-hijack-caccpropservicesclass-and-mmdeviceenumerator).
How does hijacking the MruPidlList COM object allow an attacker to maintain persistence?
The MruPidlList COM object is loaded by shell32.dll, which is called by explorer.exe at system startup. By setting the registry key `HKCU\Software\Classes\CLSID\{42aedc87-2188-41fd-b9a3-0c966feabec1}` to point to a malicious DLL, an attacker can force explorer.exe to load that DLL every time the user logs in, creating an active backdoor that triggers without user interaction. This technique is detailed in [Use COM Object hijacking to maintain persistence——Hijack explorer.exe](/news/use-com-object-hijacking-to-maintain-persistence-hijack-explorer-exe).
What are the important compilation details for the managed DLL used in CLSID hijacking, particularly regarding .NET runtime version and assembly naming?
The managed DLL must be compiled with the correct .NET runtime version that matches the target CLSID’s `RuntimeVersion` registry value. For example, for CLSID `{D5AB5662-131D-453D-88C8-9BBA87502ADE}` you must use `v2.0.50727` and compile with `csc.exe` from the .NET 2.0 directory. Also, the assembly name in the C# source (namespace `TestDotNet` and class `TestDotNet.Class1`) must match the `Assembly` registry value. If the compiled DLL’s name differs from the namespace, you must specify the `/out:TestDotNet.dll` parameter to ensure correct loading. Failure to match will result in the DLL being loaded but not executed.
Which system CLSIDs can be hijacked to bypass UAC when launching specific Microsoft Management Console (MMC) snap-ins?
The article identifies at least three CLSIDs that can be hijacked under `HKCU\Software\Classes\CLSID` to trigger a managed DLL when certain snap-ins are launched. For example, `{B29D466A-857D-35BA-8712-A758861BFEA1}` is invoked by `gpedit.msc`, and `{D5AB5662-131D-453D-88C8-9BBA87502ADE}` is invoked by `compmgmt.msc`, `eventvwr.msc`, `secpol.msc`, and `taskschd.msc`. Each requires setting `InprocServer32` to point to `mscoree.dll` with a custom `CodeBase` pointing to the attacker’s managed DLL. This method is similar to other COM-based UAC bypasses like [Bypassing UAC via COM Component IARPUninstallStringLauncher](/news/bypassing-uac-via-com-component-iarpuninstallstringlauncher).
What registry keys are modified for the CLR UAC bypass via environment variables, and how can they be set using the command line?
Two sets of registry keys are modified: under `HKCU\Environment` you set `COR_ENABLE_PROFILING=1` and `COR_PROFILER={CLSID}`; under `HKCU\Software\Classes\CLSID\{CLSID}\InprocServer32` you set the default value to the path of the malicious DLL. The article shows using `reg add` commands, e.g., `REG ADD "HKCU\Software\Classes\CLSID\{...}\InprocServer32" /ve /t REG_EXPAND_SZ /d "C:\Temp\test.dll" /f` and `REG ADD "HKCU\Environment" /v "COR_PROFILER" /t REG_SZ /d "{...}" /f`. Alternative methods like `wmic` or PowerShell are also described in the related articles on persistence.
How does the CLR-based UAC bypass technique work by setting environment variables?
The technique leverages the Common Language Runtime (CLR) profiling mechanism. By setting user-level environment variables `COR_ENABLE_PROFILING` to `1` and `COR_PROFILER` to a custom CLSID (e.g., `{FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF}`), any .NET process that starts—including high-integrity ones like `gpedit.msc`—will load a malicious DLL specified under `HKCU\Software\Classes\CLSID\{CLSID}\InprocServer32`. When the high-privilege .NET program runs, it loads the attacker’s DLL, executing code with elevated privileges and bypassing UAC. See [Use CLR to bypass UAC](/news/use-clr-to-bypass-uac) for the full POC.
What role does the userlog_read function play in displaying Last WebAdmin Sessions, and how was it identified?
The userlog_read function in /var/confd/confd.plx retrieves session records from the database and log files for display on the webadmin page. Researchers identified it by decompiling webadmin.plx and confd.plx, then searching for userlog_read. The function calls _consult_db to query confd_sessions and _iterate_files to read /var/log/confd.log. This reverse engineering approach is similar to analyzing drivers in the [Analysis of CVE-2017-8360 (Keylogger in HP Audio Driver) Exploitation](/news/analysis-of-cve-2017-8360-keylogger-in-hp-audio-driver-exploitation).
Where are the Last WebAdmin Sessions records actually stored, and how can they be cleared?
The records are stored in two locations: the reporting database (table confd_sessions) and the log file /var/log/confd.log. To clear them, you can delete entries from confd_sessions using SQL commands via psql (e.g., `DELETE FROM confd_sessions WHERE facility IN ('webadmin','acc-agent','acc_sso')`) and remove corresponding lines from the log file. This forensic cleaning process is detailed in the [Sophos UTM Analysis - Clearing Last WebAdmin Sessions Records](/news/sophos-utm-analysis-clearing-last-webadmin-sessions-records) article.
Why does modifying the /var/confd/var/storage/cfg file fail to clear Last WebAdmin Sessions records?
The /var/confd/var/storage/cfg file stores configuration data but not the session log data displayed in Last WebAdmin Sessions. The research shows that clearing attributes in the cfg file using StorableEdit does not affect the displayed records. The actual session data resides in the reporting database and log files, much like how LDAP configurations are managed separately in the [vSphere Development Guide 5 - LDAP](/news/vsphere-development-guide-5-ldap).