jeremyt12345/Hunting-For-Stuxbot
GitHub: jeremyt12345/Hunting-For-Stuxbot
一份完整的威胁狩猎实战教程，以虚构 APT 组织为例演示如何使用 Elastic Stack 进行入侵调查与攻击链追踪。
Stars: 0 | Forks: 0
# 狩猎 Stuxbot
威胁情报报告：Stuxbot
******************** 我总结了一份很长很长的 HTB 文档，内容涉及一次虚构的入侵事件、攻击者使用的方法，以及显而易见的，SOC 分析师如何检测所有这些内容。**********
网络犯罪组织“Stuxbot”构成了即时威胁，原因在于其今年早些时候发动的广泛且机会主义的钓鱼活动。该组织并不专注于特定目标，而是采取“任何人，任何时间”的操作方式。他们的活动似乎是由间谍动机而非经济利益驱动的，因为没有证据表明存在为了获利的数据窃取、勒索软件的使用或敲诈勒索。
处于攻击视线中的平台：Microsoft Windows
受威胁的实体：Windows 用户
潜在影响：受害者计算机被完全接管 / 域内权限升级
风险等级：严重 (Critical)
Stuxbot 主要通过广泛、机会主义的钓鱼活动获取初始访问权限，利用来自社交媒体、以往数据泄露和企业网站的公开数据。几乎没有迹象表明该组织参与针对性的鱼叉式钓鱼。本报告汇总了目前与该组织相关的所有已知 TTP 和 IOC，尽管这些内容仍在不断完善中。这份机密的初步评估仅供合作组织使用，敦促其迅速扫描环境以便尽早发现任何可能的入侵。
攻击序列：
调查显示，受害者被引导至托管在公共文件共享平台（如 Mega.io）上的 OneNote 文件。该文件伪装成发票，包含一个隐藏按钮，可执行嵌入的批处理脚本。此脚本下载 PowerShell 组件，构成攻击链的阶段 0 (stage 0)。部署的 RAT 是模块化的，允许广泛的入侵后能力；观察到的功能包括屏幕捕获、Mimikatz 执行和交互式命令行访问。目前的持久性一直依赖于在磁盘上投放可执行文件。
对于横向移动，Stuxbot 使用了两种方法：Microsoft 签名的 PsExec 和 WinRM。
该报告还为使用 Elastic Stack 的分析师提供了指导：启动目标系统，访问 5601 端口的 Kibana，打开 Discover，将时间范围扩展到“过去 15 年 (last 15 years)”，并将设置调整为 Europe/Copenhagen 时区。
该组织的网络安全监控依赖于作为 SIEM 运行的 Elastic Stack，分析师使用 Discover 功能审查来自多个来源的日志。这些包括 Windows 审计日志、Sysmon 日志和 PowerShell 日志（均在 windows* 下索引），以及 Zeek 网络监控日志（在 zeek* 下索引）。由于可用的威胁情报最早可追溯至 2023 年 3 月，因此必须将 Kibana 配置为至少搜索该时间段之后的日志。当前数据集由大约 118,975 条 Windows 相关日志和 332,261 条 Zeek 日志组成，构成了检测和分析的基础。
该组织拥有相对较少的员工，约 200 人，主要专注于在线营销，这使其 IT 基础设施保持轻量化。大多数日常工作依赖于标准 Office 应用程序，Gmail 通过网络浏览器作为主要电子邮件平台使用。公司笔记本电脑使用 Microsoft Edge 作为默认浏览器。远程 IT 支持通过 TeamViewer 提供，所有设备通过 Active Directory 组策略对象 进行集中管理。作为即将从 Windows 10 升级到 Windows 11 的一部分，该组织计划将端点管理迁移到 Microsoft Intune。
当务之急是调查该组织是否显示出遭受 Stuxbot 恶意软件入侵的迹象。利用威胁情报报告中提供的失陷指标，分析师必须在 Elastic Stack SIEM 内搜索可用日志，以识别任何与 Stuxbot 已知行为、战术和工件一致的活动。
狩猎行动
这一系列狩猎活动的前提假设是：一封成功的钓鱼邮件投递了一个恶意的 OneNote 文件。如果我们的假设是成功执行了一个哈希值与威胁情报报告中相匹配的二进制文件，我们将采取不同的活动序列。
尽管所有已知的初始入侵都涉及 invoice.one OneNote 诱饵，但您仍应搜寻所有其他 IOC，以防自报告以来投递方式发生了变化。
具体针对 OneNote 路径，从 Sysmon Event ID 15 (FileCreateStreamHash) 开始，以识别浏览器驱动的文件下载。
假设下载是通过 Web 浏览器中的 Gmail 进行的（Microsoft Edge 是您的默认浏览器），并从那里进行追踪。
尽管日志中出现 invoice.one 文件可能很严重，但尚未确认检测到的文件就是 Stuxbot 报告中描述的那个恶意文件。
此外，尚无人检查文件是否被执行，因此调查是不完整的。
展开事件日志会显示额外的元数据：
Microsoft Edge（process.name 或 process.executable）被用于下载该文件。
文件被下载到名为 Bob 的员工的 Downloads 文件夹中。
要追踪的关键时间戳是：
March 26, 2023 @ 22:05:47
这对应于 invoice.one 文件被下载的时间。
要交叉核对此次下载，您可以检查 Sysmon Event ID 11 (FileCreate)。
Event ID 11 记录系统上文件创建的时间。
这很有帮助，因为即使下载不涉及浏览器，它也能检测到文件创建，而 Event ID 15 是专注于浏览器的。
这种情况下的查询看起来略有不同，因为：
存储在磁盘上的文件通常包含区域标识符（如 Zone.Identifier:$DATA）。
此元数据表明文件源自互联网。
由于文件名在 invoice.one 之后可能包含额外文本，因此必须在文件名后放置通配符 (*)。
所以代替：
file.name:*invoice.one
我们会搜索类似：
file.name:invoice.one*
⭐ 1. 您之前发现了一个可疑下载
使用 Sysmon Event ID 15，您已经确认在 3 月 26 日 22:05 下载了一个 invoice.one 文件。
⭐ 2. 现在您正在验证文件创建是否也出现在不同的日志源中
Event ID 11 (FileCreate) 让您确认：
文件确实出现在磁盘上
文件名与下载事件匹配
时间戳与早期的 Event ID 15 条目一致
这被称为佐证 —— 它加强了事件是真实的且在不同日志类型间保持一致的理由。
⭐ 3. Zone Identifier 细节
当文件从互联网下载时，Windows 经常添加元数据，例如：
当您在 invoice.one 文件下载的时间检查 Sysmon Event ID 3 (Network Connections) 时，
您不会找到任何条目。
这是正常的，因为许多组织将 Sysmon 配置为不记录浏览器网络连接。
如果他们这样做，日志将被以下内容淹没：
Gmail 连接
广告追踪器
后台浏览器流量
一般网页浏览
这将使存储不堪重负并使分析更加困难。
由于 Sysmon 不记录这些基于浏览器的连接，这就是 Zeek 变得至关重要的地方。
要继续调查，您应该查看主机 WS001（IP 192.168.28.130）的 Zeek DNS 日志
特别是在下载窗口期间：
2023 年 3 月 26 日 22:05:00 → 22:05:48。
Zeek 查询将过滤：
源 IP = 192.168.28.130
存在 dns.question.name
剔除来自常见域名的噪音（google.com, gmail.com, microsoft.com 等）
此截图代表了 Stuxbot 调查的下一步：
1. invoice.one 已下载 → 事件 15
2. 文件已创建 → 事件 11
3. 主机已识别 → WS001
4. IP 已识别 → 192.168.28.130
5. Sysmon 网络事件缺失 → 预期之中
6. 切换到 Zeek DNS 日志 → 此截图
7. 过滤精确时间窗口内的 DNS 条目
8. 剔除噪音域名
9. 寻找可疑的 DNS 查询（报告中的下一步）
此截图是该链条中的第 6–8 步。
为什么这些日志在您的报告中很重要
此视图确认：
✔ 用户正在使用 Gmail
✔ 有东西从 file.io 下载
✔ Edge 的 SmartScreen 作出了反应
✔ 这发生在 invoice.one 创建的确切时刻
此截图是将下载与外部文件托管站点联系起来，并将活动回溯到用户电子邮件的 DNS 证据。
它填补了 Sysmon Event ID 3（未记录浏览器连接）留下的空白。
这如何融入更大的 Stuxbot 调查
到目前为止，报告已经：
确认了下载
通过 DNS
通过文件托管站点访问
通过 SmartScreen 扫描
通过 Sysmon 文件创建
确认了用户 + 机器
Bob
主机 WS001
IP 192.168.28.130
确认网络活动完美对齐
下载时间线
DNS
与 file.io 的连接
文件创建时间戳
现在调查转向下一个逻辑步骤：
Bob 打开了文件吗？
如果是，OneNote 接下来做了什么？
截图来自 Kibana Discover，使用 KQL 查询搜索 windows* 索引：
event.code:1 AND process.command_line:*invoice.one*
此查询的含义：
event.code: 1 → Sysmon ProcessCreate 事件
process.command_line:invoice.one → 查找命令行中包含 “invoice.one” 的任何进程创建
此搜索试图检测：
OneNote 是否真的打开了文件 “invoice.one”？
因为如果用户双击了文件，进程命令行通常包含文件名。
这三个条目：
1. 第一个事件
时间戳：Mar 26, 2023 @ 22:06:28.259
父进程：ONENOTE.EXE
这被认为是相关的。
2. 第二个事件
时间戳：Mar 26, 2023 @ 22:06:11.487
父进程：ONENOTE.EXE
也相关。
3. 第三个事件
时间戳：Mar 25, 2023 @ 22:34:24.057
父进程：ONENOTE.EXE
这一个是一天前的，因此与调查无关。
截图用一个大红 X 标记了这个底部条目，以表明它处于关键窗口（3 月 26 日 22:05–22:06 左右）之外。
✔ OneNote 生成了 CMD
✔ CMD 执行了一个名为 invoice.bat 的批处理文件
✔ 该批处理文件来自临时的 OneNote 导出文件夹
✔ 目录路径与 OneNote 存储嵌入对象的方式匹配
这与 Stuxbot 的威胁情报报告完全吻合：
OneNote 文件包含一个隐藏按钮
点击该按钮触发嵌入的 .bat
该 .bat 开始下载 PowerShell 阶段 0 脚本
所以这是确认的入侵点。
此截图是以下情况的证明：
恶意 OneNote 文件被成功打开
嵌入的脚本成功执行
批处理文件 invoice.bat 成功启动了 PowerShell
PowerShell 被用于下载和运行远程代码
此截图显示您确认的时刻：
“invoice.bat 确实执行了某事 —— 而且那某事是一个恶意的 PowerShell 命令。”
这是 IR（事件响应）式调查中的一个关键里程碑。
此截图显示了该 PowerShell 会话的完整活动轨迹。
在这里您会发现：
阶段 0 (stage‑0) 负载的下载
与远程服务器的连接
脚本的执行
可能是 RAT 的暂存
在系统上持久化的尝试
在这 17 个事件中看到的一切都是恶意软件实际所做的。
让我们逐一查看高亮注释。
🔴 1. 密码喷射脚本被转储到磁盘
C:\Users\Public\DAdminPass\rdspray.ps1
这意味着：
恶意软件创建了一个名为 rdspray.ps1 的 PowerShell 脚本。
该脚本几乎可以肯定是为凭据喷射（尝试许多密码）设计的。
它被投放到 Public 目录中，攻击者经常使用该目录，因为所有用户都可以访问它。
这与威胁情报报告中关于 Stuxbot 具有凭据收集模块的说法一致。
🔴 2. EXE 文件被放置在磁盘上（持久性）
C:\Users\bob\AppData\Local\Temp\default.exe
这意味着：
恶意软件投放了一个 EXE 文件，可能是 RAT 本身。
威胁情报报告已经指出：
“持久性涉及写入磁盘的 EXE 工件。”
此日志与之完美匹配。
此 EXE 可能成为主要的植入物。
🔴 3. 可疑 IP —— 可能的 C2
18.158.249.75
您看到：
DNS 解析
随后立即连接到该 IP
这种模式通常表明命令与控制服务器 (C2)，即恶意软件回连主控端。
文本指出“Could this be C2?” —— 意思是它是可疑的，而非已确认。
重要的部分是：
PowerShell 连接到了一个外部 IP，
就在运行下载的脚本之后。
🔴 4. NGROK 域名 + 网络连接
7aec-…-bu.ngrok.io
104.20.67.143
这意味着：
恶意软件对 NGROK 隧道服务进行了 DNS 查找。
然后它连接到解析出的 IP。
NGROK 常被滥用于：
远程访问隧道
数据窃取
C2 通信
隐藏攻击者位置
这符合 RAT (Remote Access Trojan) 行为。
🔴 5. 创建了额外的 cmdline 文件
C:\Users\bob\AppData\Local\Temp\S153Zc9g.mdline
这意味着：
PowerShell 创建了更多的暂存或临时文件。
这与以下情况一致：
暂存负载
解密数据
临时存储命令
.mdline 扩展名不是标准的 —— 可能是攻击者。
这是您确认的关键时刻：
✔ 从 Pastebin 下载的恶意 PowerShell 脚本确实执行了
✔ 它将恶意文件写入磁盘
✔ 它尝试了凭据喷射
✔ 它联系了可疑的外部 IP
✔ 它连接到了 NGROK 隧道
✔ 它很可能部署了 RAT
此截图中的所有内容都与您的威胁情报报告中描述的行为相匹配。
这是调查的“入侵后行为”部分。
以下是图像中发生的事情：
1. 数据视图：zeek*
这确认我们正在查看：
网络级日志
由 Zeek 传感器捕获
2. 查询：18.158.249.75
这过滤了以下日志：
destination.ip = 18.158.249.75
或者可能是 source.ip = 18.158.249.75（取决于映射）
根据上下文，这些是来自 WS001 的出站连接。
3. 时间范围：“Last 2 years”
这确保显示与该 IP 的所有可能连接。
4. 24 个命中
涉及该 IP 的有 24 个网络相关事件。
这意味着：
受感染的主机多次联系（或尝试联系）该 IP，
这与恶意软件信标回连远程服务器一致。
5. 显示的列
截图显示：
source.ip → 这是 WS001 的 IP (192.168.28.130)
destination.ip → 可疑 IP (18.158.249.75)
destination.port → 通常为 443 (HTTPS)，将流量隐藏在加密隧道中
这与显示以下内容的早期日志匹配：
PowerShell 启动
下载远程内容
并连接到外部主机
这意味着：
在 3 月 26 日初始感染之后，
受损主机持续与可疑远程 IP 通信
随后的多天内
表明存在持久性以及可能的活跃 C2 通信
这表明攻击者的恶意软件不仅仅运行了一次 —— 它留在了机器上并不断回连。
这正是 RAT (Remote Access Trojan) 所做的：
维持长期控制
定期发出信标
等待命令
这揭示了持久性可执行文件执行的所有活动。
有 68 个命中，意味着 default.exe 记录了 68 个事件 —— 数量庞大，暗示了广泛的入侵后行为。
在高亮框内，关键观察包括：
SharpHound.exe 被上传至
C:\Users\Public\c\SharpHound.exe
一个可疑的伪造 svchost.exe 被上传至
C:\Users\bob\AppData\Local\Temp\svchost.exe
持久性可执行文件 default.exe 本身被重新访问，可能是为了重新运行
多个出站连接指向：
18.158.249.75（疑似 C2）
ngrok.io 隧道端点
其他可疑基础设施
这指示 SharpHound：
收集所有可用的 Active Directory 侦察数据。
这是完整的 AD 映射模式，用于枚举：
域信任
用户
组
权限
ACL
会话数据
计算机对象
管理员权限
攻击路径
这与攻击者执行域侦察以找到提升权限或横向移动的路径一致。
文本强调了与恶意软件持久性组件 相关的三个关键点以及威胁情报验证步骤：
1. SharpHound 运行了两次
2. Sysmon 报告称投放的可执行文件 与威胁情报哈希匹配：018d37cbd3878258c29db3bc3f2988b6ae688843801b9abc28e6151141ab66d4
3. 下一步：检查此恶意软件是否已出现在其他设备上
这些字段共同证明，在 PKI 上，default.exe 是通过 PsExec 远程启动的，并且与已知的恶意哈希匹配。
本部分证明攻击者从 WS001 暴力破解了 svc‑sql1 账户，利用它横向移动到 PKI 和其他系统，并尝试（但失败）入侵管理员账户，标志着入侵中明显的升级阶段
**************** 这里是我的分析文档开始的地方 ***********************
调查显示，受害者被引导至托管在公共文件共享平台（如 Mega.io）上的 OneNote 文件。该文件伪装成发票，包含一个隐藏按钮，可执行嵌入的批处理脚本。此脚本下载 PowerShell 组件，构成攻击链的阶段 0 (stage 0)。部署的 RAT 是模块化的，允许广泛的入侵后能力；观察到的功能包括屏幕捕获、Mimikatz 执行和交互式命令行访问。目前的持久性一直依赖于在磁盘上投放可执行文件。
对于横向移动，Stuxbot 使用了两种方法：Microsoft 签名的 PsExec 和 WinRM。
该报告还为使用 Elastic Stack 的分析师提供了指导：启动目标系统，访问 5601 端口的 Kibana，打开 Discover，将时间范围扩展到“过去 15 年 (last 15 years)”，并将设置调整为 Europe/Copenhagen 时区。
该组织的网络安全监控依赖于作为 SIEM 运行的 Elastic Stack，分析师使用 Discover 功能审查来自多个来源的日志。这些包括 Windows 审计日志、Sysmon 日志和 PowerShell 日志（均在 windows* 下索引），以及 Zeek 网络监控日志（在 zeek* 下索引）。由于可用的威胁情报最早可追溯至 2023 年 3 月，因此必须将 Kibana 配置为至少搜索该时间段之后的日志。当前数据集由大约 118,975 条 Windows 相关日志和 332,261 条 Zeek 日志组成，构成了检测和分析的基础。
该组织拥有相对较少的员工，约 200 人，主要专注于在线营销，这使其 IT 基础设施保持轻量化。大多数日常工作依赖于标准 Office 应用程序，Gmail 通过网络浏览器作为主要电子邮件平台使用。公司笔记本电脑使用 Microsoft Edge 作为默认浏览器。远程 IT 支持通过 TeamViewer 提供，所有设备通过 Active Directory 组策略对象 进行集中管理。作为即将从 Windows 10 升级到 Windows 11 的一部分，该组织计划将端点管理迁移到 Microsoft Intune。
当务之急是调查该组织是否显示出遭受 Stuxbot 恶意软件入侵的迹象。利用威胁情报报告中提供的失陷指标，分析师必须在 Elastic Stack SIEM 内搜索可用日志，以识别任何与 Stuxbot 已知行为、战术和工件一致的活动。
狩猎行动
这一系列狩猎活动的前提假设是：一封成功的钓鱼邮件投递了一个恶意的 OneNote 文件。如果我们的假设是成功执行了一个哈希值与威胁情报报告中相匹配的二进制文件，我们将采取不同的活动序列。
尽管所有已知的初始入侵都涉及 invoice.one OneNote 诱饵，但您仍应搜寻所有其他 IOC，以防自报告以来投递方式发生了变化。
具体针对 OneNote 路径，从 Sysmon Event ID 15 (FileCreateStreamHash) 开始，以识别浏览器驱动的文件下载。
假设下载是通过 Web 浏览器中的 Gmail 进行的（Microsoft Edge 是您的默认浏览器），并从那里进行追踪。
尽管日志中出现 invoice.one 文件可能很严重，但尚未确认检测到的文件就是 Stuxbot 报告中描述的那个恶意文件。
此外，尚无人检查文件是否被执行，因此调查是不完整的。
展开事件日志会显示额外的元数据：
Microsoft Edge（process.name 或 process.executable）被用于下载该文件。
文件被下载到名为 Bob 的员工的 Downloads 文件夹中。
要追踪的关键时间戳是：
March 26, 2023 @ 22:05:47
这对应于 invoice.one 文件被下载的时间。
要交叉核对此次下载，您可以检查 Sysmon Event ID 11 (FileCreate)。
Event ID 11 记录系统上文件创建的时间。
这很有帮助，因为即使下载不涉及浏览器，它也能检测到文件创建，而 Event ID 15 是专注于浏览器的。
这种情况下的查询看起来略有不同，因为：
存储在磁盘上的文件通常包含区域标识符（如 Zone.Identifier:$DATA）。
此元数据表明文件源自互联网。
由于文件名在 invoice.one 之后可能包含额外文本，因此必须在文件名后放置通配符 (*)。
所以代替：
file.name:*invoice.one
我们会搜索类似：
file.name:invoice.one*
⭐ 1. 您之前发现了一个可疑下载
使用 Sysmon Event ID 15，您已经确认在 3 月 26 日 22:05 下载了一个 invoice.one 文件。
⭐ 2. 现在您正在验证文件创建是否也出现在不同的日志源中
Event ID 11 (FileCreate) 让您确认：
文件确实出现在磁盘上
文件名与下载事件匹配
时间戳与早期的 Event ID 15 条目一致
这被称为佐证 —— 它加强了事件是真实的且在不同日志类型间保持一致的理由。
⭐ 3. Zone Identifier 细节
当文件从互联网下载时，Windows 经常添加元数据，例如：
当您在 invoice.one 文件下载的时间检查 Sysmon Event ID 3 (Network Connections) 时，
您不会找到任何条目。
这是正常的，因为许多组织将 Sysmon 配置为不记录浏览器网络连接。
如果他们这样做，日志将被以下内容淹没：
Gmail 连接
广告追踪器
后台浏览器流量
一般网页浏览
这将使存储不堪重负并使分析更加困难。
由于 Sysmon 不记录这些基于浏览器的连接，这就是 Zeek 变得至关重要的地方。
要继续调查，您应该查看主机 WS001（IP 192.168.28.130）的 Zeek DNS 日志
特别是在下载窗口期间：
2023 年 3 月 26 日 22:05:00 → 22:05:48。
Zeek 查询将过滤：
源 IP = 192.168.28.130
存在 dns.question.name
剔除来自常见域名的噪音（google.com, gmail.com, microsoft.com 等）
此截图代表了 Stuxbot 调查的下一步：
1. invoice.one 已下载 → 事件 15
2. 文件已创建 → 事件 11
3. 主机已识别 → WS001
4. IP 已识别 → 192.168.28.130
5. Sysmon 网络事件缺失 → 预期之中
6. 切换到 Zeek DNS 日志 → 此截图
7. 过滤精确时间窗口内的 DNS 条目
8. 剔除噪音域名
9. 寻找可疑的 DNS 查询（报告中的下一步）
此截图是该链条中的第 6–8 步。
为什么这些日志在您的报告中很重要
此视图确认：
✔ 用户正在使用 Gmail
✔ 有东西从 file.io 下载
✔ Edge 的 SmartScreen 作出了反应
✔ 这发生在 invoice.one 创建的确切时刻
此截图是将下载与外部文件托管站点联系起来，并将活动回溯到用户电子邮件的 DNS 证据。
它填补了 Sysmon Event ID 3（未记录浏览器连接）留下的空白。
这如何融入更大的 Stuxbot 调查
到目前为止，报告已经：
确认了下载
通过 DNS
通过文件托管站点访问
通过 SmartScreen 扫描
通过 Sysmon 文件创建
确认了用户 + 机器
Bob
主机 WS001
IP 192.168.28.130
确认网络活动完美对齐
下载时间线
DNS
与 file.io 的连接
文件创建时间戳
现在调查转向下一个逻辑步骤：
Bob 打开了文件吗？
如果是，OneNote 接下来做了什么？
截图来自 Kibana Discover，使用 KQL 查询搜索 windows* 索引：
event.code:1 AND process.command_line:*invoice.one*
此查询的含义：
event.code: 1 → Sysmon ProcessCreate 事件
process.command_line:invoice.one → 查找命令行中包含 “invoice.one” 的任何进程创建
此搜索试图检测：
OneNote 是否真的打开了文件 “invoice.one”？
因为如果用户双击了文件，进程命令行通常包含文件名。
这三个条目：
1. 第一个事件
时间戳：Mar 26, 2023 @ 22:06:28.259
父进程：ONENOTE.EXE
这被认为是相关的。
2. 第二个事件
时间戳：Mar 26, 2023 @ 22:06:11.487
父进程：ONENOTE.EXE
也相关。
3. 第三个事件
时间戳：Mar 25, 2023 @ 22:34:24.057
父进程：ONENOTE.EXE
这一个是一天前的，因此与调查无关。
截图用一个大红 X 标记了这个底部条目，以表明它处于关键窗口（3 月 26 日 22:05–22:06 左右）之外。
✔ OneNote 生成了 CMD
✔ CMD 执行了一个名为 invoice.bat 的批处理文件
✔ 该批处理文件来自临时的 OneNote 导出文件夹
✔ 目录路径与 OneNote 存储嵌入对象的方式匹配
这与 Stuxbot 的威胁情报报告完全吻合：
OneNote 文件包含一个隐藏按钮
点击该按钮触发嵌入的 .bat
该 .bat 开始下载 PowerShell 阶段 0 脚本
所以这是确认的入侵点。
此截图是以下情况的证明：
恶意 OneNote 文件被成功打开
嵌入的脚本成功执行
批处理文件 invoice.bat 成功启动了 PowerShell
PowerShell 被用于下载和运行远程代码
此截图显示您确认的时刻：
“invoice.bat 确实执行了某事 —— 而且那某事是一个恶意的 PowerShell 命令。”
这是 IR（事件响应）式调查中的一个关键里程碑。
此截图显示了该 PowerShell 会话的完整活动轨迹。
在这里您会发现：
阶段 0 (stage‑0) 负载的下载
与远程服务器的连接
脚本的执行
可能是 RAT 的暂存
在系统上持久化的尝试
在这 17 个事件中看到的一切都是恶意软件实际所做的。
以下是图像中发生的事情：
1. 数据视图：zeek*
这确认我们正在查看：
网络级日志
由 Zeek 传感器捕获
2. 查询：18.158.249.75
这过滤了以下日志：
destination.ip = 18.158.249.75
或者可能是 source.ip = 18.158.249.75（取决于映射）
根据上下文，这些是来自 WS001 的出站连接。
3. 时间范围：“Last 2 years”
这确保显示与该 IP 的所有可能连接。
4. 24 个命中
涉及该 IP 的有 24 个网络相关事件。
这意味着：
受感染的主机多次联系（或尝试联系）该 IP，
这与恶意软件信标回连远程服务器一致。
5. 显示的列
截图显示：
source.ip → 这是 WS001 的 IP (192.168.28.130)
destination.ip → 可疑 IP (18.158.249.75)
destination.port → 通常为 443 (HTTPS)，将流量隐藏在加密隧道中
这与显示以下内容的早期日志匹配：
PowerShell 启动
下载远程内容
并连接到外部主机
这意味着：
在 3 月 26 日初始感染之后，
受损主机持续与可疑远程 IP 通信
随后的多天内
表明存在持久性以及可能的活跃 C2 通信
这表明攻击者的恶意软件不仅仅运行了一次 —— 它留在了机器上并不断回连。
这正是 RAT (Remote Access Trojan) 所做的：
维持长期控制
定期发出信标
等待命令
这些字段共同证明，在 PKI 上，default.exe 是通过 PsExec 远程启动的，并且与已知的恶意哈希匹配。
本部分证明攻击者从 WS001 暴力破解了 svc‑sql1 账户，利用它横向移动到 PKI 和其他系统，并尝试（但失败）入侵管理员账户，标志着入侵中明显的升级阶段
**************** 这里是我的分析文档开始的地方 ***********************标签：AI合规, APT攻击, Batch脚本, Conpot, DAST, DNS 反向解析, ESC8, HTTP工具, IOCs指标, IP 地址批量处理, MEGA网盘, MIT许可证, OneNote恶意文件, OpenCanary, PowerShell攻击, RAT远控木马, SOC分析, Stuxbot, TTPs分析, Windows安全, 初始访问, 域渗透, 威胁情报, 安全报告, 开发者工具, 恶意软件分析, 数据泄露, 电子数据取证, 社会工程学, 网络信息收集, 网络入侵, 网络安全审计, 网络间谍, 越狱测试, 配置审计