蓝队必读！约束委派那些坑，我差点被“合法”权限坑惨了，泣血总结的检测方案
哎，兄弟们，今天咱们不聊那些花里胡哨的渗透技巧，咱就聊聊一个让蓝队又爱又恨的东西——约束委派，说实话，我刚接触这玩意儿的时候，真是一个头两个大，感觉比看天书还难，但后来被红队按在地上摩擦了几次，才算是彻底明白了这玩意儿的重要性，我就用我这“血泪”换来的经验，跟你好好唠唠，这约束委派到底是个啥，以及咱们蓝队到底该怎么检测！文章最后有干货,记得看到底。
先说说，我为啥对这玩意儿这么敏感？ 你想想啊，域环境里，服务账户本来权限就大，要是再配置了约束委派，那简直就是给攻击者开了一扇“合法”的后门，红队那些家伙，拿到了一个配置了约束委派的服务账户的哈希或者TGT，那就能以该账户的身份，去访问指定的服务，这过程，说实话，在日志里看，完全是“合法”操作，你要是没点眼力劲儿，根本发现不了，我第一次遭遇这事儿的时候，看到日志里那个服务账户的登录记录，我还以为是自己误操作，差点就把这事儿当正常流量给放过去了，后来复盘的时候,冷汗都下来了。
那到底啥是约束委派？ 通俗点讲，就是域控告诉某个服务（比如IIS，SQL Server），“嘿，你可以代表你的用户去访问那个特定的服务”，这权限是被限制的，只能去访问指定的SPN（服务主体名称），听起来是不是挺安全的？但坏就坏在，它的限制只针对“服务”，不针对“用户”，只要这个服务账户被攻破，攻击者就能拿着这个服务账户的票据，模拟任意用户去访问目标服务，尤其是那个“非约束委派”的升级版——仅使用 Kerberos 的约束委派，攻击者甚至能直接申请一个可转发的TGT，那威力，啧啧，想想就头疼，咱们蓝队监控的重点,就是要紧盯这些配置了约束委派的账户！
最关键的问题来了，咱们蓝队该怎么检测？ 别急，我这儿有一份自己总结的“三板斧”,保证好用。
第一板斧：查配置，盯死“敏感”账户。 这可是基本功啊，各位！你需要定期去扫描域内所有配置了约束委派的账户，可以用PowerShell命令，比如Get-ADObject配合msDS-AllowedToDelegateTo这个属性来查询，一旦发现哪个账户的委派目标是高危服务（比如域控的LDAP、CIFS等），或者委派账户是特权组里的成员，那就要立刻拉响警报，说实话，这个动作做起来不复杂，但能防患于未然，特别解压，跟大扫除一样，把家里的垃圾清空,心里那叫一个舒坦。
第二板斧：看日志，警惕“异常”的Kerberos事件。 兄弟们，这是核心中的核心！敲黑板！你需要重点关注事件ID 4769（Kerberos服务票据请求），当看到请求的票据带有 “可转发”（Forwardable） 标志，并且用户名是一个服务账户，目标又指向另一个高价值服务时，十有八九就是攻击者在作祟，特别是，如果这个请求来源IP和该服务账户平时的工作习惯不符……哎呦喂，那就更不用说了，绝对是“夜猫子进宅，无事不来”。事件ID 4768（TGT请求）如果出现异常，比如请求方是个服务账户，并且选项里带了Enc_tkt_in_skew什么的，也得多留个心眼，这感觉，就像是在一堆正常流量的灰堆里，执拗地找那一点火星子，累,但值！
第三板斧：行为分析，结合上下文。 这算是高阶玩法了，你别光看单一的事件，要结合起来看，在同一个时间段内，攻击者可能先通过了AdminSDHolder的滥用或者SID History注入拿到了高权限，然后再配置委派，咱们得把 4769 和 5136（修改目录服务对象）、4670（对象权限修改）等事件关联起来看，一旦发现服务账户的msDS-AllowedToDelegateTo属性被修改，且随后出现了大量针对敏感服务的票据请求，那铁定就是出事儿了，这就像看侦探剧，得把所有的线索穿成一条线，耐心，太需要耐心了，但找到真凶的那一刻,爽飞了！
唉，说了这么多，真是一把辛酸泪。 说实话，每次做蓝队检测，都感觉是在跟红队玩猫鼠游戏，心理压力贼大，有时候看到那些日志，我都怀疑自己是不是有受虐倾向了，但没办法，安全这行,就得有这种死磕到底的劲儿！
约束委派这个机制本身是个好工具，但用不好，就是悬在头上的利剑，作为蓝队，咱们不仅要懂它，更要会查它，防它，上面说的那三招，是我在实战中摔了不少跟头才总结出来的，希望对兄弟们有所启发。千万别嫌麻烦，多看一眼日志，多做一次扫描，可能就避免了一次严重的失陷，好了，今天先聊到这儿，我得再去翻翻今天的告警日志了,咱们改天接着唠！