您的位置: 新闻资讯 > 行业动态 > 正文

僵尸网络与 APT 如何利用 DNS 请求?从 Hermit(隐士)组织看隐蔽 C2 的检测与应对(图文)


来源:mozhe 2026-11-02

 

一、最"合法"的流量,藏着最隐蔽的通道

在企业网络的边界策略里,几乎每一条协议都被管控过:80/443 要过 WAF,FTP/SSH 要收敛白名单,连 ICMP 都要做类型和限速——唯独 DNS(UDP 53),在多数企业里是"无条件放行"的。

攻击者比谁都清楚这一点。无论是拿肉鸡组建僵尸网络(Botnet)批量下发指令,还是 APT 组织渗透进来长期潜伏、悄悄外传数据,把控制指令和数据藏进看似普通的 DNS 请求里,是成本最低、穿透性最强的隐蔽通信方式之一。

这篇以腾讯命名的 APT 组织 Hermit(隐士) 为引子,讲清楚三件事:僵尸网络和 APT 组织是怎么利用 DNS 请求通信的;企业如何在海量 DNS 流量里发现异常;发现之后怎么应对。

二、先把名词摆正:僵尸网络、APT 和那个叫 Hermit 的组织

2.1 僵尸网络(Botnet)与 APT:规模与精度的两个极端

  • 僵尸网络:通过木马控制大量"肉鸡"组成的网络,追求规模,用来发起 DDoS、批量挖矿、群发垃圾邮件。控制端(C2)需要持续向成千上万台受控主机下发指令——通信通道的隐蔽性和抗封堵能力,决定僵尸网络的寿命;
  • APT(高级持续性威胁):针对特定目标(政府、金融、高科技)的定向渗透,追求潜伏时长和信息价值,同样需要一个能长期不被发现的回传通道。

两者的手法不同,但对"隐蔽 C2"的需求是相通的。DNS 恰好同时满足两者。

2.2 Hermit(隐士)是谁?

Hermit(隐士)是腾讯御见威胁情报中心于 2018 年 12 月命名披露的 APT 组织,因诱饵文档的恶意内容在受害者启用宏之前处于"隐藏"状态而得名。公开报告的要点:

  • 关联:与 Konni 组织高度关联,手法与 SYSCON/SANNY 木马一脉相承,被认为与 Darkhotel 存在关联;
  • 手法:鱼叉钓鱼邮件 + 恶意宏文档,利用系统自带工具(如 certutil)下载解码载荷,最终植入 Babyface 远控、SYSCON/SANNY 后门,长期驻留窃取信息;
  • 目标:朝鲜半岛相关的政治人物、政府机构、NGO、贸易与媒体机构,后期扩展到区块链、数字货币、金融目标与外交实体;
  • C2 通信:公开报告显示,该组织的后门使用 FTP/HTTP 等"低调协议"与控制端通信——刻意选用企业网络里"看起来正常"的协议混入流量。

一个重要提醒:安全圈还有另一个同名物——Hermit 移动间谍软件(意大利监控厂商 RCS Lab 出品,Google TAG 于 2022 年披露,针对 iOS/Android)。两者毫无关联,检索资料时不要混淆。

2.3 从 Hermit 的手法看一个共同规律

注意 Hermit 的 C2 选择:不是什么炫技协议,而是 FTP——一个几乎每家企业都放行、几乎没人盯日志的老协议。这背后的逻辑正是本文的主角:

攻击者不追求"最强的通道",追求的是"看起来最正常的通道"。

而放眼整个威胁版图,比 FTP 更正常、更必放行、更没人审计的,就是 DNS 请求。大量僵尸网络家族和 APT 活动将 DNS 用作 C2 通道或数据外传通道,这也是"DNS 隧道"长期位列企业最应防范的隐蔽通道之首的原因。

三、DNS 请求是怎么变成"隐形通道"的

理解原理是为了更好地检测,以下只做概念级拆解。

3.1 为什么 DNS 天然适合隐蔽通信

特性 对攻击者的价值
几乎所有网络无条件放行 无需打洞、无需绕过防火墙
协议不加密、但极少被审计 检测设备少、日志少人看
域名系统层级化 指令可"寄存"在恶意域名的解析记录里,受控机来"取件"
UDP 53 无连接 通信行为轻量,难触发告警

3.2 两种常见形态(概念)

形态一:C2 轮询(信标式)。受控主机周期性地请求攻击者控制的域名,解析结果返回的 IP 就是 C2 服务器地址——收到 IP 即上线。这类流量单看每一条 DNS 请求完全正常,异常只体现在频率规律和域名特征上。更换 IP 成本极低(改一条解析记录),封 IP 封不完,这是僵尸网络 C2 池的常见做法。

形态二:DNS 隧道(数据外传/指令下发)。把数据编码进子域名发起查询,攻击者的权威 DNS 收到查询即"收到数据",再把指令编码进 TXT 等记录的应答中返回——一来一回,形成双向隧道。此时 DNS 流量里会出现异常长的子域名、异常高的查询频率这类特征。

对企业的实际含义:只盯着 IP 黑名单是防不住这类通道的,因为通道本身由域名和查询行为构成。

四、检测:8 类 DNS 异常特征(可直接落地)

以下特征按"可实现难度从低到高"排列,前三项只要能拿到 DNS 日志就能做:

  1. 超长子域名:正常域名查询极少超过 50–60 字符;编码数据的子域名动辄上百字符,设阈值告警;
  2. 高熵(乱码感)子域名:随机编码的子域名与正常业务域名风格差异明显;
  3. TXT/NULL 等记录类型查询激增:正常业务几乎不查 TXT,某台内网主机频繁发起 TXT 查询是隧道的高危信号;
  4. NXDOMAIN 风暴:大量不存在的域名查询(可能来自 DGA 域名算法或域名扫描),既可能是失陷主机特征,也会压垮内部递归 DNS;
  5. 新注册/短命域名:攻击基础设施域名通常注册时间很近,结合威胁情报的"域名注册年龄"过滤;
  6. 周期性信标:某主机以固定间隔查询同一域名,昼夜不停——自动化行为的典型指纹;
  7. 单一主机查询量离群:正常办公主机的 DNS 查询量有数量级范围,离群值值得排查;
  8. 绕过内部 DNS 的解析行为:直连公网 53 端口,或使用 DoH/DoT(DNS over HTTPS/TLS)绕开审计——这是近年最需要关注的"审计盲区"。
日志从哪来:内部递归 DNS 的查询日志是第一优先级(开起来,留 90 天以上);其次防火墙/出口流量的 53 端口会话记录;有条件的接入威胁情报做域名信誉匹配。

五、应对:分层堵住 DNS 这条通道

5.1 第一层:出口收敛——只允许"指定的 DNS 出去"

  • 防火墙只放行内网指定递归 DNS 服务器的 53 端口出站,其他内网主机直连公网 DNS 一律拒绝;
  • 对 853 端口(DoT)和已知 DoH 服务商域名做显式管控,业务确有需要的白名单放行;
  • 这一条做完,"绕过审计的解析行为"当场现形,是投入产出比最高的一步。

5.2 第二层:让 DNS 日志成为情报源

  • 集中收集 DNS 查询日志(递归服务器 + 出口防火墙),接入 SIEM 或至少做到定期脚本分析;
  • 对第四节的特征清单设置告警规则,从"超长子域名 + TXT 激增 + 周期性信标"三条做起;
  • 接入威胁情报源(商业或公开 IOC 源),对恶意域名做实时匹配与拦截。

5.3 第三层:上企业级解析服务,而不是裸奔

  • 用带安全能力的企业 DNS(支持恶意域名拦截、DNSSEC 校验、解析行为分析)替代裸递归;
  • 具备条件时启用 DoH/DoT 的"内部托管"模式:允许加密,但加密的终点是自己的解析服务,兼顾隐私与审计。

5.4 第四层:端点联动,定位"谁在发"

DNS 告警只回答"哪个 IP 在发",还需要端点侧回答"是什么进程在发":

  • EDR/主机侧查看该 IP 的进程网络连接,识别异常进程、计划任务、注册表自启项(Hermit 类组织的后门普遍驻留在用户目录和自启项里);
  • 确认失陷后按应急流程隔离主机、清除驻留、重置凭据,并参考本站的源头清理清单逐项排查。

5.5 应急响应顺序(发现异常 DNS 时)

  1. 固定证据:导出相关 DNS 日志与主机进程记录;
  2. 网络侧先行:防火墙封禁相关域名/IP,或临时切断该主机的 DNS 出站;
  3. 端点侧排查:确认进程与驻留机制,隔离主机;
  4. 横向排查:以失陷主机为起点,检查同网段是否有相似行为;
  5. 修复与复盘:堵住入口(钓鱼邮件、漏洞),复盘 DNS 策略与日志缺口。

特别提醒:发现失陷后应保留证据、按监管要求上报,通过合规渠道处置。任何"反向攻击 C2"的想法都涉嫌违法,企业没有这个选项。

六、自查清单

  • 出口收敛:是否只允许指定递归 DNS 服务器发起公网解析?其他 53 端口出站是否已拒绝?
  • 加密管控:DoT(853)与常见 DoH 域名是否已纳入管控?
  • 日志:DNS 查询日志是否开启?留存是否超过 90 天?是否有人看?
  • 告警:是否对"超长子域名、TXT 激增、周期性信标、NXDOMAIN 风暴"设置了告警?
  • 情报:是否接入了至少一个威胁情报源做域名信誉匹配?
  • 解析服务:内部递归 DNS 是否启用了恶意域名拦截与 DNSSEC 校验?
  • 审计:最近一次 DNS 日志审计是什么时候?离群主机排查过吗?
  • 入口:邮件网关与宏策略是否已收紧(Hermit 类组织的主入口是钓鱼文档)?

七、常见问题(FAQ)

Q1:Hermit(隐士)组织是用 DNS 隧道攻击的吗?
公开报告显示,Hermit(腾讯命名,与 Konni 关联)的标志性手法是鱼叉钓鱼 + 恶意宏 + SYSCON/Babyface 等后门,C2 通信使用 FTP/HTTP 等低调协议,并未以 DNS 隧道作为标志性手法。但"选用没人审计的正常协议做隐蔽通信"这一逻辑与 DNS 隐蔽通道完全一致,因此本文以该组织为引子展开。
Q2:我们的防火墙没告警,是不是就没有 DNS 隧道?
大概率只是"没有检测"。多数企业的防火墙对 DNS 是无条件放行且不产生行为告警的,隧道流量在传统策略下看起来就是普通的 53 端口会话。建议先从拿到 DNS 查询日志开始。
Q3:内网某台主机 DNS 查询量特别大,一定是中招了吗?
不一定,先排除正常原因:系统更新、杀毒软件、云同步盘、CDN 业务解析都会产生大量查询。判断关键在查询"内容"(域名特征、记录类型、周期性)而不只是"数量"。
Q4:DoH/DoT 加密了 DNS,是不是就没法审计了?
这正是其被攻击者青睐的原因。应对方式不是禁止加密,而是收敛加密终点:只允许企业自己托管的 DoH/DoT 解析服务,对公网第三方 DoH 服务做显式管控。
Q5:小公司没有 SIEM,怎么起步?
三步最低配置:DNS 日志开起来并保留 90 天;每周用脚本对日志跑一遍"超长子域名 + TXT 查询 + NXDOMAIN"三个特征;出口只放行指定递归 DNS。这三件事基本零成本。
Q6:封了恶意域名的 IP 为什么还会反复出现?
因为僵尸网络普遍使用 C2 域名池与快速 Flux 技术,域名解析的 IP 频繁更换,封 IP 永远追不上换 IP。要封在域名和出口策略层面,并结合威胁情报的域名信誉。
Q7:DNSSEC 能防住 DNS 隧道吗?
不能。DNSSEC 解决的是"应答被篡改"的完整性问题,隧道用的是"正常解析行为夹带数据",两者不在一个层面。防护核心仍是出口收敛与流量分析。
Q8:员工电脑疑似失陷,第一步断网还是取证?
按预案来。原则是"先控制扩散、再固定证据":在能保存日志和内存证据的前提下隔离主机(VLAN 隔离优于直接拔线),避免直接重装导致证据灭失。事后按监管要求留存与上报。

关于墨者安全
墨者安全致力于安全防护、服务器高防、网络高防、ddos防护、cc防护、dns防护、防劫持、高防服务器、高防dns、网站防护等方面的服务,全网第一款指纹识别技术防火墙,自研的WAF指纹识别架构,提供任意CC和DDoS攻击防御

热门文章

X

7x24 小时

免费技术支持

15625276999


-->