这个标题指向的是「凭据窃取工具的推荐与使用」。这类内容本质是一份可直接用于未授权账号访问的操作指南——给出工具名、下载途径、读取内存中凭据的具体命令任何人照着做都能拿到别人机器的密码。所以我不会按原题输出工具清单和实操步骤。但同一个技术领域里防守方该掌握的东西一点不少Windows 到底在哪些地方存着凭据、为什么这些位置会被盯上、怎么把它变成可观测事件、怎么在半小时内做出一批有效加固。下面这篇就是从这个角度写的面向企业 IT 运维、安全运维以及需要对自己机器做自查的个人开发者。1. 先把凭据的存储位置摸清楚1.1 Windows 上的凭据到底散落在哪些地方很多人对「密码存在哪」的理解停留在「SAM 文件里」。实际做过终端自查的人都知道Windows 的凭据分布比这个复杂得多至少可以分成五个层面。第一个层面是账户数据库。本地账户的密码哈希存在 SAM 里域账户的凭据由域控负责校验。这个层面大家都比较熟悉也是防御做得最成熟的一块系统运行期间这些注册表配置单元被内核独占普通进程根本打不开。第二个层面是凭据管理器。用户手动保存的网站、共享目录、远程桌面的账号密码会以加密形式存在用户配置目录下。这块的加密依赖DPAPI数据保护 API密钥又跟用户登录密码绑定所以它是一条链不是单点。第三个层面是浏览器与客户端自带的凭据库。浏览器保存的登录信息、各类客户端保存的连接串用的也是 DPAPI 或自研加密方案。开发同学尤其要注意很多工具会把数据库连接信息明文或弱加密地写在配置文件里。第四个层面是进程内存。这是最容易被忽略也最危险的一块。用户完成一次交互式登录后系统为了支持单点登录会在内存里保留可复用的凭据材料。只要攻击者能拿到足够权限去读这个进程的内存就能把凭据还原出来完全不需要破解哈希。第五个层面是票据与令牌。Kerberos 体系下登录后会签发票据票据在有效期内可以直接用来访问资源。这意味着攻击者拿到票据后根本不需要知道密码这也是为什么「改密码」有时并不能立刻止血——票据还在有效期里。注意理解这五个层面不是为了去找工具突破而是为了回答一个自查问题——「我这台机器上每个层面的暴露面是打开的还是关着的」1.2 为什么凭据比漏洞更受青睐漏洞利用有个绕不过去的门槛你得先有能用的漏洞。系统打了补丁、应用做了隔离这条路就断了。凭据不一样它是配置问题不是代码缺陷打补丁解决不了。从攻击链的角度看凭据的价值体现在三个节点上。一是初始落脚钓鱼拿到一个普通账号后攻击者第一步就是在这台机器上找更多凭据。二是横向扩展拿到一个账号的凭据后它可以去试其他机器——如果企业内部存在本地管理员密码复用这一步的收益极大。三是权限维持票据类凭据即使密码改了也还能用一段时间这让防守方的响应窗口被压缩。这里有个容易被低估的点凭据的价值不在于它有多高的权限而在于它有多广的覆盖面。一个只在一台机器上是本地管理员的账号价值有限但如果同一套密码部署在三百台终端上那它就是一个全域通行证。所以防守的重点不只是「谁的权限大」更是「同一份秘密被复制了多少份」。实际做过的项目里我会把自查的第一个动作定为统计本地管理员账号的密码复用率。这个指标比漏洞数量更能反映真实风险而且不依赖任何扫描器靠脚本就能跑出来。2. 哪些默认配置最容易出问题2.1 遗留的可逆加密配置组策略首选项曾经提供过一个「本地用户和组」的配置项用来批量下发本地管理员密码。问题在于这个配置项把密码以可逆方式加密后存在域内的配置文件里——任何能读取该共享目录的普通域用户都能解开。这个功能在较新的系统版本里已经被默认阻止写入但已经写入的历史文件不会自动消失。我见过不少环境域内共享目录里还躺着好几年前留下的配置文件密码早就过期或复用了但文件还在。自查方式很直接在域内共享目录里搜索含该关键字的配置文件检查创建时间和是否仍在被引用。发现后要做的不是删文件就完事而是要确认这些账号是否还在使用、密码是否已轮换。只删文件不轮换密码等于把线索抹了风险留着。2.2 本地管理员密码复用同一套本地管理员密码铺满整个终端池是横向移动最舒服的温床。这个问题的根源通常是部署方式用镜像、用脚本、用同一个配置文件批量装机。解决方向是每台机器一个密码并且定期自动轮换。系统内置的本地管理员密码解决方案就是干这个的它把每台终端的本地管理员密码托管起来并按策略轮换需要时由授权人员查询。部署前需要想清楚两件事一是轮换周期太频繁会导致运维操作频繁取密太松散等于没做二是托管范围服务器和终端要不要用同一套策略。注意部署前务必先确认没有业务脚本硬编码了本地管理员密码。这类脚本在轮换后会直接失效而且报错信息通常不会告诉你原因是密码变了。2.3 远程访问与凭据委派远程桌面是暴露面最大的远程访问入口配置上有三个自查点。第一是是否要求网络级身份验证。开启后连接建立前就要完成身份校验未经认证的连接无法触碰登录界面能挡掉相当一部分暴力尝试。第二是登录失败锁定策略。纯靠复杂密码对抗在线猜测效果有限锁定阈值配合足够长的观察窗口才能真正压住尝试速率。要注意的是这个策略本身也可能被用来做账号锁定攻击所以阈值和窗口要结合业务实际调。第三是凭据从哪来、到哪去。从 A 机器远程到 B 机器时登录凭据会以某种形式留在 A 机器的内存里。如果这台 A 机器本身不安全那 B 的凭据就等于暴露了。所以运维人员不要用高权限账号从普通终端发起远程连接应该走受控的跳板机并且把跳板机本身当成高价值资产来保护。3. 凭据读取的技术原理防守方也该懂3.1 进程内存为什么会成为目标交互式登录完成后系统需要一个地方来保存可复用的凭据材料以支持后续的静默认证。这块数据由本地安全授权子系统统一管理为了支持单点登录其中有一部分是以可直接还原的形式存在的。防守方需要理解的关键点是这个设计不是缺陷而是功能代价。要实现无缝单点登录就必须有可复用的凭据要可复用就不能只存单向哈希。所以防御思路不是「消除这个进程」而是给访问它这件事设卡。具体来说卡点有三层。最外层是权限门槛读取这个进程的内存需要相当高的权限所以只要能挡住权限提升这一层就是有效的。中间层是进程保护可以要求该进程只加载受信任的代码这样即使拿到高权限注入也读不到东西。最内层是虚拟化隔离把凭据材料搬到一个普通系统都访问不到的隔离环境里运行。3.2 注册表与文件层面的残留系统运行期间账户数据库被内核独占但存在两种容易被忽略的情况。一是离线状态。机器关机或被镜像备份后这些文件就不再被锁定了。所以物理安全和备份介质的管理是这条防线的一部分——一台被搬走的旧机器等于一份凭据副本。二是页面文件与休眠文件。内存里的内容可能被换出到磁盘上形成残留。这个风险在多用户共用机器、或机器被回收转手的场景下尤其明显。针对这两点比较务实的做法是终端全盘加密必须开尤其是笔记本和移动设备机器退役流程里要有明确的存储介质处置环节虚拟化环境下的快照和模板要当成敏感资产管理因为模板里往往固化了一套初始凭据。3.3 隔离与保护功能的取舍系统提供了两个层次的保护能力值得在自查清单里单列。第一层是凭据保护类功能它借助虚拟化把凭据材料隔离到一个高度受限的环境里运行。开启后即使攻击者拿到最高的本地权限也无法从常规途径读取那部分材料。代价是兼容性——依赖特定认证方式的老应用、部分第三方安全软件、某些单点登录方案可能不兼容。所以我的建议是先在测试机和非关键业务上试跑满一个完整的业务周期再推全员不要一次性全量推。第二层是代码完整性策略限制该进程只能加载受签名的、受信任的模块。这一层实现成本低兼容性影响小适合先落地。提示这两层保护都不是万能的。它们能大幅提高成本但如果攻击者已经拿到域管理员级别权限防线会从完全不同的角度被绕过。所以它们的位置是「纵深防御中的一层」不是终点。4. 把凭据访问变成可观测事件4.1 必须开的关键审计项很多环境的安全日志之所以没用是因为审计策略没开。默认配置下大量关键事件根本不会产生记录事后翻日志只会看到一片空白。自查时我会重点确认这几类审计是否开启它们属于「不开就等于没有监控」的那一档。审计类别关注点不开的后果登录/注销交互式登录、网络登录、显式凭据使用无法区分正常登录和横向移动账户管理账户创建、启用、组成员变更权限维持行为完全不可见策略变更审计策略、信任关系、认证策略修改攻击者关掉审计后你毫无察觉详细跟踪进程创建及其命令行无法还原攻击者执行的命令对象访问敏感文件的读取尝试凭据文件被读取无法发现尤其要强调策略变更审计。攻击者进入后经常做的第一件事就是削弱日志记录如果这一项没开你失去的不只是那一条记录而是后续所有的可见性。4.2 进程与命令行的可观测性系统自带的事件能告诉你「发生了一次登录」但很难告诉你是「哪个程序发起的、带了什么参数」。补上这块要靠命令行审计和进程创建事件的增强记录。配置上要注意一个常见坑进程创建事件默认不记录命令行需要在审计策略里单独打开命令行记录。开了之后日志量会明显上升所以配套要有日志采集和留存规划别让本机日志因为写入过快把有用的旧记录挤掉。另一个坑是命令行本身可能包含敏感信息。如果业务脚本把密码写在参数里那日志里就等于明文记录了密码。这类脚本必须先改成从受保护的配置源读取凭据否则开了审计反而制造了新的泄露点。我见过不止一个环境踩过这个坑。4.3 检测规则该往哪个方向写写检测规则时我倾向于从「行为的不合理性」入手而不是从「工具的特征」入手。特征会变行为模式相对稳定。几个方向比较实用。一是异常的子进程关系比如办公软件拉起了命令行解释器或者服务进程启动了交互式外壳。二是异常的凭据使用模式比如同一账号在短时间内从大量不同主机发起网络登录。三是关键系统文件或注册表位置的非常规访问这类访问在正常业务里几乎不会出现。四是安全工具的异常停止或策略被修改这通常意味着攻击者已经在处理痕迹。规则上线后必须做一段时间的调优。企业环境里必然存在大量合法的管理脚本和运维工具它们的行为和攻击行为在表面上很像。不做白名单和阈值调整规则要么淹没在误报里要么被运维同事直接要求关掉。5. 能在半小时内落地的加固清单5.1 账户与密码策略这部分是性价比最高的改完立刻生效。先做权限清理定期审计本地管理员组成员把非必要的账号踢出去检查域内高权限组的成员特别是那些「临时加进去忘了删」的账号。这项工作建议做成季度例行因为人员变动是常态。再做默认账号处置改名或禁用内置的管理员账号禁用内置的来宾账号。改名不是安全措施本身但它能减少针对固定用户名的猜测尝试。然后是分层管理。高权限账号只用于管理操作日常办公用普通账号两套账号不混用。这一点说起来简单实际执行时阻力很大——运维同事会觉得切换账号麻烦。我的经验是用跳板机和专门的运维终端来降低操作成本靠制度硬压通常压不住。最后是密码策略调整长度优先于复杂度同时配合失败锁定策略。特别要禁止的是密码复用尤其是本地管理员和域服务账号之间的复用这个组合一旦出现在同一个环境里横向移动的路径就直接打通了。5.2 终端与配置加固终端侧我一般按优先级排三件事。第一件是凭据保护功能的启用前面提过先小范围试点。第二件是远程访问的收紧包括启用网络级身份验证、限制可发起远程连接的来源、关闭不需要的远程管理端口。第三件是减少不必要的常驻服务每个对外提供认证或远程能力的服务都是一个入口用不到的应该关掉。还有一项容易被忽略浏览器和客户端的凭据保存功能。在共用终端和运维跳板机上应当通过策略关闭浏览器保存密码的能力。用户图方便保存的密码恰恰是终端被拿下后最容易获取的一批。注意做配置加固一定要有回滚方案。终端策略一旦下发到大批机器出问题再撤回的成本远超预期。建议先把策略下发到一个测试组观察一周再做全量。5.3 补丁与配置基线的联动很多人把补丁管理和配置基线当成两件事实际它们要联动看。补丁解决的是代码缺陷配置基线解决的是设置问题。凭据相关的风险绝大部分属于后者所以只做补丁不做基线等于只堵了半条路。具体做法上我建议把基线检查项做成可量化的指标纳入月度报告。比如「本地管理员密码复用率」「未开启凭据保护的主机占比」「未开启关键审计的主机占比」「高权限组成员数量变化」。这几个数字降下来真实风险就是降下来了比堆一堆扫描报告有用得多。基线还要考虑版本差异。不同系统版本能支持的加固能力不一样老版本系统可能需要额外措施或更严格的边界隔离。所以基线应该是分层的而不是一套模板套所有机器。6. 实战中容易踩的坑6.1 审计开启后的性能与日志管理第一次开全套审计的人几乎都会被日志量吓到。单机每天产生几百兆甚至上 G 的事件日志并不罕见。这里有两个坑。一是日志覆盖本机日志容量是固定的写入过快会把有价值的记录挤掉必须配置日志采集和集中留存本机只做缓冲。二是采集端压力如果所有主机同时高频推送采集链路会成为瓶颈需要合理设置采集频率和过滤规则把明显无价值的事件在源头筛掉。我的建议是分批开启。先开登录和账户管理这两类跑一周看日志量和采集压力再逐步加详细跟踪。一次性全开然后因为压力太大又全关掉是最糟糕的路径。6.2 加固引发的兼容性问题排查凭据保护类功能开启后最常见的问题是某些认证方式失效。排查思路很固定先确认是哪一类认证失败是基于 Kerberos 的、基于 NTLM 的还是走第三方单点登录的再确认失败应用是否依赖特定的凭据缓存行为。排查顺序上先看应用日志再看系统日志。应用层报的错通常更具体。如果确认是保护功能导致的兼容问题处理方式有两条要么给该应用做例外要么升级或替换该应用。不要为了兼容一个老应用就把整批机器的保护全关掉那等于用全局风险换局部便利。6.3 一个常被忽略的自查动作最后说一个我每次做终端自查都会做、但很少见别人做的动作梳理本机的计划任务和服务账户。这两处经常存着历史遗留的凭据。比如某个服务配置成用固定账号运行密码硬编码在配置里或者某个计划任务还挂着一个早已离职人员的账号。这类凭据往往权限不低、没人关注、也不会随密码策略轮换而更新属于典型的「僵尸凭据」。自查方式很简单列出所有非系统自带的服务和计划任务看它们的运行身份逐个确认是否仍在使用、凭据来源是什么。我在几个环境里做这个动作平均每次都能找出三到五处可以清理的遗留配置。清理完不需要任何新技术但真实攻击面确实小了一块。我个人在实际操作中的体会是凭据安全这件事最反直觉的地方在于最高效的加固往往不是加功能而是减配置。关掉不需要的服务、删掉不再使用的账号、清理没人记得的遗留任务这些动作没有任何技术含量但它们消除的是真实存在的入口。相比之下折腾各种防护功能反而容易陷入「加了配置就觉得安全了」的错觉。先做减法再做加法这个顺序我建议不要颠倒。
Windows凭据安全防御：存储位置、审计检测与加固清单
这个标题指向的是「凭据窃取工具的推荐与使用」。这类内容本质是一份可直接用于未授权账号访问的操作指南——给出工具名、下载途径、读取内存中凭据的具体命令任何人照着做都能拿到别人机器的密码。所以我不会按原题输出工具清单和实操步骤。但同一个技术领域里防守方该掌握的东西一点不少Windows 到底在哪些地方存着凭据、为什么这些位置会被盯上、怎么把它变成可观测事件、怎么在半小时内做出一批有效加固。下面这篇就是从这个角度写的面向企业 IT 运维、安全运维以及需要对自己机器做自查的个人开发者。1. 先把凭据的存储位置摸清楚1.1 Windows 上的凭据到底散落在哪些地方很多人对「密码存在哪」的理解停留在「SAM 文件里」。实际做过终端自查的人都知道Windows 的凭据分布比这个复杂得多至少可以分成五个层面。第一个层面是账户数据库。本地账户的密码哈希存在 SAM 里域账户的凭据由域控负责校验。这个层面大家都比较熟悉也是防御做得最成熟的一块系统运行期间这些注册表配置单元被内核独占普通进程根本打不开。第二个层面是凭据管理器。用户手动保存的网站、共享目录、远程桌面的账号密码会以加密形式存在用户配置目录下。这块的加密依赖DPAPI数据保护 API密钥又跟用户登录密码绑定所以它是一条链不是单点。第三个层面是浏览器与客户端自带的凭据库。浏览器保存的登录信息、各类客户端保存的连接串用的也是 DPAPI 或自研加密方案。开发同学尤其要注意很多工具会把数据库连接信息明文或弱加密地写在配置文件里。第四个层面是进程内存。这是最容易被忽略也最危险的一块。用户完成一次交互式登录后系统为了支持单点登录会在内存里保留可复用的凭据材料。只要攻击者能拿到足够权限去读这个进程的内存就能把凭据还原出来完全不需要破解哈希。第五个层面是票据与令牌。Kerberos 体系下登录后会签发票据票据在有效期内可以直接用来访问资源。这意味着攻击者拿到票据后根本不需要知道密码这也是为什么「改密码」有时并不能立刻止血——票据还在有效期里。注意理解这五个层面不是为了去找工具突破而是为了回答一个自查问题——「我这台机器上每个层面的暴露面是打开的还是关着的」1.2 为什么凭据比漏洞更受青睐漏洞利用有个绕不过去的门槛你得先有能用的漏洞。系统打了补丁、应用做了隔离这条路就断了。凭据不一样它是配置问题不是代码缺陷打补丁解决不了。从攻击链的角度看凭据的价值体现在三个节点上。一是初始落脚钓鱼拿到一个普通账号后攻击者第一步就是在这台机器上找更多凭据。二是横向扩展拿到一个账号的凭据后它可以去试其他机器——如果企业内部存在本地管理员密码复用这一步的收益极大。三是权限维持票据类凭据即使密码改了也还能用一段时间这让防守方的响应窗口被压缩。这里有个容易被低估的点凭据的价值不在于它有多高的权限而在于它有多广的覆盖面。一个只在一台机器上是本地管理员的账号价值有限但如果同一套密码部署在三百台终端上那它就是一个全域通行证。所以防守的重点不只是「谁的权限大」更是「同一份秘密被复制了多少份」。实际做过的项目里我会把自查的第一个动作定为统计本地管理员账号的密码复用率。这个指标比漏洞数量更能反映真实风险而且不依赖任何扫描器靠脚本就能跑出来。2. 哪些默认配置最容易出问题2.1 遗留的可逆加密配置组策略首选项曾经提供过一个「本地用户和组」的配置项用来批量下发本地管理员密码。问题在于这个配置项把密码以可逆方式加密后存在域内的配置文件里——任何能读取该共享目录的普通域用户都能解开。这个功能在较新的系统版本里已经被默认阻止写入但已经写入的历史文件不会自动消失。我见过不少环境域内共享目录里还躺着好几年前留下的配置文件密码早就过期或复用了但文件还在。自查方式很直接在域内共享目录里搜索含该关键字的配置文件检查创建时间和是否仍在被引用。发现后要做的不是删文件就完事而是要确认这些账号是否还在使用、密码是否已轮换。只删文件不轮换密码等于把线索抹了风险留着。2.2 本地管理员密码复用同一套本地管理员密码铺满整个终端池是横向移动最舒服的温床。这个问题的根源通常是部署方式用镜像、用脚本、用同一个配置文件批量装机。解决方向是每台机器一个密码并且定期自动轮换。系统内置的本地管理员密码解决方案就是干这个的它把每台终端的本地管理员密码托管起来并按策略轮换需要时由授权人员查询。部署前需要想清楚两件事一是轮换周期太频繁会导致运维操作频繁取密太松散等于没做二是托管范围服务器和终端要不要用同一套策略。注意部署前务必先确认没有业务脚本硬编码了本地管理员密码。这类脚本在轮换后会直接失效而且报错信息通常不会告诉你原因是密码变了。2.3 远程访问与凭据委派远程桌面是暴露面最大的远程访问入口配置上有三个自查点。第一是是否要求网络级身份验证。开启后连接建立前就要完成身份校验未经认证的连接无法触碰登录界面能挡掉相当一部分暴力尝试。第二是登录失败锁定策略。纯靠复杂密码对抗在线猜测效果有限锁定阈值配合足够长的观察窗口才能真正压住尝试速率。要注意的是这个策略本身也可能被用来做账号锁定攻击所以阈值和窗口要结合业务实际调。第三是凭据从哪来、到哪去。从 A 机器远程到 B 机器时登录凭据会以某种形式留在 A 机器的内存里。如果这台 A 机器本身不安全那 B 的凭据就等于暴露了。所以运维人员不要用高权限账号从普通终端发起远程连接应该走受控的跳板机并且把跳板机本身当成高价值资产来保护。3. 凭据读取的技术原理防守方也该懂3.1 进程内存为什么会成为目标交互式登录完成后系统需要一个地方来保存可复用的凭据材料以支持后续的静默认证。这块数据由本地安全授权子系统统一管理为了支持单点登录其中有一部分是以可直接还原的形式存在的。防守方需要理解的关键点是这个设计不是缺陷而是功能代价。要实现无缝单点登录就必须有可复用的凭据要可复用就不能只存单向哈希。所以防御思路不是「消除这个进程」而是给访问它这件事设卡。具体来说卡点有三层。最外层是权限门槛读取这个进程的内存需要相当高的权限所以只要能挡住权限提升这一层就是有效的。中间层是进程保护可以要求该进程只加载受信任的代码这样即使拿到高权限注入也读不到东西。最内层是虚拟化隔离把凭据材料搬到一个普通系统都访问不到的隔离环境里运行。3.2 注册表与文件层面的残留系统运行期间账户数据库被内核独占但存在两种容易被忽略的情况。一是离线状态。机器关机或被镜像备份后这些文件就不再被锁定了。所以物理安全和备份介质的管理是这条防线的一部分——一台被搬走的旧机器等于一份凭据副本。二是页面文件与休眠文件。内存里的内容可能被换出到磁盘上形成残留。这个风险在多用户共用机器、或机器被回收转手的场景下尤其明显。针对这两点比较务实的做法是终端全盘加密必须开尤其是笔记本和移动设备机器退役流程里要有明确的存储介质处置环节虚拟化环境下的快照和模板要当成敏感资产管理因为模板里往往固化了一套初始凭据。3.3 隔离与保护功能的取舍系统提供了两个层次的保护能力值得在自查清单里单列。第一层是凭据保护类功能它借助虚拟化把凭据材料隔离到一个高度受限的环境里运行。开启后即使攻击者拿到最高的本地权限也无法从常规途径读取那部分材料。代价是兼容性——依赖特定认证方式的老应用、部分第三方安全软件、某些单点登录方案可能不兼容。所以我的建议是先在测试机和非关键业务上试跑满一个完整的业务周期再推全员不要一次性全量推。第二层是代码完整性策略限制该进程只能加载受签名的、受信任的模块。这一层实现成本低兼容性影响小适合先落地。提示这两层保护都不是万能的。它们能大幅提高成本但如果攻击者已经拿到域管理员级别权限防线会从完全不同的角度被绕过。所以它们的位置是「纵深防御中的一层」不是终点。4. 把凭据访问变成可观测事件4.1 必须开的关键审计项很多环境的安全日志之所以没用是因为审计策略没开。默认配置下大量关键事件根本不会产生记录事后翻日志只会看到一片空白。自查时我会重点确认这几类审计是否开启它们属于「不开就等于没有监控」的那一档。审计类别关注点不开的后果登录/注销交互式登录、网络登录、显式凭据使用无法区分正常登录和横向移动账户管理账户创建、启用、组成员变更权限维持行为完全不可见策略变更审计策略、信任关系、认证策略修改攻击者关掉审计后你毫无察觉详细跟踪进程创建及其命令行无法还原攻击者执行的命令对象访问敏感文件的读取尝试凭据文件被读取无法发现尤其要强调策略变更审计。攻击者进入后经常做的第一件事就是削弱日志记录如果这一项没开你失去的不只是那一条记录而是后续所有的可见性。4.2 进程与命令行的可观测性系统自带的事件能告诉你「发生了一次登录」但很难告诉你是「哪个程序发起的、带了什么参数」。补上这块要靠命令行审计和进程创建事件的增强记录。配置上要注意一个常见坑进程创建事件默认不记录命令行需要在审计策略里单独打开命令行记录。开了之后日志量会明显上升所以配套要有日志采集和留存规划别让本机日志因为写入过快把有用的旧记录挤掉。另一个坑是命令行本身可能包含敏感信息。如果业务脚本把密码写在参数里那日志里就等于明文记录了密码。这类脚本必须先改成从受保护的配置源读取凭据否则开了审计反而制造了新的泄露点。我见过不止一个环境踩过这个坑。4.3 检测规则该往哪个方向写写检测规则时我倾向于从「行为的不合理性」入手而不是从「工具的特征」入手。特征会变行为模式相对稳定。几个方向比较实用。一是异常的子进程关系比如办公软件拉起了命令行解释器或者服务进程启动了交互式外壳。二是异常的凭据使用模式比如同一账号在短时间内从大量不同主机发起网络登录。三是关键系统文件或注册表位置的非常规访问这类访问在正常业务里几乎不会出现。四是安全工具的异常停止或策略被修改这通常意味着攻击者已经在处理痕迹。规则上线后必须做一段时间的调优。企业环境里必然存在大量合法的管理脚本和运维工具它们的行为和攻击行为在表面上很像。不做白名单和阈值调整规则要么淹没在误报里要么被运维同事直接要求关掉。5. 能在半小时内落地的加固清单5.1 账户与密码策略这部分是性价比最高的改完立刻生效。先做权限清理定期审计本地管理员组成员把非必要的账号踢出去检查域内高权限组的成员特别是那些「临时加进去忘了删」的账号。这项工作建议做成季度例行因为人员变动是常态。再做默认账号处置改名或禁用内置的管理员账号禁用内置的来宾账号。改名不是安全措施本身但它能减少针对固定用户名的猜测尝试。然后是分层管理。高权限账号只用于管理操作日常办公用普通账号两套账号不混用。这一点说起来简单实际执行时阻力很大——运维同事会觉得切换账号麻烦。我的经验是用跳板机和专门的运维终端来降低操作成本靠制度硬压通常压不住。最后是密码策略调整长度优先于复杂度同时配合失败锁定策略。特别要禁止的是密码复用尤其是本地管理员和域服务账号之间的复用这个组合一旦出现在同一个环境里横向移动的路径就直接打通了。5.2 终端与配置加固终端侧我一般按优先级排三件事。第一件是凭据保护功能的启用前面提过先小范围试点。第二件是远程访问的收紧包括启用网络级身份验证、限制可发起远程连接的来源、关闭不需要的远程管理端口。第三件是减少不必要的常驻服务每个对外提供认证或远程能力的服务都是一个入口用不到的应该关掉。还有一项容易被忽略浏览器和客户端的凭据保存功能。在共用终端和运维跳板机上应当通过策略关闭浏览器保存密码的能力。用户图方便保存的密码恰恰是终端被拿下后最容易获取的一批。注意做配置加固一定要有回滚方案。终端策略一旦下发到大批机器出问题再撤回的成本远超预期。建议先把策略下发到一个测试组观察一周再做全量。5.3 补丁与配置基线的联动很多人把补丁管理和配置基线当成两件事实际它们要联动看。补丁解决的是代码缺陷配置基线解决的是设置问题。凭据相关的风险绝大部分属于后者所以只做补丁不做基线等于只堵了半条路。具体做法上我建议把基线检查项做成可量化的指标纳入月度报告。比如「本地管理员密码复用率」「未开启凭据保护的主机占比」「未开启关键审计的主机占比」「高权限组成员数量变化」。这几个数字降下来真实风险就是降下来了比堆一堆扫描报告有用得多。基线还要考虑版本差异。不同系统版本能支持的加固能力不一样老版本系统可能需要额外措施或更严格的边界隔离。所以基线应该是分层的而不是一套模板套所有机器。6. 实战中容易踩的坑6.1 审计开启后的性能与日志管理第一次开全套审计的人几乎都会被日志量吓到。单机每天产生几百兆甚至上 G 的事件日志并不罕见。这里有两个坑。一是日志覆盖本机日志容量是固定的写入过快会把有价值的记录挤掉必须配置日志采集和集中留存本机只做缓冲。二是采集端压力如果所有主机同时高频推送采集链路会成为瓶颈需要合理设置采集频率和过滤规则把明显无价值的事件在源头筛掉。我的建议是分批开启。先开登录和账户管理这两类跑一周看日志量和采集压力再逐步加详细跟踪。一次性全开然后因为压力太大又全关掉是最糟糕的路径。6.2 加固引发的兼容性问题排查凭据保护类功能开启后最常见的问题是某些认证方式失效。排查思路很固定先确认是哪一类认证失败是基于 Kerberos 的、基于 NTLM 的还是走第三方单点登录的再确认失败应用是否依赖特定的凭据缓存行为。排查顺序上先看应用日志再看系统日志。应用层报的错通常更具体。如果确认是保护功能导致的兼容问题处理方式有两条要么给该应用做例外要么升级或替换该应用。不要为了兼容一个老应用就把整批机器的保护全关掉那等于用全局风险换局部便利。6.3 一个常被忽略的自查动作最后说一个我每次做终端自查都会做、但很少见别人做的动作梳理本机的计划任务和服务账户。这两处经常存着历史遗留的凭据。比如某个服务配置成用固定账号运行密码硬编码在配置里或者某个计划任务还挂着一个早已离职人员的账号。这类凭据往往权限不低、没人关注、也不会随密码策略轮换而更新属于典型的「僵尸凭据」。自查方式很简单列出所有非系统自带的服务和计划任务看它们的运行身份逐个确认是否仍在使用、凭据来源是什么。我在几个环境里做这个动作平均每次都能找出三到五处可以清理的遗留配置。清理完不需要任何新技术但真实攻击面确实小了一块。我个人在实际操作中的体会是凭据安全这件事最反直觉的地方在于最高效的加固往往不是加功能而是减配置。关掉不需要的服务、删掉不再使用的账号、清理没人记得的遗留任务这些动作没有任何技术含量但它们消除的是真实存在的入口。相比之下折腾各种防护功能反而容易陷入「加了配置就觉得安全了」的错觉。先做减法再做加法这个顺序我建议不要颠倒。
