判断 C2，别只看 IP：把进程、网络与持久化串成证据链

原创

aeverj
aeverj

红队工坊

2026年10月16日 07:01
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

遇到一台主机反复访问外部地址，第一反应往往是查 IP 情报。命中了，继续追；没命中，或者属于常见云服务，就先放一边。

这一步可以帮助筛选，却回答不了最重要的问题：到底是谁在通信，它为什么会出现在这台机器上，通信前后又发生了什么？

C2，也就是命令与控制，描述的是攻击者与受控系统之间的控制关系。本文以 Windows 终端排查为例，把进程、网络和计划任务或服务放进同一条时间线。目标是让每个判断都有可复核的依据，同时看清证据还缺哪一环。

■01 先把外联线索变成调查问题

MITRE ATT&CK 的 T1071 描述了利用应用层协议开展命令与控制的行为：指令及执行结果可以承载在常见协议流量中。[1] 因此，看到 HTTPS、常用端口或熟悉域名，并不足以解释一次连接的用途。

查 IP 时，还要问清它代表谁。共享云地址可能对应多个租户；出口 NAT 后的源地址可能对应多台终端。只拿一条边界日志去匹配一条进程记录，很容易把不同对象拼到一起。

建议先写下一个能验证的问题：某台主机上的某个进程，是否在缺乏合理业务来源的情况下，持续接收外部信息，并触发了相关本地行为？

“固定间隔外联”只能推动调查。更新器、监控代理、同步客户端也会周期通信。需要比较同类设备上的正常表现、软件部署记录和实际业务时段，不要给所有环境套一个秒数阈值。

■02 一个历史案例说明了什么

微软在 2022 年 6 月公开的 POLONIUM 报告中，记录了攻击者控制的 OneDrive、Dropbox 账户被用于 C2 和数据外传。这是对合法服务的滥用，报告明确指出并非 OneDrive 平台漏洞。[2]

其中 CreepyDrive 没有原生持久化机制，进程被终止后需要重新执行。[2] 这给排查带来两个提醒：云服务的信誉不能替代端点调查；也不能把“必须发现持久化”设为认定 C2 的硬门槛。

反过来，发现计划任务或服务，同样不能直接定性。需要判断它是否解释了可疑进程的启动，以及该进程后续的行为。

■03 先让进程和网络对得上

如果环境使用 Sysmon，可以先核对三类记录：事件 1 提供进程创建与命令行上下文；事件 3 记录与进程关联的 TCP/UDP 连接，且默认关闭；事件 22 记录 DNS 查询，包括成功、失败和命中缓存的情况。ProcessGuid 有助于降低 PID 复用带来的关联错误，Sysmon 事件时间使用 UTC。[3]

落到调查记录里，至少保留主机标识、时间、进程标识、父进程、完整路径、命令行，以及对应连接的目标和端口。先固定进程身份，再向前追启动来源、向后看行为变化。只有进程名，通常不够。

不要把一台主机某个时间段内的全部外联，都算到刚出现的可疑进程头上。跨数据源关联时，应核对设备映射、时区、时间偏差和进程生命周期；缺少稳定进程标识时，应保留关联不确定性。

网络记录也各有边界。连接事件不能直接证明传输了指令，DNS 查询不能证明随后建立了连接。遇到缓存、代理或共享基础设施，应分别验证“查询了什么”“连接了谁”“由哪个进程发起”，不要只按时间接近就画等号。

开始排查前，先确认日志确实启用、规则没有过滤掉目标行为，且数据已成功入库。“查不到”可能是采集缺口，也可能是超出保留期或查询条件有遗漏。应逐项核验并写进调查限制，不能直接写成“未发生”。

■04 用计划任务和服务追启动来源

计划任务和 Windows 服务都是正常管理机制，也可能被用于执行或持久化。ATT&CK 分别以 T1053.005 和 T1543.003 描述相关滥用行为。[4][5]

排查计划任务，重点看创建主体、触发条件、运行身份，以及动作中的程序和参数。Windows 安全事件 4698 记录计划任务创建，包含任务名称和任务 XML 等信息；前提是相关审计与采集到位。[6] XML 里的动作配置还需要与实际进程启动证据对应，创建成功不等于执行成功。创建任务的账户、配置中的运行身份和实际执行进程，也要分别核对。

排查服务，可以核对服务配置指向的路径、运行账户、启动方式和配置变更时间，再查该路径是否对应后续进程。任务名或服务名只是检索入口，决定关联强度的是具体对象与实际行为。

如果一个新建任务指向某个脚本，随后确有对应进程启动并发生异常外联，这些证据可以相互补充。若任务创建早于现有日志保留期，当前配置只能说明现在的状态，不能据此断言它何时、由谁部署。

■05 把线索放进一条能被推翻的时间线

下面是虚构的防守排查示例，用于说明关联方法，与前述历史案例无关。假设所需日志已启用，且时间经过校准。

09:12，终端出现一个新计划任务，动作指向用户目录下的脚本。09:13，日志记录到与该动作一致的 PowerShell 进程启动。随后，同一进程出现 DNS 查询，并持续连接外部服务。09:20，端点又记录到它启动了新的子进程。

此时可以得到的结论是：任务配置、进程启动和网络活动形成了值得升级调查的关联。还不能仅凭这条时间线，断言外部服务器下发了指令，更不能把后续子进程自动解释成远程控制结果。

下一步应核对脚本内容与来源、任务审批记录、进程树，以及可获得的代理或应用侧记录。如果脚本对应正式部署包、任务由授权管理系统创建，且同类主机表现一致，业务解释就获得了支持。

如果找不到合理来源，又发现脚本实际处理外部指令、执行结果回传等证据，C2 判断才有更直接的支撑。调查记录要同时写“已观察到什么”和“仍待证实什么”，而不是让结论先于证据。

■06 告警进入队列后先做这五件事

1. 保留现场。保存相关日志、任务或服务配置、进程信息及文件哈希，记录来源和采集时间。避免一上来删除文件或重建任务，破坏后续验证条件。

2. 固定主体。确认是哪台主机、哪个账户、哪个进程实例在通信，核对 NAT、代理和时区映射，排除错误拼接。

3. 验证业务解释。查软件资产、部署来源和变更记录，向责任人核实用途。把可验证的部署事实写下来，不能只凭“名字眼熟”放行。

4. 扩大关联范围。围绕已确认的文件、路径、任务动作和进程关系检索其他主机，关注相同行为组合。仅按共享云 IP 扩散检索，容易引入大量无关结果。

5. 按影响处置。若已见到未授权控制或持续外传迹象，依照响应预案及时隔离并控制访问，不必等所有证据齐全；同时保留业务影响、处置依据和待验证事项。不要贸然封禁整个常用云服务域名。

■07 把关联质量写进结论

一份有用的 C2 排查结论，应该让接手的人能回答：通信主体是谁，启动来源是否清楚，网络行为与本地动作有哪些对应关系，哪些业务解释已经核验，还有哪些盲区。

IP 情报适合帮助定位线索。进程上下文帮助确定主体，网络行为帮助理解通信，任务和服务帮助追溯启动来源。证据能够相互核对，结论才站得住；其中一环缺失，也要准确记录缺口，而不是用猜测补齐。

■参考资料

[1] [MITRE ATT&CK · Application Layer Protocol · T1071]https://attack.mitre.org/techniques/T1071/

[2] [Microsoft Security Blog · 2022-06-02 Exposing POLONIUM activity and infrastructure targeting Israeli organizations]https://www.microsoft.com/en-us/security/blog/2022/06/02/exposing-polonium-activity-and-infrastructure-targeting-israeli-organizations/

[3] [Microsoft Sysinternals · Sysmon]https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon

[4] [MITRE ATT&CK · Scheduled Task · T1053.005]https://attack.mitre.org/techniques/T1053/005/

[5] [MITRE ATT&CK · Windows Service · T1543.003]https://attack.mitre.org/techniques/T1543/003/

[6] [Microsoft Learn · 4698(S) A scheduled task was created]https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4698

如果你对网络安全、红队攻防技术充满热情，渴望学习更多实战技巧，例如渗透测试、自动化脚本编写、免杀技术等， 欢迎关注我的公众号

在这里，我会持续分享更多高质量的技术文章，与你一同探索网络安全的奥秘，提升实战技能！ 让我们一起在队攻防的道路上，不断精进，突破边界！