内网安全评估做到第三周的时候我在一份共享文件夹的ACL导出清单里看到了一个非常扎眼的组名SHARE MODERATORS。这个组在域里并不显眼不在本地管理员组也不在任何域管理组里可它的权限范围却覆盖了全公司的核心共享目录——财务、研发、人事、行政几乎全占了。当时第一反应就是这组到底是干什么的谁把它建出来的为什么它能对这些共享目录做完全控制顺着这个组名往下查我发现了一条被绝大多数人忽略的权限滥用链路。这篇文章就把这次排查的全过程、根因分析和收敛方案完整写出来给正在做内网安全治理的同行一个参考。1. 初见SHARE MODERATORS一个名字听着无害、权限却大得吓人的组1.1 场景还原审计任务里冒出来的陌生组名当时我们在给一家做共享文档协同的企业做内网安全评估重点排查共享服务器上的权限配置是否合理。这类评估的常规操作是先枚举域内所有共享资源把每个共享目录的ACL导出来再逐个核对哪些组或用户额外拥有了写权限或完全控制权。在导出结果里SHARE MODERATORS这个组反复出现。它在十几个核心共享目录上拥有“完全控制”权限其中包括包含薪资数据的财务共享目录、包含源代码的研发共享目录。我翻了一下AD里的组定义组的描述写的是“负责共享文件内容审核与发布”创建时间是两年前创建者和原因都没写。组成员一共有七个人看起来都是普通业务部门的人没有一个属于IT或安全团队。仅从名字和描述来看这组人像是“负责审核共享内容的操作员”属于正常的业务角色。但问题是SHARE MODERATORS的权限是“完全控制”不是“修改”或“写入”——这意味着组成员不仅能增删改文件还能修改共享目录本身的权限设置包括把自己或其他用户添加为管理员、取消别人的访问权、把某个子目录单独拿出来变成新的共享点。1.2 SHARE MODERATORS到底管什么职责定义与权限配置的倒挂为了搞清楚这个组的完整权限边界我用了三条命令做了初步摸底。第一条是查看组成员Get-ADGroupMember -Identity SHARE MODERATORS | Format-Table Name, SamAccountName, ObjectClass第二条是列出所有包含该组的ACL条目Get-ChildItem -Path E:\Shares -Recurse -Force | Get-Acl | Where-Object { $_.AccessToString -match SHARE MODERATORS } | Format-List Path, Owner, AccessToString第三条是查该组是否被其他组嵌套加入因为AD组是可以套娃的一个组可能是另一个组的成员Get-ADGroup -Filter * -Properties MemberOf | Where-Object { $_.MemberOf -match SHARE MODERATORS } | Format-Table Name, MemberOf结果让人眉头一皱。这个组不仅直接挂在十几个共享目录的ACL上还被嵌套进了两个业务组的成员列表里。也就是说只要进了那两个业务组的任何人等于间接获得了SHARE MODERATORS的完全控制权。组里的七个直接成员反倒不是最危险的危险的是那两条嵌套关系带来的隐性成员。一个负责“审核内容”的组理论上应该只有读取、编辑、发布文件的权限对应NTFS权限里的“读取”“写入”或“修改”就够了。但它被配置成了“完全控制”再加上嵌套组成员实际影响范围完全超出了这个组的设计初衷。这种职责与权限倒挂的情况在内网里其实很常见恰恰因为它不在一眼就能看到的高危位置上才更容易被忽视。2. 权限倒挂的真相为什么这个组会变成内网横向移动的突破口2.1 从共享资源管理员到内网资源接管权限链路的三个反常点SHARE MODERATORS这种组的危险性不能只停留在“权限太大”这个表面认知上要理解它为什么能成为内网横向移动的跳板得拆开看权限链路里的三个反常点。第一个反常点是权限级别。NTFS权限和共享权限是两层叠加的实际最终权限取两者交集。很多运维团队会把共享权限设成Everyone完全控制指望NTFS层面去限制这种做法本身就留下了隐患。SHARE MODERATORS在共享权限上是大范围高层级授权在NTFS上又是完全控制两层叠加毫无收敛。第二个反常点是管理边界消失。完全控制权限意味着被授权者可以修改自身权限这在权限管理上叫“ACL自举”。一旦某个组的权限里包含“更改权限”或“取得所有权”那这个组实际上就是一个潜伏的管理员组。组成员不需要去域管提权只需要在自己有权限的共享目录上把自己加进去就能持续保持访问能力甚至可以在目录上创建隐藏共享方便后续连接。第三个反常点是嵌套关系。组嵌套是AD设计中的正常功能但在权限治理不完善的环境里嵌套关系会像毛线球一样越滚越大最终没人能说清一个用户的真实权限边界。SHARE MODERATORS被嵌套进业务组后任何一个业务组成员都可以通过正常的身份验证拿到共享资源的完全控制权这中间甚至不需要任何漏洞利用。2.2 攻击者眼中的价值SHARE MODERATORS的三种典型滥用姿势从攻击者视角来看拿到一个SHARE MODERATORS组成员账号或能假冒该组成员的身份意味着三件事第一共享文件的高价值数据相当于不设防。财务共享目录里的工资表、报销明细研发共享目录里的设计文档、未发布项目资料人事目录里的劳动合同、绩效信息全都可以直接读取和复制。第二可以通过修改ACL实现隐蔽驻留。攻击者可以新建一个专门用于后门的隐藏账号把这个账号添加到某条共享目录的ACL里再删除所有操作记录。这样即使原本的SHARE MODERATORS组成员被清理后门账号依然保留访问能力。第三共享服务器可能成为横向移动的中转站。内网里的业务服务器、数据库服务器经常存在配置备份、连接脚本等敏感文件而这些文件有时会被运维人员放在共享目录里。攻击者拿到共享目录的完全控制权后可以检索这些文件提取数据库连接字符串、服务账号密码等凭据再横向跳到更核心的系统。这几种滥用姿势的共同点是不需要攻击者具备多高的技术能力不需要利用系统漏洞纯粹靠现有权限配置就能完成。这也是权限滥用类风险最麻烦的地方防御方往往很难对这类行为做有效检测因为攻击者的操作在系统看来都是合法登录、合法读写的正常行为。3. 复现一条完整的风险路径从普通账号到共享资源控制权3.1 信息收集阶段攻击者如何发现高价值组站在模拟攻击的角度信息收集是第一步。在这个阶段攻击者通常已经拿到了一个低权限域账号可能来自钓鱼邮件、密码喷洒或泄露的凭据库总之是一个看起来人畜无害的普通账号。有了这个账号攻击者会开始枚举域环境。PowerShell自带的AD模块是最常用的工具# 枚举所有共享资源 Get-SmbShare -ComputerName 共享服务器名 # 枚举某个共享目录的ACL Get-Acl -Path \\服务器\共享名 | Format-List # 查看当前用户所在的所有组 whoami /groups # 查询组嵌套关系 Get-ADGroupMember -Identity SHARE MODERATORS -Recursive用这类命令攻击者可以在几分钟内把整个域里所有共享资源的ACL全部摸一遍找到哪些组拥有完全控制权限哪些组的成员数量少哪些组的命名看起来不起眼。SHARE MODERATORS恰好满足了全部条件权限极大、名字低调、嵌套成员多。自动化分析阶段攻击者可能会借助一些图形化分析工具把这些ACL关系、组成员关系、登录会话关系导入进去生成攻击路径图。这类工具自动标红的通常是“域管理员”“企业管理员”这类目标但真正熟悉内网的人也会关注“完全控制共享目录”这类路径因为它往往比提权到域管更隐蔽、更快见效。3.2 权限利用阶段滥用流程拆解假设攻击者已经拿到SHARE MODERATORS某个组成员的账号或者通过其他方式获得了该组的令牌后续的滥用流程大致分为四步。第一步是枚举可访问的共享资源确认哪些目录能吃下、哪些目录里放着高价值文件。这种枚举在Windows环境下很直接# 列出所有可写共享 net share第二步是直接读取高价值文件。财务目录下的Excel报表、研发目录下的项目计划、人事目录下的薪酬制度这些都是可以直接拖走的数据。如果目录里的文件太多攻击者通常会先搜索关键词缩小目标范围。第三步是修改ACL实现权限持久化。攻击者会在某个共享根目录上创建子目录并把一个自己控制的账号加进ACL赋予完全控制权限。或者更直接一点直接把后门账号加进SYSTEM组的某个不起眼的位置。这一步操作下来即使原来的组被清理攻击者依然拥有访问能力。第四步是横向移动。攻击者会继续翻找共享目录里可能存在的配置信息比如IIS配置文件里保存的数据库连接字符串、服务器部署文档里的远程连接方式、备份脚本里的服务账号凭据。这些信息一旦被提取攻击者就能从共享服务器的控制权跳到数据库服务器或业务应用服务器的控制权。3.3 收尾与痕迹处理攻击者可能会做的动作收尾阶段的常见操作包括清除访问日志、删除临时创建的账号、把修改过ACL的目录恢复原状也可能故意不恢复以便持续访问、导出数据后把原始文件的时间戳改回去。这里特别要提一个容易被防御方忽略的点攻击者修改ACL之后如果再把ACL改回原样系统日志里通常不会留下多少痕迹。Windows默认只记录登录事件和部分对象访问事件对ACL修改事件的审计默认是不开启的。很多企业在这一次评估前根本没有开启目录服务变更审计所以攻击者的ACL篡改操作可能完全不可追溯。这也解释了为什么每次内网安全评估我都建议优先排查“谁拥有完全控制权限”而不是“谁最近登录了服务器”因为前者暴露的是结构性问题后者只能发现已经发生的入侵行为。4. 排查与确认我们验证这条隐患链路的完整过程4.1 组权限审计的实操命令与工具这次排查中我们发现SHARE MODERATORS的问题后没有急着改权限而是先做了一次完整的风险确认。三步走第一步是确认组的完整权限边界。不仅看当前共享服务器上的ACL还把该组在所有域内其他资源上的引用全部拉出来。这一步用的是# 导出当前共享服务器上所有ACL的引用 $paths Get-ChildItem -Path E:\Shares -Recurse -Force foreach ($p in $paths) { $acl Get-Acl -Path $p.FullName foreach ($acc in $acl.Access) { if ($acc.IdentityReference -match SHARE MODERATORS) { [PSCustomObject]{ Path $p.FullName Identity $acc.IdentityReference.Value Rights $acc.FileSystemRights AccessType $acc.AccessControlType } } } } | Export-Csv -Path share_moderators_acl.csv -NoTypeInformation第二步是确认组成员及嵌套关系。这一步要看的是“实际可能影响的人”潜在成员和直接成员都要查Get-ADGroupMember -Identity SHARE MODERATORS -Recursive | Select-Object SamAccountName, ObjectClass | Sort-Object ObjectClass, SamAccountName | Format-Table第三步是对比职责定义。我们把组描述、部门汇报关系、日常使用记录全查了一遍确认这个组当前的实际用途只是给业务人员开放共享目录的读写权限没有任何一项工作需要“完全控制”。这三步走完结论已经很明确了SHARE MODERATORS的权限配置严重超出实际业务需要且组内成员本身也没有对应的安全授权记录属于典型的权限滥用风险。4.2 风险定级哪些指标决定危害程度这次评估中我们把类似的组权限风险分为三个等级。高风险组的特征权限级别为完全控制或取得所有权组成员或嵌套成员覆盖多个业务部门组内存在服务账号或离职未禁用账号组能访问包含敏感数据的目录。中风险组的特征权限级别为修改或写入组成员不超过五人目录包含重要业务数据但不是核心机密。低风险组的特征权限级别为读取组成员角色与权限职责匹配目录数据敏感度较低。SHARE MODERATORS初评时每一项都踩在了高风险指标上。尤其严重的是该组能访问的目录里包含财务数据和源代码这两个类型的数据在任何企业的安全等级里都属于高敏感级别。换句话说一旦这个组的某个成员账号被攻破攻击者拿到的是一把能打开公司核心资产大门的钥匙。4.3 排查中容易踩的坑排查权限风险时有几个坑值得单独提一下。第一个坑是只看共享权限不看NTFS权限。共享权限和NTFS权限是两套系统最终生效的是较严格的交集。如果只导出了共享层的ACL可能会漏掉NTFS层的过度授权。反过来也一样有些目录NTFS权限正常但共享层权限过宽。必须两层一起看。第二个坑是忽略组嵌套。很多运维人员在导出组成员时用的是非递归查询只看到直接成员看不到嵌进来的业务组成员。这种遗漏会让风险被严重低估。第三个坑是误以为管理员组才需要关注。域管理员和企业管理员固然最危险但这类组通常有完善的监控攻击者反而不会轻易碰。像SHARE MODERATORS这种中间层权限组权限足够大又不够显眼才是攻击者真正会钻的空子。5. 收敛与加固让SHARE MODERATORS回到它本该在的位置5.1 权限收敛的具体操作确认风险后修复方案按优先级拆成了三步每一步都经过测试验证才在生产环境执行。第一步是立即收紧NTFS权限。把SHARE MODERATORS在所有共享目录上的“完全控制”降为“修改”。对于财务、人事这类包含高度敏感数据的目录进一步降为“读取并执行”。这一步直接砍掉了该组修改ACL的能力堵住了权限自举的漏洞。# 以财务共享目录为例移除完全控制赋予修改权限 $path E:\Shares\Finance $acl Get-Acl -Path $path $rule New-Object System.Security.AccessControl.FileSystemAccessRule(DOMAIN\SHARE MODERATORS, Modify, ContainerInherit,ObjectInherit, None, Allow) $acl.SetAccessRule($rule) Set-Acl -Path $path -AclObject $acl执行前先在测试环境验证确认业务侧的文件发布、内容审核流程不受影响再分批推送到生产。第二步是清理嵌套关系。把SHARE MODERATORS从两个业务组的成员列表里移除让权限边界恢复到可控的固定成员范围。这一步同样需要提前跟业务方确认因为有些业务的自动化流程可能依赖旧有权限提前通知可以避免线上故障。第三步是审查现有成员。组里的七个人逐个确认在职的重新走一次授权流程明确其职责与权限匹配离职的账号立即禁用并从组里移除长期未登录的账号标记为待复查状态。同时把组描述更新为当前的职责说明避免后人看到这个组一头雾水。5.2 监控与告警让ACE修改和组变更无所遁形权限收敛做完不等于万事大吉。没有监控的修复是无效修复因为下次很可能还会有人把这个组的权限加回去。我们这次一并启用了三类监控。第一类是配置一个专门针对共享资源的操作审计策略。Windows服务器的高级安全审计策略里开启“对象访问”审计尤其是针对共享目录的ACL变更操作。开启方法是在组策略里配置计算机配置 → Windows设置 → 安全设置 → 高级审核策略配置 → 对象访问 → 文件系统 → 审核更改权限审计开启后任何对关键共享目录ACL的修改都会出现在安全事件日志里事件ID编码为具体的权限变更时监控系统会在第一时间告警。第二类是组变更监控。AD里任何属于核心敏感资源角色比如本案例中被具有高影响力组的成员变动都应该触发工单通知。域控上的安全日志会记录组修改事件把对应事件转发到日志平台并配置规则即可。具体实现可以用一套简单的规则事件内容触发条件响应动作组成员新增非工作时间高优先级告警组成员移除任意时间中优先级通知组权限变更任意时间高优先级告警嵌套组关系变化任意时间紧急告警第三类是敏感目录访问监控。财务、研发等核心共享目录的批量读取、异常时间段访问、非本部门成员的访问行为都需要单独设定规则。这里可以使用文件服务器上的文件访问审计或者第三方DLP系统重点关注单次会话内访问文件数量是否异常。5.3 长效机制权限治理不能只靠一次排查这次事件之后我最大的感触是像SHARE MODERATORS这样的权限滥用问题几乎不可能通过一次排查彻底根治真正起作用的是把权限治理变成一个持续运转的机制。首先是建立权限基线。把每个共享目录的正常权限配置固化成模板新目录上线时必须按模板初始化不允许随手给Everyone或某个组加完全控制。权限变更必须走工单流程变更记录与基线比对偏离基线的变更自动触发复核。其次是定期做ACL扫描。可以用脚本把全量ACL导出后做差异比对频率建议至少每月一次。重点看两类异常一类是新增的完全控制条目另一类是与业务角色描述明显不符的组权限配置。然后是组生命周期的管理。AD里每半年要梳理一次所有组确认组内成员是否仍为在职人员组的职责描述是否需要更新是否存在长期无人使用的僵尸组。对于不再使用的组要立即禁用避免成为权限滥用的载体。最后是与HR流程打通。员工离职、转岗、入职的信息及时同步到AD组管理流程中。这次排查中发现SHARE MODERATORS组里七个人中有两位已经离职超过三个月账号虽然已经禁用但组的关系还保留着谁能保证禁用的账号不会被重新启用呢这一环往往是最容易被忽略的。6. 一点实践经验这次排查留给我的几条检查清单做完整个SHARE MODERATORS权限收敛之后我把这次排查中反复验证的思路简化成了一份检查清单之后在做任何内网权限审计时都会先过一遍。第一先看“完全控制”和“取得所有权”再看“写入”。前两者代表能改权限本身后者只代表能改文件。能改权限的组必须逐一确认业务必要性一个组只有在真正需要管理共享配置时才应该拥有这种级别的权限。第二组成员查询必须用递归模式。只看直接成员很容易漏掉嵌套关系带来的隐性授权这跟看权限必须同时看共享层和NTFS层是同一个道理。第三组名称和描述不能轻信。SHARE MODERATORS这个名字听起来像是负责审核内容的普通组描述写得也像那么回事但实际权限完全不是那回事。一切以ACL实际配置为准文档和描述只能作为参考。第四修复权限前先做业务影响评估。不可否认像SHARE MODERATORS这样的组可能已经和业务流程深度绑定直接砍权限可能导致业务不可用。稳妥的做法是先降到最小够用权限观察一段时间确认业务侧无异常后再做最终收敛千万不要一刀切。最后再分享一个操作细节在导出的权限文件里我习惯按IdentityReference列做一次汇总统计看看哪些组出现在最多目录上哪些组的平均权限级别最高。这种维度往往能快速暴露问题完全控制权限出现频次最高的非管理员组通常就是最值得优先排查的隐患。那次排查我们一共发现了四个类似的组SHARE MODERATORS只是其中最典型的一个。核心资源权限的收敛和治理没有捷径只能通过持续的审计和复盘来不断缩小攻击面。