黑客入侵 NGINX 服务器以重定向用户流量
黑客入侵 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 的配置文件中，而这些配置文件很少被仔细检查。
此外，用户流量仍然会到达预期目的地，通常是直接到达，因此除非进行专门的监控，否则不太可能注意到攻击者基础设施的经过。
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 的配置文件中，而这些配置文件很少被仔细检查。
此外，用户流量仍然会到达预期目的地，通常是直接到达，因此除非进行专门的监控，否则不太可能注意到攻击者基础设施的经过。
关于作者
评论2次
### 结论 攻击者通过注入恶意 `location` 块和 `proxy_pass` 指令劫持 NGINX 配置，绕过常规漏洞检测机制，实现流量中转。攻击链依赖配置文件篡改而非代码漏洞，需通过配置审计和行为监控进行防御。核心危害在于攻击者通过保留请求头维持流量合法性，且流量最终仍抵达目标服务器，隐蔽性强。 --- ### 分析路径（Source-Sink 分析） 1. **Source（攻击入口）** - **Baota 面板漏洞/弱凭据**：攻击者可能通过 Baota 管理面板未授权访问或弱密码获取服务器权限。 - **横向渗透**：利用已入侵服务器部署的脚本（如 `zx.sh`）扩散，或通过未隔离的网络环境横向移动。 - **配置文件写入权限**：攻击者通过执行恶意脚本（如 `bt.sh`、`4zdh.sh`）修改 NGINX 配置文件（`sites-enabled/*.conf`、`conf.d/*.conf`）。 2. **Sink（攻击触发点）** - **恶意 `location` 块注入**：在配置文件中添加规则，将特定 URL 路径的流量通过 `proxy_pass` 重定向到 C2（如 `158.94.210.227`）。 - **请求头伪造**：保留原始 `Host`、`User-Agent` 等字段，使流量绕过 WAF 或 IDS 检测。 3. **传播与持久化** - 多阶段脚本（`zx.sh → bt.sh → 4zdh.sh → zdh.sh → ok.sh`）按层级覆盖配置，确保注入不中断服务。 - `ok.sh` 定期收集被控域名并回传数据至 C2，形成自动化监控链。 --- ### 验证步骤 #### L1-L2 配置文件审计 1. **检查 NGINX 配置文件** ```bash # 查找恶意 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. **验证配置变更时间戳** ```bash find /etc/nginx -type f -mtime -7 -exec stat --format="%n %y" {} \; # 检查最近7天修改的文件 ``` - 对比修改时间与服务器常规维护周期，排查非授权变更。 3. **检查恶意脚本残留** ```bash # 搜索与攻击链相关的脚本名 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 流量与行为检测 4. **流量捕获与分析** ```bash # 实时监控 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）。 5. **检查 C2 通信** ```bash # 检查是否存在到 158.94.210.227 的异常连接 netstat -anp | grep "158.94.210.227" # 查看历史连接记录 journalctl | grep "158.94.210.227" ``` --- ### 修复建议 1. **配置文件加固** - **签名验证**：对 NGINX 配置文件启用哈xi签名（如 `nginx -t` 结合 `diff` 或 `tripwire`）。 - **权限隔离**：仅允许 Baota 面板进程以受限用户（非 root）写入配置文件，禁止脚本直接操作配置目录。 2. **横向渗透防御** - **网络隔离**：将 NGINX 服务器与内部网络隔离，仅开放必要的管理端口（如 80/443）。 - **最小权限原则**：Baota 管理面板使用强凭据，定期检查登录日志（`/var/log/nginx/access.log`）。 3. **实时监控与告警** - **配置变更监控**：部署工具（如 `auditd`）监控 `/etc/nginx` 目录的修改事件。 ```bash 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`），监控异常代理请求模式。 --- 关键结论：**配置文件篡改是核心攻击载体**，需从权限、监控、签名验证三个维度构建防护链。
这个备用机制做的很6 即使发现 curl 或 wget 不可用， 那么也可以 则会通过 TCP 发送原始 HTTP 请求，周密的攻击思路。