Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What is the payload size constraint when using Invoke-PSImage, and how does the script handle extra pixels?
Each pixel stores one byte of payload, so the number of pixels in the image must be greater than or equal to the number of payload bytes. If there are extra pixels beyond the payload length, the script fills their color components with random values using the same bit‑manipulation pattern. This ensures the entire image is modified uniformly, avoiding visual anomalies.
Why does Invoke-PSImage only output PNG images, and what impact does this have on file size compared to JPEG?
Invoke-PSImage outputs PNG because the payload is stored in the pixel values, and PNG uses lossless compression to preserve that data exactly. JPEG uses lossy compression, which would corrupt the embedded payload. As a result, when a JPEG input is converted to PNG, the output file is typically much larger due to PNG's compression characteristics.
How does Invoke-PSImage embed a PowerShell payload into a PNG image without affecting normal viewing?
Invoke-PSImage uses a form of steganography that replaces the lower 4 bits of the Green and Blue color components of each pixel with parts of the payload. Each pixel stores one byte of data—the high and low nibbles of the payload byte go into the Blue and Green channels respectively, while the Red channel is used for random padding. This modifies the image slightly but keeps it visually recognizable. For a detailed breakdown of the embedding process, see the [Invoke-PSImage Utilization Analysis](/news/invoke-psimage-utilization-analysis) article.
Can you show the simplest PowerShell one-liner to bypass AppLocker using this technique?
Yes, based on the analysis, the shortest PowerShell commands are: `[Reflection.Assembly]::LoadFile("C:\path\to\bypass.exe")` followed by `[namespace.class]::method()` where the method contains the payload. For example, `[aaa]::bbb()` would invoke the `bbb` method in the `aaa` class to start calc.exe. This eliminates the need to import `CL_LoadAssembly.ps1`. This approach is derived from combining the methods of bohops and Casey Smith as detailed in the [original article](/news/analysis-and-summary-of-bypassing-applocker-using-assembly-load-loadfile).
What are the key requirements to successfully execute this AppLocker bypass?
The primary requirement is that the .NET assembly must be compiled against .NET Framework 2.0; compiling with .NET 4.0 will cause errors. The attacker also needs the ability to run PowerShell commands or import the diagnostic module. The technique exploits the fact that AppLocker does not restrict assembly loading via these methods, allowing code execution from arbitrary file paths. For a deeper analysis of similar bypasses, see [Testing and Analysis of Bypassing AppLocker Using LUA Scripts](/news/testing-and-analysis-of-bypassing-applocker-using-lua-scripts).
How does Casey Smith's bypass method differ from bohops' method?
Casey Smith's method reads the assembly as bytes using `[System.IO.File]::ReadAllBytes()` and then loads it via `[Reflection.Assembly]::Load($bytes)`. This avoids the need for the diagnostic script, but the underlying mechanism is the same: using `Assembly.Load` instead of `Assembly.LoadFile`. The article demonstrates both methods are functionally equivalent and can be simplified to a single `[Reflection.Assembly]::LoadFile()` call. Both techniques are only effective with assemblies compiled for .NET 2.0.
What is the core technique used by bohops to bypass AppLocker?
The core technique is to use the legitimate PowerShell diagnostic script `CL_LoadAssembly.ps1` located in `C:\windows\diagnostics\system\AERO`. The script internally calls `[System.Reflection.Assembly]::LoadFile()` to load a .NET assembly from disk. By providing the path to a malicious .NET executable compiled under .NET 2.0, an attacker can then invoke a public method from the loaded assembly to execute commands, such as calc.exe, bypassing AppLocker restrictions. For full details, refer to the [Analysis and Summary of Bypassing AppLocker Using Assembly Load & LoadFile](/news/analysis-and-summary-of-bypassing-applocker-using-assembly-load-loadfile).
Why is requests_ntlm recommended for vulnerability exploitation in EWS development compared to other methods?
requests_ntlm balances development convenience and exploit effectiveness. Unlike lower-level communication protocols that require manual handling of NTLM challenges, or higher-level libraries like [exchangelib](/news/exchange-web-service-ews-development-guide-5-exchangelib) which abstract away details needed for exploitation, requests_ntlm directly exposes NTLM authentication while remaining easy to integrate. It also supports hash-based authentication, critical for pentesting, and its Session mechanism reduces overhead. This makes it a preferred choice for writing reliable exploit code against Exchange Web Services.
What code modifications are needed when switching from a custom NTLM authentication to requests_ntlm in the ewsManage_Downloader script?
The main changes involve replacing the custom `ntlm_auth_login` function with `requests.post()` using `HttpNtlmAuth`, and adjusting parameter handling. For example, the original script accepted six arguments (`host, port, mode, domain, user, data`) but with requests_ntlm it accepts only four (`host, mode, user, data`). Additionally, `status` and `responsetext` are replaced by `res.status_code` and `res.text`, and the hash or password is passed directly as `data`. These simplifications make the code cleaner while retaining full functionality for EWS exploitation. For a deeper understanding of the original protocol, refer to the [Exchange Web Service (EWS) Development Guide 2 – SOAP XML Message](/news/exchange-web-service-ews-development-guide-2-soap-xml-message).
How can the Session mechanism in requests_ntlm improve efficiency in EWS interactions?
By using `requests.Session()` with `HttpNtlmAuth`, the Session mechanism reuses authentication credentials across multiple requests, reducing the number of NTLM handshakes. This shortens communication packets and improves performance, especially when performing bulk operations like email downloading. The article demonstrates switching to a session-based approach to streamline automated tasks in EWS development.
What authentication methods does requests_ntlm support for Exchange Web Service access?
requests_ntlm supports both plaintext password authentication and hash-based authentication. For hash authentication, the parameter format is 'ABCDABCDABCDABCD:ABCDABCDABCDABCD', allowing you to pass an NTLM hash directly. This is particularly useful for lateral movement scenarios where only hashes are available. The library is ideal for vulnerability exploitation because it encapsulates NTLM authentication without adding unnecessary complexity, as discussed in [Exchange Web Service (EWS) Development Guide 6 – requests_ntlm](/news/exchange-web-service-ews-development-guide-6-requests-ntlm).
What are some defense recommendations against RDP tunneling attacks?
Defenders should restrict RDP file sharing and virtual channel usage, monitor for unusual RDP connections, and limit which users can establish RDP sessions. Enabling Network Level Authentication (NLA) and using RDP gateways with proper logging can help detect such tunneling attempts. For more context on RDP abuse scenarios, see [Penetration Techniques - Multi-user Login for Windows Remote Desktop](/news/penetration-techniques-multi-user-login-for-windows-remote-desktop) to understand how attackers may escalate privileges on RDP hosts.
What is UniversalDVC and how does it create a tunnel over RDP?
UniversalDVC (UDVC) uses dynamic virtual channels (DVC) by registering a UDVC plugin DLL on the RDP client and running a server executable on the target. After registration via `regsvr32`, the plugin listens on a configurable local port (default 31337). The UDVC-Server connects to an internal service (e.g., HTTP on port 80), and the client can then access that internal service through its local port, effectively tunneling traffic through the RDP session.
What is rdp2tcp and how does it enable port forwarding over RDP?
rdp2tcp utilizes RDP's virtual channel functionality to multiplex TCP connections. It supports forward and reverse port forwarding, SOCKS5 proxy, and stdin/stdout forwarding. The client-side binary (rdp2tcp) runs on the attacker's machine, while the server-side binary (rdp2tcp64.exe) executes on the target RDP server. After connecting with a patched version of xfreerdp that supports the `/rdp2tcp` option, the attacker can add port forwarding rules to tunnel arbitrary traffic through the RDP session.
How does the shared file method work for establishing an RDP tunnel?
When establishing an RDP connection with file sharing enabled (using mstsc.exe, FreeRDP, or xfreerdp), a shared folder is created between client and server. The client and server can then read and write files in this shared folder to exchange data, effectively using it as a covert channel. This technique is demonstrated in the External C2 POC from Outflank, which follows Cobalt Strike's External C2 specification.
What is the main use case for establishing tunnels using Remote Desktop Protocol?
The main use case is when only one Windows server's remote desktop is accessible due to firewall restrictions, and an attacker wants to use that server as a pivot to access the internal network. By leveraging RDP's virtual channels or file sharing, they can tunnel traffic through the RDP connection, similar to [Bypassing firewall using IIS port sharing feature](/news/bypassing-firewall-using-iis-port-sharing-feature) but with RDP as the carrier.
Which tools and files are essential for setting up a Veeam Backup & Replication vulnerability debugging environment?
You need dnSpy for attaching to `Veeam.Backup.Service.exe`, the Veeam installation ISO and license from the official site, and .ini files (e.g., `Veeam.Backup.Service.ini`) to enable debug tracking. For database extraction, use DbSchema or PowerShell with MSOLEDBSQL19. The complete setup walkthrough is in the [Setting Up Veeam Backup & Replication Vulnerability Debugging Environment](/news/setting-up-veeam-backup-replication-vulnerability-debugging-environment) guide, which also references related environments like [Server Backup Manager Vulnerability Debugging Environment Setup](/news/server-backup-manager-vulnerability-debugging-environment-setup).
How does CVE-2023-27532 allow credential leakage in Veeam Backup & Replication, and how can I parse the leaked data?
CVE-2023-27532 exploits the `CredentialsDbScopeGetAllCreds` function to retrieve stored credentials in plaintext via a POC. The returned data is Base64-encoded serialized XML. To parse it correctly, use Veeam’s built-in `Veeam.Backup.Core.CProxyBinaryFormatter.Deserialize` method to extract fields like `DomainName`, `UserName`, and `Password`. This analysis is detailed in the [Setting Up Veeam Backup & Replication Vulnerability Debugging Environment](/news/setting-up-veeam-backup-replication-vulnerability-debugging-environment) article, with similarities to other debugging setups like [Sophos XG Vulnerability Debugging Environment Setup](/news/sophos-xg-vulnerability-debugging-environment-setup).
What are the steps to extract database credentials from Veeam Backup & Replication, and how do I handle SSL errors in PowerShell?
First, obtain the database port via SQL Server Configuration Manager (e.g., PID 1756 mapped to port 49720) and the database name from registry or configuration (e.g., `VeeamBackup`). Then connect using DbSchema or PowerShell. For PowerShell, if using `veeam-creds`, replace the deprecated `sqloledb` provider with `MSOLEDBSQL` or `MSOLEDBSQL19` to avoid SSL errors. Ensure the latest Microsoft Visual C++ Redistributable is installed. The full method is covered in the [Setting Up Veeam Backup & Replication Vulnerability Debugging Environment](/news/setting-up-veeam-backup-replication-vulnerability-debugging-environment) article.
How do I enable variable viewing in dnSpy when debugging Veeam Backup & Replication?
Create .ini files in the Veeam installation directory (e.g., `C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Service.ini`) with the content `[.NET Framework Debugging Control]\nGenerate TrackingInfo=1\nAllowOptimize=0`, then restart the corresponding service. This allows you to inspect variable contents during debugging. This setup is part of the environment described in the [Setting Up Veeam Backup & Replication Vulnerability Debugging Environment](/news/setting-up-veeam-backup-replication-vulnerability-debugging-environment) guide.