NGINX security alert under proxy _ pass handling attack to divert traffic

If you use NGINX to serve sites, do load balancing or as a proxy inverse, pay attention: a campaign has recently been detected in which a malicious actor commits NGINX servers and hosting management tools to redirect users' traffic to their own infrastructure, maintaining the appearance of normal.

NGINX is, by design, an intermediary between the visitor and the final server: it receives requests, applies rules, can search and send them back to other backends. That flexibility is precisely what these attackers exploit. Datadog Security Labs researchers have documented how attackers enter malicious configuration blocks into NGINX files - especially in facilities managed with the Baota panel - to capture specific routes and send them back through the directive proxy _ pass to servers controlled by them. You can read more about Datadog's work in the security section of his blog ( Datadog Security Labs).

What the campaign does is inject blocks. location that match routes chosen by the attacker and rewrite the request to include the original URL before routing it with proxy _ pass to external domains. To make the redirection seem legitimate, they keep headers like Host, X-Real-IP, User-Agent or Refer. Since proxy _ pass is a legitimate and very used feature for balancing and failing, their abuse goes unnoticed if the configurations are not inspected.

The discovered modus operandi includes a set of automated scripts that act in stages: an initial driver downloads and runs the remaining components and can even send raw HTTP requests to TCP if there are no tools such as curl or wget; another component is specifically directed to files managed by the Baota panel and selects injection templates according to the value of server _ name, overwriting the configuration so that the service does not stop providing service; there are tools that search and process configuration files in typical locations (sites-enabled, conf.d, sites-available), use text utilities to separate and edit fragments without corrupt them, validate changes with nginx -t before recharging and marking the files already infected by amounts to avoid doubling the injection; another piece focuses the attack on a subset of domains (according to researchers, many with regional terminations such as .in and .id and also sites with .edu / .gov suffixes) and uses forced reinitials as a last resort; finally there is a script that would invent a map of compromised domains and exfiltracts that information to a command and control server identified by the trackers.

Precisely because a vulnerability is not used in the NGINX engine but the ability to modify your configuration files, these attacks are complex to detect. Managers may not notice anything strange: users continue to receive the expected content and traffic does not present visible faults to the naked eye. In addition, by keeping headers and sending requests, the interaction seems legitimate from the customer's perspective and many monitoring systems ignore the difference.

If you want to check if your environment is affected, there are several practical lines of defense. Check the NGINX settings carefully for location and proxy _ pass that point to domains or PIs outside your organization; a simple command to start is to search for proxy _ pass occurrences on typical configuration routes, and always validate with nginx -t before recharge. Limit who can write in the configuration files and in the directories of the hosting panel, monitor unexpected changes with file integrity systems and record and alert on NGINX recharges or reboot. It is also recommended to restrict unauthorised outgoing traffic from web servers, and protect control panels such as Baota with strong passwords, multifactor authentication and IP access where possible. The Baota panel has an online presence on its official site ( BaoTa (BT.cn)) and it is appropriate to ensure that these bodies are exposed.

To understand why detecting these manipulations is not trivial, remember that proxy _ pass is a documented and common NGINX directive; the technical documentation itself describes its use to send requests to backends and is a fundamental piece in modern architectures ( NGINX official documentation on proxy _ pass). That means that malicious changes are camouflaged as valid and functional configurations.

If you want to follow the research or check indicators, the response teams usually publish devices and IP addresses associated with C2 for blocking in firewalls and rejection lists; for example, one of the addresses associated with the researchers can be consulted on public reputation bases ( consultation in AbuseIPDB for 158.94.210.227), which helps to take network action at the defensive level.

In short, it is not enough to protect the software: it is necessary to protect the configuration and access to it. regularly review configuration files, limit changes to authorized personnel and monitor NGINX network telemetry and recharges are essential measures to detect and contain such campaigns. If you manage servers with hosting panels, make sure that these panels are up-to-date and that access is strongly authenticated; the security of the management layer is often the most fragile link in these incidents.

If you want to deepen specific technical recommendations and mitigation practices, the community and suppliers such as Datadog or NGINX itself publish guides and technical entries that should be followed: in addition to the technical article of Datadog cited at the beginning, NGINX maintains entries on good security practices on its blog ( NGINX safety - guide and recommendations). Combining these good practices with integrity and network controls is the best recipe for not taking surprises.