Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
How can administrators defend against the exposure of sensitive information in PowerShell command history?
For Windows 10 and later (PowerShell v5), periodically clear the persistent history file at `%appdata%\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt` using `Remove-Item (Get-PSReadlineOption).HistorySavePath`. For older PowerShell versions, use `Clear-History` to erase the current session. For cmd.exe, run `doskey /reinstall` to clear command history. Prompt removal of sensitive commands (e.g., those containing passwords) helps prevent credential leakage.
What method does the article describe for exporting PowerShell command history from a process that can receive keyboard input?
The attacker simulates keyboard input by enumerating windows, finding the target PowerShell process by PID, and sending keystrokes such as `Get-History|export-csv $env:temp\history.csv`. Special characters require pressing the Shift key using `keybd_event` combined with `PostMessage`. This technique enables exporting history without direct console access—as detailed in the full article on [obtaining PowerShell command history](/news/penetration-techniques-obtaining-powershell-command-history).
How can an attacker obtain PowerShell command history from a background process that cannot receive keyboard input?
If the PowerShell process is running a script in the background (e.g., `PowerShell -ep bypass -f 1.ps1`), the attacker can read the process's command-line arguments to extract useful information. Open-source tools exist to enumerate and read these arguments, as sensitive data like credentials may be embedded directly in the script's parameters.
What are the two types of PowerShell command history and how do they differ?
The two types are **Get-History** and **Get-PSReadlineOption** (PSReadline). Get-History records commands only for the current PowerShell session and is cleared when the process exits, while PSReadline saves all commands to a persistent file at `%appdata%\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt`. This distinction is crucial in [penetration testing](/news/penetration-techniques-obtaining-powershell-command-history) because it determines whether an attacker can access history after the session ends.
What is the exploitation chain used by GadgetToJScript to execute .NET assemblies?
The chain maps a byte array to class instantiation: `byte[] -> Assembly.Load -> Assembly -> Assembly.GetType -> Type[] -> Activator.CreateInstance`. The `_ASurrogateGadgetGenerator.cs` reads compiled assembly from memory (via `TestAssemblyLoader.cs`), and then the `_SurrogateSelector.cs` acts as a wrapper. This chain also bypasses AMSI by avoiding a direct `DynamicInvoke` call, as detailed in the [GadgetToJScript Exploitation Analysis](/news/gadgettojscript-exploitation-analysis).
How can GadgetToJScript be integrated with SILENTTRINITY for C2 operations?
After setting up SILENTTRINITY, generate a C# stager (e.g., using `use csharp generate http`), extract the code, and paste it into the `payload.txt` file used by the modified GadgetToJScript. Running the generated JS script then executes the stager, causing SILENTTRINITY to receive a callback from the target machine (e.g., as the `wscript` process). This integration is described in the [GadgetToJScript Exploitation Analysis](/news/gadgettojscript-exploitation-analysis).
What modification did the author make to GadgetToJScript to simplify payload testing?
The author replaced `CompileAssemblyFromSource` with `CompileAssemblyFromFile` in `TestAssemblyLoader.cs`, allowing the payload to be read from a plain text file (`payload.txt`) instead of being embedded as an escaped string. This eliminates escape-character issues and makes payload development more intuitive, as noted in the [GadgetToJScript Exploitation Analysis](/news/gadgettojscript-exploitation-analysis).
How does GadgetToJScript bypass the .NET 4.8+ blocking of Assembly.Load?
It uses a `_DisableTypeCheckGadgetGenerator` that performs an initial deserialization to disable the ActivitySurrogateSelector type check, which is the mechanism .NET 4.8+ uses to block `Assembly.Load`. After that, a second deserialization loads the .NET program. This technique is explained in the [GadgetToJScript Exploitation Analysis](/news/gadgettojscript-exploitation-analysis) and is based on research from Silent Break Security.
What is GadgetToJScript and how does it improve upon DotNetToJScript?
GadgetToJScript is an open-source tool that encapsulates .NET programs into JS or VBS scripts, building on James Forshaw's DotNetToJScript. It adds a deserialization call chain to bypass AMSI and includes functionality to circumvent .NET 4.8+'s blocking of Assembly.Load, as detailed in the [GadgetToJScript Exploitation Analysis](/news/gadgettojscript-exploitation-analysis).
Why is the wlbsctrl.dll privilege escalation considered an old vulnerability, and what condition must be met for standard users to exploit it?
The vulnerability was publicly disclosed as early as October 9, 2012 (HTB23108). It relies on the fact that the IKEEXT service loads wlbsctrl.dll without specifying an absolute path under default Windows configurations. For a standard user to exploit it, they must find a directory in the PATH environment variable that is writable by their user account. With SafeDllSearchMode enabled, the search order includes the system directory, Windows directory, and current directory—so a writable directory early in the PATH allows placing a malicious wlbsctrl.dll there. The user then triggers the service using `rasdial` with a crafted `rasphone.pbk` file, as detailed in the [Expansion on the Exploitation of "Lateral Movement — SCM and DLL Hijacking Primer"](/news/expansion-on-the-exploitation-of-lateral-movement-scm-and-dll-hijacking-primer).
What role does MF.dll play in Remote Desktop attacks, and when is it particularly useful?
MF.dll is loaded by the system when a user initiates a Remote Desktop connection (if Remote Desktop is enabled). An attacker can place a malicious `C:\Windows\System32\MF.dll` and wait for any user to connect via RDP, at which point the DLL is executed. This technique is particularly useful for domain controllers: if you have remote file access but cannot execute commands, writing MF.dll gives you code execution the moment an administrator or user connects via RDP. This method is covered in the [Expansion on the Exploitation of "Lateral Movement — SCM and DLL Hijacking Primer"](/news/expansion-on-the-exploitation-of-lateral-movement-scm-and-dll-hijacking-primer).
How can TSMSISrv.dll and TSVIPSrv.dll be used to establish a backdoor on a domain controller?
If the domain controller has Remote Desktop enabled, the SessionEnv service automatically starts during boot and loads `C:\Windows\System32\TSMSISrv.dll` or `TSVIPSrv.dll`. Since these DLLs do not exist by default, an attacker with file write access can place a malicious DLL at that path. When the service starts, the DLL is loaded, achieving code execution and creating a persistent backdoor. This technique is useful when you can write files but cannot execute commands remotely, as described in the [Expansion on the Exploitation of "Lateral Movement — SCM and DLL Hijacking Primer"](/news/expansion-on-the-exploitation-of-lateral-movement-scm-and-dll-hijacking-primer).
What is the key difference between the original usage of wlbsctrl.dll in the primer and the privilege escalation technique described in this article?
The original [Expansion on the Exploitation of "Lateral Movement — SCM and DLL Hijacking Primer"](/news/expansion-on-the-exploitation-of-lateral-movement-scm-and-dll-hijacking-primer) used wlbsctrl.dll with administrator privileges to copy the DLL and manually start the IKEEXT service for remote code execution. The privilege escalation technique builds on this by exploiting the fact that the IKEEXT service loads wlbsctrl.dll without an absolute path, allowing standard users to hijack the DLL via a writable directory in the PATH environment variable, then trigger the service using `rasdial` with a crafted `rasphone.pbk` file.
Why can't forensic investigators blindly trust RecentFileCache.bcf and Amcache.hve records?
As demonstrated in the article, attackers with sufficient privileges can clear individual records from these files, making them unreliable for complete execution history. Techniques for clearing records are detailed in [Penetration Techniques - Clearing Single Records in RecentFileCache.bcf and Amcache.hve](/news/penetration-techniques-clearing-single-records-in-recentfilecache-bcf-and-amcache-hve). Investigators should cross‑reference with other sources like Windows system file execution records and NTFS timestamps, as discussed in [Penetration Techniques - Time Attributes of NTFS Files in Windows](/news/penetration-techniques-time-attributes-of-ntfs-files-in-windows).
What privileges are required to modify Amcache.hve, and what methods can be used to delete a single record?
Modifying Amcache.hve requires System privileges because the file is protected. Two approaches are described: manually using regedit.exe loaded with System privileges, or via a PowerShell script that loads the hive, enumerates registry keys, matches the target record, deletes the entire parent key, exports the new hive, and unloads it. The script checks for System privileges at the start. These methods build on the fundamentals covered in [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 I programmatically clear a single record from RecentFileCache.bcf without corrupting the file?
The simplest method of overwriting the record with null bytes disrupts the file format. Instead, you should delete the record's content and shift subsequent records to fill the gap, storing the modified content in a new array. The article provides an open‑source C program that reads the file, removes the specified record, and saves the result as NewRecentFileCache.bcf. This technique is one of several [penetration techniques for clearing execution records](/news/penetration-techniques-clearing-single-records-in-recentfilecache-bcf-and-amcache-hve).
What is the purpose of RecentFileCache.bcf and Amcache.hve, and on which Windows versions are they used?
RecentFileCache.bcf tracks application execution history and is used on Windows 7 (and earlier?), while Amcache.hve replaces it on Windows 8 and later, recording additional metadata like creation time and SHA1. On Windows 7 with KB2952664 installed, both files coexist. For more on clearing these records, see the full article [Penetration Techniques - Clearing Single Records in RecentFileCache.bcf and Amcache.hve](/news/penetration-techniques-clearing-single-records-in-recentfilecache-bcf-and-amcache-hve).
What key steps are involved in recalculating the CRC checksum after deleting a log entry from an EVTX file?
After deletion, the CRC32 checksum must be recalculated for both the file header (first 120 bytes) and the event records within ElfChunk (from offset 512 to `FreeSpaceOffset`). Additionally, the ElfChunk header checksum is recomputed using a 504-byte buffer that skips the event records data area. The article provides C code for CRC32 calculation and specifies the exact byte ranges needed for each checksum update.
Why is deleting the first log entry in an EVTX file more complex, and what alternative method does the article suggest?
The standard length-modification approach fails for the first log because there is no preceding log to merge into. The article suggests an alternative that manipulates the Binary XML format within event records, modifying fields like written date, template definition, and data size. This method also works for intermediate and last logs, demonstrating that deletion techniques are not unique. For implementation details, refer to the open-source code provided in the article.
How does deleting the last log entry in an EVTX file differ from deleting an intermediate log?
Deleting the last log entry follows the same length-modification principle but avoids decrementing event record identifiers of subsequent logs since there are none. Instead, the `LastEventRecordDataOffset` in ElfChunk must be recalculated by subtracting the size of the last record. This difference is highlighted in the article compared to intermediate log deletion, where identifier updates are essential for maintaining consistency.