The UAT-10608 operation demonstrates how modern threat actors have industrialized credential theft through automation and sophisticated tooling. The campaign's success hinges on a carefully orchestrated attack chain that transforms a single vulnerability into mass credential harvesting across hundreds of organizations. (Source: Cisco Talos)
The attack begins with automated reconnaissance using services like Shodan or Censys to identify Next.js applications exposed to the internet. UAT-10608's scanners probe these applications for React Server Components (RSC) endpoints vulnerable to CVE-2025-55182, known as React2Shell. This vulnerability allows attackers to send malicious serialized payloads directly to Server Function endpoints without any authentication.
When the scanner identifies a vulnerable endpoint, it crafts a specialized payload that exploits the deserialization routine in React Server Components. The server processes this payload, triggering arbitrary code execution in the Node.js process. This gives UAT-10608 immediate control over the application server — no passwords needed, no user interaction required.
Once inside, the operation shifts into automated harvesting mode. The initial exploit delivers a small dropper that fetches and executes the full multi-phase collection script from /tmp/ with randomized filenames like .eba9ee1e4.sh. This script runs through eleven distinct collection phases, each targeting specific credential types:
- environ and jsenv phases dump process environment variables containing API keys for OpenAI, Stripe, AWS, and other services
- ssh phase harvests private keys and authorized_keys files for lateral movement
- cloud_meta queries AWS, GCP, and Azure metadata services for IAM credentials
- k8s extracts Kubernetes service account tokens from containerized workloads
- docker enumerates container configurations and exposed services
- history captures shell command history revealing passwords typed in commands
The harvesting script maintains state through a meta.json file, ensuring systematic collection even if interrupted. After completing each phase, the script sends an HTTP callback to the NEXUS Listener C2 on port 8080, transmitting the victim's hostname, phase identifier, and collected data. These callbacks follow a consistent pattern: http://[C2_IP]:8080/h=[HOSTNAME]&l=[PHASE]&id=[SESSION_ID].
NEXUS Listener serves as the operation's nerve center — a password-protected web application that aggregates and organizes stolen credentials. The interface displays real-time statistics showing 766 compromised hosts within a 24-hour period, with database credentials harvested from 91.5% of victims and SSH keys from 78.2%. Operators can browse individual hosts, view credentials by category, and search across the entire dataset.
The framework's efficiency comes from complete automation. No human intervention occurs between initial vulnerability detection and credential exfiltration. The staged payload delivery, systematic collection phases, and centralized data aggregation enable UAT-10608 to compromise hundreds of organizations simultaneously while maintaining operational security through randomized filenames and nohup execution that persists even if the initial connection drops.
This industrial-scale approach transforms credential harvesting from targeted attacks on specific organizations into a commodity operation. UAT-10608 doesn't care who you are — if your Next.js application is vulnerable and exposed to the internet, you're automatically added to their collection.
Why This Matters to Your Business: Direct Impact of Compromised Credentials
The UAT-10608 campaign transforms stolen credentials into organizational catastrophe through systematic exploitation of trust relationships. When attackers harvest credentials from 766 hosts in just 24 hours, they're not just collecting passwords — they're building a comprehensive map of interconnected business systems that enables devastating follow-on attacks.
Consider what happens when attackers obtain database credentials from 91.5% of compromised hosts, as documented in this campaign. These aren't just login details; they're direct pathways to customer records, financial data, and intellectual property. A single compromised DATABASE_URL connection string provides immediate access to production databases containing years of business-critical information. The attackers can silently exfiltrate this data for months before detection, selling it on dark web markets or using it for competitive intelligence.
Key Insight: Consider what happens when attackers obtain database credentials from 91.5% of compromised hosts, as documented in this campaign.
The financial implications extend far beyond initial breach costs. Organizations processing payments face immediate exposure when Stripe API keys (found on 11.4% of compromised hosts) fall into attacker hands. These live secret keys enable fraudulent transactions, unauthorized refunds, and manipulation of payment flows. One compromised Stripe key can generate hundreds of thousands in fraudulent charges before detection, triggering merchant account suspensions, chargeback penalties, and loss of payment processing capabilities that can cripple e-commerce operations.
SSH private keys, harvested from 78.2% of victims, create persistent backdoors that survive credential rotation efforts. When organizations share SSH keys across environments — a common practice for operational efficiency — attackers gain lateral movement capabilities across entire infrastructure portfolios. They can pivot from development servers to production systems, from cloud instances to on-premises data centers, maintaining access even after the initial compromise point is remediated.
Cloud infrastructure faces particular devastation. AWS credentials discovered on 25.6% of hosts often carry broad IAM permissions due to misconfigured instance roles. Attackers with these credentials can spin up cryptocurrency mining operations on your dime, exfiltrate entire S3 buckets containing customer data, or deploy ransomware across your entire cloud estate. The average unauthorized cloud resource usage incident costs organizations $400,000 in compute charges alone, before factoring in data breach costs.
Regulatory exposure compounds financial damage. Database credentials exposing customer PII trigger mandatory breach notifications under GDPR, CCPA, and sector-specific regulations. Healthcare organizations face HIPAA violations with penalties reaching $2 million per violation category. Financial services firms risk losing their operating licenses. The average breach notification process costs $740,000 in legal fees, forensic analysis, and customer notification expenses — and that's before any regulatory fines or class-action lawsuits.
Perhaps most damaging is the intelligence value of aggregated credential data. The NEXUS Listener framework doesn't just steal passwords; it creates detailed infrastructure maps showing how your systems interconnect, what third-party services you depend on, and where your security boundaries exist. This intelligence becomes a blueprint for targeted ransomware attacks, with operators knowing exactly which systems to encrypt for maximum operational disruption. Recent ransomware incidents leveraging similar reconnaissance have demanded average payments of $4.5 million, with total recovery costs exceeding $10 million when factoring in downtime, restoration, and reputation damage.
Immediate Detection and Response Actions
Security teams must execute a three-phase response plan to counter the UAT-10608 threat, starting with immediate hunting operations and progressing to comprehensive infrastructure hardening. The campaign's automated nature means attackers are likely probing your Next.js applications right now.
Within the Next 24 Hours: Active Threat Hunting
Search your web application logs for HTTP requests to port 8080 containing URL patterns like h=<hostname>&l=jsenv&id= or h=<hostname>&l=k8s&id=. These callback signatures indicate active credential exfiltration to NEXUS Listener infrastructure. Query your SIEM for processes spawned from /tmp/ with randomized dot-prefixed names matching the pattern /tmp/.*.sh — these represent the harvesting scripts dropped post-exploitation.
Examine running processes for nohup invocations that aren't part of your standard application workflows. The harvesting toolkit specifically uses nohup sh /tmp/.<random>.sh >/dev/null 2>&1 to maintain persistence during collection phases. Check for unexpected file creation in /tmp/ including meta.json files that track harvesting progress across environ, jsenv, ssh, tokens, history, cloud_meta, k8s, docker, cmdline, and proc_all phases.
Scan outbound network connections for traffic to these confirmed C2 addresses: 144.172.102.88, 172.86.127.128, 144.172.112.136, and 144.172.117.112. Block these IPs immediately at your perimeter firewall and investigate any historical connections over the past 30 days.
Within One Week: Credential Reset and System Isolation
Force password resets for all accounts associated with Next.js applications, prioritizing those with access to Stripe payment processing, AWS infrastructure, GitHub repositories, and production databases. The campaign successfully extracted live Stripe API keys from 11.4% of victims — assume any payment-related credentials are compromised if you run vulnerable React Server Components.
Rotate all SSH keys found in ~/.ssh/ directories on web application servers. Since 78.2% of compromised hosts had SSH private keys stolen, treat any key-based authentication as potentially breached. Generate new ED25519 or RSA key pairs and update authorized_keys files across your infrastructure, ensuring no key is shared between systems.
Invalidate all cloud IAM credentials, particularly those accessible via Instance Metadata Service (IMDS) on EC2, GCP, or Azure instances. Create new service accounts with minimal required permissions and enable IMDSv2 on AWS to require session tokens for metadata access.
Within 30 Days: Systematic Vulnerability Remediation
Apply patches for CVE-2025-55182 across all Next.js deployments, prioritizing internet-facing applications. The vulnerability affects React Server Components that deserialize client data without validation — update to versions that implement proper input sanitization on Server Function endpoints.
Deploy Web Application Firewall (WAF) rules specifically targeting serialized payload patterns sent to RSC endpoints. Configure rules to block requests containing suspicious deserialization markers or unexpected object instantiation attempts in HTTP POST bodies to /_next/ paths.
Implement runtime monitoring for __NEXT_DATA__ exposure in rendered HTML that might leak server-side environment variables. Configure your application security tools to alert when NEXT_PUBLIC_ prefix discipline is violated or when getServerSideProps passes sensitive data to client components.
Who's at Risk and How to Prioritize Your Response
Organizations running Next.js applications built on React Server Components face immediate exposure to UAT-10608's automated harvesting campaign. The vulnerability affects any deployment where Server Function endpoints accept client-side serialized data — a default configuration in many production environments. Your risk multiplies exponentially if you're running containerized Next.js applications with overly permissive IAM roles or shared SSH key infrastructure.
The campaign's 766 compromised hosts reveal clear targeting priorities. Cloud-native startups and SaaS providers represent the highest concentration of victims, particularly those running microservices architectures where a single compromised container grants access to shared secrets. Financial technology companies appear disproportionately in the dataset — the presence of Stripe API keys in 11.4% of compromised hosts suggests payment processors and e-commerce platforms face elevated risk.
Critical exposure indicators demand immediate assessment:
- Next.js applications exposing
getServerSidePropsorgetStaticPropswithout proper secret filtering - React Server Components accepting serialized payloads on public-facing endpoints
- Applications where environment variables lack the
NEXT_PUBLIC_prefix discipline - Containerized deployments with mounted service account tokens at
/var/run/secrets/kubernetes.io/serviceaccount/token - EC2 instances still using IMDSv1 for metadata queries
Your credential reset prioritization should follow a risk-based approach centered on blast radius. Start with credentials that provide infrastructure-wide access: AWS IAM keys with administrative permissions require immediate rotation, followed by database connection strings containing production data. The 78.2% of hosts with compromised SSH keys creates a particularly insidious problem — these keys often persist across multiple systems, meaning rotation must occur simultaneously across your entire infrastructure to prevent re-compromise.
Key Insight: The 78.2% of hosts with compromised SSH keys creates a particularly insidious problem — these keys often persist across multiple systems, meaning rotation must occur simultaneously across your entire infrastructure to prevent re-compromise.
Emergency MFA deployment priorities based on observed attack patterns:
- GitHub and GitLab accounts linked to compromised personal access tokens (8.6% of victims)
- AWS root accounts and IAM users with programmatic access (25.6% exposure rate)
- Database administrative interfaces, particularly phpMyAdmin instances identified in Docker enumeration
- Payment gateway dashboards for organizations with exposed Stripe keys
- Internal administrative panels discovered through n8n workflow automation compromise
Resource allocation should focus on systems with cascading failure potential. A single compromised Kubernetes service account token can expose secrets across multiple namespaces, while a breached bastion host with shared SSH keys compromises your entire secure zone architecture. Organizations processing payments face dual exposure — both PCI compliance violations and direct financial fraud through compromised payment processor keys.
The automated nature of UAT-10608's scanning means delayed response equals certain compromise. Systems matching the vulnerability profile but showing no compromise indicators should still undergo immediate patching — the campaign's 24-hour window from deployment to 766 compromises demonstrates how quickly unpatched systems become victims. Focus your limited security resources on breaking the attack chain at its earliest point: preventing initial access through React2Shell exploitation, rather than attempting to secure every downstream credential store.
Patching and Hardening Against CVE-2025-55182
The React2Shell vulnerability transforms React Server Components into remote code execution gateways through a fundamental flaw in how Next.js processes serialized client data. When RSC endpoints deserialize incoming HTTP requests, they fail to validate whether the payload contains malicious object instantiation commands — essentially treating untrusted client input as executable server-side instructions.
The vulnerability exists because React Server Components were designed to accept serialized data structures from clients to enable interactive server-side rendering. However, the deserialization routine lacks proper input sanitization, allowing attackers to craft payloads that instantiate arbitrary objects or invoke methods on the server's Node.js process. This design oversight means any Next.js application exposing Server Function endpoints becomes remotely exploitable without authentication.
Patching CVE-2025-55182 requires different approaches depending on your deployment architecture. For containerized deployments on Kubernetes or Docker, update your base Node.js images to versions that include the patched React Server Components library, then rebuild and redeploy your containers using rolling updates to maintain availability. Cloud-hosted applications on Vercel, Netlify, or AWS Amplify should trigger immediate redeployments after updating package dependencies — these platforms automatically handle the underlying infrastructure updates.
On-premises deployments face more complex patching requirements. First, update your package.json to specify React versions above 18.3.0 and Next.js versions above 14.2.0, which contain the deserialization fixes. Run npm audit fix --force to resolve dependency conflicts, then execute comprehensive testing against your staging environment before production deployment. Legacy applications still running Next.js 12.x or 13.x require careful migration planning since direct patches aren't available for these versions.
Before patches can be deployed, implement these compensating controls to reduce exposure. Configure your web application firewall to inspect and block HTTP requests containing serialization markers like __reactServerFunction__ or __next_f in POST body data. These patterns indicate potential React2Shell exploitation attempts. Additionally, restrict Server Function endpoints to authenticated sessions only by implementing middleware that validates session tokens before processing any RSC requests.
Network segmentation provides another layer of protection while you prepare patches. Move Next.js applications behind reverse proxies that filter suspicious payloads, and ensure these applications cannot directly access production databases or cloud metadata services. Implement strict egress filtering on port 8080 — the NEXUS Listener framework uses this port for credential exfiltration callbacks, so blocking outbound connections prevents data theft even if initial compromise occurs.
Testing patched applications requires validating both functionality and security. Create test cases that attempt to send malicious serialized payloads to your Server Function endpoints — properly patched systems should reject these with 400 Bad Request responses rather than processing them. Monitor application logs during testing for any deserialization errors or unexpected object instantiation attempts. Prepare rollback procedures by maintaining versioned container images or application snapshots that allow rapid restoration if patches cause unexpected behavior in production.
Detecting Compromised Credentials in Your Environment
Your security team needs forensic indicators that distinguish UAT-10608's credential harvesting from legitimate authentication activity. The campaign leaves distinct fingerprints in authentication logs that reveal both the initial compromise and subsequent credential abuse.
Start by examining authentication patterns for accounts associated with compromised Next.js applications. The harvesting script collects credentials within minutes of initial compromise, but attackers typically wait 24-72 hours before using stolen credentials — creating a detectable gap between harvest and exploitation.
Authentication Anomaly Patterns
Look for database connections originating from IP addresses outside your established geographic baseline. The campaign harvested DATABASE_URL strings from 91.5% of victims, and attackers test these credentials from residential proxies or VPS providers not matching your typical connection sources. MySQL connections appearing from DigitalOcean or Linode IPs when your developers work exclusively from corporate networks signals credential abuse.
Monitor for simultaneous authentication attempts across multiple services using the same compromised credentials. The harvesting script collects OpenAI, Anthropic, and Stripe keys from environment variables — attackers often test all harvested API keys within the same timeframe, creating temporal clustering in your authentication logs.
SSH Key Abuse Detection
The campaign extracted SSH private keys from 78.2% of compromised hosts, including both ED25519 and RSA formats. These stolen keys generate specific authentication patterns:
- SSH connections from IP addresses that have never previously authenticated to your infrastructure
- Key-based authentication attempts using keys not present in your centralized key management system
- Multiple failed SSH attempts followed by successful key-based authentication — indicating attackers testing harvested keys
- SSH connections occurring outside normal business hours for accounts that historically follow predictable schedules
Cloud Service Account Indicators
AWS credentials harvested from 25.6% of victims create detectable patterns in CloudTrail logs. Watch for IAM role assumption from IP addresses outside your configured trust boundaries. The harvesting script queries Instance Metadata Service (IMDS) to obtain temporary credentials — these appear in logs as AssumeRole calls from unusual source IPs minutes after the initial compromise timestamp.
Kubernetes service account tokens extracted from containerized workloads generate audit log entries when attackers enumerate cluster resources. Look for API calls to list secrets, pods, or services from IP addresses not associated with your cluster nodes or authorized kubectl clients.
Payment Processor Abuse Signals
Stripe API keys compromised in 11.4% of cases produce distinctive usage patterns. Monitor your Stripe dashboard for API calls originating from countries where you don't operate, test charges to known testing card numbers, or bulk customer data exports that exceed your normal operational patterns. Attackers typically validate stolen Stripe keys by creating small test charges before attempting larger fraudulent transactions.
Behavioral Correlation Techniques
Cross-reference the timing of suspicious authentication events with your web application logs showing requests to port 8080. The NEXUS Listener callbacks occur immediately after credential extraction, providing a timestamp anchor for correlating downstream credential abuse. If you detect port 8080 callbacks at 14:30 UTC, examine all authentication events from harvested credential types starting approximately 24 hours later.
GitHub tokens extracted from 8.6% of victims often appear in commit logs from unfamiliar development environments. Monitor your repository audit logs for commits containing different email addresses, commits from IP ranges associated with VPN providers, or bulk repository cloning events that deviate from normal developer workflows.