1. 一次域渗透的完整复盘：为什么安全从业者必须懂攻击路径

折腾完整个内网渗透流程后，我最大的感受是：不懂攻击路径的人，永远做不好防御。工作中不少人觉得"我们公司小，没人会盯着我们打"，但实际渗透测试里，中小型企业的域环境反而是最容易被拿下的——补丁滞后、密码策略宽松、内网分段缺失，几乎每条都是致命伤。

这篇文章想用一次完整的域渗透过程复盘，带你理解攻击者视角下的真实路径。它不是教你去做坏事，而是帮助你，无论你是网络安全初学者、刚入职的安全工程师，还是企业的IT运维人员，都能明白：域渗透的攻击者是怎么思考的？一个初始漏洞如何变成域管理员权限？每一步应该看到什么告警、查什么日志、做什么加固？

先交代背景。整个项目是一个授权的内网演练环境，拓扑模拟了一家有分支机构的典型企业：总部域控Windows Server 2019，版本较旧且未打全补丁；员工终端以Windows 10为主，混杂几台Windows 7遗留设备；文件服务器两台，数据库服务器一台。账号体系全部域集成，未启用Azure AD同步，也未启用Credential Guard。简单说，这是一套在中小型企业里非常典型、非常常见的IT架构。

初始攻击面其实很清晰：对外只暴露了一台Web OA系统，跑在Windows Server上，IIS + PHP。这几乎是内网渗透的经典起手式——外网只开一个口子，攻击者想进入内网，必然先盯上这台被暴露的服务器。而我们做防御加固时，第一步要做的也正是评估：对外开放的每一个服务，是否真的有必要暴露？有没有上WAF？补丁是否及时？

接下来的内容，我会按照一次标准域渗透的推进顺序展开，把每一步的思路、工具选择、底层原理全部拆开讲清楚。这样无论你未来是做渗透测试，还是做蓝队防御，都能在前人的路径上建立自己的分析框架。

2. 从Web入口到内网立足点：初始访问阶段的攻与防

2.1 外网打点的核心思路：不碰0day，只找逻辑漏洞

很多人一想到"打点"，脑子里全是CVE、0Day、内存破坏，但实际上在真实环境中，绝大多数初始突破口都是业务逻辑漏洞。因为这个OA系统是PHP写的，版本不算新，我第一件事是做了常规的信息收集：指纹识别、目录扫描、敏感文件探测。

信息收集是所有渗透测试的地基，这一步做得细不细，直接决定了后续成功率。我用dirsearch跑了常见目录，很快发现了一个有意思的路径——/backup/目录未做访问控制，里面躺着一份三个月前的网站源码打包备份。而这套源码里，.env配置文件暴露了数据库账号密码。这里我不知道你有没有意识到问题的严重性：备份文件泄露 = 源码泄露 = 数据库凭据泄露，一次目录扫描直接打通了三条链路。

拿到数据库凭据后，我并没有直接连数据库，而是先尝试复用凭据登录OA系统的管理后台。运气不错，管理员在部署OA时顺手把数据库密码也用作了后台登录密码，这就是典型的密码复用问题。登录后台后，我又在"系统通知"编辑器里发现可以上传附件，上传点校验不严，允许PHP文件直接上传。到这里，Web层面的利用闭环就形成了：目录扫描找到备份 → 备份泄露数据库密码 → 密码复用登录后台 → 文件上传getshell。整个过程没有用到任何高深技术，全是低垂果实，但它真真切切地发生在大量企业的真实内网里。

我把这个案例放进防御视角来看，至少有四个加固点：第一，备份文件绝对不能放在Web可访问目录下；第二，凭据必须分级管理，数据库密码不应该等于业务后台密码；第三，上传点必须做白名单校验，禁止脚本文件落地；第四，敏感文件的泄露往往不是单点问题，而是多个小疏忽叠加的结果。

2.2 getshell之后的第一件事：收集当前主机的情报

拿到WebShell的那一刻，真正的内网渗透才算刚刚开始。很多人拿到Shell后急着翻数据库、提权、横跳，这其实是新手最容易犯的错误——当前主机的信息收集做得越充分，后续横向的路径就越清晰。

我先稳定了Shell的权限，用命令查看了当前进程、网络连接、本机用户、计划任务这几个指标。进程列表里出现了一个经常被忽略的点：这台Web服务器上装着一个第三方备份客户端，以服务权限运行，而当前IIS进程是普通应用池权限。我立刻意识到这可能是个提权候选点，但先不急着动，继续看网络连接。

netstat -ano 输出里有一条来源可疑的连接，指向内网192.168.10.0/24网段的另一台主机，端口是445。这说明这台Web服务器的某些任务调度，曾与内网其他Windows主机建立过SMB连接。进一步查看计划任务，我发现了一个管理员当年为了"方便同步日志"配置的任务，使用域管理员账户凭据运行。这个发现直接改变了我后续的所有规划——如果我能拿到这个任务对应的凭据或哈希，就不需要费劲做本地提权了，完全可以尝试直接横向移动。

不过我也提醒自己：稳妥推进比莽撞重要。我先把当前机器的系统信息、补丁情况、可用工具环境全部记录下来——这台机器没有装杀毒软件，这让后续操作少了很多干扰。但对防御方来说，这个事实其实很值得警惕：没有任何终端防护的Windows服务器，等于把内网大门钥匙挂在门口。

2.3 从WebShell到系统Shell的权限升级思路

在开始横向移动之前，得先把权限从IIS应用池账户提到本地管理员或至少拥有更多操作权限，否则很多命令无法执行，远程登录也受限制。这里我走了一条经典且稳妥的路线：信息收集阶段已经有备份配置文件泄露了数据库账号密码，而数据库恰好是本地的MySQL。

我先查看MySQL的data目录权限，确认root账号能通过UDF提权的方式执行系统命令。MySQL的UDF提权原理并不复杂：如果MySQL进程权限很高，且plugin_dir目录可写，就可以上传一个自定义的函数动态库，然后通过这个函数以MySQL进程身份执行系统命令。现实环境里，很多老旧的PHP站点都会附带可写的MySQL插件目录，这台机器正好命中。

UDF提权成功后的进程权限是SYSTEM，超出了我的预期。拿到SYSTEM权限后，第一件事就是抓取本机内存中的明文凭据或哈希。这里常规工具是Mimikatz，但我考虑到这个工具过于敏感，落地容易被杀，所以选择先用PowerShell读取注册表SAM和LSA信息做离线分析，效果相同但动静更小。

这一步做完后，攻击者的视角已经非常清晰了：当前主机已成内网跳板，拥有SYSTEM权限，抓到的本地管理员哈希，加上之前发现的计划任务域凭据线索——初始立足点彻底站稳了。而站在蓝队视角，到这里一定要回头看看：Web日志里有没有异常上传记录？计划任务为什么会被篡改？主机上为什么会有攻击者的工具落地痕迹？这一连串问题如果平时没有监控和告警，等攻击者真正横向移动到域控时，再想溯源就非常被动了。

3. 横向移动的第一公里：哈希传递、远程执行与内网探测

3.1 为什么哈希传递是Windows内网的"万能钥匙"

Windows的NTLM认证机制中有一个天然特性：只要拿到用户的NTLM哈希，在不需要明文密码的情况下，就能直接通过网络认证登录其他主机。这个过程就叫Pass-the-Hash（哈希传递）。准确说，它不是缺陷，而是设计的一部分，但暴露在内网后就成了攻击面。

在一台已控主机上抓到本地管理员哈希后，我利用impacket套件里的psexec.py脚本，尝试对同一网段的几台Windows主机进行远程命令执行。原理很简单：PSExec通过IPC$共享和管理共享建立连接，再通过服务控制管理器创建远程服务来执行命令，最终返回输出。它之所以经典，是因为远程服务创建本来就是Windows合法的管理手段，大多数安全设备默认不拦截。

我扫描了内网网段，确认存活主机后，将本地管理员哈希提交给crackmapexec进行批量验证。这个工具的作用可以类比为内网横向的"批量钥匙尝试器"：它会对目标主机依次尝试哈希认证，并回显当前账号是否具有管理员权限。在我复现的此环境中，有一台老旧的Windows 7主机、一台未做安全加固的文件服务器，都直接接受了这个本地管理员哈希，意味着只需要一条命令就可以在它们上面启用远程服务执行命令。

横向移动的Gręt在于：一旦环境中的一个账号在某台机器上是管理员，那么该账户的哈希在该环境的所有机器上可能都有相同的权限，除非使用了独特的本地管理员密码方案。这就是为什么微软和所有安全指南都强调，内网中必须启用本地管理员密码解决方案（LAPS），让每台机器的本地管理员密码不同，并严格限制域管理员账户在普通机器上的登录行为。

3.2 内网拓扑梳理：血液、IP与关键路径

横向移动进行到一定程度时，信息量开始爆炸。如果不知道内网到底有哪些子网、哪些机器承担什么角色，后续操作就会像无头苍蝇一样乱撞。这里我用了几种不同的探测手段，把网络拓扑逐步拼了出来。

先通过已控主机的路由表，判断网络大概有几个网段。我在Web服务器上看到的静态路由提示存在192.168.20.0/24和172.16.30.0/24两个核心网段。然后通过ARP缓存和nbtscan探测同网段的活跃主机，再用BloodHound采集域信息，把所有已知的主机名、IP、登录会话、组成员关系全部汇总到一张"地图"里。

这里必须重点聊一下BloodHound。它本质是一套图数据库分析工具，通过采集域内的ACL、组关系、登录会话等信息，建立节点和边的关系图，一眼能看出攻击者可以走的横向路径。比如它能直观展示："用户A对主机B有管理权限，且域管理员在主机B上有会话，所以通过窃取主机B上的凭据就能获取域管权限。"这种路径推导如果靠手工，可能要翻几十条ACL和数千个安全标识符，而用图数据库几乎零成本。

我把采集结果转成JSON导入，然后打开图形界面查看。发现两条关键路径：第一，文件服务器上存在一个交互式管理员会话，这个管理员属于域管理员组的嵌套成员；第二，核心网段的一台数据库服务器开放了WinRM端口，且当前域的IT支持组对它拥有完全控制权限。这两条路径合在一起，基本锁定了后续动作的目标：先通过文件服务器或数据库服务器拿到一个更高权限的账户，然后尝试直接访问域控制器。

3.3 横向移动中的武器选择：如何分清轻重缓急

横向移动不是工具越强越好，关键是每一步都要和当前权限匹配，尽量少留下日志痕迹，避免触发EDR规则。我整理一下我当时的工具选择思路，这段经验值得你好好收藏。

我在这个阶段没有一上来就用PsExec在每台机器上跑命令，而是优先用WMI和WinRM做验证。为什么？因为PsExec会在远端创建服务，而很多EDR和Windows日志审计会把事件ID 7045当作高危行为——你看到的攻击者痕迹里，这是最容易被揪出来的一个特征。而WMI调用虽然也会记录进程创建，但事件量太大，很多企业根本没有开启对WMI活动的专项告警，自然就成了横向移动的低调通道。

还需要提醒一点：任何远程执行方式都会在目标主机留下凭据使用记录，这就是为什么攻击者在横向移动之后一定要清理痕迹，也是为什么防守方要认真审计4617（账户登录）事件和4624（成功登录事件）。如果你是蓝队，看到同一账户在短时间内在多台主机上登录，基本可以直接判定横向移动。

4. 域控前的最后一道坎：域管理员权限获取的经典路径

4.1 Kerberoasting：给"上帝钥匙"做离线破解

现在我已经控制了多台普通业务主机，手里有几个本地管理员哈希，也梳理出了域结构。但要做真正意义上的"域渗透"，目标只有一个：拿到域控制器的管理权限。通往域管权限的道路通常有几条，而我这几个案例中最典型的，是通过Kerberoasting攻击拿到了域服务账户的凭证，然后一步步提升到域管理员。

Kerberoasting的原理可以这样理解：域内每个服务实例都对应一个服务主体名称（SPN），运行服务的账户可以是普通域用户，也可以是服务账户。Windows的动态Kerberos认证机制允许任何域用户请求某个SPN对应的服务票据（TGS票据），而这个票据是用服务账户的哈希加密的。拿到加密票据后，攻击者不用再接触域控，只需要在本地对这个票据做离线暴力破解，猜出服务账户的明文密码，就相当于拿到了服务账户的完整身份。

具体操作是利用impacket的GetUserSPNs.py枚举域内所有SPN账户，然后对返回的高权限服务票据做字典攻击。我筛出的目标是sqlsvc账户——这台数据库服务器上的SQL服务使用独立域账户运行，而且从BloodHound的图来看，它对多台关键业务服务器有本地管理员权限。更绝的是，这个账户的密码复杂度不高，是一个带年份的常见单词组合，字典大概跑了十几分钟就解出来了。

我要特别说一句：Kerberoasting之所以在几乎每个域环境都能奏效，不是因为它是什么高深技巧，而是服务账户默认设置的密码策略往往不合规。很多管理员给服务账户设置的密码是Service@2020这种能猜出规律的组合，从不轮换，从不检查是否加入域的敏感组。你可以立刻自查：打开域控制器的Active Directory用户和计算机，筛选服务账户，检查一下它们是否具备域管理员属性成员关系——如果有，问题就很严重了，因为攻击者拿到这个服务账户，等于直接开通了一条通往域管权限的隐蔽通道。

4.2 Kerberoasting之后的横向跃迁：从服务账户到域管理员

拿到sqlsvc账户的明文密码后，攻击面迅速扩大。因为这个账户对数据库服务器有管理权限，我先通过crackmapexec验证它能够在相关主机上执行远程命令，再于数据库服务器上收集当前登录会话。这里我期待看到的是"域管理员恰好在本机上有活动会话"，这样就能直接抓取域管哈希——这被称为"登录会话劫持"类攻击。

现实往往不如想象顺利，这台数据库服务器上没有一个域管理员会话，说明管理员平时不常登录这台服务器。但这不代表路径断了。我换了一种思路：先利用sqlsvc账户在这台服务器上执行命令，再通过读取本地注册表获取这个服务账户的名称和权限配置，发现它竟然被加入了Backup Operators组。这个组有一个典型能力：可以绕过文件系统权限，对域内任何文件做备份读取，包括关键的NTDS.dit文件——也就是Active Directory的数据库。

严格来说，Backup Operators组的默认权限已经在较新的补丁中有所收敛，但很多企业环境没有跟进更新，仍然存在历史遗留的宽松配置。我尝试通过卷影副本（Volume Shadow Copy）或者直接访问域控的C:\Windows\NTDS\目录读取NTDS.dit，但因为防火墙规则和权限配置限制，这条路没有直接走通。这说明我当前账户的权限边界还没有扩展到域控本身，只是用服务账户登录目标服务器。

不过，我已经确认了下一步的目标：利用sqlsvc对另一台计划任务服务器有本地管理权限这一点，在那台服务器上搜索配置文件或脚本中可能硬编码的域管凭据。这种操作听起来有点"碰运气"，但在实际攻防中，硬编码凭据出现的概率高得惊人，尤其是企业内部脚本。如果管理员在部署自动化脚本的时候，图省事将域管密码直接写在批处理文件里，而且文件权限没有收紧，那几乎等于把域控钥匙送到了攻击者手里。

4.3 拿下域管权限：脚本中的硬编码凭据

重复一遍思路：所有内网渗透的路径，要么是"凭据窃取→权限扩张"，要么是"权限扩张→进一步凭据窃取"。攻击者的核心目标始终是获取域管理员凭据，然后通过DCSync攻击或直接登录域控来完全掌控整个域。我这个案例，最终就是通过硬编码凭据走通的。

在计划任务服务器的C:\Scripts\目录里，我翻到了一个名为backup.ps1的PowerShell脚本。当时第一眼就注意到，脚本的末尾硬编码了一个以sa开头的字符串，配合ConvertTo-SecureString解密函数。以从业者的直觉，这大概率是个数据库账号密码，而不是域管理员密码。但抱着"多验证一下"的态度，我用这个密码去试了域控和其他关键服务器的管理员登录，结果非常意外——它居然就是域管理员的密码。

事后复盘，这个密码是运维人员图省事，把域管理员密码同时用作数据库备份账户密码，造成了凭据跨系统复用。以前我说过很多次，账号复用和凭据明文存储是域渗透能够成功的终极原因。有了这个密码，我直接用impacket的secretsdump.py对域控执行DCSync，从域控同步出所有域用户的哈希。DCSync的底层原理是模拟域控之间的复制协议，向真实域控请求密码数据，只要发起请求的账户具有Replicating Directory Changes和Replicating Directory Changes All权限，就能拿到整个AD数据库的哈希。而域管理员默认就具备这两个权限，所以这一步几乎没有任何阻碍。

DCSync执行完，输出里出现了krbtgt账户的哈希和所有域账号的哈希。krbtgt哈希之所以关键，是因为它用于签发域内所有Kerberos票据的密钥——掌握了krbtgt哈希，攻击者就可以伪造任何用户的票据，甚至创建一个不存在的用户，授予其任意权限，这就是所谓的黄金票据攻击。到这一步，整个域环境就彻底被控制了：我是真正意义上的"域管理员"。

5. 从攻击者的视角反推防御：域环境加固的落地方案

5.1 凭据治理：告别哈希传递和Kerberoasting的温床

纵观整个过程，攻击链表面的脉络是："外网备份泄露 → 数据库密码 → WebShell → 本地提权 → 哈希传递 → Kerberoasting → 硬编码凭据 → DCSync"。但本质上，这些步骤中最核心的驱动力只有一个：凭据管理混乱。防御端的优先任务，就是把这个驱动源掐断。

具体落地建议，我按优先级排一下。

第一件事：限制本地管理员在不同主机上的复用。如果每台服务器的本地管理员密码相同，攻击者拿到一个本地管理员哈希就能横切整个网段。部署微软官方推荐的LAPS（Local Administrator Password Solution），定期随机化每台主机的本地管理员密码，就能直接让哈希传递的批量验证失效。

第二件事：收敛服务账户权限。所有服务账户一律不加入域管理员组、Account Operators组、Backup Operators组等高权限组。服务账户密码必须独立、随机、定期更换，至少一年一次，最好结合托管服务账户（gMSA）来自动管理密码。

第三件事：禁止在任何脚本和配置文件中明文保存凭据。必要时改用Windows凭据管理器或者专门的密钥管理方案。运维脚本中如果需要使用账号，也应该是最小权限的专用账户，而不是域管理员。

第四件事：开启凭据保护。对Windows 10和Windows Server 2016以上的机器启用Credential Guard，将桌面登录凭据隔离在虚拟化安全进程里，这样Mimikatz类工具就没法再从内存中直接抓取哈希了。

5.2 攻击检测与日志审计：让攻击链每一步都能被发现

除了从账号治理上掐断攻击路径，防守方还必须让攻击过程可追踪、可告警。如果每一次命令执行、每一次服务创建、每一次票据请求都有日志留下来，攻击者的推进成本就会成倍提高。下面这张表是我认为域内必须重点监控的日志事件，你可以直接拿回去对照SIEM或日志平台的规则配置。

这里面最容易忽略也最值得关注的是事件ID 4769。当攻击者做Kerberoasting时，他会在短时间内发出大量针对服务账户的TGS请求，正常用户不会在几秒内请求几十个服务票据。你可以在域控上开启Kerberos审计，同时对加密类型为RC4的服务票据请求设置告警——虽然业务环境兼容性要求有时不得不保留RC4，但至少要让管理员知道这类请求发生的频率和来源。

另外一个值得投入的是对LSASS进程的保护。Windows提供了PPL（Protected Process Light）机制，将LSASS配置为受保护的进程，普通权限和非签名驱动就没法注入或读取LSASS内存。这种保护本身不复杂，可以在本地安全策略中开启，但很多企业没有这样做，导致Mimikatz类凭据窃取工具在域内畅通无阻。

5.3 纵深防御架构：给内网加上几道"闸门"

最后想聊聊架构层面的思路。上面提到的凭据治理和日志检测，解决的是"攻击者进来了怎么办"，但最理想的状态，应该是让攻击者压根进不到关键区域。这需要通过内网分段和访问控制来实现。

我建议至少把内网划分为三个信任级别：互联网边界区、业务服务器区、核心数据区。Web服务器这类面向外部的系统放在边界区，它即使被打穿，也不能直接访问业务区内的文件服务器和数据库服务器。安全组规则里一律使用显式拒绝，在核心区与其他区域之间，部署独立的防火墙或ACL。攻击者在边界区拿到的权限，应该让他无法直接路由到核心区，必须跨越单独的跳板机才能访问，而跳板机的登录行为要被严格的审计。

域控的选择也很关键。域控制器是内网安全皇冠上的明珠，它必须独立放在一个特殊的管理网段，禁止承载任何业务角色，拒绝来自非管理员的445和5985访问。域管员日常登录域控时使用的账户，必须是专门的高权限账户，不能和日常办公账号混用，最好配合管理员账户密码分离方案，让每一次域管操作都通过PAW（Privileged Access Workstation）执行。

最后再补充一个很小的但很多人都会忽略的点：本地系统的NetBIOS和LLMNR名称解析。内网中如果开启了LLMNR，攻击者可以通过响应虚假名称解析请求来捕获域用户的NTLM哈希，这是一种几乎无声的凭据窃取方式。建议在组策略中直接关闭LLMNR，并为无法解析的名称配置严格的DNS后缀搜索规则。

6. 写在复盘最后：攻防两端都该记住的几件事

这次完整的域渗透复盘走下来，我最大的体会是：真正的安全短板几乎永远出在管理侧，而不是技术侧。备份文件目录可访问、密码复用、服务账户进高权限组、脚本明文保存凭据、本地管理员密码相同……每一个环节看起来都是小问题，但串联起来就是一条让攻击者通往域控的笔直高速路。

如果你是在做防御，不妨把自己代入攻击者的角色，用我上面这条链路去检查一遍你的域环境：外网有哪些系统直接暴露？它们的备份和日志是否被保护？普通业务服务器上的本地管理员密码是否相同？服务账户是否被加入过高权限组？脚本中是否存有明文凭据？对域控的连接请求有没有监控？这些检查项并不复杂，但每落实一项，攻击者的成本就会显著上升。

如果你是在学习，我的建议是：先把自己手上的靶场环境搭起来，把域控、终端、文件服务器、Web服务器的典型架构跑通，按照我复盘的流程一步步走。过程中注重理解每一个步骤的底层原理，而不是单纯拷贝命令。真正的内网渗透高手，不是那些背了几百条命令的人，而是能说出"为什么这一步要选这个工具""这个凭据在域内还能访问什么"的人。

这次的项目算是告一段落了，但攻防双方的技术对抗永远在继续。希望这篇复盘能帮你在域渗透和域防御这两条线上都建立起更清晰的认知，至少在看到可疑的Kerberos请求、异常的SMB连接或者莫名出现的计划任务时，你已经知道背后可能发生了什么。