Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What is the core approach for deleting a single log entry from an EVTX file as described in this article?
The core approach involves modifying the log length to merge the target log entry with its preceding log entry, thereby effectively removing it. This technique is detailed in [Windows XML Event Log (EVTX) Single Log Deletion (Part 2) – Program Implementation for Deleting Single Log Records in EVTX Files](/news/windows-xml-event-log-evtx-single-log-deletion-part-2-program-implementation-for-deleting-single-log-records-in-evtx-files) and requires updating the file header's next record identifier, recalculating CRC checksums, adjusting event record identifiers of subsequent logs, and modifying ElfChunk metadata.
What role does the NTLM hash play in Pass the Hash attacks?
The NTLM hash (specifically the NT hash) is the core credential used in Pass the Hash attacks. In Windows NTLM authentication, the system verifies a user by their password hash without ever using the plaintext password. If an attacker captures this hash (e.g., from `lsass` memory), they can directly supply it to authentication protocols, impersonating the user. Since Windows Vista/Server 2008, LM hash is disabled by default, so the NT hash is often the only hash available. This hash can be used with tools like `wmiexec` or mimikatz, as described in [Domain Penetration - Implementation of Pass The Hash](/news/domain-penetration-implementation-of-pass-the-hash).
How does mimikatz's Pass-the-Hash differ from its Pass-the-Ticket approach?
Mimikatz's Pass-the-Hash (`sekurlsa::pth`) requires local administrator privileges because it injects into the `lsass.exe` process to overwrite credentials. In contrast, Pass-the-Ticket uses the external tool `kekeo` to request a TGT with just the user's NT hash, then imports that ticket via `kerberos::ptt`—all without admin rights. This makes Pass-the-Ticket a viable alternative when administrator privileges are unavailable. For more on related techniques, refer to [Penetration Techniques - Pass the Hash with Remote Desktop (Restricted Admin Mode)](/news/penetration-techniques-pass-the-hash-with-remote-desktop-restricted-admin-mode).
What tools are commonly used for Pass the Hash on Windows systems?
Common Windows tools for Pass the Hash include `wmiexec.py` from Impacket (e.g., `wmiexec -hashes LMHASH:NTHASH TEST/test1@target whoami`), the PowerShell `Invoke-TheHash` suite (Invoke-WMIExec, Invoke-SMBExec, Invoke-SMBClient), and mimikatz's `sekurlsa::pth` function. These tools allow remote command execution or file manipulation using only the password hash. For additional remote execution methods, see [Domain Penetration - Remote Execution via Scheduled Tasks in GPO](/news/domain-penetration-remote-execution-via-scheduled-tasks-in-gpo-command-line-implementation-principles-and-script-details).
What is the core principle behind Pass the Hash attacks?
Pass the Hash exploits the fact that Windows NTLM authentication uses password hashes (LM or NT hash) instead of plaintext passwords. By obtaining a user's hash, an attacker can impersonate that user during authentication without knowing the actual password. This technique bypasses the normal API call (e.g., `LsaLogonUser`) that generates the hash. More details can be found in the original article [Domain Penetration - Implementation of Pass The Hash](/news/domain-penetration-implementation-of-pass-the-hash).
Why is it important to understand the AdminSDHolder propagation mechanism when assessing domain security?
The 60-minute automatic propagation means any ACL backdoor placed on AdminSDHolder re-applies even if a specific account’s ACL is manually cleaned, making it a stealthy persistence method. Attackers may combine this with token-based attacks like [Penetration Techniques - Exploitation of net session in Windows](/news/penetration-techniques-exploitation-of-net-session-in-windows). Understanding this helps defenders prioritize detection of AdminSDHolder changes over individual account audits.
How can defenders detect and remove malicious ACL modifications on the AdminSDHolder object?
Defenders should regularly query the ACL of the AdminSDHolder object using `Get-ObjectAcl -ADSprefix "CN=AdminSDHolder,CN=System"` via PowerView and check for suspicious users. If found, remove the ACL with `Remove-DomainObjectAcl` as shown in the article’s cleanup section. Monitoring changes to this object is crucial; also consider hardening other entry points like [Penetration Techniques - Remote Registry in Windows](/news/penetration-techniques-remote-registry-in-windows).
What are the steps to add an ACL for a user to the AdminSDHolder object to gain domain admin privileges?
Using PowerView, an attacker runs `Add-ObjectAcl -TargetADSprefix 'CN=AdminSDHolder,CN=System' -PrincipalSamAccountName testa -Rights All`. After the default 60-minute propagation (adjustable via registry), `testa` obtains full control over all protected groups, enabling actions like adding accounts to Domain Admins. See the exploitation section in [Domain Penetration - AdminSDHolder](/news/domain-penetration-adminsdholder) and understand [Penetration Techniques - Access Control List in Windows](/news/penetration-techniques-access-control-list-in-windows) for ACL basics.
How can an attacker enumerate protected AD accounts and groups to identify targets for AdminSDHolder exploitation?
Protected accounts have the `AdminCount` attribute set to 1. Attackers can list them using PowerView (`Get-NetUser -AdminCount`), Adfind (`Adfind.exe -f "...admincount=1"`), or the ActiveDirectory PowerShell module. The article notes that even objects moved out of protected groups retain `AdminCount=1`, so former privileged accounts can also be targets.
What is the AdminSDHolder object and why is it a target for privilege persistence in Active Directory?
AdminSDHolder is a special AD container that acts as a template for protected accounts and groups, like Domain Admins. Every 60 minutes (by default), the domain applies its ACL to all protected objects, so if an attacker modifies the AdminSDHolder ACL, they gain persistent high privileges over these accounts. This technique is covered in detail in the article [Domain Penetration - AdminSDHolder](/news/domain-penetration-adminsdholder).
Why is the TimeGenerated field value 0x33333333 significant in EVT file parsing?
In EVT files, the end‑of‑file record has a fixed structure where the `TimeGenerated` field is set to the constant 0x33333333. During traversal, when the program encounters this value, it knows that the end of valid log records has been reached and can stop processing. This marker is essential because EVT files do not store an explicit record count in a simple way, making the sentinel value necessary for correct iteration.
How does the deletion process for EVT files differ from that for EVTX files, and what will the next article cover?
EVT deletion relies on a time range because of the lack of a unique record identifier, while EVTX deletion can target individual logs using `EventRecordID`. Additionally, the method for deleting EVT log records on the *current system* (active log) differs significantly from the offline file approach. These differences are explored in [Windows Event Viewer Log (EVT) Single Log Deletion (Part 3) — Deleting EVT Log Records for a Specified Time Period on the Current System](/news/windows-event-viewer-log-evt-single-log-deletion-part-3-deleting-evt-log-records-for-a-specified-time-period-on-the-current-system). The EVTX counterpart is covered in [Windows XML Event Log (EVTX) Single Log Deletion (Part 2) – Program Implementation for Deleting Single Log Records in EVTX Files](/news/windows-xml-event-log-evtx-single-log-deletion-part-2-program-implementation-for-deleting-single-log-records-in-evtx-files).
What are the key steps in the program implementation for deleting EVT logs within a specified time range?
The program traverses all log records in the EVT file until it reaches the end‑of‑file record (identified by `TimeGenerated == 0x33333333`). For each record, it checks whether `TimeGenerated` falls within the user‑specified time range; matching records are deleted. The remaining logs are copied into a new array using `memcpy`. After filtering, the record numbers of subsequent logs are decremented by the number of deleted entries, and the file header fields (End of file record offset, Last record number, Maximum file size) and the end‑of‑file record fields are updated accordingly. This approach is documented in the [Windows Event Viewer Log (EVT) Single Log Deletion (Part 2)](/news/windows-event-viewer-log-evt-single-log-deletion-part-2-program-implementation-for-deleting-log-records-within-a-specified-time-range-from-evt-files).
How is the time parameter handled when deleting EVT log records within a time range?
The log creation time in EVT files is stored as a time_t value (calendar time), which represents seconds since 1970-01-01 00:00:00 UTC. The program requires conversion between user‑supplied date/time strings (e.g., "2018-7-16 17:46:17") and time_t using functions like `mktime` and `_gmtime64_s`. Care must be taken to account for time zone differences; local time can be obtained via `_localtime64_s`. These conversions ensure the start and end times correctly match the `TimeGenerated` field in each log record.
Why can't the same single log deletion method used for EVTX files be applied to EVT files?
The EVT file structure does not include a unique identifier like EventRecordID, which is present in EVTX files. Without this unique value, it's impossible to locate and delete a specific log entry directly. Instead, the approach for EVT files uses the log creation time (time_t) as an input parameter, allowing deletion of all logs within a specified time range. This method is detailed in the [Windows Event Viewer Log (EVT) Single Log Deletion (Part 2) – Program Implementation for Deleting Log Records within a Specified Time Range from EVT Files](/news/windows-event-viewer-log-evt-single-log-deletion-part-2-program-implementation-for-deleting-log-records-within-a-specified-time-range-from-evt-files) article.
What is the Windows FAX DLL injection technique and how does it exploit fxsst.dll?
Windows FAX DLL injection exploits the fact that explorer.exe loads `fxsst.dll` from `C:\Windows\System32\` at startup if the fax service is enabled (default). By placing a malicious DLL named `fxsst.dll` in `C:\Windows\`, the system loads the attacker's DLL instead due to DLL search order hijacking. This publicly disclosed technique, referenced in the [Analysis of Windows Backdoor Exploitation Methods in CIA Vault7 RDB](/news/analysis-of-windows-backdoor-exploitation-methods-in-cia-vault7-rdb), provides a simple yet effective persistence method.
How does the Shell Extension persistence method hijack explorer.exe startup via COM DLL?
Shell Extension persistence works by registering a malicious COM DLL as a shell extension, which explorer.exe loads automatically during startup. This technique has been used by malware like COMRAT and ZeroAccess rootkit. The [Analysis of Windows Backdoor Exploitation Methods in CIA Vault7 RDB](/news/analysis-of-windows-backdoor-exploitation-methods-in-cia-vault7-rdb) notes that it hijacks the normal startup process of explorer.exe, providing a stealthy persistence mechanism.
What is OCI.DLL service persistence and how does it achieve auto-start via MSDTC?
OCI.DLL service persistence exploits the Microsoft Distributed Transaction Coordinator (MSDTC) service, which automatically searches specific directories for DLLs upon startup. By placing a malicious DLL in `C:\Windows\System32\` or `C:\Windows\System32\wbem\`, the backdoor loads every time the service starts. This method, used by Shadow Force and documented in the CIA Vault7 RDB analysis, is effective in both domain and non-domain environments. For a related persistence technique using Waitfor.exe, see [Use Waitfor.exe to maintain persistence](/news/use-waitfor-exe-to-maintain-persistence).
How does the Image File Execution Options technique redirect executable programs in Windows?
The Image File Execution Options technique modifies a registry key under `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options` to redirect a target executable (e.g., notepad.exe) to a different program (e.g., calc.exe) by adding a Debugger string value. For example, starting notepad.exe would then execute calc.exe. As noted in the [Analysis of Windows Backdoor Exploitation Methods in CIA Vault7 RDB](/news/analysis-of-windows-backdoor-exploitation-methods-in-cia-vault7-rdb), antivirus software typically intercepts such registry modifications.
What is VBR persistence and how is it used to execute backdoors during Windows startup?
VBR (Volume Boot Record) persistence, as detailed in the [Analysis of Windows Backdoor Exploitation Methods in CIA Vault7 RDB](/news/analysis-of-windows-backdoor-exploitation-methods-in-cia-vault7-rdb), involves hooking kernel code during the Windows startup process to load unsigned drivers. This technique, implemented by the tool Stolen Goods 2.0, is compatible with WinXP (x86) and Win7 (x86/x64) and was derived from the Carberp source code. It allows backdoors to execute before system defenses are fully active.