Imagine your website suddenly sending visitors to a completely different, unknown place, all without you knowing! That's the alarming reality for some NGINX server owners as a sophisticated hacking campaign is actively compromising their systems, hijacking user traffic, and rerouting it through the attackers' own hidden infrastructure. This isn't your typical exploit; it's a stealthy infiltration that's leaving many scratching their heads.
NGINX, for those unfamiliar, is a powerful and widely-used open-source tool that acts as a traffic manager for the web. Think of it as a super-efficient receptionist for your website, handling connections between users and servers. It's essential for tasks like serving web pages, balancing loads so your site doesn't crash under pressure, caching content for speed, and acting as a reverse proxy to shield your main servers. It’s the silent workhorse behind many of your favorite online experiences.
The clever minds at DataDog Security Labs uncovered this malicious operation. They found that attackers are specifically targeting NGINX installations, often those managed by the Baota hosting control panel. This campaign seems to have a particular eye for websites using Asian top-level domains (like .in, .id, .pe, .bd, and .th) and even crucial government and educational sites (.edu and .gov). This broad targeting raises concerns about the potential impact across various sectors.
But here's where it gets particularly sneaky... Instead of breaking into the NGINX software itself, the attackers are subtly altering its configuration files. They're injecting malicious 'location' blocks – imagine adding secret instructions to your receptionist's script. These instructions intercept incoming requests based on specific URL paths chosen by the attacker. Then, using a directive called 'proxypass,' they rewrite these requests to include the entire original URL and send the traffic off to domains controlled by the attackers. This is a masterful deception because the 'proxypass' directive is normally used for legitimate purposes like load balancing, meaning its abuse doesn't typically set off any alarms. It’s like using a secret handshake to get past security!
To make this hijacked traffic look as legitimate as possible, the attackers are diligently preserving crucial request headers. This includes details like the 'Host' (which website was requested), 'X-Real-IP' (the visitor's apparent IP address), 'User-Agent' (the browser or device used), and 'Referer' (where the visitor came from). By keeping these intact, the rerouted traffic blends in seamlessly, making it incredibly difficult to spot.
The entire operation is orchestrated by a sophisticated, multi-stage toolkit that automates the NGINX configuration injections. Let's break down its five stages:
- Stage 1 – zx.sh: This is the initial mastermind. It's responsible for downloading and kicking off all the subsequent stages. It's even got a clever backup plan: if standard tools like curl or wget aren't available, it can send raw HTTP requests directly over TCP to get the job done.
- Stage 2 – bt.sh: This stage focuses specifically on NGINX configurations managed by the Baota panel. It intelligently selects the right injection templates based on the server's name and then carefully overwrites the configuration. Crucially, it reloads NGINX in a way that aims to prevent any service interruptions, keeping the deception going smoothly.
- Stage 3 – 4zdh.sh: This stage is like a meticulous librarian, searching through common NGINX configuration directories. It uses powerful parsing tools to ensure it doesn't corrupt any files. It even has a system to detect if previous injections have already occurred by using hashing and a global mapping file. Before applying any changes, it validates them with
nginx -tand then reloads the service. - Stage 4 – zdh.sh: This stage takes a more focused approach, primarily targeting configurations within
/etc/nginx/sites-enabled, with a special emphasis on .in and .id domains. It follows a similar process of testing and reloading configurations, with a forceful restart (pkill) as a last resort if needed. - Stage 5 – ok.sh: The final act is reconnaissance. This stage scans the compromised NGINX configurations to build a comprehensive map of all the hijacked domains, the injection templates used, and the proxy targets. All this valuable intel is then sent back to a command-and-control (C2) server located at 158.94.210[.]227.
And this is the part most people miss... These attacks are incredibly difficult to detect precisely because they don't exploit a flaw in NGINX itself. Instead, the malicious instructions are cleverly hidden within the configuration files, which are typically not scrutinized with the same intensity as the software code. Furthermore, because user traffic often still reaches its intended destination, albeit via a detour, the subtle rerouting is unlikely to be noticed unless very specific monitoring is in place.
This sophisticated method of compromising servers raises some serious questions. Is it time for website owners to move beyond basic security checks and implement more rigorous configuration auditing? And considering the attackers are leveraging legitimate NGINX directives, how can security tools effectively differentiate between normal operations and malicious intent? Let us know your thoughts in the comments below!
