service渗透

去年秋天，我在一个客户现场做内网排查。他们的运维团队一直觉得"服务账户密码够复杂就安全"，直到我在一台跳板机上翻出一个名为svc_backup的账户，密码是Backup@2023。这个账户在域里躺了四年，权限是Domain Admin。

问题不在密码本身。问题在于这个账户被配置成了某个备份服务的登录身份，而那台跑备份服务的机器，补丁落后了七个月。

服务账户为什么是软肋

普通用户账户有交互式登录行为——有人每天登录、注销，异常活动容易被发现。服务账户不一样。它设计出来就是给程序用的，没人盯着它什么时候登录、从哪台机器登录。一个服务账户可以在凌晨三点从一台你根本不知道存在的服务器上请求Kerberos票据，日志里看起来完全正常。

更麻烦的是权限继承。很多企业给服务账户授予过高权限，因为"省事"。SQL Server要访问文件共享？给个Domain Admin吧。IIS应用程序池要调用另一个服务？加到管理员组吧。这些决定在部署当天看起来合理，三个月后没人记得。

我见过最离谱的一个案例：某公司的监控系统服务账户，密码写在GitHub上一个公开仓库的配置文件里。那个仓库是两年前一个实习生建的，用来做内部工具的原型。实习生走了，仓库还在，密码没换过。

Kerberoasting：不碰密码也能拿到哈希

Kerberoasting是我在渗透测试里用得最多的手法之一。原理不复杂：任何域用户都可以向域控请求某个服务账户的Kerberos服务票据（TGS），而这张票据是用服务账户的NTLM哈希加密的。拿到票据之后，离线爆破就行。

关键在于，这个过程不需要管理员权限，不需要触发任何警报。你只需要一个普通域账户，加上几行PowerShell。

Add-Type -AssemblyName System.IdentityModel Set- SPN -Identity "MSSQLSvc/db01.corp.local:1433" New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/db01.corp.local:1433" 

票据到手，用Rubeus或者hashcat跑字典。如果服务账户密码是Summer2022!这种，几分钟就出来了。出来之后能干什么？取决于那个服务账户的权限。如果是配置了无约束委派（Unconstrained Delegation）的账户，你可以直接冒充域管。

一个真实的横向移动路径

回到开头那个客户。我拿到svc_backup的哈希之后，没有直接破解——密码太复杂。但我注意到这个账户配置了无约束委派。这意味着我可以诱导域控向这台机器发起认证，然后捕获域控的TGT。

具体操作：用svc_backup的身份在跳板机上跑一个打印后台程序（Print Spooler），然后用PetitPotam或者PrinterBug强制域控回连。域控的TGT落到我手里，接下来就是DCSync，拿krbtgt哈希，做黄金票据。整个过程从普通域用户到域管，不到四十分钟。

客户的安全团队事后复盘，发现所有环节的日志都有记录，但没有任何告警规则覆盖"服务账户异常请求TGT"这个行为。他们的SIEM只监控了交互式登录失败和特权组变更。

防御不是改密码那么简单

给服务账户换复杂密码有用，但不够。Kerberoasting的本质是"任何域用户都能请求服务票据"，密码强度只是增加了爆破成本。真正的缓解措施是：

用Group Managed Service Accounts（gMSA）。密码由AD自动管理，128位随机，每30天轮换。攻击者拿到的票据加密密钥一直在变，离线爆破的窗口期极短。代价是配置麻烦，很多老应用不支持。

另一个方向是监控。服务账户的TGS请求应该有基线——哪个账户、从哪台机器、请求哪个SPN、什么时间。偏离基线的行为直接告警。我在客户现场部署过一条简单的规则：同一服务账户在五分钟内请求超过三个不同SPN的TGS，触发调查。一周内抓到两次内部扫描。

最后，别给服务账户Domain Admin。这句话听起来像废话，但我每次渗透测试都能遇到至少一个。把服务账户放进专门的OU，用组策略限制它的登录范围，只允许在特定机器上作为服务登录。这些操作不复杂，只是没人做。

服务渗透的核心逻辑就一句话：攻击者不关心你的边界防火墙多贵，他们只关心哪个账户能在内网里安静地移动。svc_backup就是那个账户。

很赞哦!（787）