Hackers compromise NGINX servers to redirect user traffic

Hackers are compromising NGINX servers in a sophisticated campaign that hijacks user traffic and reroutes it through attacker-controlled infrastructure, according to researchers at DataDog Security Labs.

NGINX is open-source software for web traffic management that intermediates connections between users and servers. It's employed for web serving, load balancing, caching, and reverse proxying. The malicious campaign targets NGINX installations and Baota hosting management panels used by sites with Asian top-level domains (.in, .id, .pe, .bd, and .th) and government and educational sites (.edu and .gov).

How the attack works

The attackers modify existing NGINX configuration files by injecting malicious 'location' blocks that capture incoming requests on attacker-selected URL paths. They then rewrite them to include the full original URL, and forward traffic via the 'proxy_pass' directive to attacker-controlled domains.

This abuse of the 'proxy_pass' directive is particularly insidious because it's normally used for legitimate load balancing purposes, allowing NGINX to reroute requests through alternative backend server groups to improve performance or reliability. Since this is standard functionality, the malicious use doesn't trigger typical security alerts.

Request headers such as 'Host,' 'X-Real-IP,' 'User-Agent,' and 'Referer' are preserved to make the traffic appear legitimate to both the destination server and any monitoring systems.

The multi-stage attack toolkit

The attack employs a sophisticated scripted multi-stage toolkit that operates in five distinct stages:

Stage 1 – zx.sh: Acts as the initial controller script, responsible for downloading and executing the remaining stages. It includes a fallback mechanism that sends raw HTTP requests over TCP if curl or wget are unavailable.

Stage 2 – bt.sh: Targets NGINX configuration files managed by the Baota panel. It dynamically selects injection templates based on the server_name value, safely overwrites the configuration, and reloads NGINX to avoid service downtime.

Stage 3 – 4zdh.sh: Enumerates common NGINX configuration locations such as sites-enabled, conf.d, and sites-available. It uses parsing tools like csplit and awk to prevent configuration corruption, detects prior injections via hashing and a global mapping file, and validates changes using nginx -t before reloading.

Stage 4 – zdh.sh: Uses a narrower targeting approach focused mainly on /etc/nginx/sites-enabled, with emphasis on .in and .id domains. It follows the same configuration testing and reload process, with a forced restart (pkill) used as a fallback.

Stage 5 – ok.sh: Scans compromised NGINX configurations to build a map of hijacked domains, injection templates, and proxy targets. The collected data is then exfiltrated to a command-and-control (C2) server at 158.94.210[.]227.

Overview of the hijacking attack Source: Datadog

Why these attacks are difficult to detect

These attacks are particularly challenging to detect because they don't exploit an NGINX vulnerability. Instead, they hide malicious instructions in configuration files, which are rarely scrutinized by security teams.

Additionally, user traffic still reaches the intended destination, often directly, so the passing through attacker infrastructure is unlikely to be noticed unless specific monitoring is performed. The preserved headers and legitimate-looking traffic patterns make detection even more difficult.

Protection and detection strategies

Organizations running NGINX servers should implement several protective measures:

• Regular configuration audits: Implement automated scanning of NGINX configuration files to detect unauthorized 'location' blocks or unusual 'proxy_pass' directives

• Integrity monitoring: Use file integrity monitoring (FIM) tools to alert on unauthorized changes to NGINX configuration files

• Network traffic analysis: Monitor for unusual patterns in traffic routing, particularly unexpected connections to external proxy servers

• Access control: Restrict who can modify NGINX configurations and maintain detailed audit logs of all changes

• Security hardening: Ensure NGINX is running with minimal privileges and that configuration directories have appropriate permissions

Broader context

This attack represents a growing trend of configuration-based attacks that exploit legitimate functionality rather than software vulnerabilities. Similar techniques have been observed in other web infrastructure attacks, including recent incidents involving Cloudflare misconfigurations and compromised hosting panels.

The sophistication of this multi-stage toolkit, combined with its ability to evade detection while maintaining service availability, makes it particularly dangerous for organizations that rely on NGINX for critical web services.

Organizations should review their NGINX configurations immediately and implement the protective measures outlined above to prevent falling victim to this stealthy attack technique.