黑客入侵 NGINX 服务器以重定向用户流量

2026-02-05 10:41:41 2 970

黑客入侵 NGINX 服务器以重定向用户流量

攻击者正在入侵 NGINX 服务器,劫持用户流量并将其重新路由到攻击者的后端基础设施。

NGINX 是一款用于网络流量管理的开源软件。它充当用户和服务器之间的连接桥梁,并用于网站服务、负载均衡、缓存和反向代理。

DataDog 安全实验室的研究人员发现,此次恶意活动的目标是亚洲顶级域名(.in、.id、.pe、.bd 和 .th)以及政府和教育网站(.edu 和 .gov)使用的 NGINX 安装和 Baota 主机管理面板。


攻击者通过注入恶意“location”块来修改现有的 NGINX 配置文件,从而捕获攻击者选择的 URL 路径上的传入请求。

然后,他们重写这些 URL,使其包含完整的原始 URL,并通过“proxy_pass”指令将流量转发到攻击者控制的域。

被滥用的指令通常用于负载均衡,允许 NGINX 将请求重新路由到备用后端服务器组以提高性能或可靠性;因此,滥用该指令不会触发任何安全警报。

请求头(例如“Host”、“X-Real-IP”、“User-Agent”和“Referer”)会被保留,以使流量看起来合法。

该攻击使用脚本化的多阶段工具包来执行 NGINX 配置注入。该工具包分五个阶段运行:

第一阶段 – zx.sh:作为初始控制脚本,负责下载并执行剩余阶段。它包含一个备用机制,如果 curl 或 wget 不可用,则会通过 TCP 发送原始 HTTP 请求。
第二阶段 – bt.sh:针对由 Baota 控制面板管理的 NGINX 配置文件。它会根据 server_name 值动态选择注入模板,安全地覆盖配置,并重新加载 NGINX 以避免服务中断。
第三阶段 – 4zdh.sh:枚举常见的 NGINX 配置位置,例如 sites-enabled、conf.d 和 sites-available。它使用 csplit 和 awk 等解析工具来防止配置损坏,通过哈希和全局映射文件检测先前的注入,并在重新加载之前使用 nginx -t 验证更改。
第四阶段 – zdh.sh:采用更精准的目标定位方法,主要针对 /etc/nginx/sites-enabled 文件,尤其关注 .in 和 .id 域名。它遵循相同的配置测试和重新加载流程,并以强制重启 (pkill) 作为备用方案。
第五阶段 – ok.sh:扫描被入侵的 NGINX 配置,构建被劫持域名、注入模板和代理目标的映射图。收集到的数据随后被泄露到 158.94.210[.]227 的命令与控制 (C2) 服务器。

这些攻击很难被检测到,因为它们不利用 NGINX 漏洞;相反,它们将恶意指令隐藏在 NGINX 的配置文件中,而这些配置文件很少被仔细检查。

此外,用户流量仍然会到达预期目的地,通常是直接到达,因此除非进行专门的监控,否则不太可能注意到攻击者基础设施的经过。

关于作者

alanbit18篇文章14篇回复

评论2次

要评论?请先  登录  或  注册
  • 2楼
    2026-2-10 10:17

    结论

    攻击者通过注入恶意 location 块和 proxy_pass 指令劫持 NGINX 配置,绕过常规漏洞检测机制,实现流量中转。攻击链依赖配置文件篡改而非代码漏洞,需通过配置审计和行为监控进行防御。核心危害在于攻击者通过保留请求头维持流量合法性,且流量最终仍抵达目标服务器,隐蔽性强。


    分析路径(Source-Sink 分析)

    1. Source(攻击入口)

      • Baota 面板漏洞/弱凭据:攻击者可能通过 Baota 管理面板未授权访问或弱密码获取服务器权限。
      • 横向渗透:利用已入侵服务器部署的脚本(如 zx.sh)扩散,或通过未隔离的网络环境横向移动。
      • 配置文件写入权限:攻击者通过执行恶意脚本(如 bt.sh4zdh.sh)修改 NGINX 配置文件(sites-enabled/*.confconf.d/*.conf)。
    2. Sink(攻击触发点)

      • 恶意 location 块注入:在配置文件中添加规则,将特定 URL 路径的流量通过 proxy_pass 重定向到 C2(如 158.94.210.227)。
      • 请求头伪造:保留原始 HostUser-Agent 等字段,使流量绕过 WAF 或 IDS 检测。
    3. 传播与持久化

      • 多阶段脚本(zx.sh → bt.sh → 4zdh.sh → zdh.sh → ok.sh)按层级覆盖配置,确保注入不中断服务。
      • ok.sh 定期收集被控域名并回传数据至 C2,形成自动化监控链。

    验证步骤

    L1-L2 配置文件审计

    1. 检查 NGINX 配置文件

      # 查找恶意 location/proxy_pass 指令  grep -rni "proxy_pass" /etc/nginx/*  grep -rni "location" /etc/nginx/* | grep -v "root\|alias"  
      • 关注异常 proxy_pass 值(如 http://158.94.210.227/proxy 或动态 URL)。
    2. 验证配置变更时间戳

      find /etc/nginx -type f -mtime -7 -exec stat --format="%n %y" {} \;  # 检查最近7天修改的文件  
      • 对比修改时间与服务器常规维护周期,排查非授权变更。
    3. 检查恶意脚本残留

      # 搜索与攻击链相关的脚本名  find /tmp /var/tmp /root /home -name "*zx.sh*" -o -name "*bt.sh*"  # 检查 cron 或 systemd 定时任务  cron -l | grep "zx.sh\|bt.sh"  systemctl list-timers --all | grep "nginx"  

    L3-L4 流量与行为检测

    1. 流量捕获与分析

      # 实时监控 NGINX 反向代理流量  tcpdump -i any port 80 or 443 -w nginx_traffic.pcap  # 解析 PCAP 文件查找异常代理请求  tshark -r nginx_traffic.pcap -Y "http.request.uri contains 'proxy_pass'"  
      • 检查 Host 头是否与目标域名匹配(如请求 .in 域名却指向外部 IP)。
    2. 检查 C2 通信

      # 检查是否存在到 158.94.210.227 的异常连接  netstat -anp | grep "158.94.210.227"  # 查看历史连接记录  journalctl | grep "158.94.210.227"  

    修复建议

    1. 配置文件加固

      • 签名验证:对 NGINX 配置文件启用哈xi签名(如 nginx -t 结合 difftripwire)。
      • 权限隔离:仅允许 Baota 面板进程以受限用户(非 root)写入配置文件,禁止脚本直接操作配置目录。
    2. 横向渗透防御

      • 网络隔离:将 NGINX 服务器与内部网络隔离,仅开放必要的管理端口(如 80/443)。
      • 最小权限原则:Baota 管理面板使用强凭据,定期检查登录日志(/var/log/nginx/access.log)。
    3. 实时监控与告警

      • 配置变更监控:部署工具(如 auditd)监控 /etc/nginx 目录的修改事件。
        auditctl -w /etc/nginx -p wa -k nginx_config_watch  
      • 流量行为分析:设置 WAF 规则拦截 proxy_pass 相关的异常 URL 路径模式。
    4. 攻击链中断

      • 阻断 C2 通信:将 158.94.210.227 添加到防火墙黑名单(iptables 或云防火墙)。
      • 清理恶意脚本:删除所有与攻击链相关的 .sh 文件,并重置 Baota 面板凭证。

    技术延伸(防御反推)

    • 攻击者视角:攻击者依赖配置文件的“合法”修改特性,需通过以下技术防御:
      1. 配置版本控制:使用 etckeeper 或 Git 管理 NGINX 配置变更,记录所有修改记录。
      2. 自动化检测:编写脚本定期对比配置文件与基线版本,触发差异告警。
      3. 运行时保护:启用 NGINX 主动健康检查模块(nginx-module-vts),监控异常代理请求模式。

    关键结论:配置文件篡改是核心攻击载体,需从权限、监控、签名验证三个维度构建防护链。

  • 1楼
    2026-2-6 09:15

    这个备用机制做的很6 即使发现 curl 或 wget 不可用, 那么也可以 则会通过 TCP 发送原始 HTTP 请求,周密的攻击思路。