企业官网建设流程全解析

1. 先从"日志到底是啥"说起：Windows取证的第一块基石

做应急响应这几年，我有个很深的感触——大部分新人接到Windows日志排查任务的时候，不是不会用工具，而是不知道"该找什么"。鼠标点开事件查看器，看到几百上千条日志，眼睛先花了，然后就开始一条条瞎翻，翻到半夜也没翻出个所以然。第二届Solar月赛的Windows日志排查题，考的就是这个：你有没有一套清晰的排查逻辑，能不能从零散的日志里把攻击者的行动轨迹拼出来。

先说一句大实话：Windows日志排查的本质，不是"看日志"，而是"做时间线"。攻击者进了机器，无论是弹shell、传webshell、加账号、开计划任务，还是拖数据，都会在系统里留下记录。日志排查要做的，就是把这些散落在各个角落的记录捞出来，按时间排序，还原出攻击者从踩点到收尾的完整路径。这件事做好了一个人就是一个蓝队小分队，做不好，就算装了再贵的EDR也白搭。

这场比赛里涉及的Windows日志，主要集中在五类：安全日志（Security）、系统日志（System）、应用程序日志（Application）、PowerShell操作日志、计划任务日志。其中安全日志是绝对核心，攻击者登录成功、登录失败、创建用户、修改权限、开启服务、远程桌面登录等等关键动作，全都记在里面。但光有安全日志不够——攻击者执行了哪条命令、webshell落地在哪个目录、计划任务注册了哪个脚本，这些信息需要从别的日志里去补。所以完整排查的第一步，是先搞清楚"日志都能告诉我什么"。

我自己的习惯，是用一个"三层漏斗"的思路来理解Windows日志体系：

• 系统层日志：记录系统服务、驱动、关机重启这些底层的运行状态。攻击者把机器搞蓝屏、停掉安全服务、篡改驱动的时候，会在这里留痕。
• 安全层日志：记录账户登录、权限变更、对象访问这些跟"谁干了什么"直接相关的行为。这是排查的绝对主场。
• 应用层日志：记录各软件自己的运行情况，包括PowerShell执行、IIS请求、第三方服务、甚至攻击者植入的后门程序的启动信息。

这三层对应到实际排查动作上，就是我常说的"先看安全日志锁定时间点和账户，再去系统和应用日志里追命令和工具"。顺序很重要，如果你一上来就在应用日志里翻，很容易被无关信息带偏。

还有一点要提前说清楚：真实业务场景里的日志体量，远比比赛题大得多。一台跑了几年的域控，安全日志可能几十万条，直接打开事件查看器去翻，翻到天荒地老也翻不完。所以正规的做法，是先想办法把日志批量导出成文本或CSV，再用命令行工具做筛选和统计。这次月赛题的体量还没到那么夸张，但这个"先导出、后筛选"的思路，是所有Windows日志排查的通用打法。

1.1 事件查看器之外的取证工具准备

很多教程一上来就教你点开eventvwr.msc，然后对着窗口一顿点。但实际上，有一定排查经验的人都懂——事件查看器这玩意儿，看单条日志还行，做批量分析效率太低。我平时做日志排查，常用的是下面这几个组合：

• wevtutil：Windows自带的命令行日志管理工具，可以导出指定时间段的日志、指定事件ID的日志。导出到XML或EVTX格式后，配合其他工具做二次处理。它的主要作用是"把日志搬回家"。
• Log Parser：微软官方出品的日志分析利器，用SQL语法直接查询EVTX文件，效率极高。比如一条命令就能统计出"今天有多少次4625登录失败事件"。这工具对新手略有点门槛，但值得花半小时学，回报率非常高。
• Event Log Explorer / FullEventLogView：第三方GUI工具，加载EVTX文件后可以快速筛选、排序、高亮。我在处理大批量日志时经常用FullEventLogView，一秒钟加载几十万条毫无压力，比系统自带的好用太多。
• PowerShell：尤其是Get-WinEvent，这是我最常用的"瑞士军刀"。它跟Log Parser比，胜在更灵活，可以结合管道做各种组合条件过滤，而且支持把结果直接输出成表格或者CSV。

比赛和实战中，我会先把目标机器的事件日志全部导出，然后Copy到自己的工作机上分析。这样做有两个好处：第一是不影响业务机器，避免你在上面操作时对系统产生新的干扰；第二是导出的EVTX文件可以反复分析，不用反复访问目标机。不过你如果是在比赛现场做，也可以直接Get-WinEvent连查带筛，效率也不低。

1.2 时间坐标轴：排查前必须确认的基准线

排查日志之前，建议先做一件事：确认目标机器的当前时间、时区、开机时间。

听起来很基础，但很多人会在这里栽跟头。Windows事件日志里的时间戳，默认是本地时间，如果机器的时区设置跟你的分析环境不一致，你拼出来的时间线可能整个偏移好几个小时。比如一台设置了UTC+8的服务器，你拿UTC时间来分析，所有事件都差了8小时，排查结果全乱。更麻烦的是，攻击者可能已经改过系统时间，用完再还原，这种情况在真实入侵中不少见。

我的习惯是先用systeminfo看一下系统开机时间，再用w32tm /query /status确认时间源是否正常，然后拿一条最近的登录事件（比如4624）跟实际情况做个交叉验证。这样就能确认日志时间戳是否可靠。

另外，日志里有两种时间概念要分清：事件生成时间（TimeCreated）和事件写入时间（TimeWritten）。在正常情况下，这俩时间基本一致，但某些延迟写入的场景下会出现偏差。别指望它完全分毫不差，但在分钟级这个粒度上来说，这个偏差可以忽略不计。排查时统一以TimeCreated为准，别混着用，免得自己在时间线上把自己绕晕。

提示：如果目标机器设置了时间同步NTP服务器，而攻击者又改过本地时间导致偏差很大时，请以域控或NTP服务器上的时间记录为准。比赛里一般不会出这么变态的干扰项，但真实场景中一旦出现，这是一个很容易被忽略的"隐形坑"。

2. 安全日志的主战场：账户登录与身份认证的攻防痕迹

Windows安全日志里，跟账号登录相关的事件ID是最核心的，也是这次Solar月赛排查题的主要得分点。攻击者的绝大多数行为，都要落到"某个账户登录了某台机器"这个动作上。你把这些登录事件理清楚了，攻击路径也就清楚了一半。

2.1 4625登录失败：暴破行为的时间特征

事件ID4625代表"账户登录失败"。单条4625说明不了什么问题——你自己输错密码也会产生4625。但在短时间内，从同一来源IP发起的大量4625，就是典型的暴力破解特征。

排查时我会做两件事：

第一，统计4625事件的总数和时间分布。用PowerShell一句话就能拉出来：

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625} | Group-Object {$_.TimeCreated.ToString('yyyy-MM-dd HH:mm')} | Sort-Object Count -Descending | Select-Object -First 20

这样能看到哪一分钟的登录失败次数异常高，基本就圈定了暴破高峰期。

第二，提取4625事件里的关键字段——登录账户名、来源IP、登录类型、失败原因。注意看失败子状态码：

• 0xC0000064：用户名不存在，这是攻击者在扫有效账号
• 0xC000006A：密码错误，说明用户名正确，攻击者已经踩到有效账户了
• 0xC0000234：账户被锁定，说明锁定策略已经触发

比赛中常考的考点是：攻击者暴力破解了哪个账号、从哪个IP来的、持续了多久。数据全在4625日志里，关键是你要会聚合成"攻击画像"，而不是只汇报"存在大量登录失败"。

2.2 4624登录成功：分清正常登录与可疑登录

事件ID4624代表登录成功。这是排查里信息量最大的日志条目，但也是最容易被误判的。每条4624都会记录登录类型（Logon Type），这个字段直接告诉你攻击者是用什么方式进来的。我列出最常见的几种：

比赛里出现最多的可疑登录类型是10（RDP）和8（Web明文）。前者对应攻击者远程进机器操作，后者对应webshell利用或IIS被攻破后执行命令。看到登录类型10，下一步就去关联4625的记录；看到类型8，就要警觉是不是Web层面出了问题。

另外，4624里还有两个字段要重点关注：源IP（Source Address）和登录账户（Account Name）。如果有个平常不登录的账户（比如Guest、或者攻击者在后渗透阶段新建的账户）突然产生了登录类型2或10的记录，这就是妥妥的入侵信号。

比赛里有个常见的坑：攻击者复用了一个本来就存在的低权限账号来做RDP登录。这种"合法账户非法使用"的情况，光看单条日志很难发现问题，需要结合"登录时间是否在深夜""来源IP是否外网""登录后紧接着是否有敏感操作"这些综合特征去判断。这也是为什么我一直强调——不要只看登录日志本身，要跟后面的进程、命令日志串起来看。

2.3 用户账户打点：新增、禁用、改密、加入管理员组

除了登录行为，安全日志还会记录账户本身的变更。这几个事件ID必须烂熟于心：

• 4720：创建了新用户。攻击者在拿下机器后，为了维持权限，经常创建一个隐蔽的新账号。
• 4732 / 4728 / 4756：把用户加入了本地管理员组/域管理员组/内置管理员组。
• 4724：尝试重置密码。
• 4722：用户账户被启用。
• 4738：用户账户属性被修改。

实战里我见过太多次了——攻击者创建一个叫"support"或者"backupadmin"之类的账号，然后加进管理员组，再用这个账号做RDP登录。整个过程在安全日志里就是一条清晰的链路：先4720，再4732，再4624。三步下来，铁证如山。

排查时，可以用这条命令把账户变更相关的事件一网打尽：

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4720,4732,4728,4756,4724,4722,4738} | Select-Object TimeCreated, Id, @{n='Account';e={$_.Properties[0].Value}}, @{n='Operator';e={$_.Properties[3].Value}} | Format-Table -AutoSize

特别注意一下，是谁（Operator）创建了这个账户。如果操作者也是个异常账户，那基本可以确认是同一伙攻击者的连环操作。比赛做题时，顺着这条线往下挖，攻击链路很快就浮出来了。

2.4 RDP登录成功之后的"连锁痕迹"

远程桌面（RDP）是攻击者最喜欢用的横向移动和持久化手段之一，这次月赛题里也给了相关的考点。跟RDP相关的要关注的不仅是4624类型10，还有4778（RDP重连）和4779（RDP断开）。这三个事件在攻击时间线里能画出一个完整的远程操作窗口。

在RDP会话期间，攻击者在机器上的所有命令执行、文件访问、服务启动，都会在安全日志（4688）和系统日志里留下痕迹。我的排查套路是：先锁定一个可疑的RDP会话时间段，然后把该时间段内所有其他日志全部过滤出来，通过时间戳的巧合度来判断哪些操作是攻击者干出来的。

还有一个隐蔽的追踪技巧：Windows会在RDP连接成功时记录客户端的名称（Client Name）和IP，在4624日志的详细字段里能看到。有时候攻击者用的是内网跳板机，你顺藤摸瓜就能找到内网里的另一台失陷机器。比赛里如果给了内网环境，这就是"从单机排查扩展到域内排查"的关键突破口。

3. 进程与计划任务：攻击者留下"活口"的地方

很多新人做日志排查，做完了登录账户这块就以为大功告成。但实际上，登录成功只是攻击的第一环，攻击者在机器里跑了什么、留了什么东西，才是处置阶段最需要知道的。

3.1 4688进程创建日志：相当于"抓拍"了每条命令

如果系统开启了审核进程创建策略（或者通过GPO开启了命令行包含），安全日志里会产生事件ID4688，记录每一次进程的创建，包括进程名、路径、命令行参数。这就相当于Windows给攻击者的每条命令都拍了一张高清照片。

排查4688时，我最关注这几个特征：

• PowerShell.exe、cmd.exe、wscript.exe、cscript.exe、mshta.exe 的异常出现。这些是攻击者最常用来执行命令的宿主程序。
• 命令行里出现下载、编码、混淆的关键词，比如certutil -urlcache、IEX、powershell -enc、base64这一类的。
• 从临时目录或可疑路径启动的进程，比如从C:\Users\Public、C:\Windows\Temp、C:\ProgramData下运行的exe。

这里要单独说一下PowerShell的排查。攻击者非常喜欢用PowerShell做无文件攻击，因为它可以直接内存执行，不落地exe。你可以用下面这条命令，检查PowerShell的脚本块日志（ScriptBlock Logging）：

Get-WinEvent -LogName 'Microsoft-Windows-PowerShell/Operational' | Where-Object {$_.Id -eq 4104} | Select-Object TimeCreated, Message

事件ID4104是PowerShell脚本块日志，能把攻击者执行的PS代码原文记录下来。真实案例中，很多webshell和COBALT STRIKE的加载器，最后都是从4104日志里抄出来的。这次月赛里，如果你发现某条4624登录之后紧跟着出现一堆4104，那基本就是攻击者在跑payload。

3.2 计划任务的隐藏后门：藏在%SystemRoot%\System32\Tasks里的'棋子'

攻击者建立持久化，最经典的手段之一就是计划任务。安全日志里对应的事件ID是4698（创建了计划任务）和106（计划任务已注册，位于Microsoft-Windows-TaskScheduler/Operational日志）。但这里有个大坑——如果攻击者直接用命令创建计划任务并且删除了安全日志，你靠事件日志是看不出来的。

那怎么办？直接看文件系统。

计划任务的实体定义文件存在C:\Windows\System32\Tasks\目录下，每个任务一个XML格式的文件。比赛或者实战中，我拿到机器后一定会去这个目录翻一圈，重点看：

• 最近修改时间异常的XML文件（攻击者刚创建的）
• 任务指向的路径是否在Temp、Public、ProgramData这些敏感目录
• 任务内容里的命令行是否包含下载执行、PowerShell编码等特征

另外，用schtasks /query /fo LIST /v这个命令也能列出所有计划任务的详细信息。我平时是"命令行查询+直接翻目录"双管齐下：命令行看运行状态，目录里看文件内容。

还有一个容易被忽略的持久化位置是启动项。检查HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run和HKEY_LOCAL_MACHINE\...\Run这些注册表键值，用reg query或者Autoruns工具都能快速扫出来。攻击者把后门程序放在启动项里，重启就能再次上线，这个套路在实战里极其常见。

注意：计划任务和启动项的排查，本质是"文件/注册表取证"逻辑，跟纯日志分析不太一样。但在完整应急响应中，它们必须跟事件日志的结论互相印证，否则你没法判断某个账号的嫌疑行为是否真的落地了。

3.3 服务与驱动：系统日志里的"常规操作"也可能是异常操作

系统日志（System）里还有一个值得关注的事件ID——7045（安装了一个服务）。攻击者用sc create或者Metasploit的persistence模块装后门服务时，系统会记下服务的名称和可执行文件路径。这是排查服务型后门时最直接的证据。

同一时期，Windows安全日志里往往还会伴随着4697（服务安装尝试）的记录。这两条可以交叉验证。比赛里如果出现了"某服务路径指向C:\Users\Public\下某个exe"这种组合，基本可以直接判定为后门服务。

我见过不少新人在这里栽跟头，原因是他们在系统日志里翻半天，翻出大量正常的服务安装记录（比如杀软更新、系统组件升级），然后就拿不准哪个是恶意的。我的判断标准只有一个：路径是否异常。正常服务都是从C:\Windows\System32或C:\Program Files下启动的，一旦看到服务文件放在Temp、Public、AppData这些目录，先标红再说，不用纠结。

4. 事件ID速查表：Windows日志排查的"九阴真经"

做Windows日志排查，到最后拼的就是对事件ID的熟练度。我记得自己刚开始学的时候，是拿着一个Excel表边查边做的，效率极低。为了这次Solar月赛，我把平时最常用的事件ID整理成了一张速查表，你们可以直接存下来当手册用。

这张表我建议你们打印出来或者放在手边，做题的时候不用再一个个去翻文档。但我必须强调一句——知道事件ID只是第一步，关键是要会"组合判断"。比如：

• 4625（暴破）+ 4624（成功）= 暴破成功了，赶紧看成功登录的IP和后继操作。
• 4720（建用户）+ 4732（加入管理员组）+ 4624（登录成功）= 攻击者建了个管理员账号并已使用，这是完整的高权限渗透链路。
• 4688（创建进程）+ 4104（PS脚本块）= 攻击者执行了具体的命令，直接提取payload内容。
• 1102（日志清除）+ 7045（安装服务）= 高级攻击者痕迹，先怀疑它是惯犯。

比赛做题也好，真实应急也好，不要孤立地看单条日志，一定要学会把多个事件ID串成一个"故事"。这也是资深蓝队和新人最大的区别所在。

4.1 日志清除事件：攻击者的"遮羞布"反而成了铁证

单独把1102拎出来说，因为这是比赛里一个特别容易忽略的送分点。攻击者为了掩盖痕迹，往往会用wevtutil cl Security或者Clear-EventLog清掉安全日志，然后系统就会生成一条ID 1102的日志——"安全日志已被清除"。

印第安纳琼斯一句话：你越是掩盖，越证明你有问题。所以看到1102时，不要觉得"完了日志没了"，恰恰相反，你应该在记录里高亮"日志清除事件"，然后：

1. 记录清除时间（攻击者离开的大致时间点）。
2. 检查清除时间之前系统的其他日志（System、Application、PowerShell）都留下了什么。
3. 特别关注清除时间附近是否还有残余的4624、4688等事件，这些往往是攻击者"没清干净"或者"忘清理"的部分。
4. 去查看C:\Windows\System32\winevt\Logs目录下EVTX文件的最后写入时间。即使被清了，文件系统层面也会留下时间痕迹。

比赛里有些选手一看到"日志被清"就直接放弃了，结果丢了一大堆分。实际上，日志清除这个行为本身就是最好的攻击指示器。在真实应急响应里，光凭这一条就能把"误报"和"真被打了"区分开一大半。

4.2 事件查看器与文件系统痕迹的交叉验证

前面说了很多"看日志"，现在补一个"看文件系统"的维度。日志排查做到后面，一定要跟文件系统的时间戳结合起来看，两者互为验证。重点检查这几个目录：

• C:\Users\Public—— 攻击者特别喜欢临时落脚的地方，因为Everyone可写。
• C:\Windows\Temp—— 攻击者解压工具、释放payload的高频目录。
• C:\ProgramData—— 常被用来藏后门程序。
• C:\Users\<用户>\AppData\Local\Temp—— 用户级临时目录，也容易被利用。
• C:\inetpub\wwwroot—— 如果机器是Web服务器，这里是webshell的高发地。

去看这些目录里有没有比系统安装时间还新的exe、ps1、dll、jpg（伪装图片的马）、zip（打包好的工具）等文件，然后记录文件创建时间、修改时间、访问时间。这些时间戳会在你的时间线还原里起到关键作用，尤其是当日志被人为删除的时候，文件时间戳几乎成了唯一的时间锚点。

5. 还原攻击时间线：让日志"开口说话"

以上全部是"信息收集"，但应急响应真正出活儿的阶段，是把收集到的碎片拼成一条完整的攻击链。比赛里的最后一问，往往就是"描述攻击者的入侵路径"。如果你手里有几百条日志、几十个可疑事件，却理不清顺序，那你前面做的功课基本等于白费。

5.1 从"零散事件"到"攻击故事"的归纳逻辑

我自己的还原逻辑，是按"踩点 → 突破 → 提权 → 持久化 → 痕迹清理 → 后续收尾"这条主线走的：

1. 踩点与突破：看4625暴破记录、Web访问日志（IIS）、RDP登录记录。找出攻击者是从哪个口子进来的。
2. 有效账户获取：看4624成功登录记录。确认攻击者用了哪个账号、什么登录类型。
3. 提权与横向：看4720建号、4732加组、4672特权分配。
4. 命令执行与落地：看4688、4104、7045。确认攻击者跑了什么命令、装了什么服务。
5. 持久化：看4698、106计划任务、注册表Run键、服务项。
6. 痕迹清理：看1102日志清除、文件删除行为、工具清理。
7. 数据外泄：看共享访问、4688里的压缩命令、网络连接日志等。

串完主线后，再回头把每条日志的精确时间填进去。比如："14:32:05，攻击者从IP 203.0.113.5发起暴破；14:47:18，4625暴破出现首次成功；14:47:20，攻击者利用该账号RDP登录（4624，类型10）；14:49:33，创建后门用户'helpdesk'（4720）；14:50:11，将用户加入Administrators组（4732）；14:52:44，执行PowerShell下载payload（4104）；15:03:17，注册计划任务做持久化（4698）；15:15:02，清除安全日志（1102）。"

这么一列，攻击者的所有行为一目了然，处置建议也就自然而然地出来了：封禁IP、删除账号、删除计划任务、查杀后门、核查数据外泄范围、修改所有相关账户密码。比赛的问答题部分，这么写基本就是满分模板。

5.2 时间线还原的常见误区与比赛"陷阱"

时间线还原有个最常见的误区：只盯着安全日志，忽略了其他日志。我见过很多考生写出"攻击者通过RDP登录后执行了PowerShell"，结果问他"凭什么判断是PowerShell"，他答不上来——因为他其实只是猜的。要让结论站得住脚，你必须从4104里直接贴出攻击者执行的命令原文，或者从4688里找到powershell.exe的创建记录。每一条结论，都要对应一条具体的日志证据。

比赛里还有一个比较"阴间"的干扰项：攻击者使用了合法账户的合法操作。比如用管理员账号RDP登录，然后用命令行做了一些看起来正常的操作。这种情况下，日志本身没有任何恶意特征。你要判断它是否是攻击行为，只能靠"时间是否异常（半夜）、来源IP是否异常（外网）、登录后行为是否与业务相关"这些侧写信息。这种题目其实是考你"异常发现"的能力——判断一个账户是不是失陷，不能只看"它有没有做坏事"，而是看"它做事的上下文是否可疑"。

另外一个比赛陷阱是日志时间跳跃。有的题目会故意让攻击者修改系统时间，造成日志时间顺序错乱。遇到这种情况，我的处理方式是：以每条日志的原始时间戳（Raw TimeCreated）为准去重建顺序，同时结合目标机器的事件序列号（RecordNumber）来辅助判断。事件序列号的递增顺序是逻辑顺序，不受系统时间篡改影响。如果你发现某个时段内时间戳混乱但序列号递增正常，那就要高度怀疑时间篡改了。

5.3 实战演练：拿一个小型入侵案例练手

为了给你们直观感受，我模拟一个比赛常考的小型案例，你们可以做练习验证自己的流程：

已知线索：一台Windows Server 2016，安装了IIS和MSSQL。安全日志存在11:00-11:30之间的"分钟级"密集4625事件，来源IP全部为192.168.110.66。之后出现一次4624类型8的登录成功，账户是sa。紧接着在C:\inetpub\wwwroot\下出现一个新文件help.aspx。11:35左右，安全日志出现4720和4732事件，新建用户sqlsupport被加入Administrators组。11:40，出现4104事件，PowerShell执行了一段下载命令。

推理链：

1. sa账号的暴破与成功登录，指向MSSQL的弱口令攻击。类型8说明是Web/网络层面的登录，配合aspx新文件，判断攻击者利用了MSSQL提权（xp_cmdshell等）写入webshell。
2. help.aspx是webshell，攻击者通过它执行系统命令。
3. 4720+4732说明攻击者在成功getshell后建立了后门账号。
4. 4104里的下载命令，可能是攻击者在下发第二阶段的工具或C2 payload。

处置动作：删除help.aspx、删除sqlsupport用户、修复MSSQL弱口令、封禁来源IP、清点该时间段内其他文件变更。

这个小案例其实是把多个考点串在一个场景里。你们拿到月赛真题后，可以按这个思路一步步推，基本不会跑偏。

6. 交卷与收尾的细节：找到线索之后，别在"提交动作"上白丢分

很多教程写到"还原出攻击链路"就结束了，但实操中还有最后一步——怎么把发现整理成一份合格的应急响应报告。比赛打分也好，真实工作汇报也好，报告本身的质量直接影响最终评价。

6.1 输出报告的核心结构：结论前置、证据后附

应急响应报告的写法跟技术博客完全不同，核心原则是"结论前置、证据后附"。评委或者领导打开你的报告时，要先看到结果，而不是先看你分析了一个小时的心路历程。我的习惯模板是这样的：

• 概述：机器IP、时间窗口、确认的入侵路径一句话概括。
• 入侵时间线：按时间排序列出关键事件，每条都要带事件ID和日志来源。
• 攻击行为明细：暴破来源、成功登录、新账号、持久化手段、执行命令的原文，全部贴出。
• 影响评估：哪些账户受影响、哪些数据可能被访问、后门范围多大。
• 处置建议：按紧急程度排序，从封IP、删账号、杀文件，到改密码、补漏洞、加固策略。

写报告时有一个硬性要求：每条结论必须带上证据。比如你说"存在暴破"，就要附上4625事件的数量统计、时间分布、来源IP；你说"攻击者利用MSSQL提权"，就要贴出对应的登录类型8的4624日志、以及xp_cmdshell相关行为在4688/4104里的记录。证据链闭环，报告才站得住脚。

6.2 容易被扣分的四个细节

根据我这几年当评委和做实战评审的经验，有四件小事经常被忽略，但恰恰是会扣分的点：

第一，没有区分"必然安全"和"真正可疑"。很多选手把所有4624、所有RDP登录全部列为"可疑"，结果报告里全是无关信息。评委一看就知道你没理解日志，分数自然不高。正确做法是结合上下文挑出真正异常的，其余的正常事件不要写进"可疑"清单。

第二，忽视了日志清除痕迹。前面说过，1102是攻击者活动的强信号，扫日志时先看一眼有没有它。如果被清了，你至少要在报告里提一句"安全日志于某时间被清除"，这本身就是一个重要发现。

第三，遗漏了"脏数据"和干扰项。比赛中经常混入一些正常用户的操作记录，比如正常运维人员也在同一时间远程登录过。如果不加区分，全部算到攻击者头上，时间线就乱了。处理办法是：先把正常运维时段、正常部署时段的日志排除掉，再对剩下的日志做深入分析。

第四，没有留下可复现的筛选命令。我的报告末尾一般会附上我用过的PowerShell筛选命令，这样其他同事可以重复我的分析步骤，也算是对自己工作的一个留痕。比赛里附上这个，也能证明你的每一步结论都是可追溯的，而不是"感觉是这样"。

6.3 我的几点个人经验收尾

啰嗦了这么多，最后说几句掏心窝子的话。Windows日志排查这件事，看起来是技术活，其实更像是"侦探活"——技术上无非是那几个事件ID、那几个筛选命令，真正拉开差距的，是你的思路清不清晰、能不能把碎片拼成图。

我自己的体会是：排查时先快速扫一遍全局，再深入钻细节。全局扫描的作用是建立"这机器到底发生了什么"的整体认知，避免一上来就陷进某条日志里出不来。比如我先用10分钟分组统计所有4624、4625、1102、7045、4720、4698、4104，看看有没有"异常聚集"，有聚集的地方永远是重点中的重点；然后再对异常聚集点逐条精读。这套打法我在比赛和实战里都很稳。

最后分享一个小技巧：做日志分析时，我会把暂时判定为"高可疑"的事件信息直接复制进一个Excel表，按时间排好。随着排查深入，这张表会越来越接近最终的攻击时间线。做完哈希、截图、留存——这既是比赛答题的依据，也是真实应急响应里后续溯源和追责的核心材料。祝你们月赛顺利，争取把每个坑都踩明白、把每分都拿到手。