引言被边界思维耽误了二十年的安全观几乎所有传统企业网络架构都建立在同一个隐含前提上内网是可信的公网是不可信的。于是我们建防火墙、DMZ、IPS把资源像城堡一样围起来护城河之外视为敌区护城河之内视为自己人。这套模型在终端固定、办公集中、业务自建的年代勉强成立。但今天它已经彻底破产边界被云、VPN、BYOD、远程办公、影子 IT 撕得千疮百孔攻击者拿到一个普通员工终端后平均只需要几小时到几天就能摸到域控勒索软件团伙的标准作业流程里横向移动是必经环节而不是可选项。换句话说内网不是安全区而是攻击者的主场。公网是难进易守内网恰恰相反——“易进难守”。一次钓鱼、一个弱口令就可能在扁平化的内网里被放大成全资产沦陷。这里需要先纠正一个常见的认知偏差很多管理者把公网被打穿当作最高风险把内网当作事故之后的缓冲区。但从攻击者的投入产出比来看结论恰恰相反。攻破公网边界往往需要 0day、需要绕过 WAF 与 IPS、需要面对流量侧的各种检测成本和被发现概率都高而一旦进入内网攻击者面对的是一张默认互信、凭证遍地、日志稀疏、协议古老的网络——他可以用系统自带的工具、用合法账号、走合法端口完成从一个普通员工到全域管理员的跃迁。攻击者在内网里最常做的事情用一句话概括就是用你的工具、你的账号、你的权限去打你的机器。本文从攻击链视角拆解入口怎么破、内网为什么这么适合横向移动、如何检测、以及真正有效的优化方向。需要说明的是本文的立场不是内网无用论而是内网必须按不可信来设计。业内常说的Assume Breach假设已被入侵并不是一句口号而是一套工程约束既然攻击者迟早会站在内网里那么设计目标就不该是把门焊死而应该是即便他进来了也只能拿到一小块、也只能待一小会儿。一、核心原理内网信任模型为什么必然失效1.1 边界防御的三个错误假设假设一存在清晰的内外边界。现实是混合云、SaaS、分支机构、外包驻场、供应商运维通道边界早已是概率云。一个暴露在公网的 VPN 设备漏洞就等价于把内网大门钥匙挂到网上。这个假设的致命之处在于它把网络位置等同于信任等级。只要源 IP 落在10.0.0.0/8或172.16.0.0/12里很多企业的防火墙策略就直接放行IPS 也往往对东西向流量不做深度检测。于是攻击者只要找到一个能把流量塞进内网的通道——VPN、SSLVPN、RDP 网关、邮件服务器、CI/CD 跳板、甚至一台被拿下的打印机——他就自动获得了内部人待遇。更糟的是很多企业给内网网段做了例外策略导致横向流量的检测能力远低于南北向流量。假设二内部资产和人员可信。供应链投毒、内部人员误操作、服务账号滥用、被钓鱼的 HR 电脑都能从可信侧发起攻击。现实中的可信侧至少包含五类主体正式员工、外包与驻场人员、第三方运维厂商、机器账号服务账号、gMSA、SQL 服务账号、以及大量遗留的应用集成账号。这五类主体的权限边界往往从未被梳理过很多服务账号是十年前为某个项目开通的项目早已下线账号却还带着域内高权限躺在目录里。它们既是可信主体也是攻击者最喜欢的跳板——因为用它们发起的操作日志上看起来完全合法。假设三静态防御足够。边界防御的本质是一次通过、永久通行。攻击者只需要成功一次防守方却要每次都成功——这是不对称博弈防守方必输。用概率语言描述假设单次防御成功率 99.9%一天有 100 万次探测那么每天漏掉的次数就是 1000 次。防守方要在每一个时刻、每一个入口、每一个协议上都保持正确攻击者只需要在某一个时刻、某一个入口上正确一次。这就是为什么堆设备的边际收益递减得极快——设备数量增长告警量呈线性甚至超线性增长而分析师的数量是固定的。1.2 内网在攻击链中的位置风险的放大器对照 MITRE ATTCK完整链条是Initial Access → Execution → Persistence → Privilege Escalation → Defense Evasion → Credential Access → Discovery → Lateral Movement → Collection → C2 → Exfiltration注意Initial Access 只是买票入场真正决定损失规模的是Lateral Movement。公网暴露面决定能不能进来内网架构决定进来后能走多远。前者是概率问题后者是结构问题——而结构问题远比概率问题更值得投入。把这条链拆成三段损失模型会更直观第一段Initial Access损失 1 台终端。绝大多数企业对这个阶段的容忍度是允许发生尽快响应。第二段Credential Access Lateral Movement损失 N 台主机 M 个高价值账号。这一段是放大器N 和 M 的大小完全由内网架构决定。如果本地管理员密码全网复用N 可以瞬间从 1 跳到几千如果服务账号是弱口令且可 KerberoastM 会包含运维跳板机。第三段Domain Dominance Impact损失 全域。DCSync 拿到krbtgt的 Hash 之后攻击者可以伪造任意用户的黄金票据Golden Ticket即使你把所有密码改掉票据依然有效——除非连续修改两次krbtgt密码。所以安全投入的性价比排序应该是减少凭证复用 网络微隔离 域控加固 边界堆设备。但现实中绝大多数预算的顺序是反过来的。1.3 内网成为横向移动温床的四个根因根因一协议层默认信任。SMB、LDAP、NTLM、WMI、WinRM、RDP 这些内网主力协议大多设计于可信网络时代。NTLM 的挑战-响应机制甚至不需要明文密码抓到一个 NTLM Hash 就能 Pass-the-Hash 直接登录。以 NTLM 为例服务端发送一个随机 Challenge客户端用密码的 NT Hash 对 Challenge 做加密后回传 Response服务端用自己存储的 NT Hash 做同样计算并比对。整个流程从头到尾不需要明文密码也不需要解密Hash。这意味着只要你拿到了 NT Hash你就能完整地走完认证流程。密码多复杂都无所谓——因为攻击者根本不猜密码他用的是密码的等价物。这也是为什么强制 16 位复杂密码这类策略在面对 PtH 时几乎毫无作用。真正有效的是禁用 NTLM或至少限制其使用范围、开启 SMB Signing、把高权限账号放进 Protected Users 组、启用 Credential Guard 防止 LSASS 被读取。根因二网络扁平化。一个 /16 的办公网任意两台主机三层可达。没有微隔离横向移动就是平推。扁平化网络里攻击者的扫描行为成本极低。一条nmap -sT -Pn -p 445,3389,5985 10.0.0.0/16就能在几分钟内拿到全网存活资产清单。更麻烦的是很多企业的 ACL 只做了办公网 → 服务器网的粗粒度控制办公网内部、服务器网内部几乎全通。于是攻击者从任意一台终端出发都能直达数据库、文件服务器、备份服务器。根因三凭证复用。域内所有机器的本地管理员密码相同这是 PtH 能一击致命的根本原因。一个终端的本地 Hash等于全公司终端的钥匙。这个问题的根源通常是镜像克隆装机时把一台机器配置好本地管理员密码然后克隆出几千台或者用同一份 GPO 脚本批量设置本地管理员密码。结果就是全网 RID 500 的密码完全一致。攻击者从任意一台机器 dump 出本地管理员 Hash就能登录所有使用同一镜像的机器——不需要域管权限就能拿下几千台主机。根因四域控是单点信任中枢。AD 的设计哲学是认证集中化攻击者只要拿到域管票据就能给任意账户提权、给任意机器下发策略。这是特性不是漏洞——但它意味着域控失守 全域失守。还有一个常被忽视的细节AD 的信任是可传递的。域 A 信任域 B域 B 信任域 C那么 C 的域管可能通过 SID History 或跨域票据打到 A。很多集团型企业的域林结构复杂信任关系从未被完整审计过这给攻击者提供了大量绕路空间。二、攻击入口从外到内的三条主流路径路径一边缘设备与远程接入。VPN、堡垒机、Exchange、Citrix、防火墙管理口的弱口令与未修复漏洞ProxyLogon、Fortinet SSL-VPN 系列等是近年来最高频的入口。这类设备往往对外暴露 补丁滞后 日志稀薄堪称完美跳板。为什么边缘设备如此好用三个原因它们必须对外暴露。业务上离不开所以不能像内网系统那样靠不暴露来防御。它们的补丁周期极长。一台防火墙或 VPN 网关的升级往往涉及业务中断需要窗口期、需要回滚方案导致很多设备常年落后十几个版本。ProxyLogonCVE-2021-26855 系列爆发时全球仍有大量 Exchange 在补丁发布数月后未修复。它们的日志要么不产生要么不采集。很多安全团队只采集了 Windows 事件日志而 VPN 网关的登录日志、配置变更日志躺在设备本地既没被 SIEM 采集也没人看。攻击者在里面创建账号、改路由、开隧道防守方一无所知。路径二钓鱼与终端突破。邮件附件ISO/LNK/宏文档、恶意浏览器插件、水坑攻击。终端是内网里防御最薄、权限最贴近用户身份的一环。近几年的钓鱼手法有明显演进从早期的宏文档Office 默认禁用宏后失效到 ISO/IMG 挂载绕过 Mark-of-the-Web再到 LNK 文件伪装成发票.pdf.lnk、HTML 走私HTML Smuggling把恶意载荷直接写在 HTML 里由浏览器拼接落地。这些手法的共同点是不依赖漏洞而是依赖用户点击与系统默认行为因此传统 AV 的拦截率很不稳定。路径三供应链与运维通道。第三方运维账号、跳板机、CI/CD 流水线凭证泄露。这类入口最隐蔽因为用合法凭证做合法操作日志上看不出异常。典型场景包括外包厂商用同一个运维账号登录几十家客户CI/CD 的部署账号拥有生产环境写权限且 Token 明文存在仓库变量里开发人员把生产数据库连接串提交到 Git。这类入口的特点是没有恶意软件、没有异常 IP、没有可疑进程检测几乎完全依赖行为基线和权限收敛。落地之后攻击者会先做Discovery——而这一步往往靠系统自带工具就能完成也就是所谓的Living off the Land。常见的 LoTL 工具清单目的常用工具说明域内信息枚举net group /domain、nltest /dclist、dsquery系统自带无告警主机与端口发现Test-NetConnection、net view、arp -a复用系统能力凭证获取procdump、comsvcs.dllMiniDump、reg save可绕过部分 AV远程执行psexec、wmic /node、Invoke-Command、schtasks /s全部是合法管理工具数据打包7z、rar、Compress-Archive系统或常用软件自带防守方需要意识到禁止这些工具是不现实的它们是运维的日常。正确的做法是建立基线——知道在正常情况下谁在什么时候用这些工具、连了哪些主机、用了什么账号然后对偏离基线的行为告警。三、实战案例一条从钓鱼到域控的完整路径下面是一个高度典型细节做了脱敏的复盘时间线全程不到 48 小时时间阶段关键动作为什么没被发现T0h入口财务人员打开发票LNK加载 Cobalt Strike Beacon用户终端无 EDR仅装传统 AVT1h发现用net group Domain Admins /domain枚举系统自带命令无告警T3h凭证窃取Dump LSASS拿到本地管理员 NTLM Hash同一 Hash 全公司通用T5h横向 #1PtH 登录文件服务器落一个服务型后门复用合法凭证无异常登录T12h凭证窃取Kerberoasting请求服务票据离线爆破服务账号4769 事件海量无基线告警T20h横向 #2用爆破出的服务账号登录运维跳板机该账号本就有登录权限T30h提权在跳板机内存中找到域管会话票据Pass-the-Ticket票据复用无需密码T36h控制DCSync 拉取全域 Hash流量与正常域控复制高度相似T47h影响批量下发勒索加密——复盘结论非常清晰没有一个环节是靠高危漏洞完成的全部是配置缺陷、凭证卫生问题和信任过度。这类攻击不会触发任何漏洞扫描器的告警。把这条时间线再拆细一点会看到更多值得警惕的细节T0h 到 T1h为什么发现阶段几乎不可见net group Domain Admins /domain这条命令走的是 LDAP 查询落到域控上是一条正常的目录读取事件4662/1644。在一个每天有上万次目录查询的环境里单看这一条毫无异常。真正能识别它的是主机维度的命令序列——一台财务终端在 5 分钟内先后执行了whoami /all、net group /domain、ipconfig /all、nltest /dclist这个组合才是有意义的信号。可惜大多数企业的日志采集止于域控侧终端侧的命令行审计4688 命令行参数根本没开。T3hLSASS Dump 的三种姿势。攻击者通常不会直接调用MiniDumpWriteDump这种签名明显的 API而是用comsvcs.dll的MiniDump导出函数rundll32 comsvcs.dll, MiniDump PID out.bin full直接reg save HKLM\SAM与reg save HKLM\SYSTEM离线提取本地 Hash用带微软签名的procdump.exe很多 AV 白名单它。检测思路不是禁止某个工具而是监控非白名单进程读取 lsass.exe 内存——这需要 EDR 或至少 Sysmon 的ProcessAccess事件Event ID 10TargetImage为lsass.exeGrantedAccess含0x1010或0x1410。T12hKerberoasting 为什么难发现攻击者请求任意带 SPN 的账号的服务票据TGS这一步完全合法任何用户都能做。域控上会产生 4769 事件且加密类型往往是 RC40x17。真正有价值的检测规则是“同一源主机在短时间内请求大量不同 SPN 的 RC4 票据”。单条 4769 是噪音几十条来自同一 IP 的 RC4 请求就是信号。而现实中很多企业的 4769 事件根本没被采集或者采集了但没人建规则。T36hDCSync 的隐蔽性。DCSync 的原理是伪装成一台域控向真域控请求目录复制。它不落地任何文件、不执行任何恶意代码只是走了正常的 DRSUAPI 协议。检测的唯一抓手是4662 事件中出现了复制相关的权限 GUID1131f6aa-...、1131f6ad-...且发起者不是域控机器账号。这条规则简单、误报低但前提是你得采集 4662 并且配置了对象的 SACL 审计——很多企业两者都没做。四、检测视角两段可落地的代码4.1 用 PowerShell 审计横向移动的前提条件防守的第一性原理是先消除攻击者的便利条件。Kerberoastable 账户和未约束委派是两条最常见的捷径应定期审计。# 需 RSAT 的 ActiveDirectory 模块仅限授权环境运行Import-ModuleActiveDirectoryWrite-Host 1. Kerberoastable 账户启用了 SPN 的用户账户-ForegroundColor CyanGet-ADUser-Filter{ServicePrincipalName-like*-andEnabled-eq$true}-Properties ServicePrincipalName,PasswordLastSet,LastLogonDate|Select-ObjectName,SamAccountName,ServicePrincipalName,PasswordLastSet,LastLogonDate|Sort-ObjectPasswordLastSet|Format-Table-AutoSize# 关注点PasswordLastSet 超过 2 年、且 SPN 属于高价值服务MSSQLSvc、http、cifs的账号# 这些账号一旦被 Kerberoast 爆破成功攻击者就能直接登录对应服务器Write-Host 2. AS-REP Roastable 账户未开启 Kerberos 预认证-ForegroundColor CyanGet-ADUser-Filter{DoesNotRequirePreAuth-eq$true-andEnabled-eq$true}-Properties DoesNotRequirePreAuth,PasswordLastSet|Select-ObjectName,SamAccountName,PasswordLastSet|Format-Table-AutoSize# 这类账号的 TGT 可以被离线爆破风险等级与 Kerberoastable 相当# 正常环境中这个列表应该是空的如果不为空优先确认是否为历史遗留配置Write-Host 3. 未约束委派的主机与账户 -ForegroundColor CyanGet-ADObject-LDAPFilter(userAccountControl:1.2.840.113556.1.4.803:524288)-Properties userAccountControl,servicePrincipalName|Select-ObjectName,ObjectClass,DistinguishedName|Format-Table-AutoSize# 524288 TRUSTED_FOR_DELEGATION# 未约束委派的机器上任何用户登录都会把 TGT 留在内存里# 攻击者控制该机器后可直接窃取域管的 TGT —— 这是横向移动到域控的经典捷径Write-Host 4. 本地管理员密码是否复用抽样比对设置时间-ForegroundColor Cyan# 注意需要本地管理员权限且必须获得书面授权$targetsGet-ADComputer-Filter{Enabled-eq$true}-SearchBaseOUServers,DCcorp,DClocal|Select-Object-First 50-ExpandProperty Nameforeach($tin$targets){try{$pwdSetInvoke-Command-ComputerName$t-ScriptBlock{(Get-LocalUser-Name Administrator).PasswordLastSet}-ErrorAction Stop[PSCustomObject]{Host $t;AdminPwdLastSet $pwdSet}}catch{[PSCustomObject]{Host $t;AdminPwdLastSet N/A不可达或无权限}}}# 判读方法如果几十台机器的 AdminPwdLastSet 时间戳完全一致# 说明它们由同一份镜像或同一条 GPO 脚本批量设置 —— 即密码大概率复用# 这正是 PtH 一击致命的根本原因应尽快用 Windows LAPS 或第三方 PAM 替代踩坑提醒这段脚本本身就是一个域内侦察脚本它读取的信息量与攻击者的 Discovery 阶段高度重合。因此必须在获得书面授权的前提下运行建议在专用的**管理网段 / PAW特权访问工作站**上执行而不是在普通办公终端脚本运行行为本身应被审计并留档避免防守方自己制造了一次可疑的域枚举。4.2 用 Sigma KQL 检测横向移动的两个关键信号审计是事前减少便利条件检测是事中发现正在进行。下面两条规则分别针对PtH 的登录特征和DCSync 的目录复制特征可直接翻译成 Sigma 或 Sentinel/Defender 的 KQL。规则一一个账号在短时间内登录大量不同主机横向移动的强特征// Sentinel / Defender XDR - Advanced Hunting // 场景NTLM 网络登录LogonType 3从一个源 IP 扩散到多台主机 SecurityEvent | where EventID 4624 | where LogonType 3 // 网络登录 典型横向移动 | where AuthenticationPackageName ~ NTLM // PtH 几乎必然走 NTLM | where IpAddress !in (-, 127.0.0.1, ::1) // 排除本地登录噪音 | where Account !endswith $ // 排除机器账号另建规则 | summarize LogonCount count(), TargetHosts dcount(Computer), HostSample make_set(Computer, 20) by Account, IpAddress, bin(TimeGenerated, 1h) | where TargetHosts 5 // 阈值需按环境基线调整 | order by TargetHosts desc判读要点正常用户不会在一小时内用 NTLM 登录 5 台以上服务器。这个模式的背后要么是运维在批量操作应纳入白名单基线要么就是 PtH 平推。阈值不要照搬 5应该先用 30 天历史数据跑一遍看正常业务的分布再取 P99 作为阈值。规则二非域控主机发起目录复制DCSynctitle:疑似 DCSync 攻击-非域控主机请求目录复制id:8f2a1c34-5b6d-4e7f-9a01-2c3d4e5f6a7bstatus:experimentaldescription:检测 4662 事件中出现的目录复制权限且发起者不是域控机器账号logsource:product:windowsservice:securitydetection:selection_event:EventID:4662selection_property:Properties|contains:-1131f6aa-9c07-11d1-f79f-00c04fc2dcd2# DS-Replication-Get-Changes-1131f6ad-9c07-11d1-f79f-00c04fc2dcd2# DS-Replication-Get-Changes-All-89e95b76-444d-4c62-991a-0facbeda640c# DS-Replication-Get-Changes-In-Filtered-Setfilter_machine:SubjectUserName|endswith:$# 正常的域控间复制使用机器账号condition:selection_event and selection_property and not filter_machinefalsepositives:-Azure AD Connect 同步账号应加入显式白名单-合法的第三方目录同步工具level:critical为什么这条规则误报极低因为 DCSync 的权限 GUID 只在目录复制场景出现而合法的目录复制发起者几乎总是域控的机器账号以$结尾。只要把 AAD Connect 的同步账号加进白名单剩下的命中基本可以直接按域控已被拿下来处理。这也是为什么强烈建议开启目录对象的 SACL 审计——不开启4662 事件根本不会产生规则再准也无从匹配。一条额外建议部署 Honeytoken蜜罐账号。在目录里建一个看起来像服务账号、名字带svc_、但没有任何实际用途的账号给它设一个容易被 Kerberoast 的 SPN然后对它的任何登录、任何票据请求告警。正常业务永远不会碰它一旦有动静基本可以确定是攻击者在做 Discovery。五、常见问题FAQQ1我们内网有防火墙做区域隔离为什么还是被横向移动打穿了大概率是三个原因之一一是隔离策略只做了南北向办公网到服务器网东西向仍全通二是策略是默认放行 少量拒绝而不是默认拒绝 白名单放行三是策略虽然写了但从未做过从每台主机发起的可达性验证实际生效范围与设计严重不符。建议用自动化工具定期做全量可达性探测把设计中的 ACL和实际连通性做差集差集就是风险面。Q2我们已经部署了 EDR为什么还是被 DCSync 成功了EDR 主要覆盖终端上的进程行为而 DCSync 是网络协议层的攻击——攻击者只是调用了 DRSUAPI 的复制接口没有任何恶意进程落地。更多硬核网安与AI工具包请扫码获取完整源码EDR 可能只能看到一个 PowerShell 或 Mimikatz 进程在跑 内网真的比公网安全吗？从攻击入口到横向移动解析企业内网风险
引言被边界思维耽误了二十年的安全观几乎所有传统企业网络架构都建立在同一个隐含前提上内网是可信的公网是不可信的。于是我们建防火墙、DMZ、IPS把资源像城堡一样围起来护城河之外视为敌区护城河之内视为自己人。这套模型在终端固定、办公集中、业务自建的年代勉强成立。但今天它已经彻底破产边界被云、VPN、BYOD、远程办公、影子 IT 撕得千疮百孔攻击者拿到一个普通员工终端后平均只需要几小时到几天就能摸到域控勒索软件团伙的标准作业流程里横向移动是必经环节而不是可选项。换句话说内网不是安全区而是攻击者的主场。公网是难进易守内网恰恰相反——“易进难守”。一次钓鱼、一个弱口令就可能在扁平化的内网里被放大成全资产沦陷。这里需要先纠正一个常见的认知偏差很多管理者把公网被打穿当作最高风险把内网当作事故之后的缓冲区。但从攻击者的投入产出比来看结论恰恰相反。攻破公网边界往往需要 0day、需要绕过 WAF 与 IPS、需要面对流量侧的各种检测成本和被发现概率都高而一旦进入内网攻击者面对的是一张默认互信、凭证遍地、日志稀疏、协议古老的网络——他可以用系统自带的工具、用合法账号、走合法端口完成从一个普通员工到全域管理员的跃迁。攻击者在内网里最常做的事情用一句话概括就是用你的工具、你的账号、你的权限去打你的机器。本文从攻击链视角拆解入口怎么破、内网为什么这么适合横向移动、如何检测、以及真正有效的优化方向。需要说明的是本文的立场不是内网无用论而是内网必须按不可信来设计。业内常说的Assume Breach假设已被入侵并不是一句口号而是一套工程约束既然攻击者迟早会站在内网里那么设计目标就不该是把门焊死而应该是即便他进来了也只能拿到一小块、也只能待一小会儿。一、核心原理内网信任模型为什么必然失效1.1 边界防御的三个错误假设假设一存在清晰的内外边界。现实是混合云、SaaS、分支机构、外包驻场、供应商运维通道边界早已是概率云。一个暴露在公网的 VPN 设备漏洞就等价于把内网大门钥匙挂到网上。这个假设的致命之处在于它把网络位置等同于信任等级。只要源 IP 落在10.0.0.0/8或172.16.0.0/12里很多企业的防火墙策略就直接放行IPS 也往往对东西向流量不做深度检测。于是攻击者只要找到一个能把流量塞进内网的通道——VPN、SSLVPN、RDP 网关、邮件服务器、CI/CD 跳板、甚至一台被拿下的打印机——他就自动获得了内部人待遇。更糟的是很多企业给内网网段做了例外策略导致横向流量的检测能力远低于南北向流量。假设二内部资产和人员可信。供应链投毒、内部人员误操作、服务账号滥用、被钓鱼的 HR 电脑都能从可信侧发起攻击。现实中的可信侧至少包含五类主体正式员工、外包与驻场人员、第三方运维厂商、机器账号服务账号、gMSA、SQL 服务账号、以及大量遗留的应用集成账号。这五类主体的权限边界往往从未被梳理过很多服务账号是十年前为某个项目开通的项目早已下线账号却还带着域内高权限躺在目录里。它们既是可信主体也是攻击者最喜欢的跳板——因为用它们发起的操作日志上看起来完全合法。假设三静态防御足够。边界防御的本质是一次通过、永久通行。攻击者只需要成功一次防守方却要每次都成功——这是不对称博弈防守方必输。用概率语言描述假设单次防御成功率 99.9%一天有 100 万次探测那么每天漏掉的次数就是 1000 次。防守方要在每一个时刻、每一个入口、每一个协议上都保持正确攻击者只需要在某一个时刻、某一个入口上正确一次。这就是为什么堆设备的边际收益递减得极快——设备数量增长告警量呈线性甚至超线性增长而分析师的数量是固定的。1.2 内网在攻击链中的位置风险的放大器对照 MITRE ATTCK完整链条是Initial Access → Execution → Persistence → Privilege Escalation → Defense Evasion → Credential Access → Discovery → Lateral Movement → Collection → C2 → Exfiltration注意Initial Access 只是买票入场真正决定损失规模的是Lateral Movement。公网暴露面决定能不能进来内网架构决定进来后能走多远。前者是概率问题后者是结构问题——而结构问题远比概率问题更值得投入。把这条链拆成三段损失模型会更直观第一段Initial Access损失 1 台终端。绝大多数企业对这个阶段的容忍度是允许发生尽快响应。第二段Credential Access Lateral Movement损失 N 台主机 M 个高价值账号。这一段是放大器N 和 M 的大小完全由内网架构决定。如果本地管理员密码全网复用N 可以瞬间从 1 跳到几千如果服务账号是弱口令且可 KerberoastM 会包含运维跳板机。第三段Domain Dominance Impact损失 全域。DCSync 拿到krbtgt的 Hash 之后攻击者可以伪造任意用户的黄金票据Golden Ticket即使你把所有密码改掉票据依然有效——除非连续修改两次krbtgt密码。所以安全投入的性价比排序应该是减少凭证复用 网络微隔离 域控加固 边界堆设备。但现实中绝大多数预算的顺序是反过来的。1.3 内网成为横向移动温床的四个根因根因一协议层默认信任。SMB、LDAP、NTLM、WMI、WinRM、RDP 这些内网主力协议大多设计于可信网络时代。NTLM 的挑战-响应机制甚至不需要明文密码抓到一个 NTLM Hash 就能 Pass-the-Hash 直接登录。以 NTLM 为例服务端发送一个随机 Challenge客户端用密码的 NT Hash 对 Challenge 做加密后回传 Response服务端用自己存储的 NT Hash 做同样计算并比对。整个流程从头到尾不需要明文密码也不需要解密Hash。这意味着只要你拿到了 NT Hash你就能完整地走完认证流程。密码多复杂都无所谓——因为攻击者根本不猜密码他用的是密码的等价物。这也是为什么强制 16 位复杂密码这类策略在面对 PtH 时几乎毫无作用。真正有效的是禁用 NTLM或至少限制其使用范围、开启 SMB Signing、把高权限账号放进 Protected Users 组、启用 Credential Guard 防止 LSASS 被读取。根因二网络扁平化。一个 /16 的办公网任意两台主机三层可达。没有微隔离横向移动就是平推。扁平化网络里攻击者的扫描行为成本极低。一条nmap -sT -Pn -p 445,3389,5985 10.0.0.0/16就能在几分钟内拿到全网存活资产清单。更麻烦的是很多企业的 ACL 只做了办公网 → 服务器网的粗粒度控制办公网内部、服务器网内部几乎全通。于是攻击者从任意一台终端出发都能直达数据库、文件服务器、备份服务器。根因三凭证复用。域内所有机器的本地管理员密码相同这是 PtH 能一击致命的根本原因。一个终端的本地 Hash等于全公司终端的钥匙。这个问题的根源通常是镜像克隆装机时把一台机器配置好本地管理员密码然后克隆出几千台或者用同一份 GPO 脚本批量设置本地管理员密码。结果就是全网 RID 500 的密码完全一致。攻击者从任意一台机器 dump 出本地管理员 Hash就能登录所有使用同一镜像的机器——不需要域管权限就能拿下几千台主机。根因四域控是单点信任中枢。AD 的设计哲学是认证集中化攻击者只要拿到域管票据就能给任意账户提权、给任意机器下发策略。这是特性不是漏洞——但它意味着域控失守 全域失守。还有一个常被忽视的细节AD 的信任是可传递的。域 A 信任域 B域 B 信任域 C那么 C 的域管可能通过 SID History 或跨域票据打到 A。很多集团型企业的域林结构复杂信任关系从未被完整审计过这给攻击者提供了大量绕路空间。二、攻击入口从外到内的三条主流路径路径一边缘设备与远程接入。VPN、堡垒机、Exchange、Citrix、防火墙管理口的弱口令与未修复漏洞ProxyLogon、Fortinet SSL-VPN 系列等是近年来最高频的入口。这类设备往往对外暴露 补丁滞后 日志稀薄堪称完美跳板。为什么边缘设备如此好用三个原因它们必须对外暴露。业务上离不开所以不能像内网系统那样靠不暴露来防御。它们的补丁周期极长。一台防火墙或 VPN 网关的升级往往涉及业务中断需要窗口期、需要回滚方案导致很多设备常年落后十几个版本。ProxyLogonCVE-2021-26855 系列爆发时全球仍有大量 Exchange 在补丁发布数月后未修复。它们的日志要么不产生要么不采集。很多安全团队只采集了 Windows 事件日志而 VPN 网关的登录日志、配置变更日志躺在设备本地既没被 SIEM 采集也没人看。攻击者在里面创建账号、改路由、开隧道防守方一无所知。路径二钓鱼与终端突破。邮件附件ISO/LNK/宏文档、恶意浏览器插件、水坑攻击。终端是内网里防御最薄、权限最贴近用户身份的一环。近几年的钓鱼手法有明显演进从早期的宏文档Office 默认禁用宏后失效到 ISO/IMG 挂载绕过 Mark-of-the-Web再到 LNK 文件伪装成发票.pdf.lnk、HTML 走私HTML Smuggling把恶意载荷直接写在 HTML 里由浏览器拼接落地。这些手法的共同点是不依赖漏洞而是依赖用户点击与系统默认行为因此传统 AV 的拦截率很不稳定。路径三供应链与运维通道。第三方运维账号、跳板机、CI/CD 流水线凭证泄露。这类入口最隐蔽因为用合法凭证做合法操作日志上看不出异常。典型场景包括外包厂商用同一个运维账号登录几十家客户CI/CD 的部署账号拥有生产环境写权限且 Token 明文存在仓库变量里开发人员把生产数据库连接串提交到 Git。这类入口的特点是没有恶意软件、没有异常 IP、没有可疑进程检测几乎完全依赖行为基线和权限收敛。落地之后攻击者会先做Discovery——而这一步往往靠系统自带工具就能完成也就是所谓的Living off the Land。常见的 LoTL 工具清单目的常用工具说明域内信息枚举net group /domain、nltest /dclist、dsquery系统自带无告警主机与端口发现Test-NetConnection、net view、arp -a复用系统能力凭证获取procdump、comsvcs.dllMiniDump、reg save可绕过部分 AV远程执行psexec、wmic /node、Invoke-Command、schtasks /s全部是合法管理工具数据打包7z、rar、Compress-Archive系统或常用软件自带防守方需要意识到禁止这些工具是不现实的它们是运维的日常。正确的做法是建立基线——知道在正常情况下谁在什么时候用这些工具、连了哪些主机、用了什么账号然后对偏离基线的行为告警。三、实战案例一条从钓鱼到域控的完整路径下面是一个高度典型细节做了脱敏的复盘时间线全程不到 48 小时时间阶段关键动作为什么没被发现T0h入口财务人员打开发票LNK加载 Cobalt Strike Beacon用户终端无 EDR仅装传统 AVT1h发现用net group Domain Admins /domain枚举系统自带命令无告警T3h凭证窃取Dump LSASS拿到本地管理员 NTLM Hash同一 Hash 全公司通用T5h横向 #1PtH 登录文件服务器落一个服务型后门复用合法凭证无异常登录T12h凭证窃取Kerberoasting请求服务票据离线爆破服务账号4769 事件海量无基线告警T20h横向 #2用爆破出的服务账号登录运维跳板机该账号本就有登录权限T30h提权在跳板机内存中找到域管会话票据Pass-the-Ticket票据复用无需密码T36h控制DCSync 拉取全域 Hash流量与正常域控复制高度相似T47h影响批量下发勒索加密——复盘结论非常清晰没有一个环节是靠高危漏洞完成的全部是配置缺陷、凭证卫生问题和信任过度。这类攻击不会触发任何漏洞扫描器的告警。把这条时间线再拆细一点会看到更多值得警惕的细节T0h 到 T1h为什么发现阶段几乎不可见net group Domain Admins /domain这条命令走的是 LDAP 查询落到域控上是一条正常的目录读取事件4662/1644。在一个每天有上万次目录查询的环境里单看这一条毫无异常。真正能识别它的是主机维度的命令序列——一台财务终端在 5 分钟内先后执行了whoami /all、net group /domain、ipconfig /all、nltest /dclist这个组合才是有意义的信号。可惜大多数企业的日志采集止于域控侧终端侧的命令行审计4688 命令行参数根本没开。T3hLSASS Dump 的三种姿势。攻击者通常不会直接调用MiniDumpWriteDump这种签名明显的 API而是用comsvcs.dll的MiniDump导出函数rundll32 comsvcs.dll, MiniDump PID out.bin full直接reg save HKLM\SAM与reg save HKLM\SYSTEM离线提取本地 Hash用带微软签名的procdump.exe很多 AV 白名单它。检测思路不是禁止某个工具而是监控非白名单进程读取 lsass.exe 内存——这需要 EDR 或至少 Sysmon 的ProcessAccess事件Event ID 10TargetImage为lsass.exeGrantedAccess含0x1010或0x1410。T12hKerberoasting 为什么难发现攻击者请求任意带 SPN 的账号的服务票据TGS这一步完全合法任何用户都能做。域控上会产生 4769 事件且加密类型往往是 RC40x17。真正有价值的检测规则是“同一源主机在短时间内请求大量不同 SPN 的 RC4 票据”。单条 4769 是噪音几十条来自同一 IP 的 RC4 请求就是信号。而现实中很多企业的 4769 事件根本没被采集或者采集了但没人建规则。T36hDCSync 的隐蔽性。DCSync 的原理是伪装成一台域控向真域控请求目录复制。它不落地任何文件、不执行任何恶意代码只是走了正常的 DRSUAPI 协议。检测的唯一抓手是4662 事件中出现了复制相关的权限 GUID1131f6aa-...、1131f6ad-...且发起者不是域控机器账号。这条规则简单、误报低但前提是你得采集 4662 并且配置了对象的 SACL 审计——很多企业两者都没做。四、检测视角两段可落地的代码4.1 用 PowerShell 审计横向移动的前提条件防守的第一性原理是先消除攻击者的便利条件。Kerberoastable 账户和未约束委派是两条最常见的捷径应定期审计。# 需 RSAT 的 ActiveDirectory 模块仅限授权环境运行Import-ModuleActiveDirectoryWrite-Host 1. Kerberoastable 账户启用了 SPN 的用户账户-ForegroundColor CyanGet-ADUser-Filter{ServicePrincipalName-like*-andEnabled-eq$true}-Properties ServicePrincipalName,PasswordLastSet,LastLogonDate|Select-ObjectName,SamAccountName,ServicePrincipalName,PasswordLastSet,LastLogonDate|Sort-ObjectPasswordLastSet|Format-Table-AutoSize# 关注点PasswordLastSet 超过 2 年、且 SPN 属于高价值服务MSSQLSvc、http、cifs的账号# 这些账号一旦被 Kerberoast 爆破成功攻击者就能直接登录对应服务器Write-Host 2. AS-REP Roastable 账户未开启 Kerberos 预认证-ForegroundColor CyanGet-ADUser-Filter{DoesNotRequirePreAuth-eq$true-andEnabled-eq$true}-Properties DoesNotRequirePreAuth,PasswordLastSet|Select-ObjectName,SamAccountName,PasswordLastSet|Format-Table-AutoSize# 这类账号的 TGT 可以被离线爆破风险等级与 Kerberoastable 相当# 正常环境中这个列表应该是空的如果不为空优先确认是否为历史遗留配置Write-Host 3. 未约束委派的主机与账户 -ForegroundColor CyanGet-ADObject-LDAPFilter(userAccountControl:1.2.840.113556.1.4.803:524288)-Properties userAccountControl,servicePrincipalName|Select-ObjectName,ObjectClass,DistinguishedName|Format-Table-AutoSize# 524288 TRUSTED_FOR_DELEGATION# 未约束委派的机器上任何用户登录都会把 TGT 留在内存里# 攻击者控制该机器后可直接窃取域管的 TGT —— 这是横向移动到域控的经典捷径Write-Host 4. 本地管理员密码是否复用抽样比对设置时间-ForegroundColor Cyan# 注意需要本地管理员权限且必须获得书面授权$targetsGet-ADComputer-Filter{Enabled-eq$true}-SearchBaseOUServers,DCcorp,DClocal|Select-Object-First 50-ExpandProperty Nameforeach($tin$targets){try{$pwdSetInvoke-Command-ComputerName$t-ScriptBlock{(Get-LocalUser-Name Administrator).PasswordLastSet}-ErrorAction Stop[PSCustomObject]{Host $t;AdminPwdLastSet $pwdSet}}catch{[PSCustomObject]{Host $t;AdminPwdLastSet N/A不可达或无权限}}}# 判读方法如果几十台机器的 AdminPwdLastSet 时间戳完全一致# 说明它们由同一份镜像或同一条 GPO 脚本批量设置 —— 即密码大概率复用# 这正是 PtH 一击致命的根本原因应尽快用 Windows LAPS 或第三方 PAM 替代踩坑提醒这段脚本本身就是一个域内侦察脚本它读取的信息量与攻击者的 Discovery 阶段高度重合。因此必须在获得书面授权的前提下运行建议在专用的**管理网段 / PAW特权访问工作站**上执行而不是在普通办公终端脚本运行行为本身应被审计并留档避免防守方自己制造了一次可疑的域枚举。4.2 用 Sigma KQL 检测横向移动的两个关键信号审计是事前减少便利条件检测是事中发现正在进行。下面两条规则分别针对PtH 的登录特征和DCSync 的目录复制特征可直接翻译成 Sigma 或 Sentinel/Defender 的 KQL。规则一一个账号在短时间内登录大量不同主机横向移动的强特征// Sentinel / Defender XDR - Advanced Hunting // 场景NTLM 网络登录LogonType 3从一个源 IP 扩散到多台主机 SecurityEvent | where EventID 4624 | where LogonType 3 // 网络登录 典型横向移动 | where AuthenticationPackageName ~ NTLM // PtH 几乎必然走 NTLM | where IpAddress !in (-, 127.0.0.1, ::1) // 排除本地登录噪音 | where Account !endswith $ // 排除机器账号另建规则 | summarize LogonCount count(), TargetHosts dcount(Computer), HostSample make_set(Computer, 20) by Account, IpAddress, bin(TimeGenerated, 1h) | where TargetHosts 5 // 阈值需按环境基线调整 | order by TargetHosts desc判读要点正常用户不会在一小时内用 NTLM 登录 5 台以上服务器。这个模式的背后要么是运维在批量操作应纳入白名单基线要么就是 PtH 平推。阈值不要照搬 5应该先用 30 天历史数据跑一遍看正常业务的分布再取 P99 作为阈值。规则二非域控主机发起目录复制DCSynctitle:疑似 DCSync 攻击-非域控主机请求目录复制id:8f2a1c34-5b6d-4e7f-9a01-2c3d4e5f6a7bstatus:experimentaldescription:检测 4662 事件中出现的目录复制权限且发起者不是域控机器账号logsource:product:windowsservice:securitydetection:selection_event:EventID:4662selection_property:Properties|contains:-1131f6aa-9c07-11d1-f79f-00c04fc2dcd2# DS-Replication-Get-Changes-1131f6ad-9c07-11d1-f79f-00c04fc2dcd2# DS-Replication-Get-Changes-All-89e95b76-444d-4c62-991a-0facbeda640c# DS-Replication-Get-Changes-In-Filtered-Setfilter_machine:SubjectUserName|endswith:$# 正常的域控间复制使用机器账号condition:selection_event and selection_property and not filter_machinefalsepositives:-Azure AD Connect 同步账号应加入显式白名单-合法的第三方目录同步工具level:critical为什么这条规则误报极低因为 DCSync 的权限 GUID 只在目录复制场景出现而合法的目录复制发起者几乎总是域控的机器账号以$结尾。只要把 AAD Connect 的同步账号加进白名单剩下的命中基本可以直接按域控已被拿下来处理。这也是为什么强烈建议开启目录对象的 SACL 审计——不开启4662 事件根本不会产生规则再准也无从匹配。一条额外建议部署 Honeytoken蜜罐账号。在目录里建一个看起来像服务账号、名字带svc_、但没有任何实际用途的账号给它设一个容易被 Kerberoast 的 SPN然后对它的任何登录、任何票据请求告警。正常业务永远不会碰它一旦有动静基本可以确定是攻击者在做 Discovery。五、常见问题FAQQ1我们内网有防火墙做区域隔离为什么还是被横向移动打穿了大概率是三个原因之一一是隔离策略只做了南北向办公网到服务器网东西向仍全通二是策略是默认放行 少量拒绝而不是默认拒绝 白名单放行三是策略虽然写了但从未做过从每台主机发起的可达性验证实际生效范围与设计严重不符。建议用自动化工具定期做全量可达性探测把设计中的 ACL和实际连通性做差集差集就是风险面。Q2我们已经部署了 EDR为什么还是被 DCSync 成功了EDR 主要覆盖终端上的进程行为而 DCSync 是网络协议层的攻击——攻击者只是调用了 DRSUAPI 的复制接口没有任何恶意进程落地。更多硬核网安与AI工具包请扫码获取完整源码EDR 可能只能看到一个 PowerShell 或 Mimikatz 进程在跑