搞Windows运维和安全的同学几乎都绕不开SMB和RDP这两个协议SMB共享是内网文件访问的主力通道RDP远程桌面是日常管理服务器的保命手段。但反过来说这俩也正是暴力破解和横向移动最常盯上的目标。Windows安全日志里头SMB登录和RDP登录最终都会留下4624登录成功、4625登录失败这类事件日志溯源说白了就是把这些零散记录按时间线串起来搞清楚是谁、从哪个IP、在什么时间、用什么账号、干了什么。这篇文章我想把Windows SMB/RDP日志溯源的完整套路系统总结一遍。内容偏向实战适合手里管着Windows服务器、需要做安全排查或应急响应的运维、安全工程师也适合刚入门的小白照着操作。文章不会只堆事件ID还会把每一步的原理和踩过的坑都讲清楚。1. 溯源前的基础准备先搞清日志在哪怎么确保它一直在记1.1 安全日志的位置与审计策略检查Windows的日志文件默认存放在C:\Windows\System32\winevt\Logs目录下后缀是.evtx平时用得最多的事件查看器运行eventvwr.msc就是从这个目录读数据的。做日志溯源最核心的是“Windows日志-安全Security”这一项它记录了账号登录、权限变更、对象访问等安全相关事件。SMB和RDP的登录最终都会在这里产生4624或4625。我接手过的不少服务器第一反应都是直接去翻安全日志结果发现里面什么都没有或者只有零星几条。原因基本都一样这台机器的审计策略根本没开。默认情况下Windows Server会记录一部分登录事件但很多桌面版系统、精简版系统默认不记录详细登录审计安全日志干净得让人心虚。检查方法很快运行里输入secpol.msc打开本地安全策略进入“安全设置-本地策略-审核策略”重点确认“审核登录事件”和“审核帐户登录事件”这两项成功和失败最好都勾上。Windows 2008之后系统还提供了高级审核策略路径在“安全设置-高级审核策略配置”界面复杂一点但粒度更细可以精确到“登录/注销-审核登录”、“对象访问-审核详细文件共享”这些子类别。生产环境我建议直接用高级审核策略配合下来能覆盖SMB共享访问审计和RDP登录审计的完整需求。还有一个命令行工具auditpol适合批量检查或配置多台机器。比如查看当前审核策略auditpol /get /category:*批量开启登录审核可以这样auditpol /set /subcategory:登录 /success:enable /failure:enable具体子类别名称在不同语言版本系统里略有差异建议先/get看一眼实际名称再下发。注意域环境下组策略可能覆盖本地策略如果是域内服务器记得在组策略管理里确认默认域策略或对应OU策略的审核设置不然本地改了也是一场空。1.2 日志大小、保留策略与清理告警安全日志默认大小一般是128MB对登录频繁的服务器几天就可能写满。满了之后如果策略是“覆盖早于X天的事件”最老的日志会被覆盖真到了溯源的时候正好缺了攻击发生那几天的数据。这种坑我踩过不止一次后来凡是重要服务器我都会把安全日志最大大小调到1GB以上策略选“按需覆盖事件”这样既能保证写满后不停止审计又能尽可能保留更长的历史。也有运维为了留住日志选“不覆盖事件手动清理”这个选择要慎重。一旦日志写满系统会直接停止记录新事件审计当场失效比覆盖更麻烦。如果确实需要长期留存正确做法是把日志转发或者定期导出归档而不是靠单机硬扛。日志被清空本身就是一个极其重要的告警信号。安全事件ID 1102表示“审计日志已清除”当一台机器在某个时间点出现1102、后面日志戛然而止绝大多数情况是攻击者在清理痕迹少部分是管理员误操作。遇到1102第一反应应该是把主机隔离然后立刻对系统盘做只读镜像取证。记住一个原则攻击者为什么要清日志因为他知道自己在日志里留下了大量痕迹。所以1102出现的那一刻这台机器基本可以判定已经失陷。2. SMB日志溯源用事件ID把暴力破解和异常共享访问挖出来2.1 看SMB登录先盯这几张事件ID表SMB共享访问的认证最终走的还是Windows登录体系所以查SMB暴力破解要看的核心事件就集中在下面这几个事件ID含义溯源价值4624账号登录成功确认攻击是否得手记录账号、源IP、登录ID4625账号登录失败爆破主证据记录失败原因状态码、源IP、源端口4776域控制器尝试验证账号凭据域环境下判断密码爆破是否命中记录源IP和账号5140网络共享对象被访问判断攻击者登录后访问了哪些共享5145网络共享对象被检查是否可访问详细文件共享精确到共享下的文件路径前提是开启详细文件共享审核4625是查爆破最先要捞的数据。里面有个状态码字段能直接告诉你失败原因0xC000006A表示密码错误0xC0000064表示用户名不存在0xC0000234表示账号被锁定0xC0000072表示账号已禁用。看到大量0xC0000064的时候要格外警惕这说明攻击者正在探测有效账号比单纯爆破已知账号更危险。SMB并不局限于文件共享它也是很多漏洞利用的入口。如果日志里出现大量4656对象句柄请求或5145指向异常路径的访问同时系统日志里出现SMB相关的异常报错就要考虑是不是漏洞利用尝试得把网络层抓包和安全设备告警联动起来看。2.2 用PowerShell快速聚合统计来源IP直接在事件查看器里按4625过滤然后一条条翻这在几十条记录时还行但遇到暴力破解就是几万条翻到吐血也看不出规律。正确做法是先做聚合统计把4625按来源IP分组统计每个IP在时间窗口内的失败次数。下面这个PowerShell脚本可以直接改参数跑$start Get-Date 2025-01-01 00:00:00 $end Get-Date 2025-01-31 23:59:59 Get-WinEvent -FilterHashtable {LogNameSecurity; Id4625; StartTime$start; EndTime$end} | Group-Object {e{$_.Properties[18].Value}} | Sort-Object Count -Descending | Select-Object -First 20 Count, Name这里有个非常关键的坑4625事件Properties数组里索引18在不同Windows版本下不一定都是源IP。Windows Server 2012 R2、2016、2019、2022之间我实测过存在偏移某些系统打了补丁后字段顺序也会变。所以写脚本之前一定要先挑一条4625事件把Properties整个打印出来逐个对照确认哪一个是IP、哪一个是端口再批量执行。否则统计出来可能根本不是你想要的字段。聚合完成之后筛选标准我一般这样定同一源IP在5分钟内失败次数超过10次或一天内超过50次直接列入重点排查对象。当然这个阈值要根据业务场景调整有些自动化系统跑批本来就会频繁输错密码要结合业务知识判断不能一刀切。2.3 别忘了5140和5145共享本体也留痕很多管理员只知道看登录事件忽略了共享访问的事件这是SMB溯源里比较可惜的一个盲区。5140表示网络共享对象被访问能记录谁在什么时间访问了哪个共享5145更进一步可以精确到共享里的文件路径和访问权限级别。但这里有个前提5145默认是不记录的。需要在高级审核策略里打开“对象访问-审核详细文件共享”并且对共享文件夹本身配置成功/失败的审核ACE。很多公司以为开了审核策略就能查文件访问历史结果事后发现5145一条没有大概率就是没配置共享文件夹的ACE审计或者没有勾选详细文件共享子类别。对文件服务器来说5145的价值很高。攻击者爆破成功后通常会先看共享目录里有什么好东西再挑着下载。通过5145能还原出他到底动了哪些文件这在数据泄露评估里非常关键。我处理过的一起事件攻击者登录后访问了十几个共享最终锁定他真正下载的敏感文件靠的就是5145的事件记录。2.4 从SMB漏洞利用到后渗透的扩展排查SMB日志溯源不能只盯着登录失败。像漏洞利用类攻击往往不会产生大量4625因为攻击者直接走漏洞通道或者已经拿到了合法账号。这时候要把排查范围从安全日志扩展到系统日志和应用日志比如SMBv1相关异常事件3019、3036等还有网络层的行为特征。更常见的情况是攻击者爆破一个账号成功后会紧接着用这个账号做进一步操作。所以登录成功事件4624才是整个链条的核心。找到那条来自爆破IP的4624之后顺着Logon ID和时间往后翻看后面有没有4720创建新用户、4732将成员添加到安全组、4724尝试重置密码这类后渗透操作。一旦发现这些事件在同一时间窗口内出现基本可以确认不是误报而是完整的入侵链条。3. RDP日志溯源从登录类型和会话事件还原每一次远程登录3.1 登录类型是第一把尺子RDP登录在安全日志里也是4624和4625想要快速区分它和其他登录方式就要看“登录类型”Logon Type字段。常用值如下Logon Type含义典型场景2本地交互登录直接在本机键盘鼠标操作3网络登录SMB共享访问、net use等4批处理登录计划任务运行5服务登录Windows服务启动10远程交互登录RDP远程桌面看到4624或4625先看Logon Type如果是10基本确定是RDP登录。有些运维疑惑为什么某些内网管理软件登录后显示类型3而不是10那是因为它走的不是标准RDP协议或者中间有跳板机转发这种事要结合源IP和会话记录判断别一看到类型3就下结论说不是远程操作。筛选RDP登录成功的命令其实很简单在事件查看器过滤4624后再看Logon Type列。不过事件查看器默认列表里没有这个字段需要自己添加“登录类型”列或者直接用PowerShell导出更省事下面第4章会给详细脚本。3.2 RDP会话生命周期与三件套除了登录成功失败RDP会话还有几个专属事件串起来能还原完整的会话生命周期4778会话重新连接到窗口站也就是重连4779会话断开连接但注意断开不等于注销会话可能还挂在后台判断一次RDP攻击是否真正得手至少要找到三个事件对应的4624成功登录、后续的4779断开、以及可选的4778重连。这三个事件能拼出攻击者建立会话、操作机器、离开的基本时间线。如果只看到大量4625没有对应的4624那大概率是爆破没有成果攻击者连门都没进去。这里有个实战经验RDP的4624成功事件里有个“已登录进程”字段正常管理员远程管理时进程通常是explorer.exe或rdpclip.exe如果登录后立刻出现非常规进程名或者紧接着有进程创建事件4688前提是开启审核进程创建就要怀疑是不是被植入了后门或执行了恶意程序。3.3 RDP连不上的排查路径服务、端口、注册表说完了日志再说说和RDP日志配套的一个高频故障。很多人查RDP暴力破解前先遇到的往往是“远程桌面连不上”比如rdp not listening、或者rdp wrapper not supported这类提示。RDP连不上我的固定排查顺序是三件事服务、端口、注册表。服务看Remote Desktop ServicesTermService是否在运行启动类型是否为自动。端口执行netstat -ano | findstr 3389确认处于LISTENING状态。注册表检查HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server下的fDenyTSConnections值为0表示允许远程桌面值为1表示拒绝。这三项正常之后再看防火墙入站规则是否放行3389以及系统属性-远程里是否勾选了“允许远程连接到此计算机”。很多时候服务器明明开了RDP但连接还是超时问题就出在防火墙默认拦截上跟服务本身一点关系都没有。至于rdp wrapper not supported这类提示这里多说一句。RDP Wrapper这类工具需要在系统版本匹配的前提下替换或Hook termsrv.dllWindows一更新就容易失效报not supported太正常了。如果你只是为了运维管理需要多用户并发会话最稳妥的路径是走Windows Server的远程桌面服务角色或者在管理场景下用mstsc /admin开管理会话不建议依赖第三方工具去改系统核心文件。我见过不止一次因为强上wrapper导致远程服务彻底起不来、最后只能跑机房物理操作的案例代价太大。3.4 成功登录后的提权痕迹攻击者RDP登录成功后如果要做提权安全日志会留下4672为新登录分配特殊权限。虽然管理员正常登录也会产生4672但这个事件配合4624一起看很有价值。我通常这样过滤筛选4624且Logon Type为10再关联同一时间戳附近的4672账号是Administrator或者某个特权账号来源IP又是之前爆破时的异常IP这时候可以基本判定这是攻击者的成功登录。加上前面说的4720、4732这些账号操作事件整个RDP攻击链就完整了。再看细一点Windows的TerminalServices日志通道里还有1149事件专门记录“用户身份验证成功”属于RDP层面的认证日志比安全日志更贴近远程桌面本身。如果安全日志被清但TerminalServices日志还残留一部分这两边交叉比对往往能补回不少线索。4. 日志关联分析与自动化把零散事件拼成攻击时间线4.1 手工时间线怎么建日志溯源最忌讳的就是逮着一条日志死磕。正确的思路是先建时间线把相关事件按时间排序再连点成线。我的做法是先导出一张总表列包含时间、事件ID、账号、源IP、登录类型、状态码、Logon ID、目标机器、备注。有了这张表按时间一排序攻击路径就自然浮现了。一个典型的完整入侵链条通常是这样的某天凌晨开始大量4625集中出现来源IP分布在几个固定地址账号是Administrator和常见用户名状态码多为0xC000006A或0xC0000064。排查中突然出现一条4624成功Logon Type为10来源IP正好在之前的爆破IP列表里账号是Administrator。紧接着几分钟内出现4720创建新用户、4732将新用户加入Administrators组、4724重置密码。新账号随后通过SMB进行网络登录类型3访问共享目录触发5145详细访问记录。最后出现1102日志清除或者4779断开RDP会话。把这五步的时间列出来整个事件的来龙去脉就还原了七八成。如果没有日志采集系统手工在事件查看器里点至少要先把时间范围设准不然混入大量无关的正常事件干扰判断。4.2 可复用的PowerShell导出脚本下面给一个实际能用起来的脚本用来导出指定时间段的RDP登录成功事件保存成CSV$start Get-Date 2025-01-01 00:00:00 $end Get-Date 2025-01-31 23:59:59 $events Get-WinEvent -FilterHashtable {LogNameSecurity; Id4624; StartTime$start; EndTime$end} $result foreach ($e in $events) { # 建议先打印一条事件的所有Properties确认索引 if ($e.Properties[8].Value -eq 10) { [PSCustomObject]{ Time $e.TimeCreated Account $e.Properties[5].Value LogonType $e.Properties[8].Value SourceIP $e.Properties[18].Value LogonId $e.Properties[7].Value } } } $result | Sort-Object Time | Export-Csv -Path rdp_logon.csv -NoTypeInformation -Encoding UTF8再次强调Properties的索引在不同系统版本上有差异务必先抽样验证。验证方法很简单拿一条已知的4624事件执行$e.Properties | ForEach-Object { $_.Value }把输出和微软官方文档的4624字段说明对照一遍确认哪个索引是账号、哪个是登录类型、哪个是源IP再跑完整脚本。这一步我省略过结果导出的CSV全是错位字段等于白忙。同理导出SMB登录失败可以这样Get-WinEvent -FilterHashtable {LogNameSecurity; Id4625; StartTime$start; EndTime$end} | Select-Object TimeCreated, {nAccount;e{$_.Properties[5].Value}}, {nSourceIP;e{$_.Properties[18].Value}}, {nStatus;e{$_.Properties[8].Value}} | Export-Csv -Path smb_failed.csv -NoTypeInformation -Encoding UTF84.3 多服务器场景的日志采集与告警机器一多逐台登录翻日志是不现实的。中小环境推荐的零成本方案是Windows事件转发WEF把成员机的安全日志实时转发到一台日志收集服务器配合计划任务做定时统计。虽然没有SIEM那么强但做基础分析足够。如果想更进一步可以写一个简单的计划任务脚本每5分钟统计一次全量服务器日志中单IP在近5分钟内的4625次数超过阈值就发告警。这个思路在没预算买商业平台的小团队里非常实用。核心脚本和上面类似区别只是加了一层循环读取多台机器的事件或者读取转发过来的集中日志。采集通道配好之后还有一个容易忽略的点时间同步。多台服务器时间不一致时间线就是乱的。域环境下通过域控的W32Time同步非域环境要配置统一NTP源并且确认时区一致。虚拟机场景特别容易出问题宿主机时间漂移会传染给所有虚拟机这个要优先处理。5. 常见问题与排查技巧实录日志缺失、状态码和RDP故障全记录5.1 日志溯源高频问题速查表把日常处理过的问题整理成一张速查表遇到类似情况可以快速定位现象可能原因排查方向安全日志完全没有4625审计策略未开启登录失败审核检查secpol.msc或高级审核策略确认失败审计开启某段时间日志缺失日志大小限制触发覆盖查看日志属性-最大日志大小和保留策略出现1102日志清空事件日志被手动清除立即隔离主机对系统盘做只读取证4625状态码0xC000006A密码错误常规爆破特征按源IP聚合统计4625状态码0xC0000064用户名不存在说明在探测账号后续若有4624需重点排查4625状态码0xC0000234账号被锁定结合域控锁定策略判断是否定向爆破RDP连不上但服务进程正常防火墙/网关/NLA配置问题检查netstat监听、防火墙入站规则、系统远程设置SMB共享访问查不到5145未开启详细文件共享审核高级审核策略开启“详细文件共享”并配置共享ACE日志时间错乱跨度大时区或时间同步异常检查NTP配置、W32Time服务、VM时区攻击来源显示为内网跳板IP攻击者通过跳板机或堡垒机中转结合跳板机审计记录继续向下溯源跨网段SMB连不上防火墙策略、SMB版本协商、服务异常检查服务、端口445监听、协议版本和网络连通性5.2 几个实战避坑提醒最后分享几个处理过程中总结出来的教训第一看到大量4625先查账号锁定策略。有些爆破看似猛烈但因为锁定策略没生效攻击者可以无限次尝试这不代表系统安全恰恰说明配置存在缺失。真正要警惕的是那种“精准试探”比如针对某个高权限账号每天只试三五次这种低频爆破靠统计阈值基本发现不了需要结合登录时间分布异常来判断。第二域环境要注意看域控和成员机的双份日志。账号登录验证事件在域控上记录为4776成员机可能只有网络登录相关的记录两边单独看都是断的合起来才能看出完整链路。第三如果服务器装了EDR或主机安全Agent溯源时一定用Agent日志和系统日志交叉验证。系统日志主要记录账号和登录层面Agent能补上进程级、文件级的线索比如攻击者执行了哪条命令、写了哪个文件这些在安全日志里是看不到的。第四溯源做完一定要写事件报告。内容不用复杂把时间线、受影响账号、来源IP、处置措施列出来就行。不写的话过两个月再回看可能连当时判断的过程都想不起来更别说拿去和同事或上级同步结论了。最后再啰嗦一句日志完整性的价值。日志不是出事之后才想起来开的给所有Windows服务器提前把审计策略调好、日志调大、采集通道配好可能只花几十分钟但真正到应急响应那天它带来的确定性和节省的时间远超你当时那点投入。如果你手里正好有一台之前被爆破过的机器现在就把它导出日志练练手按文章里的脚本跑一遍统计你会发现自己对这台机器安全状态的理解完全不一样了。
Windows SMB/RDP日志溯源：从4624/4625到攻击时间线还原
搞Windows运维和安全的同学几乎都绕不开SMB和RDP这两个协议SMB共享是内网文件访问的主力通道RDP远程桌面是日常管理服务器的保命手段。但反过来说这俩也正是暴力破解和横向移动最常盯上的目标。Windows安全日志里头SMB登录和RDP登录最终都会留下4624登录成功、4625登录失败这类事件日志溯源说白了就是把这些零散记录按时间线串起来搞清楚是谁、从哪个IP、在什么时间、用什么账号、干了什么。这篇文章我想把Windows SMB/RDP日志溯源的完整套路系统总结一遍。内容偏向实战适合手里管着Windows服务器、需要做安全排查或应急响应的运维、安全工程师也适合刚入门的小白照着操作。文章不会只堆事件ID还会把每一步的原理和踩过的坑都讲清楚。1. 溯源前的基础准备先搞清日志在哪怎么确保它一直在记1.1 安全日志的位置与审计策略检查Windows的日志文件默认存放在C:\Windows\System32\winevt\Logs目录下后缀是.evtx平时用得最多的事件查看器运行eventvwr.msc就是从这个目录读数据的。做日志溯源最核心的是“Windows日志-安全Security”这一项它记录了账号登录、权限变更、对象访问等安全相关事件。SMB和RDP的登录最终都会在这里产生4624或4625。我接手过的不少服务器第一反应都是直接去翻安全日志结果发现里面什么都没有或者只有零星几条。原因基本都一样这台机器的审计策略根本没开。默认情况下Windows Server会记录一部分登录事件但很多桌面版系统、精简版系统默认不记录详细登录审计安全日志干净得让人心虚。检查方法很快运行里输入secpol.msc打开本地安全策略进入“安全设置-本地策略-审核策略”重点确认“审核登录事件”和“审核帐户登录事件”这两项成功和失败最好都勾上。Windows 2008之后系统还提供了高级审核策略路径在“安全设置-高级审核策略配置”界面复杂一点但粒度更细可以精确到“登录/注销-审核登录”、“对象访问-审核详细文件共享”这些子类别。生产环境我建议直接用高级审核策略配合下来能覆盖SMB共享访问审计和RDP登录审计的完整需求。还有一个命令行工具auditpol适合批量检查或配置多台机器。比如查看当前审核策略auditpol /get /category:*批量开启登录审核可以这样auditpol /set /subcategory:登录 /success:enable /failure:enable具体子类别名称在不同语言版本系统里略有差异建议先/get看一眼实际名称再下发。注意域环境下组策略可能覆盖本地策略如果是域内服务器记得在组策略管理里确认默认域策略或对应OU策略的审核设置不然本地改了也是一场空。1.2 日志大小、保留策略与清理告警安全日志默认大小一般是128MB对登录频繁的服务器几天就可能写满。满了之后如果策略是“覆盖早于X天的事件”最老的日志会被覆盖真到了溯源的时候正好缺了攻击发生那几天的数据。这种坑我踩过不止一次后来凡是重要服务器我都会把安全日志最大大小调到1GB以上策略选“按需覆盖事件”这样既能保证写满后不停止审计又能尽可能保留更长的历史。也有运维为了留住日志选“不覆盖事件手动清理”这个选择要慎重。一旦日志写满系统会直接停止记录新事件审计当场失效比覆盖更麻烦。如果确实需要长期留存正确做法是把日志转发或者定期导出归档而不是靠单机硬扛。日志被清空本身就是一个极其重要的告警信号。安全事件ID 1102表示“审计日志已清除”当一台机器在某个时间点出现1102、后面日志戛然而止绝大多数情况是攻击者在清理痕迹少部分是管理员误操作。遇到1102第一反应应该是把主机隔离然后立刻对系统盘做只读镜像取证。记住一个原则攻击者为什么要清日志因为他知道自己在日志里留下了大量痕迹。所以1102出现的那一刻这台机器基本可以判定已经失陷。2. SMB日志溯源用事件ID把暴力破解和异常共享访问挖出来2.1 看SMB登录先盯这几张事件ID表SMB共享访问的认证最终走的还是Windows登录体系所以查SMB暴力破解要看的核心事件就集中在下面这几个事件ID含义溯源价值4624账号登录成功确认攻击是否得手记录账号、源IP、登录ID4625账号登录失败爆破主证据记录失败原因状态码、源IP、源端口4776域控制器尝试验证账号凭据域环境下判断密码爆破是否命中记录源IP和账号5140网络共享对象被访问判断攻击者登录后访问了哪些共享5145网络共享对象被检查是否可访问详细文件共享精确到共享下的文件路径前提是开启详细文件共享审核4625是查爆破最先要捞的数据。里面有个状态码字段能直接告诉你失败原因0xC000006A表示密码错误0xC0000064表示用户名不存在0xC0000234表示账号被锁定0xC0000072表示账号已禁用。看到大量0xC0000064的时候要格外警惕这说明攻击者正在探测有效账号比单纯爆破已知账号更危险。SMB并不局限于文件共享它也是很多漏洞利用的入口。如果日志里出现大量4656对象句柄请求或5145指向异常路径的访问同时系统日志里出现SMB相关的异常报错就要考虑是不是漏洞利用尝试得把网络层抓包和安全设备告警联动起来看。2.2 用PowerShell快速聚合统计来源IP直接在事件查看器里按4625过滤然后一条条翻这在几十条记录时还行但遇到暴力破解就是几万条翻到吐血也看不出规律。正确做法是先做聚合统计把4625按来源IP分组统计每个IP在时间窗口内的失败次数。下面这个PowerShell脚本可以直接改参数跑$start Get-Date 2025-01-01 00:00:00 $end Get-Date 2025-01-31 23:59:59 Get-WinEvent -FilterHashtable {LogNameSecurity; Id4625; StartTime$start; EndTime$end} | Group-Object {e{$_.Properties[18].Value}} | Sort-Object Count -Descending | Select-Object -First 20 Count, Name这里有个非常关键的坑4625事件Properties数组里索引18在不同Windows版本下不一定都是源IP。Windows Server 2012 R2、2016、2019、2022之间我实测过存在偏移某些系统打了补丁后字段顺序也会变。所以写脚本之前一定要先挑一条4625事件把Properties整个打印出来逐个对照确认哪一个是IP、哪一个是端口再批量执行。否则统计出来可能根本不是你想要的字段。聚合完成之后筛选标准我一般这样定同一源IP在5分钟内失败次数超过10次或一天内超过50次直接列入重点排查对象。当然这个阈值要根据业务场景调整有些自动化系统跑批本来就会频繁输错密码要结合业务知识判断不能一刀切。2.3 别忘了5140和5145共享本体也留痕很多管理员只知道看登录事件忽略了共享访问的事件这是SMB溯源里比较可惜的一个盲区。5140表示网络共享对象被访问能记录谁在什么时间访问了哪个共享5145更进一步可以精确到共享里的文件路径和访问权限级别。但这里有个前提5145默认是不记录的。需要在高级审核策略里打开“对象访问-审核详细文件共享”并且对共享文件夹本身配置成功/失败的审核ACE。很多公司以为开了审核策略就能查文件访问历史结果事后发现5145一条没有大概率就是没配置共享文件夹的ACE审计或者没有勾选详细文件共享子类别。对文件服务器来说5145的价值很高。攻击者爆破成功后通常会先看共享目录里有什么好东西再挑着下载。通过5145能还原出他到底动了哪些文件这在数据泄露评估里非常关键。我处理过的一起事件攻击者登录后访问了十几个共享最终锁定他真正下载的敏感文件靠的就是5145的事件记录。2.4 从SMB漏洞利用到后渗透的扩展排查SMB日志溯源不能只盯着登录失败。像漏洞利用类攻击往往不会产生大量4625因为攻击者直接走漏洞通道或者已经拿到了合法账号。这时候要把排查范围从安全日志扩展到系统日志和应用日志比如SMBv1相关异常事件3019、3036等还有网络层的行为特征。更常见的情况是攻击者爆破一个账号成功后会紧接着用这个账号做进一步操作。所以登录成功事件4624才是整个链条的核心。找到那条来自爆破IP的4624之后顺着Logon ID和时间往后翻看后面有没有4720创建新用户、4732将成员添加到安全组、4724尝试重置密码这类后渗透操作。一旦发现这些事件在同一时间窗口内出现基本可以确认不是误报而是完整的入侵链条。3. RDP日志溯源从登录类型和会话事件还原每一次远程登录3.1 登录类型是第一把尺子RDP登录在安全日志里也是4624和4625想要快速区分它和其他登录方式就要看“登录类型”Logon Type字段。常用值如下Logon Type含义典型场景2本地交互登录直接在本机键盘鼠标操作3网络登录SMB共享访问、net use等4批处理登录计划任务运行5服务登录Windows服务启动10远程交互登录RDP远程桌面看到4624或4625先看Logon Type如果是10基本确定是RDP登录。有些运维疑惑为什么某些内网管理软件登录后显示类型3而不是10那是因为它走的不是标准RDP协议或者中间有跳板机转发这种事要结合源IP和会话记录判断别一看到类型3就下结论说不是远程操作。筛选RDP登录成功的命令其实很简单在事件查看器过滤4624后再看Logon Type列。不过事件查看器默认列表里没有这个字段需要自己添加“登录类型”列或者直接用PowerShell导出更省事下面第4章会给详细脚本。3.2 RDP会话生命周期与三件套除了登录成功失败RDP会话还有几个专属事件串起来能还原完整的会话生命周期4778会话重新连接到窗口站也就是重连4779会话断开连接但注意断开不等于注销会话可能还挂在后台判断一次RDP攻击是否真正得手至少要找到三个事件对应的4624成功登录、后续的4779断开、以及可选的4778重连。这三个事件能拼出攻击者建立会话、操作机器、离开的基本时间线。如果只看到大量4625没有对应的4624那大概率是爆破没有成果攻击者连门都没进去。这里有个实战经验RDP的4624成功事件里有个“已登录进程”字段正常管理员远程管理时进程通常是explorer.exe或rdpclip.exe如果登录后立刻出现非常规进程名或者紧接着有进程创建事件4688前提是开启审核进程创建就要怀疑是不是被植入了后门或执行了恶意程序。3.3 RDP连不上的排查路径服务、端口、注册表说完了日志再说说和RDP日志配套的一个高频故障。很多人查RDP暴力破解前先遇到的往往是“远程桌面连不上”比如rdp not listening、或者rdp wrapper not supported这类提示。RDP连不上我的固定排查顺序是三件事服务、端口、注册表。服务看Remote Desktop ServicesTermService是否在运行启动类型是否为自动。端口执行netstat -ano | findstr 3389确认处于LISTENING状态。注册表检查HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server下的fDenyTSConnections值为0表示允许远程桌面值为1表示拒绝。这三项正常之后再看防火墙入站规则是否放行3389以及系统属性-远程里是否勾选了“允许远程连接到此计算机”。很多时候服务器明明开了RDP但连接还是超时问题就出在防火墙默认拦截上跟服务本身一点关系都没有。至于rdp wrapper not supported这类提示这里多说一句。RDP Wrapper这类工具需要在系统版本匹配的前提下替换或Hook termsrv.dllWindows一更新就容易失效报not supported太正常了。如果你只是为了运维管理需要多用户并发会话最稳妥的路径是走Windows Server的远程桌面服务角色或者在管理场景下用mstsc /admin开管理会话不建议依赖第三方工具去改系统核心文件。我见过不止一次因为强上wrapper导致远程服务彻底起不来、最后只能跑机房物理操作的案例代价太大。3.4 成功登录后的提权痕迹攻击者RDP登录成功后如果要做提权安全日志会留下4672为新登录分配特殊权限。虽然管理员正常登录也会产生4672但这个事件配合4624一起看很有价值。我通常这样过滤筛选4624且Logon Type为10再关联同一时间戳附近的4672账号是Administrator或者某个特权账号来源IP又是之前爆破时的异常IP这时候可以基本判定这是攻击者的成功登录。加上前面说的4720、4732这些账号操作事件整个RDP攻击链就完整了。再看细一点Windows的TerminalServices日志通道里还有1149事件专门记录“用户身份验证成功”属于RDP层面的认证日志比安全日志更贴近远程桌面本身。如果安全日志被清但TerminalServices日志还残留一部分这两边交叉比对往往能补回不少线索。4. 日志关联分析与自动化把零散事件拼成攻击时间线4.1 手工时间线怎么建日志溯源最忌讳的就是逮着一条日志死磕。正确的思路是先建时间线把相关事件按时间排序再连点成线。我的做法是先导出一张总表列包含时间、事件ID、账号、源IP、登录类型、状态码、Logon ID、目标机器、备注。有了这张表按时间一排序攻击路径就自然浮现了。一个典型的完整入侵链条通常是这样的某天凌晨开始大量4625集中出现来源IP分布在几个固定地址账号是Administrator和常见用户名状态码多为0xC000006A或0xC0000064。排查中突然出现一条4624成功Logon Type为10来源IP正好在之前的爆破IP列表里账号是Administrator。紧接着几分钟内出现4720创建新用户、4732将新用户加入Administrators组、4724重置密码。新账号随后通过SMB进行网络登录类型3访问共享目录触发5145详细访问记录。最后出现1102日志清除或者4779断开RDP会话。把这五步的时间列出来整个事件的来龙去脉就还原了七八成。如果没有日志采集系统手工在事件查看器里点至少要先把时间范围设准不然混入大量无关的正常事件干扰判断。4.2 可复用的PowerShell导出脚本下面给一个实际能用起来的脚本用来导出指定时间段的RDP登录成功事件保存成CSV$start Get-Date 2025-01-01 00:00:00 $end Get-Date 2025-01-31 23:59:59 $events Get-WinEvent -FilterHashtable {LogNameSecurity; Id4624; StartTime$start; EndTime$end} $result foreach ($e in $events) { # 建议先打印一条事件的所有Properties确认索引 if ($e.Properties[8].Value -eq 10) { [PSCustomObject]{ Time $e.TimeCreated Account $e.Properties[5].Value LogonType $e.Properties[8].Value SourceIP $e.Properties[18].Value LogonId $e.Properties[7].Value } } } $result | Sort-Object Time | Export-Csv -Path rdp_logon.csv -NoTypeInformation -Encoding UTF8再次强调Properties的索引在不同系统版本上有差异务必先抽样验证。验证方法很简单拿一条已知的4624事件执行$e.Properties | ForEach-Object { $_.Value }把输出和微软官方文档的4624字段说明对照一遍确认哪个索引是账号、哪个是登录类型、哪个是源IP再跑完整脚本。这一步我省略过结果导出的CSV全是错位字段等于白忙。同理导出SMB登录失败可以这样Get-WinEvent -FilterHashtable {LogNameSecurity; Id4625; StartTime$start; EndTime$end} | Select-Object TimeCreated, {nAccount;e{$_.Properties[5].Value}}, {nSourceIP;e{$_.Properties[18].Value}}, {nStatus;e{$_.Properties[8].Value}} | Export-Csv -Path smb_failed.csv -NoTypeInformation -Encoding UTF84.3 多服务器场景的日志采集与告警机器一多逐台登录翻日志是不现实的。中小环境推荐的零成本方案是Windows事件转发WEF把成员机的安全日志实时转发到一台日志收集服务器配合计划任务做定时统计。虽然没有SIEM那么强但做基础分析足够。如果想更进一步可以写一个简单的计划任务脚本每5分钟统计一次全量服务器日志中单IP在近5分钟内的4625次数超过阈值就发告警。这个思路在没预算买商业平台的小团队里非常实用。核心脚本和上面类似区别只是加了一层循环读取多台机器的事件或者读取转发过来的集中日志。采集通道配好之后还有一个容易忽略的点时间同步。多台服务器时间不一致时间线就是乱的。域环境下通过域控的W32Time同步非域环境要配置统一NTP源并且确认时区一致。虚拟机场景特别容易出问题宿主机时间漂移会传染给所有虚拟机这个要优先处理。5. 常见问题与排查技巧实录日志缺失、状态码和RDP故障全记录5.1 日志溯源高频问题速查表把日常处理过的问题整理成一张速查表遇到类似情况可以快速定位现象可能原因排查方向安全日志完全没有4625审计策略未开启登录失败审核检查secpol.msc或高级审核策略确认失败审计开启某段时间日志缺失日志大小限制触发覆盖查看日志属性-最大日志大小和保留策略出现1102日志清空事件日志被手动清除立即隔离主机对系统盘做只读取证4625状态码0xC000006A密码错误常规爆破特征按源IP聚合统计4625状态码0xC0000064用户名不存在说明在探测账号后续若有4624需重点排查4625状态码0xC0000234账号被锁定结合域控锁定策略判断是否定向爆破RDP连不上但服务进程正常防火墙/网关/NLA配置问题检查netstat监听、防火墙入站规则、系统远程设置SMB共享访问查不到5145未开启详细文件共享审核高级审核策略开启“详细文件共享”并配置共享ACE日志时间错乱跨度大时区或时间同步异常检查NTP配置、W32Time服务、VM时区攻击来源显示为内网跳板IP攻击者通过跳板机或堡垒机中转结合跳板机审计记录继续向下溯源跨网段SMB连不上防火墙策略、SMB版本协商、服务异常检查服务、端口445监听、协议版本和网络连通性5.2 几个实战避坑提醒最后分享几个处理过程中总结出来的教训第一看到大量4625先查账号锁定策略。有些爆破看似猛烈但因为锁定策略没生效攻击者可以无限次尝试这不代表系统安全恰恰说明配置存在缺失。真正要警惕的是那种“精准试探”比如针对某个高权限账号每天只试三五次这种低频爆破靠统计阈值基本发现不了需要结合登录时间分布异常来判断。第二域环境要注意看域控和成员机的双份日志。账号登录验证事件在域控上记录为4776成员机可能只有网络登录相关的记录两边单独看都是断的合起来才能看出完整链路。第三如果服务器装了EDR或主机安全Agent溯源时一定用Agent日志和系统日志交叉验证。系统日志主要记录账号和登录层面Agent能补上进程级、文件级的线索比如攻击者执行了哪条命令、写了哪个文件这些在安全日志里是看不到的。第四溯源做完一定要写事件报告。内容不用复杂把时间线、受影响账号、来源IP、处置措施列出来就行。不写的话过两个月再回看可能连当时判断的过程都想不起来更别说拿去和同事或上级同步结论了。最后再啰嗦一句日志完整性的价值。日志不是出事之后才想起来开的给所有Windows服务器提前把审计策略调好、日志调大、采集通道配好可能只花几十分钟但真正到应急响应那天它带来的确定性和节省的时间远超你当时那点投入。如果你手里正好有一台之前被爆破过的机器现在就把它导出日志练练手按文章里的脚本跑一遍统计你会发现自己对这台机器安全状态的理解完全不一样了。
