Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What is VSTO and how can it be used to implement an Office backdoor?
VSTO (Visual Studio Tools for Office) is a framework for customizing Office applications with add-ins. Attackers can create a VSTO add-in (e.g., a Word Add-in) that executes malicious code when Office starts. As detailed in [Office backdoor implemented using VSTO](/news/office-backdoor-implemented-using-vsto), this provides a stealthy persistence mechanism that loads even when macros are disabled.
How does the decryption algorithm selection work when extracting credentials in sekurlsa::wdigest?
The algorithm is chosen based on the length of the encrypted credential data: if the length is a multiple of 8, AES in CFB mode is used; otherwise, 3DES in CBC mode is applied. The decryption keys (AES and 3DES) are obtained from the lsasrv.dll module, along with the initialization vector. This process is part of the broader LSASS credential extraction techniques, which also include methods like [Usage of SSP in Mimikatz](/news/usage-of-ssp-in-mimikatz).
What are the key differences in data structures and offsets when implementing sekurlsa::wdigest across different Windows versions?
The main differences involve the offsets for IV, DES, and AES keys in lsasrv.dll, and the structure of the BCRYPT_KEY used for decryption—Win7 uses `KIWI_BCRYPT_KEY`, while Windows 8 and 10 use `KIWI_BCRYPT_KEY81`. The AES and 3DES decryption keys are stored inside a `KIWI_HARD_KEY` structure, with `cbSecret` indicating the length. These version-specific offsets are detailed in the Mimikatz source and the [Implementation of sekurlsa::wdigest in Mimikatz](/news/implementation-of-sekurlsa-wdigest-in-mimikatz) article.
Why can't sekurlsa::wdigest extract plaintext passwords on Windows Server 2008 R2 and later systems by default, and how can this be enabled?
By default, Windows Server 2008 R2 and later systems do not store plaintext passwords in WDigest credentials, so the module cannot export them. This can be resolved by modifying the registry to enable WDigest Auth: run `reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest` with the appropriate value, then require the user to log in again. This is similar to how other credential harvesting techniques, like the [Application of Password Filter DLL in Penetration Testing](/news/application-of-password-filter-dll-in-penetration-testing), require configuration changes.
What is the purpose of the sekurlsa::wdigest module in Mimikatz and how does it work at a high level?
The sekurlsa::wdigest module extracts plaintext credentials from the LSASS process by reading and decrypting stored WDigest data. It first elevates to Debug privileges, obtains a handle to lsass.exe, then locates the memory positions of wdigest.dll and lsasrv.dll. Using the IV, AES, and 3DES keys retrieved from lsasrv.dll, it decrypts the credential information found in wdigest.dll. This process is detailed in the [Implementation of sekurlsa::wdigest in Mimikatz](/news/implementation-of-sekurlsa-wdigest-in-mimikatz) article.
Why does the ETW USB keylogger POC require Windows 8+ for USB 3.0 support and administrator privileges?
USB 3.0 support was added in Windows 8 because the kernel-mode ETW provider for USB keyboards evolved with the operating system. Administrator privileges are necessary to access the ETW session and kernel-level events. The POC's dependencies and setup are detailed in [Study Notes Weekly No.3](/news/study-notes-weekly-no-3-use-odbcconf-to-load-dll-get-exports-etw-usb-keylogger). Understanding these requirements is crucial for both implementing and defending against such ETW-based monitoring techniques.
What is the purpose of using odbcconf.exe with a response file to load a DLL that executes PowerShell commands?
NickTyrer extended odbcconf's DLL loading capability to execute PowerShell commands within the loaded DLL, using UnmanagedExports and System.Management.Automation. This allows stealthy code execution without triggering command-line detection of `regsvr` strings. For compilation instructions and details, refer to [Study Notes Weekly No.3](/news/study-notes-weekly-no-3-use-odbcconf-to-load-dll-get-exports-etw-usb-keylogger). This technique fits into the broader family of application whitelisting bypasses, such as [using tracker.exe to load DLLs](/news/study-notes-weekly-no-4-use-tracker-to-load-dll-use-csi-to-bypass-umci-execute-c-from-xslt-file).
How does the ETW-based USB keylogger POC work and what are its limitations?
The POC uses Event Tracing for Windows (ETW) to capture keystrokes from USB keyboards by leveraging kernel-mode event providers. It requires administrator privileges and works on Windows 7+ with USB 2.0 or 3.0 (not PS/2). Major limitations include recording latency, instability, and error messages like 'ignoring non-usb keyboard device'. The full technique is described in [Study Notes Weekly No.3](/news/study-notes-weekly-no-3-use-odbcconf-to-load-dll-get-exports-etw-usb-keylogger). ETW keylogging is a novel approach compared to other application whitelisting bypass methods such as [using BGInfo](/news/study-notes-of-using-bginfo-to-bypass-application-whitelisting).
What advantages does the Get-Exports PowerShell script offer over ExportsToC++ for extracting DLL exports?
Get-Exports, developed by b33f@FuzzySecurity, eliminates the need for Microsoft Visual Studio and .NET Framework 2.0, making it more convenient and faster. It supports both 32-bit and 64-bit DLLs and generates usable C++ code directly. This script was introduced in [Study Notes Weekly No.3](/news/study-notes-weekly-no-3-use-odbcconf-to-load-dll-get-exports-etw-usb-keylogger) as an improvement over the earlier ExportsToC++ tool.
How can odbcconf.exe be used to bypass command-line monitoring of regsvr32 when loading DLLs?
By using the `/f` parameter of odbcconf.exe, you can pass a response file (`.rsp`) containing the `REGSVR` command with the DLL path. This avoids having the `regsvr` string in the command-line arguments visible to monitoring tools. For more details, see [Study Notes Weekly No.3(Use odbcconf to load dll & Get-Exports & ETW USB Keylogger)](/news/study-notes-weekly-no-3-use-odbcconf-to-load-dll-get-exports-etw-usb-keylogger). This technique is similar to other bypass methods like [using sdclt.exe to bypass UAC](/news/study-notes-of-using-sdclt-exe-to-bypass-uac) that also leverage alternate execution paths.
What are the two methods for actually deleting the log record once the handle and parameters are obtained?
The first method parses the EVTX binary format manually, locates the record with the specified `EventRecordID`, and overwrites it in memory before flushing to disk. The second method uses the Windows API `EvtExportLog` to export the log file while excluding the target record, then replaces the original file with the filtered result. Both methods are implemented in the injected DLL and the loader, as shown in the [Windows XML Event Log (EVTX) Single Log Entry Deletion (Part 5) – Deleting a Single Log Entry from the Current System by Obtaining Log File Handle via DuplicateHandle](/news/windows-xml-event-log-evtx-single-log-entry-deletion-part-5-deleting-a-single-log-entry-from-the-current-system-by-obtaining-log-file-handle-via-duplicatehandle).
How does the technique achieve inter-process message passing between the loader and the injected DLL?
The loader creates two shared memory-mapped file objects using `CreateFileMapping` with security attributes that allow all access (since the injected DLL runs as SYSTEM). The loader writes the log file handle and the target `EventRecordID` into these shared memory regions. The injected DLL reads from the same mappings after injection, converting the string data to integers to obtain the parameters needed for deletion. This shared memory method avoids the parameter‑passing limitations of `CreateRemoteThread`.
How does the technique enumerate the handle for a specific EVTX log file in the Eventlog service process?
The technique uses `NtQuerySystemInformation` with `SystemHandleInformation` to enumerate all handles system-wide, then filters for those belonging to the Eventlog service process. It then calls `NtDuplicateObject` to retrieve the name and value of each handle, matching against the target log file path (e.g., `Security.evtx`). This method works on Windows 7 and later, and is similar to the approach used in [Windows XML Event Log (EVTX) Single Log Deletion (Part 3) – Deleting a Single Log Record from the Current System by Releasing File Handles](/news/windows-xml-event-log-evtx-single-log-deletion-part-3-deleting-a-single-log-record-from-the-current-system-by-releasing-file-handles).
What is the main approach described in Part 4 for deleting a single EVTX log record from the current system?
Part 4 introduces a technique where the attacker injects a DLL into the Eventlog service process (svchost.exe) to obtain and use the exclusive handle to a specific EVTX log file. Once inside the process, the injected code can modify the log file directly, bypassing the exclusive lock that normally prevents external processes from writing to it. This approach is detailed in [Windows XML Event Log (EVTX) Single Log Entry Deletion (Part 4) – Deleting a Single Log Record from the Current System by Obtaining Log File Handle via Injection](/news/windows-xml-event-log-evtx-single-log-entry-deletion-part-4-deleting-a-single-log-record-from-the-current-system-by-obtaining-log-file-handle-via-injection).
How does the Credential Manager differ between Windows 7 and Windows 8+ from a penetration testing perspective?
Starting from Windows 8, the Credential Manager interface was redesigned and added a separate 'Web Credentials' vault for credentials saved by Internet Explorer. Windows 7 does not have this distinction and instead has a 'Prompt for permission' option that can block automated extraction. Testers should be aware that the Get‑VaultCredential.ps1 script works on Win8+ for IE‑stored credentials, while on Windows 7, other methods like mimikatz or Invoke‑WCMDump may be needed. Understanding these differences is crucial during [information retrieval from Windows Credential Manager](/news/penetration-techniques-information-retrieval-from-windows-credential-manager).
Why might a penetration tester need to use a PowerShell script like Invoke-WCMDump.ps1 instead of mimikatz for extracting credential passwords?
Invoke‑WCMDump.ps1 is effective for extracting plaintext passwords from Generic Credentials that are not stored by Internet Explorer, such as manually added credentials. While mimikatz can also handle Generic Credentials, it cannot extract those saved by IE. Invoke‑WCMDump can also export Domain Credentials information (excluding plaintext). Additionally, on Windows 7, when the 'Prompt for permission when a program uses this password' option is enabled, PowerShell scripts trigger a prompt that cannot be bypassed, whereas mimikatz might still work silently.
What built-in Windows command-line tools can be used to list credential information, and how do they differ?
Windows provides two built-in tools: `vaultcmd` and `cmdkey`. `vaultcmd` offers more detailed operations, such as listing vaults (`/list`), credential names with GUIDs (`/listschema`), and properties including file location and protection method (`/listproperties`). `cmdkey /list` simply lists all stored Windows credentials. Both are useful for initial reconnaissance during the [post‑exploitation phase](/news/penetration-techniques-information-retrieval-from-windows-credential-manager) to identify available credentials.
How can penetration testers extract plaintext passwords from Domain Credentials stored in the Windows Credential Manager?
Plaintext passwords for Domain Credentials can be extracted using the mimikatz tool with the `sekurlsa::logonpasswords` command, which displays credential information at the credman location. Mimikatz can also extract plaintext passwords for Generic Credentials, but it cannot extract those saved by Internet Explorer. For IE‑stored Generic Credentials, the Get‑VaultCredential.ps1 PowerShell script from PowerSploit is effective.
What are the two main categories of credentials stored in Windows Credential Manager, and what is the key difference between them in terms of access permissions?
The two main categories are Domain Credentials and Generic Credentials. Domain Credentials can only be read and written by the Local Security Authority (LSA), meaning normal user permissions cannot extract their plaintext passwords. Generic Credentials, however, can be read and written by user processes, so regular permissions can often extract their plaintext passwords. This distinction guides tool selection during [information retrieval from Windows Credential Manager](/news/penetration-techniques-information-retrieval-from-windows-credential-manager).
How can defenders detect Boolang-based shellcode execution in their environment?
Defenders should monitor for unusual usage of the Boolang compiler DLLs (Boo.Lang.Compiler.dll, etc.) loaded by processes like PowerShell or csc.exe. Log events indicating dynamic compilation of scripts in memory, especially when followed by process injection calls (e.g., QueueUserAPC, CreateRemoteThread). Additionally, inspect PowerShell scripts that load assemblies via reflection or download external script files. The article [Exploitation Analysis of Executing Shellcode via Boolang Language](/news/exploitation-analysis-of-executing-shellcode-via-boolang-language) suggests that such techniques are similar to those used by [Netsh persistence](/news/netsh-persistence) and should be tracked with behavioral analytics.