Hackers Are Hijacking NGINX Servers Without Installing Malware

Hackers are hijacking NGINX web servers and rerouting live traffic through their own infrastructure. No malware installed, no vulnerability exploited. Just a few lines changed in a configuration file, and every visitor’s data flows through attacker-controlled servers without anyone noticing. 🧐

NGINX is the most popular web server on the planet. It powers over 5 million websites and handles roughly one in three web connections worldwide. Banks, governments, and universities all depend on it. And right now, a campaign is silently turning these servers into traffic relays.

DataDog Security Labs researchers Ryan Simon and Christophe Tafani-Dereeper just published their findings, and the technical details are wild.

The attackers are not dropping malware onto servers. They are not exploiting a bug in NGINX. They are editing configuration files, the same files that every system administrator works with daily. A few directives added in the right places, and the server starts forwarding all traffic through a middleman. The website still loads, pages still work, everything looks completely normal. But every single request passes through the attacker’s servers first.

That means passwords, session tokens, API calls, everything in transit can be captured, copied, or modified in real time. An attacker sitting in that position can impersonate users, steal credentials mid-session, and alter what people see on the page without leaving a trace.

The way they get in is through a completely separate vulnerability called React2Shell, tracked as CVE-2025-55182. This is a critical remote code execution flaw in React Server Components with a perfect 10.0 CVSS score. It was publicly disclosed on December 3, 2025, and within hours, state-sponsored hackers were already using it. GreyNoise has recorded over 8.1 million attack sessions since disclosure.

The damage is already done in many places. Palo Alto Networks Unit 42 confirmed that more than 60 organizations have been breached through React2Shell, across financial services, government, education, tech, and telecom in the US, Asia, South America, and the Middle East. Wiz Research found that 39 percent of all cloud environments contain vulnerable React or Next.js instances. And Rapid7 released an official Metasploit exploit module in December, which means any attacker with basic skills can now point and shoot.

React2Shell is the front door. Once the attackers are inside, they deploy a toolkit of five automated shell scripts that take over the NGINX configuration. This is not some quick and dirty hack. This toolkit is professionally built.

Here is how it works.

The first script, zx.sh, runs the show. It downloads and executes all the other scripts. And here is the clever part: if curl and wget are blocked on the server, it does not give up. It builds a raw TCP connection and sends HTTP requests by hand. This toolkit was built to work even in locked-down environments where security tools have removed common utilities.

The second script, bt.sh, goes specifically after servers running Baota Panel, a Chinese web hosting management tool installed on millions of servers since 2014. It searches through Baota’s config path at /www/server/panel/vhost/nginx, checks whether the server has already been compromised, and picks an injection template based on the domain’s top-level domain. Then it triggers a reload instead of a full restart so existing connections stay alive and nobody notices anything changed.

The third script, 4zdh.sh, goes wider. It scans standard NGINX config directories like sites-enabled, conf.d, and sites-available. It uses csplit and awk to parse server blocks without breaking the configuration structure, generates MD5 hashes to track what has already been injected, and runs nginx -t to validate everything before making changes. If the test fails, it stops. Whoever built this does not want to crash servers and draw attention.

The fourth script, zdh.sh, takes a narrower approach focused on Linux and containerized NGINX environments. It targets /etc/nginx/sites-enabled and prioritizes domains ending in .in and .id. If a graceful reload fails, it falls back to pkill.

The fifth script, ok.sh, is the spy. It scans all compromised NGINX configurations, builds a complete map of every hijacked domain, every injection template, and every proxy target. It writes a report to /dev/shm/nginx_scan.txt or /tmp/nginx_scan.txt and sends everything to a command-and-control server at 158.94.210[.]227.

What these scripts actually change in the config files comes down to four standard NGINX directives.

→ location blocks capture incoming requests on specific URL paths → rewrite changes the request URL to include the full original path → proxy_pass forwards the traffic to attacker-controlled domains → proxy_set_header adjusts headers so everything looks legitimate

These are not obscure commands. System administrators use them every single day. That is exactly why this is so hard to detect. The malicious lines look like normal configuration. NGINX loads them without any error, and the server keeps running like nothing happened.

The campaign specifically targets servers with Asian top-level domains.

→ .in (India) → .id (Indonesia) → .pe (Peru) → .bd (Bangladesh) → .th (Thailand) → .edu (education) → .gov (government)

GreyNoise data from January 26 to February 2 shows 1,083 unique source IPs involved in React2Shell exploitation that feeds directly into this NGINX hijacking campaign. Two IPs were responsible for 56 percent of all attack traffic. The first, 193.142.147[.]209, generated 488,342 sessions and opens reverse shells on port 12323 directly back to the scanner. That is not automated harvesting, that is someone who wants hands-on access. The second, 87.121.84[.]24, deployed XMRig cryptocurrency miners through staging servers that have been hosting attacker domains since at least 2020. Neighboring IPs in the same subnet are distributing Mirai and Gafgyt botnet variants targeting IoT devices.

In cybersecurity, attribution is one of the hardest problems. IP addresses can be spoofed. Tools can be shared between groups. Language strings in code can be faked. What researchers know for certain is how the toolkit works, what infrastructure it uses, and where it points. AWS identified connections to Earth Lamia, a group targeting financial services, logistics, and government organizations across multiple continents, and to Jackpot Panda, which focuses on East and Southeast Asia. Google confirmed that Iran-nexus actors are exploiting React2Shell as well. The toolkit specifically targets Baota Panel, which is predominantly deployed on Chinese-hosted infrastructure. But infrastructure location and attribution are two different things.

Here is what makes this whole thing particularly nasty.

Most security tools look for malware, suspicious executables, or unusual network signatures. None of that applies here. There is no malicious binary to detect and no exploit signature to match. The attackers are hiding inside legitimate configuration files that were already on the server. A config review that only checks whether NGINX starts without errors will miss this completely because the injected directives are syntactically valid.

And the users visiting these compromised websites will never know. The pages load, the SSL certificate is still valid, and the URL in the browser bar is correct. Everything looks fine. But between the user and the actual website, there is now an invisible relay capturing everything.

What to do if running NGINX servers.

→ Review all NGINX config files for proxy_pass directives pointing to unknown backend servers → Search for unexpected rewrite rules and location blocks that were not part of the original setup → Check for the mapping file at /tmp/.domain_group_map.conf → Look for scan reports in /dev/shm/nginx_scan.txt or /tmp/nginx_scan.txt → Set up file integrity monitoring on all NGINX configuration directories → Monitor network logs for connections to 158.94.210[.]227 → If running React or Next.js applications, patch CVE-2025-55182 immediately → Treat NGINX configuration files as a security control surface, not just operational files that only matter when something breaks

The bigger picture here is that attackers are moving away from obvious malware. They are learning to live inside the infrastructure that is already there. When the attack looks like normal server administration, traditional detection does not stand a chance. The only defense is knowing how these systems work well enough to spot what does not belong.

This is exactly why understanding how attackers manipulate web infrastructure matters. I cover networking fundamentals, traffic interception, web application hacking, and real scanning and enumeration techniques in my ethical hacking course:

• → Join my complete ethical hacking course

(The link supports me directly as your instructor!)

Hacking is not a hobby but a way of life.