kingsrule50/azure-soc-homelab

## 📋 实验总结 | 字段 | 详情 | |---|---| | **认证对齐** | CompTIA Security+ · CySA+ · Splunk Core Certified User | | **预估时间** | 4–6 小时（跨多个会话） | | **预估成本** | **$0** — Splunk Free 许可 (500 MB/天) | | **难度** | 中级 | | **Azure 资源** | 2× VMs (Ubuntu 24.04 LTS + 实验 1 的 Windows Server) | | **职业相关性** | SOC 分析师 T1–T3 · 安全工程师 · 事件响应人员 | ## 🎯 概述 ### 本实验解决的问题 一个中型组织每天生成**数百万条日志事件** — Windows 事件日志、Active Directory 身份验证事件、防火墙日志和云资源日志。如果没有 SIEM，这些日志分散在不同的系统中，无法跨系统搜索、关联事件或识别跨越多个来源的攻击模式。 本实验模拟了**企业 SOC 环境**的运作方式： - 一个 **Windows Server VM**（来自实验 1 的 Active Directory 环境）生成真实的认证事件 - 一个 **Splunk Universal Forwarder** 通过内部 Azure 网络传输这些日志 - 一个 **Splunk SIEM 实例** 索引、搜索和可视化数据 - **SPL 检测规则** 突出显示暴力破解尝试、非工作时间登录和账户锁定 - **自动化警报** 在超过威胁阈值时触发 — 无需人工检查 ## 🏗 架构 ### 数据流图  ### 信任边界与安全设计决策 | 边界 | 应用的规则 | 原理 | |---|---|---| | **端口 8000 (Web UI)** | 仅限**我的 IP** | 防止未授权访问 Splunk 界面 | | **端口 9997 (转发器)** | 仅限 **VNet 范围** (10.0.0.0/16) | 日志摄取绝不应暴露在公共互联网上 | | **端口 22 (SSH)** | 仅限**我的 IP** | 限制对 Ubuntu VM 的管理访问 | | **端口 3389 (RDP)** | 仅限**我的 IP**（Windows VM） | 遵循对域控制器的最低权限访问原则 | ## ✅ 前置条件 - 在 Azure 中部署了 Active Directory Windows Server VM（实验 1） - Azure 订阅（免费层即可） - SSH 客户端 — macOS/Linux 上的终端或 Windows 上的 PuTTY - 在 [splunk.com](https://splunk.com) 注册的 Splunk 免费账户 ### Windows Server VM — 实验 1 AD 域控制器 Windows Server DC02 VM 作为 Active Directory 日志源，为本 SIEM 实验提供数据。 **DC02 VM 创建 — 配置：** 该 VM 在 Azure 的 `kingsvm_group` 资源组下创建。镜像选择了 Windows Server 2025 Datacenter (Azure Edition)，大小设置为 Standard_D2s_v3（2 个 vCPU，8 GiB 内存），区域设置为美国东部。将 VM 命名为 `DC02` 遵循了企业环境中使用的域控制器命名约定。  **DC02 部署进行中：** 点击 **查看 + 创建** 然后 **创建** 后，Azure 开始预配 VM。部署屏幕确认正在创建网络接口和公共 IP 地址资源以及 VM 本身。  **DC02 部署完成：** 部署在不到 2 分钟内成功完成。绿色的 **部署成功** 通知确认所有资源 — VM、NIC 和公共 IP — 均已无错误地预配。  **DC02 — 配置了原生 RDP 连接（端口 3389）：** 从 DC02 VM 边栏导航到 **连接 > 原生 RDP**。确认了公共 IP (20.120.38.222) 和端口 3389。在连接前，在 NSG 中将 RDP 的源 IP 限制设置为仅限我的 IP，遵循最低权限访问原则。  **正在建立到 DC02 的 RDP 会话：** 下载并打开 RDP 文件后，会话以 `Admin01` 身份连接。"请等待用户"屏幕确认会话握手完成且 Windows 桌面正在加载 — VM 响应正常且可访问。  ## 🚀 部署 ### 步骤 1 — 在 Azure 中预配 Splunk Ubuntu 24.04 LTS VM #### Azure VM 配置 | 设置 | 值 | |---|---| | **操作系统** | Ubuntu 24.04 LTS | | **大小** | Standard_D2s_v3 (2 个 vCPU，8 GB RAM) | | **操作系统磁盘** | 30 GB | | **入站 NSG 规则 1** | 端口 **8000** → TCP → 来源：我的 IP | | **入站 NSG 规则 2** | 端口 **9997** → TCP → 来源：VNet (10.0.0.0/16) | | **入站 NSG 规则 3** | 端口 **22** → TCP → 来源：我的 IP | **VM 配置 — 镜像、大小和身份验证：** 在 Azure 门户中，导航到 **虚拟机 > 创建**。镜像选择了 Ubuntu Server 24.04 LTS (x64 Gen2)，大小选择了 Standard_D2s_v3 (2 个 vCPU，8 GiB) — 这是 Splunk 为实验室环境推荐的最低规格。身份验证设置为 SSH 公钥，对于 Linux 服务器来说比密码身份验证更安全。  **VM 配置 — 订阅和资源组：** 该 VM 被添加到现有的 `kingsvm_group` 资源组中，这样所有实验室资源可以一起管理，并在实验结束时作为一个整体删除。区域设置为美国东部以匹配 DC02，使两个 VM 位于同一个 Azure VNet 中，以实现低延迟的内部通信。  **Ubuntu 24.04 LTS VM 部署进行中：** 验证通过后，确认了部署。网络接口 (`splunk-server31`) 和公共 IP (`splunk-server-ip`) 资源正在首先预配，然后是 VM 本身。  **部署完成 — splunk-server 上线：** **部署成功** 通知确认所有资源均已创建，没有错误。点击 **转到资源** 以打开 VM 边栏，并在继续进行 SSH 之前确认公共 IP 地址。  **splunk-server VM 属性 — 确认操作系统、大小和网络：** 从 VM **属性** 选项卡确认：操作系统是 Linux (Ubuntu 24.04)，大小是 Standard D2s v3（2 个 vCPU，8 GiB RAM），私有 IP 是 10.0.0.4，并且 VM 连接到 `kingsvm-vnet/default` 子网 — 与 DC02 相同的 VNet。这确认了两个 VM 共享一个内部网络，无需经过公共互联网即可通信。  #### 配置的 NSG 规则 部署后，向 `kingsvm-nsg` 网络安全组添加了三个入站规则以控制对 Splunk VM 的访问。 **添加入站规则 — 端口 8000 (Splunk Web UI)：** 导航到 Splunk VM > **网络 > 网络设置 > 创建端口规则 > 入站端口规则**。将目标端口设置为 `8000`，协议设置为 TCP，操作设置为允许，并将规则命名为 `allow-splunk-web`。来源限制为仅限我的 IP 地址 — 端口 8000 绝不能向公共互联网开放，因为它提供了对 Splunk 管理界面的直接访问。  **添加入站规则 — 端口 9997 (转发器输入)：** 为端口 `9997` 创建了第二条规则 — Splunk 用于从 Universal Forwarder 接收日志的端口。命名为 `allow-splunk-forwarder`。来源设置为 VNet 地址范围 (10.0.0.0/16) 而不是我的 IP，因为是 DC02（而不是我的本地机器）将日志发送到 Splunk。限制为 VNet 确保此端口仅可从同一网络中的其他 Azure VM 访问。  **确认所有 NSG 入站规则 — RDP :3389, Web UI :8000, 转发器 :9997：** 最终的 NSG 状态显示六个入站规则。三条自定义规则 — RDP (300)、allow-splunk-web (301) 和 allow-splunk-forwarder (302) — 均显示 **允许** 状态。默认的 Azure 规则 (AllowVnetInBound, AllowAzureLoadBalancer, DenyAllInBound) 保持不变。  #### 验证了 VM 之间的 VNet 连通性 在安装 Splunk 之前，测试了从 DC02 到 Splunk VM 私有 IP 的连接，以确认两个 VM 可以通过 Azure VNet 通信。 **从 DC02 到 Splunk VM 的 Ping 测试 — 0% 丢包：** 在 DC02 的管理员 PowerShell 会话中，运行 `ping 10.0.0.4` — Splunk VM 的私有 IP。所有 4 个数据包均已接收，丢包率 0%，响应时间低于 5ms，确认两个 VM 可以通过内部 VNet 互相访问。这至关重要 — Universal Forwarder 将把日志发送到此私有 IP 的 9997 端口。  **确认 Windows Server 上已安装 OpenSSH — SSH 客户端就绪：** 在 PowerShell 中运行 `Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Client*'` 以确认 DC02 上是否提供了 OpenSSH。结果显示 `State: Installed`，这意味着可以直接从 Windows Server 终端运行 SSH 命令 — 无需额外工具即可连接到 Ubuntu Splunk VM。  #### 通过 SSH 安装 Splunk Enterprise 使用私有 IP (10.0.0.4) 通过 VNet 从 DC02 建立了到 Ubuntu Splunk VM 的 SSH 会话 — 使所有流量都保留在 Azure 内部。 **SSH 会话已建立 — azureuser@splunk-server (Ubuntu 24.04.4 LTS)：** 从 DC02 PowerShell 终端运行 `ssh azureuser@10.0.0.4`。接受主机指纹并输入密码后，Ubuntu 24.04.4 LTS 欢迎屏幕确认连接成功。系统信息显示 28GB 磁盘、3% 内存使用率和 134 个运行进程 — 确认 VM 健康状况良好，可以安装 Splunk。  **Splunk 安装前更新了系统包：** 在安装任何软件之前，运行 `sudo apt update && sudo apt upgrade -y` 以确保所有系统包都是最新的。这是安装服务器应用程序之前的标准做法 — 过时的包可能会导致依赖冲突或留下已知的漏洞。输出显示从 Azure 的 Ubuntu 镜像更新了 24+ 个软件包仓库。  ``` # 通过 SSH 连接到 Ubuntu 24.04 LTS 虚拟机，然后执行以下操作： # 下载 Splunk Enterprise — Linux .deb 安装包 wget -O splunk-10.2.2-linux-amd64.deb \ "https://download.splunk.com/products/splunk/releases/10.2.2/linux/splunk-10.2.2-80b90d638de6-linux-amd64.deb" # 安装该软件包 sudo dpkg -i splunk-10.2.2-linux-amd64.deb # 启动 Splunk 并接受许可证协议 sudo /opt/splunk/bin/splunk start --accept-license # 设置 Splunk 在虚拟机重启时自动启动 sudo /opt/splunk/bin/splunk enable boot-start ``` **Splunk 安装完成 — 确认 Web 服务器在 :8000 运行：** 安装输出显示所有初步检查通过，为 TLS 生成了 RSA 私钥，最后一行确认 Splunk Web 服务器在 `http://splunk-server:8000` 可用。"等待 Web 服务器"行上的 `Done` 状态确认 Splunk 启动成功并正在监听连接。  #### 访问了 Splunk Web UI 随着 Splunk 的运行，使用 Splunk VM 的私有 IP 和端口 8000 从 DC02 浏览器访问了 Web 界面。 **Splunk Enterprise 登录页面 — 通过浏览器在 10.0.0.4:8000 访问：** 在 DC02 上打开浏览器并导航到 `http://10.0.0.4:8000`。Splunk Enterprise 登录页面加载成功，确认端口 8000 可从 VNet 内访问，并且 Splunk 的 Web 服务器进程正在运行。使用安装期间设置的管理员凭据登录。  **Splunk Enterprise 主页 — 以管理员身份登录：** Splunk 主页确认以管理员账户成功登录。左侧边栏显示已安装的应用程序（搜索和报告、审计跟踪、Splunk 安全网关），主区域显示入门选项 — 添加数据、搜索数据、可视化数据和管理警报。这是所有后续配置的起点。  ### 步骤 2 — 配置了数据输入 #### Windows Server 上安装了 Sysmon 在 DC02 上部署了 Sysmon（系统监视器），以丰富 Windows 事件日志，包括进程创建、网络连接和文件更改事件 — 提供超越标准 Windows 安全事件的更深入主机可见性。 **从 Microsoft Sysinternals 下载了 Sysmon v15.2：** 在 DC02 上，打开浏览器并导航到 `learn.microsoft.com/en-us/sysinternals/downloads/sysmon`。下载了 Sysmon v15.2 (4.6 MB)。选择 Sysmon 是因为它能生成标准 Windows 事件日志无法捕获的高保真遥测数据 — 尤其是进程创建链和由特定进程发起的网络连接。  **Sysmon 文件解压到 C:\Tools\Sysmon：** 下载的 Sysmon.zip 被解压到 `C:\Tools\Sysmon` 的专用文件夹。该文件夹包含四个文件：Eula.txt、Sysmon.exe（32 位）、Sysmon64.exe（64 位）和 Sysmon64a.exe（ARM）。由于 DC02 运行的是 64 位 Windows Server 环境，因此使用了 Sysmon64.exe 进行安装。  **保存了 Sysmon 配置文件 (sysmonconfig-export.xml)：** 从社区维护的仓库（SwiftOnSecurity 的 sysmonconfig）下载了 Sysmon 配置文件，并将其保存为 `C:\Tools\Sysmon` 内的 `sysmonconfig-export.xml`。该配置文件控制 Sysmon 捕获哪些事件以及忽略哪些事件 — 使用维护良好的社区配置可以防止过多的噪声，同时确保关键事件被记录。  **Sysmon64 已安装并启动 — 确认 SplunkForwarder 服务正在运行：** 从管理员 PowerShell 会话，导航到 `C:\Tools\Sysmon` 并运行 `.\Sysmon64.exe -accepteula -i sysmonconfig-export.xml`。输出确认：配置已验证，Sysmon64 已安装，SysmonDrv 驱动程序已安装并启动。之后运行 `Get-Service *splunk*` 确认 SplunkForwarder 服务已经在运行 — 遥测收集器和日志传输器同时处于活动状态。  #### Windows Server 上安装了 Universal Forwarder 在 DC02 上安装了 Splunk Universal Forwarder，以通过私有 VNet IP 自动将 Windows 事件日志传输到 Splunk 索引器。 - **部署服务器：** `10.0.0.4:8089` - **接收索引器：** `10.0.0.4:9997` **Universal Forwarder 设置向导 — 选择了本地 Splunk Enterprise 实例：** 在 DC02 上，从 `splunk.com/en_us/download/universal-forwarder.html` 下载了 Splunk Universal Forwarder Windows 64 位安装程序。在安装期间，接受许可协议并选择了**本地 Splunk Enterprise 实例**（而不是 Splunk Cloud）。接收索引器设置为 `10.0.0.4:9997` — Splunk VM 的私有 IP 以及配置为接收转发器数据的端口。  **Universal Forwarder 安装进行中：** 安装程序正在将文件复制到 `C:\Program Files\SplunkUniversalForwarder`。进度条确认安装正在进行。完成后，转发器将自身注册为 Windows 服务并自动启动 — 向导完成后无需手动启动。  #### 配置了 inputs.conf 在 DC02 上的 `C:\Program Files\SplunkUniversalForwarder\etc\system\local\` 路径下创建了 `inputs.conf`，以告知转发器应收集哪些 Windows 事件日志并转发到 Splunk： ``` [WinEventLog://Security] disabled = 0 start_from = oldest current_only = 0 evt_resolve_ad_obj = 1 [WinEventLog://System] disabled = 0 [WinEventLog://Application] disabled = 0 ``` 保存文件后，使用 `Restart-Service SplunkForwarder` 重启了转发器服务以应用配置。`start_from = oldest` 设置确保收集系统上已有的历史事件，而不仅仅是从当前开始的新事件。 ## 🔎 SPL 检测查询 所有搜索都在 Splunk Web UI 的 **搜索和报告** 中运行。搜索栏接受 SPL（Splunk 处理语言）查询，并从索引的日志数据中返回结果。 ### 确认了数据流 **初始搜索 — 从 DC02 (WinEventLog:System) 到达的第一个事件：** 为了验证日志是否正在流动，在 Splunk 搜索栏中运行了 `index=* EventCode=1`，时间范围设置为**过去 24 小时**。搜索返回了 9 个事件，全部来自 `DC02`，`sourcetype=WinEventLog:System`。这确认了 DC02 上的 Universal Forwarder 正在成功将日志传输到 Splunk 并且它们正在被正确索引。  **安全事件搜索 — 从 DC02 索引了 40,642 个事件：** 运行了 `index=* sourcetype=WinEventLog:Security` 以查询完整的安全日志。搜索返回了来自 DC02 的 **40,642 个事件** — 确认包含所有认证事件（登录、失败、锁定）的安全事件日志正在被成功转发和索引。左侧的"有趣字段"面板显示了 Splunk 为安全事件类型自动提取的 `EventCode`、`Account_Name`、`Logon_Type` 和其他字段。  ### 成功登录（事件 ID 4624） **EventCode=4624 搜索 — 返回了 15 个成功登录事件：** 在搜索和报告中运行了下面的查询，选择了**过去 24 小时**。搜索将安全事件过滤为仅限 EventCode 4624（成功登录），然后按账户名称和登录类型对结果进行分组。从 DC02 返回了 15 个事件 — 全部是预期的系统和服务账户活动。在管理员会话之外没有出现交互式用户登录（登录类型 2 或 10），确认没有未授权访问。  ``` index=* sourcetype=WinEventLog:Security EventCode=4624 | stats count by Account_Name, Logon_Type | sort -count ``` | 登录类型 | 含义 | |---|---| | `2` | 交互式（用户在键盘前） | | `3` | 网络（文件共享/网络资源） | | `5` | 服务账户（自动化 — 预期的） | | `10` | 远程交互（RDP 会话） | ### 登录失败尝试（事件 ID 4625） 运行了以下搜索以识别身份验证失败尝试。在真实的调查中，当账户锁定警报触发时，这通常是首先运行的查询之一： ``` index=* sourcetype=WinEventLog:Security EventCode=4625 | stats count by Account_Name, Workstation_Name | sort -count ``` ### 账户锁定事件（事件 ID 4740） ``` index=* sourcetype=WinEventLog:Security EventCode=4740 | table _time, Account_Name, Caller_Computer_Name | sort -_time ``` ### 前 10 名登录失败用户名 — 威胁狩猎 ``` index=* sourcetype=WinEventLog:Security EventCode=4625 earliest=-24h | stats count as failures by Account_Name | sort -failures | head 10 ``` ### 非工作时间登录检测 ``` index=* sourcetype=WinEventLog:Security EventCode=4624 | eval hour=strftime(_time, "%H") | where hour < 7 OR hour > 19 | table _time, Account_Name, Workstation_Name, Logon_Type | sort -_time ``` ## 📊 仪表板 在 Splunk 中构建了一个 **Windows 安全监控仪表板**，以提供持久、一目了然的安全状况视图，而无需每次手动运行搜索。 **创建新仪表板对话框 — 选择了经典仪表板：** 在顶部 Splunk 导航栏中导航到 **仪表板**，然后点击 **创建新仪表板**。仪表板命名为 `Windows Security Monitoring Dashboard`，描述为"安全事件监控、登录跟踪和进程活动分析"。选择了 **经典仪表板** 而不是仪表板工作室，因为它使用更简单的基于 XML 的面板编辑器 — 更适合于注重设置速度而非视觉自定义的实验室环境。  **添加了"登录活动随时间变化"面板（折线图 — EventCode=4624 时间图表）：** 在仪表板编辑器中，点击了 **+ 添加面板 > 新建 > 折线图**。面板标题为"登录活动随时间变化"，并输入了 SPL 搜索 `index=* sourcetype=WinEventLog:Security EventCode=4624 | timechart count`。选择折线图是因为时间图输出是时间序列 — 折线格式使登录量趋势和异常峰值一目了然。  **添加了"非工作时间登录"面板（事件列表 — 非工作时间检测查询）：** 使用**新建 > 事件**添加了第二个面板。标题为"非工作时间登录"，使用了带有 `eval hour` 和 `where hour < 7 OR hour > 19` 的非工作时间检测 SPL，以过滤工作时间以外的登录。选择事件列表而不是图表，因为确切的账户名、时间戳和工作站是关键细节 — 图表会聚合并隐藏这种粒度。  **仪表板 — "过去 24 小时账户活动 24 小时顶级进程"面板：** 完成的仪表板显示了前两个面板填充了来自 DC02 的实时数据。**账户活动**条形图显示 DC02$、SYSTEM 和 SplunkForwarder 是顶级认证来源 — 全部是预期的服务账户。**顶级进程**事件列表显示来自 DC02 的最近安全事件，EventCode=4688（进程创建），由步骤 2 中配置的 Sysmon 遥测数据驱动。  **仪表板 — "登录活动随时间变化"和"非工作时间登录"面板：** 底部的两个面板显示了登录量随时间的变化以及非工作时间登录事件。**登录活动随时间变化**折线图显示在 5 月 16-17 日午夜左右出现活动峰值 — 对应于 Splunk 配置和转发器重启会话。**非工作时间登录**面板捕获了那些在上午 7 点至晚上 7 点窗口之外的相同会话作为 EventCode=4624 事件，证明检测逻辑正在正确工作。  | 面板标题 | SPL 基础 | 可视化 | |---|---|---| | 账户活动 — 过去 24 小时 | `EventCode=4624` + `stats count by Account_Name` | 条形图 | | 顶级进程 — 过去 24 小时 | `EventCode=4688` + `stats count by Creator_Process_Name` | 事件列表 | | 登录活动随时间变化 | `EventCode=4624` + `timechart count` | 折线图 | | 非工作时间登录 | 非工作时间查询 + `eval hour` 过滤 | 事件列表 | ## 🚨 自动化告警 配置了一个计划告警，以自动检测高权限登录次数 — 消除了手动检查仪表板的需要。 **保存为告警对话框 — 高权限登录次数，每 15 分钟计划一次：** 在搜索栏中运行并验证 EventCode=4672 检测查询后，点击了**保存为 > 告警**。告警配置如下：类型设置为 **计划**，Cron 表达式 `*/15 * * * *` 以每 15 分钟运行一次，时间范围为**过去 24 小时**，触发条件设置为**结果数量大于 0**。触发操作设置为**针对每个结果**，以便每个单独的高权限账户触发一个单独的告警条目，而不是一个合并的通知。  **检测查询结果 — 按账户和计算机统计的特权登录：** 在保存告警之前，在搜索栏中验证了底层 SPL 查询。查询返回了 22 个事件，显示了两个账户 — SYSTEM（21 个事件）和 SplunkForwarder（1 个事件）— 都在 DC02 上。这些是预期的高权限服务账户。在真实环境中，任何意外账户名出现在此结果中都表示潜在的特权升级，需要立即调查。  ``` index=* sourcetype=WinEventLog:Security EventCode=4672 | stats count as privilege_logons by Account_Name, ComputerName | where privilege_logons > 0 ``` **确认告警已激活 — "高权限登录次数"状态：已启用 ✅：** 导航到 **设置 > 搜索、报告和告警** 以验证告警已保存并处于活动状态。告警出现在列表中，类型为 **告警**，下次计划时间为 `2026-05-17 01:00:00 UTC`，状态为 **已启用**。这确认了 Splunk 将每 15 分钟自动运行一次检测查询，无需任何手动干预。  | 设置 | 值 | |---|---| | **名称** | `高权限登录次数` | | **告警类型** | 计划 | | **Cron 表达式** | `*/15 * * * *` (每 15 分钟) | | **时间范围** | 过去 24 小时 | | **触发条件** | 结果数量大于 `0` | | **触发** | 针对每个结果 | ## ✔️ 验证 **splunk-server VM — 状态：运行中，Standard D2s v3，Ubuntu 24.04：** 在 Azure 门户中导航到 `splunk-server` VM 概述，以确认 VM 处于"正在运行"状态。基本要素面板确认：操作系统是 Linux (Ubuntu 24.04)，大小是 Standard D2s v3，公共 IP 是 20.102.65.90，私有 IP 是 10.0.0.4，并且 VM 连接到 `kingsvm-vnet/default` 子网。所有值均与部署期间应用的配置匹配。  **网络设置 — 确认所有 NSG 规则（最终状态）：** 导航到 `splunk-server > 网络 > 网络设置` 以确认最终的 NSG 规则状态。可见六个入站规则：RDP (3389)、allow-splunk-web (8000) 和 allow-splunk-forwarder (9997) 是三条自定义规则，全部显示 **允许**。这三条规则的来源设置正确 — 确认没有端口意外地向公共互联网开放超出预期。  **kingsvm_group 资源组 — 完整的实验室基础设施（DC02 + splunk-server + VNet + NSG）：** 导航到 **资源组 > kingsvm_group** 以确认所有 10 个实验室资源均已成功部署并在一处可见：DC02 (VM)、DC02-ip（公共 IP）、dc02363 (NIC)、DC02 OS 磁盘、kingsvm-nsg (NSG)、kingsvm-vnet (VNet)、splunk-server (VM)、splunk-server-ip（公共 IP）、splunk-server31 (NIC) 和 splunk-server 磁盘。将所有资源组织在一个资源组中，可以在不再需要时干净利落地通过一次操作删除整个实验室。  **PowerShell 验证 — Test-NetConnection :8000 = True，SplunkForwarder 运行中，Sysmon 记录了 71,742 个事件：** 从 DC02 PowerShell 以管理员身份运行了三个最终检查： 1. `Test-NetConnection 10.0.0.4 -Port 8000` — 返回 `TcpTestSucceeded: True`，确认 DC02 可以通过 VNet 在端口 8000 上访问 Splunk Web 界面。 2. `Get-Service *splunk*` — 为 SplunkForwarder 服务返回 `Status: Running`，确认日志正在主动传输到 Splunk。 3. `Get-WinEvent -ListLog "Microsoft-Windows-Sysmon/Operational"` — 显示记录计数为 **71,742 个事件**，确认 Sysmon 正在 DC02 上主动记录端点遥测数据。  | 检查项 | 结果 | |---|---| | **数据流入 Splunk** | 从 DC02 索引了 40,642 个安全事件 ✅ | | **EventCode=4624 搜索** | 返回了 15 个成功登录事件 ✅ | | **仪表板已填充** | 所有面板均使用实时数据渲染 ✅ | | **告警已激活** | "高权限登录次数" — 状态：已启用 ✅ | | **端口 8000 可达** | `Test-NetConnection 10.0.0.4 -Port 8000` → TcpTestSucceeded: True ✅ | | **SplunkForwarder 服务** | 状态：运行中 ✅ | | **Sysmon 运行正常** | Microsoft-Windows-Sysmon/Operational 日志中有 71,742 个事件 ✅ | ## 📁 作品集证据 ### SPL 搜索历史 **Splunk 搜索历史 — 实验期间执行的所有检测查询：** 导航到 Splunk 主页 > **搜索历史** 选项卡，以捕获实验期间运行的所有 SPL 查询的完整记录。历史记录显示在过去 90 天内执行了 8 次搜索，涵盖：非工作时间登录检测、进程创建分析（EventCode=4688）、索引枚举、特权登录检测（EventCode=4672）、完整安全事件查询、成功登录分析（EventCode=4624）、Sysmon 运营查询以及初始数据确认搜索（EventCode=1）。这展示了跨多个检测用例的实践经验。  ### 安全仪表板 — 实时数据 **Windows 安全监控仪表板 — 包含真实 DC02 数据的账户活动和顶级进程面板：**  **Windows 安全监控仪表板 — 登录活动随时间变化和非工作时间登录：**  ### 每个面板演示的内容 **账户活动 — 过去 24 小时：** 显示哪些账户在 DC02 上产生了最多的认证事件。在真实的 SOC 环境中，此面板会立即突出显示任何行为异常的账户 — 例如，一个服务账户突然产生交互式登录，或者一个用户账户的事件量远高于基线。条形图格式使得一眼就能轻松发现异常值，无需运行手动搜索。 **顶级进程 — 过去 24 小时：** 由 Sysmon EventCode=4688（进程创建）驱动，此面板揭示了域控制器上正在生成哪些可执行文件。合法的 DC 运行着一套可预测的进程集 — 任何出现在此列表中的陌生二进制文件都值得立即调查。这种可见性正是将一个仪表完善的环境与一个盲飞环境区分开来的地方。 **登录活动随时间变化：** 折线图将认证量映射到时间上，使得识别正常工作时间之外的峰值变得简单明了。凌晨 2 点突然出现的登录量激增，是任何静态表格都无法清晰展现的模式。此面板将原始事件计数变成了一个故事。 **非工作时间登录：** 直接查询发生在上午 7 点至晚上 7 点之外的交互式和远程登录。服务账户在夜间登录是预期的，并会在上下文中被过滤掉 — 此面板寻找的是在异常时间出现的人类登录，在真实环境中这将触发一级分析师的立即调查。 ## 🧠 展示的技能 | 技能 | 真实世界应用 | |---|---| | **Splunk 部署与数据输入配置** | Universal Forwarder 是将日志输入 Splunk 的标准企业方法 | | **Sysmon 部署和配置** | 行业标准的主机遥测工具，广泛应用于企业 SOC 环境 | | **SPL 查询编写** | SOC 调查和威胁狩猎的核心分析技能 | | **安全仪表板构建** | 对登录失败、锁定和异常的持续可见性 | | **特权登录监控** | 监控事件 ID 4672 以发现特权升级模式 | | **自动化检测规则工程** | 所有基于 SIEM 的 SOC 运营的基础 | | **非工作时间异常检测** | 揭示工作时间之外的可疑访问 | ### 职业相关性 | 角色 | 应用 | |---|---| | **SOC 分析师 Tier 1** | 监控仪表板，搜索日志寻找可疑活动，上报发现 | | **SOC 分析师 Tier 2–3** | 构建检测规则，跨源关联事件，使用 SPL 进行威胁狩猎 | | **云安全工程师** | Microsoft Sentinel 和 AWS Security Hub 基于相同的 SIEM 概念运行 | | **事件响应人员** | 日志时间线重建，在活跃事件期间界定入侵范围 | ## 🔗 相关实验 | 实验 | 描述 | |---|---| | **实验 1** | Azure 中的 Active Directory + Windows Server — 为本 SIEM 提供日志源 | | **实验 2** | *（在此链接你的实验 2）* | | **实验 4** | *（在此链接你的下一个实验）* | ## 📚 参考文献 - [Splunk Enterprise 文档](https://docs.splunk.com/Documentation/Splunk) - [Splunk SPL 快速参考](https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/ListOfSearchCommands) - [Windows 安全事件 ID — Microsoft 文档](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor) - [Splunk Universal Forwarder 下载](https://www.splunk.com/en_us/download/universal-forwarder.html) - [Sysmon — Microsoft Sysinternals](https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon) - [CIS 基准 — Windows Server](https://www.cisecurity.org/benchmark/microsoft_windows_server)

标签：Active Directory, AI合规, Azure, Conpot, PB级数据处理, Plaso, SOC分析, SPL查询, Terraform 安全, URL发现, Windows安全, Windows日志, 免杀技术, 安全仪表板, 安全实验室, 安全工程, 安全检测, 安全运维, 暴力破解检测, 检测规则, 生产级技能, 红队行动, 网络资产发现, 自动化警报, 认证对齐, 零成本实验