服务器被挖矿了？Linux 入侵排查的 7 个取证命令

凌晨告警显示一台业务机的 CPU 长时间接近满载，接口超时开始增多。登录以后，进程列表里不一定会出现名字直白的 xmrig；攻击者可以伪装进程名，把二进制放到共享内存，再用 cron 或 systemd timer 自动拉起。此时最容易犯的错误是先杀进程、删文件或重启机器。那样可能暂时恢复业务，却会丢失进程命令行、网络连接、打开文件和内存映射等挥发证据，最后无法回答入口、影响范围与是否存在后门。

本文以 Ubuntu Server 22.04 LTS 为例，提供一条低影响的 Linux 主机取证路径。所谓“7 个命令”是七类优先证据：进程、网络套接字、打开文件、认证日志、登录历史、持久化项和文件系统痕迹。命令不会自动给出“挖矿”结论；结论必须由 PID、父子关系、时间线、外联地址、日志和配置差异相互验证。若主机仍承载关键流量，请先留证，随后由值班负责人决定摘流和隔离。

取证前的边界：先保存事实，不急于清理

开始前记录告警编号、主机名、观察时间、时区和业务影响。本文中的 <事件目录> 替换为本次事件专用且权限受控的目录，例如 /var/tmp/ir-20260730-001；不要用攻击者常会清理的普通 /tmp。、<用户名>、<开始时间>、<结束时间> 都是占位符，必须替换为本机实际值。没有证据支持时，报告中只能写“可疑”或“待确认”，不能把推测写成根因。

bash
#!/usr/bin/env bash
set -euo pipefail

# 将 <事件目录> 替换为本次事件的受控保存位置。
evidence_dir="<事件目录>"
umask 077
install -d -m 0700 "$evidence_dir"
date --iso-8601=seconds | tee"$evidence_dir/collected_at.txt"
hostnamectl | tee"$evidence_dir/host_identity.txt"
uname -a | tee"$evidence_dir/kernel.txt"
df -hT | tee"$evidence_dir/filesystem_capacity.txt"

umask 077 让新证据文件默认仅管理员可读，install -d 在创建时设置权限。若根分区空间不足，选择已有的本地受控挂载盘，或按事件流程请求磁盘快照；不要为了腾空间直接删除日志、临时目录或容器层。疑似 root 失陷时，本机输出也只能视为线索，应尽快同时保留网络、云审计和镜像侧证据。

下列脚本是连续的只读采集。它不会停止服务、不改防火墙、不删除文件。journalctl 的时间范围需要按告警前后扩大，例如 24 或 48 小时；采集范围本身应写入事件记录。

bash
#!/usr/bin/env bash
set -euo pipefail

evidence_dir="<事件目录>"
stamp="$(date +%Y%m%dT%H%M%S%z)"
ps auxwwf > "$evidence_dir/$stamp"_ps_auxwwf.txt
ss -plantue > "$evidence_dir/$stamp"_ss_plantue.txt
journalctl --since '24 hours ago' --no-pager > "$evidence_dir/$stamp"_journal_24h.txt
last -Faiwx > "$evidence_dir/$stamp"_last.txt
systemctl list-unit-files --state=enabled > "$evidence_dir/$stamp"_enabled_units.txt

活跃进程、/proc 内容和网络连接会随进程退出而消失，因此顺序通常是“进程与连接→日志与留驻→落地文件”。如果必须隔离主机，隔离属于高风险变更：会中断用户请求、同步任务和远程管理，也可能让攻击者结束进程。先确认负载均衡能摘除实例、带外控制台或跳板机仍可达，保存现有规则并获得授权；隔离后验证业务副本和错误率，误伤时按导出的规则或成员列表回滚。

bash
#!/usr/bin/env bash
set -euo pipefail

# 仅导出规则，供审批和回滚使用；本段不实施任何封禁。
evidence_dir="<事件目录>"
nft list ruleset > "$evidence_dir/nftables_before_isolation.nft"
ifcommand -v ufw >/dev/null 2>&1; then
  ufw status numbered > "$evidence_dir/ufw_before_isolation.txt"
fi

命令一：ps，从进程树发现不合理的计算负载

先看进程的 CPU、内存、运行时长、用户、父进程和完整参数。挖矿进程可能以普通用户运行，也可能通过已失陷的 www-data、ubuntu 或应用账号启动。进程名可以伪造；更有价值的是可执行路径、父子链和参数中是否存在下载、代理、线程数或远端地址。

bash
ps -eo pid,ppid,user,ni,stat,lstart,etime,%cpu,%mem,comm,args --sort=-%cpu

关注“长期高 CPU + 账户不符合职责 + 父进程不合理”的组合。STAT 为 D 往往代表不可中断 I/O 等待，Z 是僵尸进程，两者不能按挖矿解释；Java、数据库、压缩、备份与批处理也可能正常占满 CPU。先比对作业计划和业务指标，再继续定位 PID。

bash
pstree -aps <PID>

-a 显示参数，-p 显示 PID，-s 展示目标到 systemd 的祖先链。systemd → nginx → php-fpm → sh → curl 应回查 Web 请求和应用日志；sshd → bash → wget 应回查认证日志；cron → sh 则优先查定时任务。这里的价值是建立启动链，而不是因为 sh 存在就判定恶意。

bash
#!/usr/bin/env bash
set -euo pipefail

pid="<PID>"
evidence_dir="<事件目录>"
test -d "/proc/$pid"
readlink -f "/proc/$pid/exe" | tee"$evidence_dir/proc_$pid"_exe.txt
tr'\0'' ' < "/proc/$pid/cmdline" | tee"$evidence_dir/proc_$pid"_cmdline.txt
tr'\0''\n' < "/proc/$pid/environ" \
  | sed -E 's/(TOKEN|PASSWORD|SECRET|KEY)=[^ ]+/\1=<已脱敏>/' \
  > "$evidence_dir/proc_$pid"_environ_sanitized.txt
awk '{print "pid=" $1, "ppid=" $4, "start_ticks=" $22}'"/proc/$pid/stat" \
  > "$evidence_dir/proc_$pid"_stat.txt

PID 会复用，因此应同时保存采集时间、lstart 和 /proc//stat 中的启动 tick。/proc//exe 位于 /dev/shm、/tmp、隐藏目录或显示 deleted 时风险会升高，但合法应用的解压与临时执行同样可能产生这些路径。不要用单一路径作为根因证据。

环境变量中可能有令牌、数据库密码或云凭据，因此脚本只保存脱敏副本。这是一份辅助记录，不应以它替代受控的密钥泄露处置。如果发现可疑下载命令，要记录命令行及其父进程，不要在生产机重复执行 curl、bash 或二进制来“验证”。

命令二：ss，给异常外联建立网络证据

挖矿程序通常要与矿池或中转代理保持连接，但端口并非固定。ss 从内核套接字表读取状态，适合先抓取所有监听和已建立连接。以下命令不做 DNS 反查，能避免采集过程额外访问网络并保留数字地址。

bash
ss -Htanp state established
# 将 <PID> 替换为已确认的可疑进程；没有结果不代表连接安全。
ss -plantue | rg "pid=<PID>,"

-H 去掉表头，-t 限定 TCP，-a 包含所有相关 socket，-n 保留数字地址，-p 显示关联进程。目的 IP 在海外、端口陌生或连接持续，并不等于矿池：CDN、对象存储、监控 SaaS 和软件仓库也会出现外联。应将远端地址、端口、PID、首次出现时间与资产允许清单、代理日志和 DNS 记录比对。

bash
ss -plunt

该视图用于找意外监听端口。0.0.0.0:端口表示全部 IPv4 地址都能访问，127.0.0.1:端口只对本机可达，风险不同。容器端口映射、监控 exporter、调试服务都可能合法；先反查 PID 的进程路径和变更记录，再考虑关闭端口。

将 替换为数字 PID。没有匹配结果可能表示连接已断开、目标走 UDP、权限不足或 PID 已退出，不能解读为无异常。UDP 可另用 ss -planue 复查。为了证明可疑连接是否持续，可在有限时间内重复采样。

bash
#!/usr/bin/env bash
set -euo pipefail

evidence_dir="<事件目录>"
for i in 1 2 3 4 5; do
date --iso-8601=seconds
  ss -Htanp state established
sleep 30
done > "$evidence_dir/established_connections_5x30s.txt"

五次、每次 30 秒的采样不会插包、不会阻断流量。若同一 PID 稳定连向未知地址，同时 CPU 曲线升高，怀疑程度增加；若连接只在备份窗口出现，应优先核查备份任务和发布计划。不要把无限循环的 ss 输出写入磁盘。

命令三：lsof，把可执行文件、socket 和删除痕迹关联起来

ss 能告诉我们 socket 属于哪个 PID，lsof 可以补齐该进程打开的可执行文件、当前目录、内存映射和已删除对象。攻击者可能运行后删除落地文件名，内核仍持有文件描述符，lsof 的 deleted 线索就很重要。Ubuntu 未预装 lsof 时，不要在已失陷主机上临时联网安装；优先通过运维镜像或隔离分析环境补充。

bash
lsof -nP -p <PID>

-nP 禁止 DNS 与端口名解析，-p 只查看目标进程。重点检查 txt 类型的执行文件、cwd、mem 映射、DEL 或 deleted 项。看到 /var/lib/containerd、overlay 挂载并不自动异常；容器节点必须继续映射其 cgroup。

bash
lsof -nP +L1

+L1 会列出链接数小于 1 的仍打开文件。它常常命中正常日志轮转残留，不能据此删除。应保存路径、所属进程、大小和时间，再区分它是业务日志、升级遗留还是可疑可执行文件。因已删除日志而满盘的恢复空间动作应独立走变更：先保留证据、确认影响服务、评估重启窗口，并准备回滚。

bash
cat /proc/<PID>/cgroup
docker ps --no-trunc --format 'table {{.ID}}\t{{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

在 systemd cgroup v2 环境中，内容可能含 .service、kubepods、containerd 或 Docker 容器 ID 片段。它用于证明 PID 属于宿主服务还是工作负载，不能靠目录猜测。Docker 节点可读取运行容器清单，不要在尚未留证时执行停止或删除。

若 PID 属于 Kubernetes Pod，应从审计日志、kubelet 日志、镜像摘要和命名空间继续调查。直接 docker rm -f 或删除 Pod 会损失容器层证据，编排器还可能马上重建副本，既没有消除入口也未减小范围。

命令四：journalctl，用日志恢复账号和服务时间线

挖矿入口可能是 SSH 弱口令、泄露密钥、WebShell、暴露的 CI、容器逃逸或供应链脚本。日志的任务是证明“哪个账号何时登录、哪个 unit 何时启动、何时出现下载或权限提升”，而不是从关键词直接推断攻击。Ubuntu 的 SSH 认证记录通常也写入 /var/log/auth.log，但 systemd journal 更便于按时间和 unit 聚合。

bash
journalctl --since '<开始时间>' --until'<结束时间>' --no-pager -o short-iso
timedatectl status
journalctl --disk-usage

将时间占位符替换为明确范围，例如 2026-07-30 01:00:00 到 2026-07-30 05:00:00。short-iso 便于对齐监控、Nginx 与堡垒机日志。全量日志可能较大，应先落证据目录；后续筛选只能作为索引，不能代替保存原始范围。

bash
journalctl -u ssh.service --since '<开始时间>' --until'<结束时间>' --no-pager -o short-iso

Ubuntu 通常为 ssh.service，其他系统可能为 sshd.service，执行前用 systemctl status 确认。关注 Accepted publickey、Accepted password、Failed password、session opened 和 sudo；将来源 IP 与堡垒机出口、办公网段及授权清单核对。一次失败登录不足以说明突破，失败爆发后紧随成功登录才是值得重点调查的时间链。

bash
sudo rg -n -i 'curl|wget|/bin/sh|base64|cmd=|eval\(|\.php' \
  /var/log/nginx/access.log /var/log/nginx/error.log

假设 Nginx 使用默认日志路径；实际路径应从 nginx -T 或配置中的 access_log 确认。该正则只是线索筛选，合法安装脚本也会有 curl，正常业务 URI 也可能携带 Base64。真正的判断依据应包括请求时间、客户端地址、响应码、上游日志和同一时刻异常子进程。

若 System clock synchronized 为 no，跨系统时间线要标明时钟可能偏差；不要在取证时贸然同步时间，时间跳变会影响排序。journalctl --disk-usage 只报告占用，不会主动清理日志。

命令五：last 与 lastlog，核验交互式登录

last 读取 /var/log/wtmp，适合查成功会话和重启时间；lastlog 显示账户的最后登录记录。两者可能因日志轮转不完整，也可能被高权限攻击者篡改，因此必须与 journal、堡垒机和云控制台审计交叉验证。

bash
last -Faiwx | head -n 80

-F 显示完整时间，-a 把远端主机放在末列，-i 用 IP 表示来源。关注非工作时间的成功登录、非堡垒机来源、服务账号出现交互会话、会话在机器重启前后异常中断。wtmp begins 只代表本地文件的可追溯起点，不代表主机历史从此开始。

bash
lastlog -u <用户名>

服务账号没有登录记录通常正常，反而是 www-data、nobody 等不应交互登录的账号出现近期来源地址时值得优先调查。某些认证方式和容器环境不会更新 lastlog，Never logged in 不是安全证明。用本地账户清单核对 UID、shell 与家目录时也要考虑组织自定义策略。

bash
getent passwd | awk -F: '$3 >= 1000 || $1 == "root" {print $1, $3, $6, $7}'

Ubuntu 常从 UID 1000 分配普通账户，但并非安全边界。不要因为 UID 大就执行 userdel：部署、备份和监控账户也会在此范围。若确认恶意账户，先导出家目录元数据、authorized_keys 和关联日志，获得批准后禁用；撤销前必须保留另一条已验证的管理员通道，防止把自己锁在主机外。

命令六：systemctl、cron 与 SSH 公钥，寻找留驻机制

进程被终止后又出现，通常说明存在留驻。常见位置包括 systemd service/timer、root 或应用账号 crontab、/etc/cron.*、rc.local、shell profile、SSH authorized_keys、部署钩子和容器编排。先全面枚举，再查看可疑对象的真实内容，不要按照 unit 名或文件名臆断。

bash
systemctl list-unit-files --state=enabled --no-pager
systemctl list-timers --all --no-pager

第一条列出开机启用的单元，第二条列出定时触发器。监控、备份和安全 agent 均可能有自定义 timer。发现陌生对象时，应该先确认它的来源、创建时间和变更单，而不是立即 disable --now。

bash
systemctl cat <单元名>
systemctl show <单元名> -p FragmentPath -p ExecStart -p User -p Environment

将 <单元名> 替换为完全限定 unit，例如 suspicious.service。FragmentPath 给出文件位置，ExecStart 与 User 可以对应进程树。停用 unit 会改变现场并可能中断业务；应先复制单元文件和引用脚本元数据，选择灰度实例验证后再变更。

bash
find /etc/systemd/system /usr/lib/systemd/system -maxdepth 2 -type f \
  -printf'%TY-%Tm-%TdT%TT%z %u:%g %m %p\n' 2>/dev/null | sort

本地覆盖和管理员创建单元通常在 /etc/systemd/system，发行版单元在 Ubuntu 上也常见于 /lib/systemd/system。时间新、权限异常、指向临时目录或远程下载器的单元风险较高，但仍需结合内容、进程与日志确认。

bash
#!/usr/bin/env bash
set -euo pipefail

evidence_dir="<事件目录>"
{
printf'%s\n''### /etc/crontab and /etc/cron.d'
  sed -n '1,240p' /etc/crontab 2>/dev/null || true
  find /etc/cron.d -maxdepth 1 -type f -exec sh -c 'echo "### $1"; sed -n "1,240p" "$1"' _ {} \;
printf'%s\n''### per-user crontabs'
while IFS=: read -r user _ uid _ _ _ _; do
if [ "$uid" -eq 0 ] || [ "$uid" -ge 1000 ]; then
      crontab -u "$user" -l 2>/dev/null | sed "s/^/[$user] /" || true
fi
done < /etc/passwd
} > "$evidence_dir/cron_inventory.txt"

脚本只读取 cron 定义，并容忍不存在的用户 crontab。不要把每分钟 curl 下载脚本的条目直接删除；先保存原始条目、计算关联脚本哈希、确认账户和进程。确认需临时停用时，应把原条目放入受控备份，以最小范围注释或替换，并在回滚时恢复；crontab -r 没有交互确认，不适合作为排障操作。

bash
find /root /home -xdev -type f -name authorized_keys \
  -printf'%m %u:%g %TY-%Tm-%Td %p\n' 2>/dev/null

这个命令仅列出公钥文件及其元数据，避免在工单中传播密钥注释。异常密钥的证据是“未授权账户、非预期密钥、成功登录、随后启动可疑进程”的组合，而不是文件存在本身。撤销密钥前需备份原文件，确认第二会话可登录，修改后新开会话验证，失败时从备份恢复。

命令七：find、哈希和包校验，建立落地文件证据

文件系统检查不能无边界扫全盘，而应围绕告警时间、可疑 PID 和常见落地点建立清单。攻击者偏好 /tmp、/var/tmp、/dev/shm 和用户可写目录，但这些同样是合法临时文件位置。筛选结果需要由 owner、mtime、文件类型、进程引用、下载日志和发布记录共同解释。

bash
find /tmp /var/tmp /dev/shm -xdev -type f -mtime -7 \
  -printf'%TY-%Tm-%TdT%TT%z %s %m %u:%g %p\n' 2>/dev/null | sort

-xdev 避免跨越挂载点，-mtime -7 以 24 小时桶计算，并非精确的 168 小时。精确范围可改用 -newermt ‘<时间>’。若临时目录文件很多，先缩小时间窗口或锁定具体路径，以免采集增加 I/O 压力。

bash
find /tmp /var/tmp /dev/shm -xdev -type f -perm /111 \
  -printf'%TY-%Tm-%TdT%TT%z %s %m %u:%g %p\n' 2>/dev/null | sort

可执行位是有用筛选条件，却不是恶意标签。编译缓存、合法安装器和运维脚本都可能命中。对已确认需要分析的文件，先记录类型、哈希和 inode 元数据；不要运行样本，也不要将可能含业务配置的文件上传到公共网站。

bash
file --brief --mime-type <可疑文件路径>
sha256sum <可疑文件路径>
stat --printf='path=%n\nsize=%s\nowner=%U:%G\nmode=%a\nmtime=%y\nctime=%z\n' <可疑文件路径>

ctime 是 inode 元数据变更时间，不等同于创建时间。SHA-256 用于确保后续分析样本没有被替换，不用于单独定性。若二进制已删除但进程仍运行，可从 lsof 与 /proc//exe 获取线索；复制和转储应按受控取证流程操作。

bash
dpkg -V
dpkg -S <可疑文件路径> || true

Ubuntu 的 dpkg -V 只能核验由包管理器登记的文件，它无法覆盖自编译程序、应用发布目录、容器层或攻击者新建文件。任何差异都要逐条解释：配置文件本来就可能被管理员修改。先确认文件归属，再检查变更记录，切勿用重装包覆盖证据。

|| true 仅防止“未找到归属”让 shell 返回失败；无包归属不是恶意结论。/usr/local、监控 agent 与自研应用通常不受 dpkg 管理。对于这些路径，需要以 CI/CD 制品哈希、部署工单与文件所有者验证来源。

bash
find /usr/local/bin /usr/local/sbin -xdev -type f -mtime -30 \
  -printf'%TY-%Tm-%TdT%TT%z %s %m %u:%g %p\n' 2>/dev/null | sort

/usr/local 正是本地安装目录，所以最近修改往往完全正常。只有当文件同时关联未知 unit、异常外联和不合理父进程时，才形成较强的恶意证据链。

从线索到根因：用交叉证据写结论

可靠结论至少包含四个事实：哪个 PID 以哪个用户运行、可执行或脚本位于哪里；它连接了哪些地址和端口；谁或什么机制启动它；入口相关的认证、Web、sudo 或 CI 日志能否对上时间。仅有 CPU 高没有未知进程、连接、留驻或入口痕迹时，正确结论是“待排查的资源异常”。反之，持续高 CPU、未知二进制、未知外联、cron/systemd 自恢复与异常登录彼此吻合，才能支持“已被挖矿或已被未授权程序利用”的判断。

确认发生入侵后，根治一般不是在原机删掉矿工。应隔离实例、保留磁盘或快照、搜索同一哈希、路径、账户和外联地址在其他资产的痕迹、轮换可能泄露的凭据，并从可信镜像重建。重建之前要修补有证据支持的入口，例如限制管理面来源、撤销泄露 SSH 密钥、升级确认受影响的组件、修复 Web 上传或命令注入。没有关闭入口，恢复同一脆弱配置只会再次被利用。

处置前检查、验证和回滚

封禁出站、摘除实例、停用 unit、删除 cron、撤销密钥、终止进程和重启主机均是高风险操作。执行前要明确目标 PID、账户或规则，确认业务已经摘流或存在可用副本，保存原配置与证据，选择单机灰度，指定观察窗口。执行后验证业务探针、错误率、CPU、连接数与异常外联；业务异常时立即恢复摘流前的负载均衡成员或服务状态。

bash
#!/usr/bin/env bash
set -euo pipefail

pid="<PID>"
unit="<单元名>"
evidence_dir="<事件目录>"
{
echo"=== target process ==="
  ps -p "$pid" -o pid,ppid,user,lstart,etime,%cpu,args
echo"=== target unit ==="
  systemctl show "$unit" -p Id -p ActiveState -p SubState -p ExecStart -p FragmentPath
echo"=== current connections ==="
  ss -plantue | rg "pid=$pid," || true
echo"=== capacity before action ==="
uptime
  free -h
} > "$evidence_dir/containment_precheck.txt"

该脚本只是处置前的证据快照。获批后，优先由负载均衡或编排器摘流，再使用对应系统的期望状态控制，而不是裸 kill -9。任何变更都应保留一条已验证的管理通道；若停错服务、撤错密钥或规则导致业务异常，利用事前导出的配置恢复，并把变更与回滚时间追加到事件时间线。

最后的值班记录不要只写“已处理”。应写明发现时间、受影响资产、证据文件校验值、已确认或待确认的入口、受影响凭据的处置、隔离和恢复时间、横向搜索范围、未解决风险与责任人。真正的闭环不是机器看起来恢复正常，而是团队能据此判断攻击者是否仍保有访问能力。

证据保管与横向范围判断

证据采集完成后，应把原始文本、配置副本、哈希清单和分析笔记分开保存。原始文件不能被筛选结果覆盖；分析笔记要注明命令、执行时间、执行账号、主机时区和文件来源。对每个重要文件计算的校验值应在移交前后复核，目的是证明内容在交接期间没有被无意修改，而不是把哈希当成恶意判定库。若证据包含访问令牌、客户数据、命令行中的密码或内网地址，应放在受限事件库并遵守保留期，普通故障工单只引用脱敏摘要。

横向排查应从已经确认的、区分度高的事实开始，例如可执行文件 SHA-256、精确的落地路径、异常 systemd 单元内容、未授权 SSH 公钥指纹、明确的父进程链以及同时出现的外联地址和端口。单独使用常见矿池端口、curl 关键字、某个国家的 IP 或一个宽泛进程名会造成大量误报。将每个检索条件标记为“确认 IOC”或“待验证线索”，并记录没有命中的资产范围、日志保留缺口和无法访问的系统，避免把“未发现”误写成“未受影响”。

凭据处置也要按照影响范围分层。确认攻击者曾读取应用环境变量、部署密钥、云实例角色或容器镜像仓库凭据时，应按依赖关系轮换：先创建新凭据并在灰度实例验证，再切换引用，最后撤销旧凭据。直接先撤销共享凭据可能让应用、备份和自动化同时中断；不撤销又会保留攻击路径。轮换后通过访问日志、认证失败率和新旧凭据使用记录验证切换完成，并将旧凭据撤销时间纳入事件时间线。

最后，重新上线应以可信重建和可验证配置为目标。保留的证据可以帮助定位入口，但不应被当作继续在疑似失陷主机上长期运行的理由。对不能立即重建的系统，应记录临时补偿措施、隔离边界、监控规则、到期时间和业务负责人；到期后仍未完成重建，应作为风险事项升级，而不是默认延长。

取证命令的意义不在于把所有异常都归为攻击，而在于让每一个处置决定都能回到可复核的事实：它何时发生、证据来自哪里、谁确认过、为什么认为影响范围到此为止。这样，后续复盘才能把一次应急经验转化为更可靠的镜像、权限、日志和监控基线。

扫描下方二维码添加助理

（务必记得备注：138页K8S实战案例）

100%可以直接获得笔记~

（是扫码领取，不是在公众号后台回复，

别看错了哦）