被攻击后排查进程状态是确认入侵痕迹最直接的切入点，因为任何攻击行为最终都要通过进程在系统上留下执行痕迹，而排查的关键是先找进程的“异常变更”，再顺着进程回溯攻击路径。
服务器被入侵怎么排查进程痕迹
当你怀疑服务器被入侵时,别急着把进程一个个看过去，先从进程的视角想清楚你面对的是什么。
从进程状态里找出“不该存在的东西”
攻击者留下的进程通常有一些共同特征,排查时参考下面这个清单，命中越多，越需要警惕：
- 进程名伪装：比如用
svchost.exe替换字母（svch0st）、在系统进程名后加空格、或用相似字体混淆的进程名，肉眼很难分辨。 - 父子进程关系异常：例如
crond（定时任务服务）突然派生出一个bash进程，或者nginx进程的子进程是python脚本，这明显不合常理。 - CPU或内存占用长期高位：挖矿程序是重灾区，通常占用多核CPU，导致系统负载长期居高不下。
- 网络连接异常：进程与外部IP建立大量连接，或频繁尝试连接非标准端口（如443、8443、8080以外的随机高端口）。
- 启动时间可疑：进程启动时间发生在你没有部署任何业务的深夜时段，或者与系统日志中异常登录的时间点吻合。
用命令把可疑进程“揪”出来
排查进程不是只看一眼就够了,要按下面的步骤逐层深入：
- 第一步,用
top或htop按CPU占用排序，直接锁定高资源消耗的进程，这一步通常能解决60%以上的挖矿类入侵。 - 第二步,用
ps -ef查看全部进程列表，关注进程的启动用户，如果发现www用户启动了/tmp目录下的程序，大概率是Webshell上传后执行的。 - 第三步,用
lsof -p [PID]查看进程打开了哪些文件，如果发现进程的工作目录在/tmp、/var/tmp
、
/dev/shm下，基本可以断定这是临时落地的恶意程序。 - 第四步,用
ls -la /proc/[PID]/exe查看进程的真实可执行文件路径，这一步能有效识别进程名伪装名称可以改，但可执行文件的真实路径骗不了人。
隐藏进程怎么找
有些rootkit级别的工具会挂钩ps和top命令，让你看不到恶意进程，这时候可以试试：
- 使用
unhide工具扫描隐藏进程。 - 对比
ps -ef和ls /proc | grep 数字的差异，凡是/proc目录下有数字目录但ps输出里没有的PID，都是被刻意隐藏的进程。
被入侵后如何确认入侵痕迹，从进程回溯攻击入口
找到可疑进程只是第一步,接下来要回答一个问题：它怎么进来的？
顺着进程的“出生信息”找登录来源
- 查看进程的环境变量：
cat /proc/[PID]/environ，这一步信息量很大，能从中看到攻击者执行脚本时设置的工作目录、传入的参数、甚至数据库密码和API密钥。 - 结合
last和lastlog命令检查最近登录记录，重点关注凌晨2点到5点之间的SSH登录，以及来源IP是否归属国外或异常地区。 - 检查
history命令记录，如果管理员共享账号，通过历史命令时间线能还原攻击者在系统上的具体操作路径。
排查系统账户和定时任务
攻击者拿到权限后,通常会在进程之外留下“后门”，方便下次进入：
- 检查
/etc/passwd中是否有新增用户，特别是UID为0（与root同权限）的账户。 - 检查
crontab -l和/etc/cron.d/目录下的定时任务，日常运维中相当一部分入侵者会通过定时任务反复拉起恶意进程。 - 检查
authorized_keys文件，看是否有陌生的公钥被写入root或业务账户下的.ssh目录。
行业共识是持久化后门加临时进程的组合是入侵者最常规的操作模式，前者负责维持访问，后者负责具体执行。
入侵排查中进程分析与系统日志的优先级
很多人在排查时纠结先看进程还是先看日志,这里给出一个较为清晰的排查节奏。
先看进程再看日志
进程是实时状态，日志是历史记录，如果服务器还在运行，先抓进程相当于抓住“案发现场的嫌疑人”，再翻日志相当于“回看监控录像”，如果只翻日志，恶意进程可能在此过程中自我删除，线索就断了。
排查顺序建议按如下优先级：
- 第一优先级：
ps -ef、top、lsof -p，确认哪些进程正在运行、连接了哪些地址。 - 第二优先级：查看
/var/log/secure或/var/log/auth.log，确认成功登录的时间点、IP、使用的账户名。 - 第三优先级：查看Web访问日志（如
/usr/local/nginx/logs/access.log），定位攻击者利用哪个漏洞、哪个URL路径完成webshell上传，再反向关联到进程启动时间。
进程IP连接泄露的溯源线索
用netstat -anop或ss -anp可以查看进程对应的网络连接状态，把可疑进程连接的IP提取出来，再配合威胁情报平台查询该IP是否有恶意记录，这比单纯分析日志更能快速确认入侵来源。
文件时间线是还原入侵路径的拼图
攻击者下载工具、执行脚本、上传恶意文件都会留下时间戳，用find / -mtime -3找出最近三天内被修改过的文件，重点关注以下敏感目录：
/tmp、/var/tmp、/dev/shm/usr/local/bin、/usr/bin- 网站目录下的
uploads、images等可写目录
把这些文件的修改时间与可疑进程的启动时间对齐,就能得到一条相对完整的攻击时间线。
以进程为中心的纵深排查思路
单看进程列表不够保险,要结合系统状态做交叉验证。
检查内存中的隐藏进程
攻击者为了躲避排查,可能直接注入内存执行，不在磁盘上落文件，此时用常规
ps命令看不到进程，但系统负载和网络连接会暴露异常：
- 使用
ps -aux | awk '{print $11}'筛选出路径异常的进程名。 - 查看
/proc目录下是否存在读写异常的特殊PID。 - 有能力的团队可以用
Volatility等工具抓取内存镜像做分析，这一步能发现无文件攻击的痕迹。
对比基线是最高效的办法
如果你此前保存过系统的进程基线（如ps -elf的存档），直接做差异对比就能快速定位新增的可疑进程，没有基线的情况下，建议在排查完成后，生成一份当前进程快照存到离线环境，作为今后排查的参考。
排查过程中的易错点
- 不要直接
kill -9可疑进程，先对可执行文件做备份，再记录进程的网络连接和命令行参数，最后确认无误后再终止，直接杀掉进程会丢失溯源所需的临时文件与连接信息。 - 不要在受害机上直接分析恶意样本,把文件打包加密码后传到隔离的沙箱环境再做行为分析。
- 不要只清理不修复,清掉进程和文件后，必须修复漏洞、改掉账户密码、清理后门，否则短期内会被再次入侵。
被入侵后排查进程的常见问题
服务器被入侵后怎么自检才能确认恶意进程已经被彻底清除
清理完成后,重启服务器再执行一次完整检查，观察恶意进程是否随系统启动重新拉起，排查范围覆盖启动项、定时任务、开机脚本、服务配置等持久化位置，判断是否残留自启动机制，系统稳定运行一周且未再出现异常连接，才能基本认定清除完成。
进程排查与日志分析的先后顺序该如何把握
先查看进程实时状态,再分析日志还原攻击路径，进程提供线索，日志验证结论，组合使用才不会遗漏关键证据。
被入侵后如何确认入侵痕迹不是误报
将可疑进程的启动时间、命令行参数、网络连接和文件路径四个维度交叉验证，如果四个维度都指向异常行为，则误报概率极低，建议立即隔离服务器。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/654303.html
