企业官网建设流程全解析

提到内网安全测试，很多人的第一反应是域控、票据、横向移动这些听着就很有攻击性的名词。但我在一线做了这么多年内网审计，真正让公司数据在内部"裸奔"的，往往不是某个高深的 0day，而是共享文件夹上那组看起来低调的名字——SHARE MODERATORS。这个组名直译过来就是"共享审核员"，负责文件服务器上的共享配置、访问权限调整和共享映射维护。听起来应该只有少数运维人员能用，权限也应该严格收敛，可在实际内网环境里，它被嵌套进高权限组、被错误委派成员添加能力、甚至和 Domain Users 挂钩的情况，我见过不止一次。这篇文章从我在一次授权内网测试中遇到的真实案例出发，讲一讲 SHARE MODERATORS 组权限滥用是怎么被发现的、验证链路长什么样，以及最后如何通过最小权限原则把坑填平。适合负责域环境维护的运维、企业安全审计人员，以及想提升内网安全视野的测试工程师参考。

1. 先弄明白：SHARE MODERATORS 在内网共享体系里是什么位置

1.1 共享文件夹里的两层权限模型：为什么交集规则最容易翻车

在 Windows 域环境里，一个用户通过网络访问文件服务器的共享文件夹，实际上要过两道闸门。第一道是共享层权限，在共享目录的属性里配置，只对网络路径访问生效。第二道是 NTFS 权限，定义在 NTFS 卷上的具体目录和文件里，无论用户通过本地登录还是网络访问，都必须受它约束。最终权限取两道闸门的交集。

举一个最简单的例子：共享层给了某个用户完全控制，但是 NTFS 层只允许读取，那用户实际能做的只有读；反过来，NTFS 层给了完全控制，共享层只允许读取，结果也一样，还是只能读。这个交集规则看起来很简单，但恰恰是最容易翻车的地方。

在实际运维中，很多管理员喜欢在共享层给一个宽泛的授权，比如 Everyone 完全控制，然后寄希望于 NTFS 层去做精细限制。这种做法本身不是绝对不可接受，但风险在于一旦 NTFS 层也出现宽泛授权，或者被某个组嵌套关系绕过，两道闸门就同时失守了。我在一次内网审计中，就见过一台文件服务器的共享层是 Everyone 完全控制，NTFS 层又保留了历史遗留的 Authenticated Users 完全控制，这两个条件叠加在一起，意味着任何登录到内网的域账号都能把该共享里的敏感文件看个遍。

1.2 SHARE MODERATORS 组的"官方职责"与实际权限

SHARE MODERATORS 这个组名不是 Windows 内置的，而是很多企业 IT 在部署共享文件服务时自定义创建的管理组。它的典型职责包括：新建共享、停止共享、修改共享描述；调整共享层的用户授权列表；维护共享映射、DFS 链接和客户端访问；处理文件服务器迁移时的共享配置。

从设计角度看，这种组的权限面应当向 IT 管理团队收敛，成员数量通常个位数，而且不应直接嵌套在 Domain Admins 或本地 Administrators 里。可我在实际环境里见到最多的情况是，这个组慢慢变成了一个"万金油"角色：为了省事，把一个共享的修改权直接挂在 SHARE MODERATORS 上，然后又把一批业务人员拉进这个组。久而久之，组里面的人和组外面的权限已经完全对不上了。

用个生活化的类比来说，SHARE MODERATORS 就像小区的物业管理员。物业管理员有公共区域的钥匙很正常，但如果物业的权限卡能刷开每一户住户的房门，甚至还能把门禁授权随手发给路人，那这个小区基本上就没有安全可言了。共享服务器上的 SHARE MODERATORS 组权限滥用，就是这种"物业卡"现象：一个负责公共配置的管理组，因为权限范围失控，变成了整个文件系统的高权限后台。

1.3 组权限滥用的五种常见形态

结合我自己的排查经验，SHARE MODERATORS 组权限滥用绝大多数逃不出这几种形态：

1. 组被嵌套进高危组。例如把 SHARE MODERATORS 放进本地 Administrators，或者通过某个全局组间接嵌套进 Domain Admins，成员权限就出现了跳跃式的放大。
2. 组成员长期不清理。一个只有 5 个岗位需要使用的管理组，实际成员却高达几十人，其中一半是离职员工或转岗员工。
3. 组的委派权限过宽。在 AD 中，如果某个普通用户对 SHARE MODERATORS 对象拥有了写入成员（WriteMember）的权限，他理论上就可以把自己或其他账号加进组里，这等于把管理通道交给了不该有权限的人。
4. 组被当作业务文档组使用。明明带的是 MODERATORS 的管理属性，却因为图方便，直接把某个部门的文档编辑权限挂在上面。
5. 组在跨域迁移中保留了 SIDHistory，旧域的 SID 仍然指向它，造成历史权限遗留。

其中第 3 种往往最难发现，因为日常看组成员是看不到的，必须检查 AD 对象本身的 ACL 才能发现谁拥有写成员的能力。很多企业把安全重点放在密码策略和防火墙规则上，恰恰忽略了这类"管理通道"的授权扩散。

2. 内网审计视角：如何把这个"隐形管理员"揪出来

2.1 先盘点：用两条命令找出域内可疑共享组

在域环境中，第一步我会把名字里带 SHARE 或者 MODERATOR 的组全部捞出来。在安装了 AD 管理工具的机器上，用 PowerShell 直接查询也可以，但我更推荐用 PowerView 的 Get-DomainGroup，因为它在跨域场景下更灵活，返回的信息也更全面。

Get-DomainGroup -Filter "samaccountname -like '*share*' -or samaccountname -like '*moderator*'" | Select-Object samaccountname, distinguishedname

拿到组名单后，紧接着枚举组成员的完整列表，这里的关键是递归。如果不加递归，只能看到直接成员；加了递归，才能看到嵌套进来的所有用户和组。命令如下：

Get-DomainGroupMember -Identity "SHARE MODERATORS" -Recurse | Select-Object MemberName, MemberObjectClass, GroupDomain

这一步做完，你可以先把结果导出为 CSV 存档，后期每一个变动都有据可查。我在实际排查中，导出 CSV 这个动作相当重要，因为权限治理最后要能回溯：某个成员是什么时候进来的、是通过哪个组进来的、现在是否仍然在职。没有这份基线数据，后面清理的时候很容易出现误删或者漏删。

2.2 再扫共享：把文件服务器上的共享和 ACL 全量摸清

组在 AD 侧看到的只是"人的集合"，真正造成数据泄露的是这个组在文件服务器上的落地权限。所以第二步要对目标文件服务器做共享枚举。在 Windows Server 2008 以后的机器上，直接 PowerShell 就能查：

Get-SmbShare Get-SmbShareAccess -Name "hr_docs$"

如果要批量审计，我习惯用 Linux 侧的工具做一次全量扫描，例如 SMBMap 或者 NetExec（原 CrackMapExec）的 --shares 参数。它们会把目标主机上所有可见共享以及是否可匿名访问一次列出来。隐蔽共享（以 $ 结尾）在这里也能看到，这是手动翻图形界面经常漏掉的点。

smbmap -H fs01

这一步的产出应该是一张"共享-路径-共享权限"对照表。我会把每个共享的 ShareAccess 导出来，再和 NTFS 层的权限做里外比对。很多年代久远的服务器上会有几十个共享，其中至少有三五个是历史遗留的临时目录，连所有者都说不清用途。这类目录就是内网安全测试中最容易出成果的地方。

2.3 最后测"基因"：组嵌套与委派检查，揪出真正的黑手

共享和组成员只能告诉你"当前状态"，要去追溯为什么一个普通用户能拥有管理能力，必须检查组嵌套关系和 AD 对象的 ACL。

递归查嵌套在前面已经做了，这里重点讲检查委派。所谓委派，就是谁有权修改 SHARE MODERATORS 的成员。PowerView 的 Get-DomainObjectAcl 可以直接看：

Get-DomainObjectAcl -Identity "SHARE MODERATORS" | Where-Object { $_.ActiveDirectoryRights -match "WriteMember|WriteDacl|GenericAll|GenericWrite" }

输出中每一行都代表一个主体对该组对象的访问权限。如果出现了一个普通业务账号或者 Authenticated Users，你就应该意识到：这个组的成员名单并不是只有管理员能改，任何拥有该权限的普通用户都能往里面加人。加人之后，再通过组的既有权限去访问共享文件，权限滥用的闭环就形成了。这也是我在真实测试中验证过的最典型的滥用链路之一。

3. 真实复盘：一次授权内网测试里的完整发现链路

3.1 环境与边界：授权测试中的约定

这是某制造企业的一次内网安全测试。客户的目标是评估核心文件服务器是否存在过度共享和权限管理风险。测试前我们与客户签订了明确的授权范围，只允许使用低权限测试账号，不对生产数据做修改，发现敏感文件后立即停止读取并报告。这类约定不是走过场，它界定了你怎么验证、哪些行为不可以做，否则测试本身就可能变成违规操作。

3.2 从普通域账号到读到敏感文件：实测过程记录

测试账号是一个普通的域用户，加入域时间不长，没有任何特殊组成员关系。先从共享枚举开始：

net view \\fs01 /all smbmap -H fs01

很快发现一个名为 hr_docs$ 的隐藏共享，指向的是人事部的共享目录。隐藏共享出现在这里的意义在于，它不是通过常规方式暴露在浏览列表里的，但只要有路径和适当权限就可以访问。接着尝试建立连接：

net use \\fs01\hr_docs$

连接成功。再列目录，里面出现了"绩效评估"和"薪酬核算"两个子目录。此时按照授权约定，我记录下路径后不再继续读取文件内容，进入追根溯源阶段。到这里其实已经足够说明问题：一个低权限测试账号能穿透到人事敏感目录，已经构成了严重风险。

3.3 追根溯源：问题出在哪一层，三层对账

直接读目标共享的访问控制列表，发现三层配置都存在明显问题。为了看清楚，我把三层对账结果整理成了下面这张表：

这三层叠加后，最终效果是：任何域用户都能通过网络共享修改人事文件。这个问题如果仅仅看某一个层面，比如只调整共享层或只调整 NTFS 层，并不能完全堵住，必须三层同时收敛。这也是我把这一类问题叫作"组权限滥用"的原因——真正的问题不在单一配置，而在于组、ACL、共享策略之间的联合失控。

3.4 复盘：这不是单一配置错误

事后和客户运维团队一起复盘，发现问题不是一天形成的。最初搭建文件服务器时，为了图省事，在共享权限上用了 Everyone；后来为了让 NTFS 目录能够被多个部门以不同权限访问，又把一些历史权限直接继承下来，其中就包括 Authenticated Users 的 Modify。SHARE MODERATORS 组的嵌套则是某次"快速授权"过程中，运维直接把 Domain Users 塞进了共享运维组，本意是要让所有人都能读某个公共目录，结果这个组被 SHARE MODERATORS 引用，一不留神就把全员带成了审核员。

整个链条里没有任何一次操作是恶意的，全是图省事和继承叠加出来的结果。这让我想起很多内网安全事件的根因分析：攻击者未必用了多么高深的技术，往往只是顺着管理员留下的权限空隙走了几步而已。

4. 修复与加固：把误配的组权限拉回正轨

4.1 最小权限落地四步法：从盘点开始

修复动作不能只盯着 SHARE MODERATORS 一个组，要做全量收敛。第一步是盘点。把全公司文件服务器上的共享清单、路径、归属部门全部盘出来，找不出业务归属的一律先设置告警，不主动删除。盘点的输出是一张 Excel 矩阵，每一行记录共享名、路径、负责人、部门、主要使用人、共享权限、NTFS 权限。

这个矩阵后续就是权限复核的依据，没有矩阵的权限管理就是一笔糊涂账。很多人问我权限治理从哪开始，我的回答永远是：先把现状摸清，否则改什么都是盲改。

4.2 按业务收敛授权：共享层最小化，NTFS 层精细化

有了矩阵之后，按最小权限原则做三件事：

• 共享层权限最小化。只保留 Administrators、SYSTEM 和必要的管理组，业务侧全部改由 NTFS 层控制。
• NTFS 层权限明确化。对每个业务目录只放对应的业务组，删除 Authenticated Users、Everyone 等宽泛主体。
• 组嵌套纠正。把 Domain Users 从共享运维组中移除，重建一个明确的业务读组，只挂接确实需要该共享的人员。

以这次遇到的情况为例，hr_docs$ 的共享权限改为只允许 Administrators 和 SHARE MODERATORS；hr_docs$ 目录的 NTFS 权限只保留人事部组的读取和写入。这样即便共享层的管理组出现问题，NTFS 层也还守得住最后一道防线。

4.3 给 SHARE MODERATORS 组做"瘦身"：从权限源头收口

组的瘦身要从两个维度同时进行。成员维度上，清退掉非运维岗位的账号，入组必须经过审批，并记录工单号。安全维度上，在 AD 中重新设置 SHARE MODERATORS 对象的 ACL，移除所有非 IT 管理员的写入成员权限。

瘦身完成后，对组做一次递归成员导出，作为新的基线。我个人建议这个基线每个月做一次快照对比，一般用 PowerShell 脚本就能完成。脚本逻辑不复杂：递归枚举成员，生成哈希，与上一次基线比对，有差异就发邮件告警。这个动作成本很低，但能有效防止权限在无人知晓的情况下悄悄膨胀。

4.4 审计与告警：让下次滥用第一时间暴露

域控上的日志需要开启组成员变更审计。与组事件直接相关的几个 ID 包括：4728 表示成员被添加到通用安全组，4729 表示成员被移除；4732/4733 对应本地安全组的添加和移除。配合域控日志转发到 SIEM 平台，对异常加入行为（比如凌晨、非 IT 账号、加入后马上访问敏感共享）设置告警。

文件服务器上还要开启对象访问审计，在人事目录的 SACL 中加入 Everyone - 完全控制 - 失败 的审计规则，事件 ID 4663 会在普通用户尝试读取敏感文件时产生记录。需要注意的是，4656/4663 的日志量可能极其庞大，审计规则只建议覆盖高敏感目录，不要全盘开启，否则日志系统很快就会被淹没。

5. 常见问题与排查实录：权限滥用的那些"坑"

5.1 为什么改了共享权限，用户还是能访问？

很多人改了共享权限后，发现用户照样能访问，立刻怀疑是不是配置没生效。我在排查过很多次之后可以负责任地说，百分之九十的原因是 NTFS 层放行了。因为最终有效权限永远取共享权限与 NTFS 权限的交集，共享层如果只给了某个用户读，但 NTFS 层给了完全控制，用户仍然可以通过其他路径访问到文件内容。

排查时一定要看两条链路的交集。Windows 提供的"有效访问"（Effective Access）功能是最直观的工具，输入用户账号后，可以精确列出这个用户从所有组中继承到的最终权限。在我的工作流里，这个功能已经替代了传统的手工推算。

5.2 为什么组成员删了，用户还是能读？

另一种常见现象是，管理员把某个用户从 SHARE MODERATORS 组里移除后，用户仍然能访问共享目录。这种情况需要优先排查三处：

1. 是否还有其他嵌套组也包含了该用户；
2. 文件系统上是否直接给了该用户单独的 ACE；
3. 是否存在 SIDHistory，用户账号迁移前的 SID 仍拥有权限。

排查手段不复杂，PowerView 递归查询，再比对文件系统 ACL 即可。但这类问题往往隐蔽，因为图形界面上看组成员已经干干净净，实际权限却纹丝不动。

5.3 怎么判断是"业务需要"还是"权限滥用"：三个提问模板

在一次内网审计的中后期，最常遇到的反问是："这个组的权限是我们业务需要的，凭什么不能给？"我的回应一般很简单：追问三个问题。

• 这个权限和该用户的岗位职责是否直接匹配？
• 这是不是最小范围，为什么看薪酬明细而不是只给汇总表格？
• 这个权限上一次被复核是什么时候，有没有记录？

如果三个问题任何一个答不上来，这个权限就需要重新审查。安全当然不能一刀切砍业务，但也不能让权限在没有存在理由的情况下无限膨胀。给权限找一个存在理由，本来就是权限治理的根本。

5.4 权限收敛后的回归验证

修复完成后不能直接宣告结束，要做一次完整的回归验证。用测试账号重新执行共享枚举，确认敏感共享已不可见或拒绝访问；用域管理工具重新导出 SHARE MODERATORS 的成员列表，确认基线一致；再用"有效访问"逐一核查关键账号的最终权限。

我还会顺手做一次模拟：让一个普通业务账号尝试访问旧路径，确认返回访问拒绝。这个步骤虽然简单，却能有效防止运维人员改完 A 配置忘了 B 配置的疏漏，值得养成习惯。很多权限修复项目过了几周又复发，就是因为没有做这一步回归。

做了这么多年安全，我最大的体会是，真正让内网数据失控的往往不是高级攻击，而是权限面在一次次"图省事"中被人为撑大。SHARE MODERATORS 这种组名本身就很能说明问题——它带着管理属性，如果管理属性变成全员可用，那整个共享体系基本就是敞开的。

我现在养成的习惯是，每个月第一个周一，把那台文件服务器上的敏感组快照脚本结果发到运维群，让各个团队认领自己名下的权限。不需要复杂的平台，一条 PowerShell 脚本加一封邮件就能把权限膨胀按住。最后再提醒一句：每一次修改共享权限时，都多看一眼那条"取交集"的规则，很多事故就是从共享权限放太宽开始的。