挖矿木马应急响应实战：从Systemd持久化到横向移动的清除与溯源

1. 项目概述：一次真实的挖矿木马应急响应复盘

最近在红日靶场做蓝队防御练习，正好复盘到一个典型的挖矿木马应急响应案例。这活儿干多了，你会发现挖矿木马就像网络里的“牛皮癣”，清除不彻底就容易反复发作，而且它背后往往隐藏着更严重的安全隐患——比如攻击者已经拿到了你服务器的控制权。这次复盘不是纸上谈兵，而是基于一个真实的应急响应场景，模拟从告警发现、现场排查、病毒清除到攻击溯源的完整闭环。对于蓝队成员、安全运维或者想了解应急响应流程的朋友来说，这个过程能帮你建立起一套清晰的处置思路，知道“告警响了之后，第一步该干什么，第二步该看哪里”。

挖矿木马应急响应，核心目标就三个：快速止血、清除病灶、溯源根因。听起来简单，但实战中往往因为环境复杂、线索零散而手忙脚乱。这次我们遇到的是一种利用Systemd服务进行持久化驻留的挖矿木马变种，它结合了自动化运维工具进行横向移动，清理起来颇为棘手。下面，我就把这次从接到“态势感知告警”到最终“闭环处置”的全过程，结合红队常见的攻击手法和蓝队的防御视角，拆解开来，一步步分享给你。你会发现，应急响应不仅是技术活，更是体力活和细心活。

2. 事件背景与初始研判

2.1 告警触发与初步信息收集

事件始于监控平台的一条高危告警。态势感知系统检测到内网多台服务器存在对外连接可疑矿池域名的行为，CPU使用率也出现异常飙升，典型挖矿特征。作为蓝队值守人员，第一时间不是直奔服务器去查进程，而是先做信息收集，这能帮你节省大量时间。

我的习惯动作是，立即登录安全运营平台（SOC）或日志分析系统，调取告警主机的详细信息。关键信息包括：

• 主机IP和资产信息：这台服务器是谁在管理？属于哪个业务部门？运行什么关键应用（比如，这次发现很多是Hadoop集群节点）？业务重要性决定了处置的紧急程度。
• 告警时间线：第一次出现可疑连接是什么时候？是单点爆发还是多点同时出现？这有助于判断是“外部一次性入侵”还是“内网已横向扩散”。
• 网络流量日志：抓取到的可疑域名或IP是什么？尝试在威胁情报平台（如微步在线、VirusTotal）上查询这些IOC（失陷指标），确认是否为已知矿池。
• 关联告警：在相近时间段，是否有针对同一批主机的暴力破解、漏洞利用等告警？挖矿木马很少是“空降”的，它一定有入口。

在这次案例中，初始信息显示有38台服务器告警，且多为大数据平台的Hadoop节点。这是一个非常危险的信号，因为Hadoop如果存在未授权访问漏洞，极易成为攻击者打入内网的跳板。初步研判方向立刻指向：攻击者可能利用了Hadoop的漏洞获取了初始立足点，随后植入挖矿木马，并尝试在内网横向移动。

注意：应急响应的第一步永远是“评估影响范围，避免打草惊蛇”。除非业务已中断需立即恢复，否则不建议第一时间重启服务器或杀进程，这可能会清除攻击者留下的进程、网络连接等宝贵痕迹。应先进行“无损”的信息收集。

2.2 制定应急响应计划

面对几十台告警主机，不能一头扎进去一台台查。需要制定一个高效的排查计划。我们当时的小组快速确定了以下步骤：

1. 划分优先级：将告警主机分为三类。A类：核心业务服务器，需立即在线分析并制定最小影响清除方案。B类：非核心但存有敏感数据的服务器。C类：测试或开发环境服务器。优先处理A类。
2. 确定排查路径：采用由点到面的策略。先集中精力深入分析1-2台典型受害主机（我们选了一台CPU异常最明显的Hadoop数据节点），摸清木马的文件、进程、持久化方式等特征。再利用这些特征（如特定进程名、文件路径、计划任务内容、网络连接特征）在内网进行批量筛查，快速定位所有受感染主机。
3. 准备工具包：提前准备好干净的U盘或通过内部可信通道下载好排查工具，避免使用受害主机上可能被篡改的系统命令（如ps、netstat、ls等）。常用工具包括：
   • chkrootkit、rkhunter：用于检查Rootkit。
   • busybox：提供静态编译的干净版系统命令。
   • Elasticsearch、Sysinternals Suite（对于Windows）：高级进程和网络分析工具。
   • 自主编写的脚本：用于快速收集系统信息（如ps auxf,netstat -antp,crontab -l,systemctl list-units等）。
4. 沟通协调：立即通知相关业务系统的负责人和运维团队，告知风险，争取操作时间窗口，并协调可能的业务中断预案。

3. 现场排查与深度分析

3.1 受害主机现场取证

登录到选定的典型受害主机（Linux系统），开始现场取证。这里分享一套我常用的排查命令和顺序，就像医生的“望闻问切”。

第一步：检查系统资源与异常进程

# 查看整体资源，寻找异常高CPU占用进程 top -c htop (如果已安装，视图更友好) # 仔细查看进程树，挖矿进程常伪装成常见系统进程名 ps auxf | less # 重点关注：CPU/内存占用高、奇怪的用户（如非root的陌生用户）、奇怪的命令行参数（特别是含有矿池地址或端口）

很快，我们发现了一个名为kthreaddk的进程（伪装成内核线程kthreadd），CPU占用接近100%。使用ls -al /proc/<PID>/exe查看该进程的可执行文件路径，指向/usr/bin/.kthreaddk，一个隐藏目录下的可疑文件。

第二步：检查网络连接

# 查看所有网络连接，寻找对外连接可疑IP/端口 netstat -antp | grep ESTA # 或使用更强大的 ss 命令 ss -antp # 发现进程 kthreaddk 正在连接一个海外IP的3333端口（常见矿池端口）

将连接的外网IP在威胁情报平台查询，确认为已知门罗币（XMR）矿池。

第三步：检查持久化机制（这是清除的关键）挖矿木马为了存活，会想尽办法让自己重启。我们检查了所有常见的自启动项：

# 1. 系统服务（Systemd） systemctl list-units --type=service --state=running | grep -v systemd ls -la /etc/systemd/system/ /usr/lib/systemd/system/ | grep -E '(kthread|mine|systemd)' # 发现了一个可疑服务：/etc/systemd/system/systemd-logind.service（伪装成系统登录服务） # 2. 计划任务（Cron） crontab -l # 查看当前用户的 ls -la /etc/cron* /var/spool/cron/ # 查看系统级和其他用户的 cat /etc/crontab # 发现了一条异常任务：*/10 * * * * root /tmp/.X11-unix/.rsync/cron.sh # 3. 启动脚本 ls -la /etc/init.d/ /etc/rc*.d/ cat /etc/rc.local 2>/dev/null # 4. 用户相关启动项 ls -la ~/.bashrc ~/.bash_profile ~/.profile

我们发现该木马同时利用了Systemd服务和Cron计划任务做双重持久化，非常顽固。

第四步：定位并分析恶意文件根据进程和计划任务找到的路径，顺藤摸瓜：

# 查看可疑目录 ls -la /usr/bin/.kthreaddk/ /tmp/.X11-unix/.rsync/ # 检查文件内容，注意不要直接执行 file /usr/bin/.kthreaddk/kthreaddk # 查看文件类型，是ELF可执行文件 strings /usr/bin/.kthreaddk/kthreaddk | grep -i pool # 尝试提取字符串，可能发现矿池地址 cat /tmp/.X11-unix/.rsync/cron.sh # 查看脚本内容，发现其会下载新样本、清理竞品挖矿木马、并尝试通过SSH横向传播

在脚本中，我们看到了利用sshpass进行密码爆破、以及利用ansible批量执行命令的痕迹。

第五步：检查日志（寻找入侵痕迹）

# 查看认证日志，寻找爆破或异常登录 tail -f /var/log/secure /var/log/auth.log grep -i 'fail\|accept' /var/log/secure* | head -50 # 查看历史命令，看攻击者执行了什么 history cat ~/.bash_history # 注意：狡猾的攻击者会清空历史记录，但有时会有遗漏。

在日志中，我们发现了大量来自同一内网IP的SSH失败登录尝试，以及后续的成功登录记录。

3.2 横向移动与影响范围确定

通过分析Cron脚本和网络连接，我们判断木马已在内部传播。于是，利用在第一台主机上提取的IOC（恶意文件哈希、进程名、计划任务特征、矿池域名），编写了一个简单的扫描脚本，在内网批量执行，快速定位了所有受影响主机。最终确认感染主机数量从最初的38台上升到了69台。

横向传播的主要方式，与我们初始研判和脚本分析一致：

1. 利用自动化运维工具：攻击者在内网某台失陷主机上发现了Ansible的配置文件和主机清单，直接利用其向全网节点下发恶意任务。
2. SSH密钥与密码爆破：木马会扫描受害主机上的~/.ssh/id_rsa私钥和~/.ssh/known_hosts文件，尝试免密登录其他主机。同时，会尝试用弱密码字典进行SSH爆破。
3. 利用已知漏洞：对未修复漏洞的服务（如Hadoop、Jenkins、PostgreSQL）进行批量攻击。

实操心得：在大型内网，手动排查效率极低。一定要在分析清楚首个样本后，立即提取指纹（IOC），并转化为自动化检测脚本或SIEM/SOC平台的检测规则，进行全网扫描。同时，检查内网中自动化运维平台（SaltStack, Ansible）的管理节点是否安全，它们一旦被控，等同于交出整个集群的权限。

4. 病毒清除与系统加固

4.1 恶意进程与文件清除

清除工作必须彻底，顺序很重要，否则木马会“死灰复燃”。

第一步：切断网络（可选但推荐）对于非核心业务服务器，如果条件允许，先将其从网络隔离（拔网线或防火墙阻断），防止其在清除过程中继续对外通信或对内传播。

第二步：结束恶意进程

# 找到进程PID ps aux | grep kthreaddk # 强制结束进程，注意有些木马有守护进程，可能需要一起结束 kill -9 <PID> # 再次检查进程是否被其他机制拉起

如果进程反复被拉起，说明持久化机制没清除干净。

第三步：清除持久化项目

# 1. 停止并禁用Systemd服务 systemctl stop systemd-logind.service # 注意，这个假冒的服务名 systemctl disable systemd-logind.service rm -f /etc/systemd/system/systemd-logind.service systemctl daemon-reload # 2. 删除计划任务 crontab -l | grep -v '\.rsync' | crontab - # 删除当前用户的特定任务 # 直接编辑系统文件或删除对应的cron脚本文件 rm -f /tmp/.X11-unix/.rsync/cron.sh rm -rf /tmp/.X11-unix/.rsync/ # 3. 删除恶意文件 rm -rf /usr/bin/.kthreaddk/ # 使用 find 命令查找并删除近期创建的、异常的隐藏文件 find / -name “.*” -type f -mtime -7 | xargs ls -la

第四步：检查并清理SSH密钥

# 检查 authorized_keys cat ~/.ssh/authorized_keys # 检查是否有未知的私钥 ls -la ~/.ssh/ # 如果发现可疑密钥，立即删除

攻击者常会添加自己的公钥到authorized_keys以实现免密登录后门。

4.2 漏洞修复与安全加固

清除木马是治标，修复漏洞才是治本。根据溯源结果，我们做了以下加固：

1. 修复Hadoop未授权访问漏洞：这是本次事件的初始入口。立即为Hadoop集群启用Kerberos认证，或至少配置IP白名单限制访问来源，关闭不必要的服务端口。
2. 强化SSH安全：
   • 禁止root用户直接SSH登录：修改/etc/ssh/sshd_config，设置PermitRootLogin no。
   • 使用密钥对认证，禁用密码认证：设置PasswordAuthentication no。
   • 修改默认SSH端口。
   • 安装fail2ban工具，自动屏蔽暴力破解IP。
3. 检查并加固自动化运维工具：对Ansible/SaltStack控制机进行严格审计，使用最小权限原则，配置文件和主机清单加密存储，并定期更换认证凭据。
4. 系统层面：
   • 更新所有软件到最新版本，修补已知漏洞。
   • 设置强密码策略，定期更换密码。
   • 限制非必要的外网访问。在防火墙上对服务器出站连接实施白名单策略，特别是禁止访问已知的矿池IP和端口。
   • 安装主机入侵检测系统（HIDS）或EDR（端点检测与响应）工具，监控文件、进程和网络行为的异常。

5. 攻击链溯源与复盘

5.1 还原攻击路径

通过关联多台早期失陷主机的日志，我们大致还原了攻击者的攻击链（APT Kill Chain）：

1. 侦察与武器化：攻击者通过互联网扫描，发现目标单位官网服务器存在某个未公开的Nday漏洞（或是弱口令）。
2. 初始入侵：利用该漏洞，攻击者在官网服务器上获取了Webshell。
3. 建立持久化与横向移动：通过官网服务器作为跳板，攻击者向内网渗透。他们在内网一台管理不严的堡垒机（或开发测试服务器）上上传了frp等反向代理工具，打通了一条从外网到内网的稳定通道。
4. 内网探测：攻击者通过通道进入内网后，开始扫描。发现了大量使用默认端口且未授权访问的Hadoop YARN ResourceManager服务。
5. 漏洞利用与挖矿植入：利用Hadoop YARN的未授权RCE漏洞，攻击者在多台数据节点上远程执行命令，下载并执行了SystemdMiner挖矿木马的一键安装脚本。
6. 横向扩散与持久化：木马脚本除了挖矿，还内置了通过SSH密钥、弱口令和Ansible进行横向传播的功能。同时，它创建了Systemd服务和Cron任务，确保自身存活。
7. 持续牟利：最终，内网数十台服务器沦为“矿工”，持续为攻击者挖取加密货币。

5.2 暴露的安全问题与改进建议

这次事件暴露了客户环境中几个典型的安全短板：

• 边界防御失效：官网服务器作为对外窗口，存在漏洞且未被及时发现。
• 内网无隔离：攻击者通过一台边缘服务器即长驱直入核心生产网（IDC机房）。
• 漏洞管理缺失：Hadoop等中间件的严重已知漏洞长期未修复。
• 安全监控盲区：对服务器异常出站连接（连接矿池）缺乏有效监控和阻断。
• 配置管理混乱：存在弱口令、相同口令、自动化运维工具配置不当等问题。

基于此，我们给出的核心建议与奇安信案例中的建议高度吻合，但更具体：

1. 网络架构优化：实行严格的网络分区隔离，生产网、办公网、测试网之间通过防火墙隔离，仅开放最小必要的访问策略。服务器区域应限制甚至禁止主动访问互联网。
2. 加强安全监控：部署全流量威胁检测设备（如NTA/NDR），或优化现有态势感知规则，重点监控对已知恶意IP/域名（尤其是矿池）的访问，以及内网异常的横向扫描流量（如大量SSH爆破、SMB连接尝试）。
3. 建立漏洞管理闭环：定期进行漏洞扫描，对扫描出的高危漏洞，必须设定明确的修复时限并跟踪闭环。特别是面向互联网的资产和核心业务系统。
4. 强化主机安全：所有服务器安装EDR或轻量级HIDS，统一进行基线核查、进程监控和文件完整性校验。统一配置强密码策略和SSH安全策略。
5. 做好应急准备：定期进行应急响应演练，让运维和安全团队熟悉流程。提前准备好干净的应急工具包和排查脚本。

6. 蓝队防御视角的常态化建设思考

一次应急响应是对日常安全建设最好的检验。从蓝队防御的角度看，不能总是疲于奔命地“救火”，而应该致力于让“火”烧不起来，或者一有“火星”就能立刻发现。

第一，建设有效的检测体系。挖矿木马的检测点其实很多：CPU/内存异常、计划任务变更、新增系统服务、连接可疑外网IP/域名、出现异常隐藏文件或进程。关键在于如何将这些离散的告警关联起来，形成高置信度的安全事件。这就需要SIEM或SOC平台具备良好的日志聚合和关联分析能力。例如，将“主机CPU持续高于90%”的监控告警，与“该主机连接了威胁情报库中的矿池域名”的网络告警进行关联，就能快速定位挖矿主机。

第二，推行最小权限原则和零信任网络。本次事件中，攻击者利用一台失陷主机就能通过SSH密钥和Ansible横扫内网，根本原因在于内网信任过度。应推行基于身份的访问控制，即使是内网访问，也需要认证和授权。对于运维通道（如SSH），建议使用堡垒机进行统一管理和审计，跳板机本身必须进行高强度安全加固。

第三，重视供应链和第三方组件安全。Hadoop、Jenkins、Consul这些开源组件是攻击的高频目标。在引入这些组件时，安全团队应介入评估，制定安全配置基线，并纳入统一的漏洞管理和补丁更新流程。不能因为它是开源或第三方软件，就放任不管。

第四，常态化红蓝对抗与演练。通过定期组织内部红队演练或利用像“红日靶场”这样的平台进行训练，主动去发现网络中的脆弱点。蓝队成员在演练中能更深刻地理解攻击者的思维和路径，从而优化自己的监控规则和响应流程。演练结束后，必须对发现的问题进行复盘和整改，形成安全能力提升的闭环。

挖矿木马应急响应，看似是清除一个消耗资源的恶意程序，实则是一场对防御体系完整性的压力测试。它考验的是从边界防护、入侵检测、到内部权限控制、漏洞管理、再到事件响应等一系列环节是否扎实。希望通过这次详细的复盘，能为你构建更强大的防御能力提供一些切实可行的思路和抓手。安全没有一劳永逸，唯有持续监控、快速响应、不断加固，才能在这场攻防对抗中占据主动。