Datadog Security Labs has reported a large-scale malicious campaign in which attackers gain access to Nginx servers and silently route user traffic through their own infrastructure. The attack abuses legitimate Nginx reverse proxy features, making the activity appear indistinguishable from normal load balancing and therefore extremely difficult for traditional monitoring and security tools to detect.
Targeted infrastructure: Nginx servers and Baota hosting panels
According to Datadog’s analysis, the campaign is associated with exploitation of a vulnerability tracked as React2Shell, which is believed to provide the initial foothold on vulnerable systems. Once inside, the attackers focus on environments running Nginx and the Baota (also known as BT) hosting control panel, a popular web hosting management solution widely used for virtual and dedicated servers, especially in Asian markets.
The compromised infrastructure primarily serves domains popular in Asia, including .in, .id, .pe, .bd, .th. The operators also show a clear interest in .edu and .gov domains. Targeting educational and government sites is strategically valuable: these domains enjoy high reputation among users and search engines, which increases the success rate of phishing, financial fraud, and the distribution of malware when traffic is silently intercepted or modified.
How attackers hijack Nginx traffic without exploiting Nginx itself
Abuse of Nginx location blocks and proxy_pass directives
On compromised servers, the attackers do not exploit vulnerabilities in Nginx itself. Instead, they manipulate existing configuration files. Hidden location blocks are injected into active configuration files, carefully crafted to intercept requests to specific URLs and forward them using the proxy_pass directive to attacker-controlled servers.
Crucially, during this proxying, the forwarded request retains the original context. HTTP headers such as Host, X-Real-IP, User-Agent, Referer, and others are preserved. From the outside, the traffic still appears to be a legitimate request to the original website, merely traversing a standard load balancer or reverse proxy tier. For most security tools and SIEM rulesets, this looks like normal Nginx behavior, not an indicator of compromise.
Automated Nginx configuration tampering at scale
Datadog’s researchers highlight that the adversaries rely on an automated toolkit to apply these configuration changes rapidly and consistently. The observed workflow includes scanning for vulnerable systems, exploiting React2Shell or related flaws, modifying Nginx and Baota configuration files, inserting malicious location and proxy_pass directives, and finally restarting or reloading Nginx to activate the changes.
This automation allows the attackers to scale the campaign across many hosts with minimal effort. Malicious directives are embedded inside existing, often complex, configuration files that are rarely subjected to systematic integrity checks in many organizations. As a result, even experienced administrators may overlook a few extra lines in a large configuration file, particularly when they appear syntactically valid.
Why malicious Nginx reverse proxy attacks are so hard to detect
A key factor in the campaign’s effectiveness is that user traffic still ultimately reaches the legitimate site. End users see the correct interface, can log in, submit forms, and complete transactions as usual. The fact that their requests and responses transit attacker-controlled infrastructure remains invisible from the user’s perspective.
First, the attack leverages standard Nginx functionality: reverse proxying and load balancing. For monitoring systems and many security baselines, such configurations are typical for high-traffic websites and microservices architectures. Without a known-good configuration baseline, malicious proxy rules blend in with legitimate ones.
Second, the attackers avoid changing application code or Nginx binaries. They operate exclusively at the configuration level. Configuration files are often a blind spot in security operations if organizations lack formal integrity monitoring, file whitelisting, or version control for infrastructure-as-code. Tools focused only on code or package integrity may miss this entire class of attack.
Third, without dedicated network telemetry and route analysis, administrators may not realize that a subset of requests is routed via untrusted IP ranges or domains. Nginx access logs on the victim server can look routine: they show inbound requests and successful responses. Any suspicious behavior—such as credential harvesting, injection of malicious JavaScript, or traffic cloning—occurs on the attacker’s proxy infrastructure, outside the victim’s logging and monitoring perimeter.
This pattern resembles advanced reverse-proxy phishing and “ad-injection” campaigns previously documented by industry vendors such as Cloudflare and Google, where attackers position themselves transparently in the communication path rather than directly compromising front-end application code.
Security best practices to protect Nginx and Baota environments
Given Nginx’s widespread adoption—industry surveys such as W3Techs attribute roughly a third of all websites to Nginx-based stacks—abuse of its configuration layer has systemic impact. To reduce risk from similar campaigns, organizations should adopt a layered defense approach:
1. Implement configuration integrity monitoring. Treat Nginx and Baota configuration files as critical assets. Use version control (e.g., Git), configuration management (Ansible, Puppet, Chef), or dedicated file integrity monitoring to compare current configs with known-good baselines and alert on any unauthorized changes.
2. Harden and segment administrative access. Strictly limit accounts allowed to modify Nginx and hosting control panel settings. Enforce multi-factor authentication, use key-based access for SSH, restrict management interfaces to dedicated admin networks or VPNs, and separate admin planes from public-facing services.
3. Patch vulnerabilities quickly, including React2Shell. Maintain an active vulnerability management process that tracks issues affecting frameworks, hosting panels, and supporting components. Prioritize patching and mitigations for vulnerabilities like React2Shell that can grant initial remote code execution or web shell access.
4. Deploy deep network and proxy path monitoring. Correlate expected proxying behavior with actual flows. Monitor for unexpected external IPs or domains appearing in upstream or proxy_pass directives, and use network detection and response (NDR) tools to flag unusual routing paths or sudden changes in outbound traffic patterns from web tiers.
5. Use specialized web security controls. Deploy a web application firewall (WAF), intrusion detection/prevention systems (IDS/IPS), and traffic behavior analytics capable of detecting anomalous request patterns, suspicious header manipulations, and unexpected content injection—even when requests appear to succeed normally.
As this campaign demonstrates, once attackers gain a single foothold on a server, they can convert Nginx into a powerful, stealthy traffic interception layer. Organizations that regularly audit their configurations, enforce strict access controls, aggressively remediate vulnerabilities, and invest in advanced monitoring are far better positioned to disrupt such attacks early and protect both their own infrastructure and the users who trust their services.
