A threat actor is compromising NGINX servers in a campaign that hijacks user traffic and reroutes it through the attacker’s backend infrastructure.
NGINX is open-source software for web traffic management. It intermediates connections between users and servers and is employed for web serving, load balancing, caching, and reverse proxying.
The malicious campaign, discovered by researchers at DataDog Security Labs, 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).
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.
The abused directive is normally used for load balancing, allowing NGINX to reroute requests through alternative backend server groups to improve performance or reliability; hence, its abuse does not trigger any security alerts.
Request headers such as ‘Host,’ ‘X-Real-IP,’ ‘User-Agent,’ and ‘Referer’ are preserved to make the traffic appear legitimate.
The attack uses a scripted multi-stage toolkit to perform the NGINX configuration injections. The toolkit operates in five 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
These attacks are hard to detect because they do not exploit an NGINX vulnerability; instead, they hide malicious instructions in its configuration files, which are rarely scrutinized.
Also, 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.
Modern IT infrastructure moves faster than manual workflows can handle.
In this new Tines guide, learn how your team can reduce hidden manual delays, improve reliability through automated response, and build and scale intelligent workflows on top of tools you already use.
Get the guide
