背景

2023 年 9 月 18 日，接到运维部消息，有一台服务器被举报为恶意服务器，展开排查。

处置思路

1. 确认威胁状态、原因

2. 确认服务器状态、用途、影响

3. 应急（仅保证必要程序运行，下线非不要服务，备份服务器，必要时直接下线服务器）

4. 排查服务器通信状态、进程、后门、日志等

5. 清除木马文件

6. 评估事件损失，恢复服务器状态

7. 木马文件入口排查，安全加固

8. 梳理事件成因、影响、排查过程，生成案例报告

   排查

9. 威胁情报中心收集具体情况

   1. 微步威胁情报中心。（原标记 CS 远控，现已更新）
      1. 
   2. qax 威胁情报中心。（标记为 CS 远控）
      1. 
   3. 360 威胁情报中心。（显示为 3 个危险样本）
      1. 

10. 联系运维同事，分析服务器用途，如无必要，先做公网下线处理。

    1. 该系统是运维部使用的一台 linux 测试跳板机，部署了开源堡垒机 jumpserver，已做公网下线处理。

11. 登录机器，开始排查

    1. 查看部署软件。仅有 jumpserver、 docker 以及 jumpserver 所依赖的服务，无其他软件
    2. 查看端口。（与运维同事共同排查，无异常端口。但开放了 80/443/22 端口，可能需要进一步排查是否有风险）
    3. 查看进程。（与运维同事共同排查，无异常进程。）
       1. 端口、进程无异常。猜测以下两种情况：
          1. 已经被植入后门，随用随上线，当前木马并未在线；
          2. 进程与端口做了隐藏处理（如果真是这样，那就麻烦了）
          3. （补充第三点，当时真没往这儿想）误报
    4. 检查可能得后门
       1. 用户列表、影子文件。（无异常）
       2. 计划任务。（使用脚本遍历所有用户的计划任务，无计划任务。无异常）
       3. 定时进程列表。（存在定时的临时文件清理。无异常）
       4. 认证文件。（无异常）
    5. 检查日志
       1. 系统登录日志 last（无异常）
       2. jumpserver 日志 /opt/jumpserver/core/logs（无异常，最早为 2022 年 10 月 26 日， 与运维同事确认过，确实是这个时间点部署的，不存在删除日志的操作）
       3. 系统内核日志（无异常）
       4. nginx 日志 /var/log/nginx/access.log（无异常）
       5. 系统认证和授权日志 /var/log/auth.log（无异常）

12. 怀疑人生中……

13. 咨询大佬，大佬提醒从威胁情报平台重新寻找突破口，针对性的排查，不要下意识的排除误报这种可能。

14. 整装待发，重新从威胁情报平台寻找线索。

    1. 360 威胁情报平台（360 威胁情报平台通信样本中发现，文件类型为 Win64，而我们的机器是 Linux
       1. 

15. 有点怀疑是误报了，联系曾经在奇安信、360、微步的朋友，协助确认被标记恶意IP的原因

    1. 最终微步的朋友给出确切的结论：此 IP 于 2022 年 10 月 16 日之前，属于一台 Windows 服务器，运行过名为 test.exe 的远控木马，有足够的证据证明此文件为 CS 远控端生成，同时，同 C 段下还有 6 台服务器被同样的方式远控。IP 于 2022 年 10 月 22 日更换属主（也就是我们公司，与我们运维部之前反应的 10 月 26 日部署 jumpserver 作为堡垒机使用的情况，时间基本吻合），现有足够证据证明该 IP 已非攻击者所有，判定为安全，将威胁情报更新“过期”。
    2. 
    3. 同步反馈至奇安信威胁情报平台。于 9 月 21 日下午也收到回复，确认误报，已更新状态。
    4.