查Windows管理员组成员最直接命令是net localgroup administrators，其输出列表中每个用户名均拥有完全控制权，需区分内置、域和本地账户，空结果或隐藏账户（注册表SAM路径下）须立即排查。
查 Windows 管理员组成员：用 net localgroup administrators 最直接
系统最高权限实际由 administrators 用户组控制，而不是某个叫“admin”的账户——哪怕你改了 administrator 账户名，只要它还在这个组里，就仍是最高权限。所以第一步永远是确认谁真正在这个组里。
实操建议：
- 以管理员身份打开 CMD（右键开始菜单 → “Windows Terminal (Admin)” 或搜索 CMD → 右键“以管理员身份运行”）
- 执行：
net localgroup administrators，输出列表里的每个用户名都拥有完全控制权 - 注意区分内置账户（如
Administrator）、域账户（如DOMAIN\user）和本地新建账户（如hacker），后者若非你创建，必须立即处理 - 如果看到空行或只显示“命令成功完成”，说明该组为空——这极不正常，可能已被清空或遭篡改，需进一步检查 SAM 或组策略
识别隐藏账户：注册表 HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\Names 是真相所在
黑客常通过注册表创建隐藏账户，这类账户不会出现在 lusrmgr.msc 或 net user 结果中，但能登录、提权、驻留。关键路径在 SAM 子键下，名字存在但 SID 未映射到常规用户列表。
实操建议：
- 运行
regedit→ 导航至HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\Names - 若提示“拒绝访问”，右键
SAM键 → “权限” → 勾选当前管理员用户的“完全控制” → 确定后重进 - 展开
Names，对比右侧列出的用户名和net user输出；多出来的就是隐藏账户（如svc_backdoor、adm1n_） - 不要直接删注册表项——先用
net user username /delete尝试删除；失败再考虑导出备份后手动清理对应 SID 子键
排查跨环境双重特权账户：Microsoft Entra ID + Active Directory 同时拥有的管理员角色最危险
一个用户既是 Azure 的 Global Administrator，又是本地域的 Domain Admins 成员，等于同时打通云和内网大门。攻击者拿下任一端，就能横向跳转到另一端，这种组合比单点高权限风险高出数个量级。
实操建议：
- 在 Microsoft Entra admin center 查看
Roles and administrators→ 导出所有全局/特权角色成员名单 - 在域控服务器上运行：
dsquery group -name "Domain Admins" | dsget group -members | dsget user -samid获取本地域管列表 - 人工比对两个名单，标记交集——这些账户必须降权：要么从 Entra ID 移除全局管理员，要么从 AD 移出 Domain Admins 组
- 切忌用“临时需要”理由保留双重特权；最小权限原则在这里不是建议，是防线底线
PostgreSQL / MySQL 中误判“最高权限”的常见陷阱
数据库里没有叫“root”或“admin”的固定超级用户概念，权限靠角色继承和属性标记。比如 PostgreSQL 的 usesuper 字段为 t 才代表真正超级用户；MySQL 的 SELECT * FROM mysql.user WHERE Super_priv='Y' 才是有效判断依据——仅看用户名或是否在 pg_roles 里出现，会漏掉或误报。
实操建议：
- PostgreSQL：执行
SELECT usename, usesuper, valuntil FROM pg_user WHERE usesuper;，重点关注valuntil是否为空或远期，避免过期却仍具权限的僵尸账号 - MySQL：用
SELECT User, Host, Super_priv FROM mysql.user WHERE Super_priv='Y';，注意Host列——'%'比'localhost'危险得多，意味着可远程提权 - 别依赖图形工具界面显示的“管理员”标签，它们常缓存旧状态；一切以系统表实时查询为准
权限排查最易被忽略的一点：时间维度。一个账户昨天还是普通用户，今天可能已被加进 Administrators 组；一条数据库授权语句可能刚执行完就生效，但日志还没落盘。静态快照永远不够，得结合 wevtutil qe security /q:"*[System[(EventID=4732)]]"（AD 组变更日志）或 PostgreSQL 的 log_statement = 'ddl' 配置，才能看清“谁、何时、为什么”获得了最高权限。
