NGINX config tampering enables stealth web traffic hijack

Datadog Security Research has tracked a web traffic hijacking campaign that abuses NGINX configuration files to intercept and reroute live user sessions through attacker-controlled servers.

The activity marks a shift from attacks on stored data to quietly monitoring and manipulating active web traffic for extended periods. By staying in the path between users and sites, attackers can harvest credentials in transit, impersonate users, and modify web pages or API responses in real time-while sessions appear normal to victims.

Datadog linked the campaign to actors associated with recent React2Shell exploitation. The technique relies on malicious NGINX configurations that act as an invisible relay between users and legitimate web services.

Researchers Christophe Tafani-Dereeper and Ryan Simon monitored exploitation activity after React2Shell was disclosed. Their findings point to configuration tampering rather than the installation of new malware on disk.

Target profile

Observed targeting concentrates on Asian top-level domains and related infrastructure. Datadog highlighted domains ending in .in, .id, .pe, .bd, .edu, .gov, and .th as part of the pattern.

The analysis also points to the use of Chinese hosting infrastructure and the Baota Panel (BT), a web hosting management interface that can manage NGINX and related web stack components.

Datadog framed the campaign as an example of attackers persisting by abusing legitimate mechanisms. Because configuration files are part of routine administration, unauthorised changes can be harder to spot in busy environments.

How it works

NGINX is widely used as a web server and reverse proxy. Configuration files define its behaviour and control how traffic is routed and processed.

Several common directives can be abused during an intrusion. Datadog highlighted proxy_pass, rewrite, proxy_set_header, and location as key directives used in the campaign.

proxy_pass forwards requests to backend servers, often for load balancing or as part of an application gateway. rewrite changes the request URL. proxy_set_header influences the request context passed to upstream systems. location controls how the server processes requests for specific paths.

Rather than adding new binaries, the attackers modified existing NGINX configuration files. That reduces the chance of detection by tools focused on malware signatures and suspicious executables.

Multi-stage tooling

The campaign uses an automated, multi-stage toolkit. The initial entry point is a script called zx.sh, which orchestrates later steps and fetches components using common tools such as curl and wget.

If those tools are unavailable, the toolkit falls back to a Bash function that creates a raw TCP connection and sends an HTTP request, allowing it to operate in environments with restricted utilities.

One stage, bt.sh, targets Baota deployments. It enumerates the configuration path /www/server/panel/vhost/nginx and checks whether malicious proxied domains already exist before proceeding.

The script uses the server_name variable to select an injection template based on the domain's top-level domain, then chooses a path via a hardcoded variable. It iterates through the configuration file, finds the server_name directive, saves the original line, appends the malicious configuration, and overwrites the file.

To reduce disruption, it attempts an NGINX reload so existing connections remain active. If that fails, it attempts a full restart.

A more advanced script, 4zdh.sh, expands the search to common NGINX configuration directories, including /etc/nginx/sites-enabled, /etc/nginx/conf.d, and /etc/nginx/sites-available, and also checks for Baota. It uses csplit and awk to identify server blocks and inject changes without corrupting the configuration structure.

The same stage checks for prior injections and generates MD5 hashes. Datadog's analysis says it stores a global map file at /tmp/.domain_group_map.conf and runs nginx -t to validate the configuration before attempting a reload.

Another stage, zdh.sh, focuses on Linux or containerised NGINX environments with a narrower path scope. It targets /etc/nginx/sites-enabled and prioritises top-level domains such as .in and .id, with a fallback restart method that uses pkill.

The toolkit also includes a mapping and reporting stage, ok.sh. Datadog said it generates a report of active traffic hijacking rules, writes a temporary file named nginx_scan.txt in /dev/shm or /tmp, and exfiltrates the data to a command-and-control server at 158.94.210[.]227.

Defensive focus

The campaign increases pressure on defenders to treat web server configuration as a security control surface, not just an operational artefact. It also underscores the risk of attacks that avoid installing obvious malware, where endpoint tools may look first.

"This campaign highlights a growing blind spot in traditional web security. Attackers are increasingly persisting by abusing legitimate configuration mechanisms rather than deploying obviously malicious software," said Tafani-Dereeper.

"In this case, the attackers consistently modified existing NGINX configuration files rather than introducing new binaries. That means defences focused only on malware detection or network signatures may never see the attack," Simon said.