1. 项目全景与红队目标拆解红队渗透测试这件事说白了就是替攻击者提前探一遍路。这次项目从外网入口突破开始一路打到内网横向移动完成最终形成一条完整的攻击链用来验证目标业务系统的真实风险。很多团队做安全建设时会陷入一个误区觉得装了防火墙、上了WAF、做了分区分域就万事大吉结果攻防演练一开打入口被突破后内网直接裸奔横向移动几乎没有遇到像样的阻碍。我做红队这些年最大的感受是攻击链的价值不在于你拿到了多少个权限、攻陷了多少台服务器而在于把“漏洞为什么能被利用、权限为什么能拿得稳、横向为什么拦不住”这些问题彻底讲清楚。红队报告里的每条路径往后都能转化成一条防御规则往前都能追溯到某个配置疏漏或者人的习惯问题。这次项目的目标对象是一个典型的业务型企业网络架构不算复杂但业务系统种类很多。有对外暴露的Web应用有内部办公系统有开发测试环境还有一堆运维人员自己搭的零散服务。红队的核心KPI也很直接从一个未授权的外部攻击者视角出发在不使用任何已知内部情报的情况下找到至少一条能进入内网并获取核心业务数据权限的完整路径。接到这个任务之后我没有急着上手扫端口第一件事是跟目标方确认了授权范围和测试边界。这是红队项目和真正的恶意攻击之间最大的分水岭也是整条链路能够“实战化”而不出事故的前提。范围确认清楚之后才开始进入技术层面对外攻击面有哪些、内网分区分域怎么划、核心资产在哪、运维入口有哪些、人员的暴露面有多大。从攻击面模型反推路径是红队最常用的方法论。我们不会一上来就盯着某一个系统死磕而是先把“可能被打进去的入口”全部列出来再根据入口的暴露程度、脆弱性预判、进入后的权限位置来做排序。排序逻辑通常是运维入口优先于业务入口存量系统优先于新系统弱凭证集中点优先于强认证点。这样做的好处是效率高因为你真正能够投入精力的入口通常只有三到四个大多数攻击面都是同一类问题的重复。这次项目中最有价值的部分在后半段入口突破之后的内网横向链路。老实说现在大多数企业的边界防线已经比以前强多了漏洞扫描器扫出来的高危漏洞并不多。但内网一旦进了人很多问题就藏不住了。Red team从入口跳到内网的那一刻起真正的考验才开始。后续的内容我会按实际执行的时间线来拆解这条链路从资产收集、入口利用、权限维持到内网信息收集、横向移动最后是复盘和防御建议。2. 外网入口阶段侦察与突破2.1 资产收集别被资产清单骗了红队的第一件事永远是从外部视角摸清攻击面而不是依赖对方提供的资产清单。资产清单这东西理论上应该和实际网络对得上但我在实际项目里发现偏差几乎是常态。有的是因为运维人员只登记了核心生产系统忘了批量的测试环境有的是因为某个业务部门自己拉了云主机根本没人知道还有的是人员离职后忘记了某个旧的Git仓库上面存了代码和密钥。这次项目的第一步就是先把目标企业所有可能的子域名、IP段、证书信息、备案信息、开源情报里泄露的代码仓库全部拉出来做交叉比对。我用了一套常规的开源情报收集流程再结合DNS记录和证书透明度日志进行信息收集。这一步不需要什么高深技术拼的就是细心和耐心。像某些子域名解析到旧服务器或者某个泛解析把所有不存在的域名都指向同一台主机这些都是能够帮助快速圈定真实资产的线索。收敛出来的资产大概有三类一类是官方业务系统主要面向外部用户防护相对严格一类是办公辅助系统比如企业内部的知识库、工单系统、文件共享服务这类系统一般没有做太多安全加固有的干脆就是默认配置还有一类是开发测试环境虽然IP端口不对外但通过某些临时开放的通道或者反代配置可以被访问到。在这三类里开发测试环境往往是最容易出问题的因为开发人员为了调试方便经常会关掉认证或者用弱密码。针对每一个候选资产我会记录它的开放端口、服务指纹、HTTP响应特征、登录页面类型。这一步不追求直接打进去而是为了给后续的攻击面排序提供依据。比如某个系统用的是老版本的应用框架某个系统登录接口没有验证码保护某个系统直接把调试模式开到了公网这些信息比单纯的端口扫描结果要有用得多。2.2 入口突破从弱凭证到系统漏洞的组合利用资产梳理清楚之后真正的入口突破阶段才开始。这里要强调一个原则红队做事不是对着漏洞扫描器出来的报告一条条复现而是把每一个可能的薄弱点当成一次“机会窗口”去看。一个系统打不进去不代表它的认证机制无懈可击也许换个思路从另一个相关系统入手就进去了。这次入口突破的关键点在一个人力资源部的旧系统上。这个系统是好几年前外包开发的一直没怎么升级使用的是弱口令而且存在一个已公开的未授权访问漏洞。我用常规扫描工具确认了这个漏洞存在后没有立刻去提权或者横向而是先把这个入口的权限情况摸清楚。通过未授权接口直接拿到了系统后台的管理权限后台里存了不少历史数据虽然没有财务和核心代码但足以作为进入内网的跳板。像这种“旧系统 弱口令 未修补漏洞”的组合在红队项目里出现的概率高得吓人。很多企业把精力放在新系统的攻防演练上把旧系统当成“存量包袱”处理结果这个包袱恰恰就是突破口。在这个系统上我本地测试时做了记录系统后台有一个功能允许上传文件上传后文件名和路径是可控的虽然没有做完整的限制但Web服务是以低权限用户运行的。也就是说拿到了Web权限但还远远不是内网的管理员权限。这里有个小技巧拿到Web权限后不用急着提权到SysAdmin级别的账号先看看当前权限能访问哪些内部网络资源。红队最常见的一种操作就是“以眼前这台机器为跳板横向看一圈”因为很多内网系统都是以主机名或内网IP来互相访问的你站在Web服务器上天然就获得了内网的一个观察视角。通过读取网站配置文件和本地缓存信息我顺藤摸瓜找到了一些数据库连接地址、内部API地址还有运维人员留下的自动化任务配置。入口突破的操作到这里只完成了一半。接下来要做的是权限维持也就是确保这条入口不会因为对方安全人员的应急响应而关闭。这个过程我会单独讲原因很简单权限维持关系到整条攻击链的稳定性如果入口刚打进一次就被封了后面的内网横向移动根本没法开展。2.3 权限维持入口不是“打进去”就完事很多新人做渗透测试习惯把“拿到Shell”当成任务终点但红队不是这么做的。红队要的是“拿到Shell并且保证这个Shell在较长一段时间内可用”。在目标企业有蓝队值守的情况下你打进一个系统后对方可能几分钟内就会发现告警并封掉入口。所以在进入内网之前先要做的动作是权限维持。权限维持的手段有很多种直接点说写计划任务、注册服务、加启动项、替换二进制文件、利用Web应用本身的功能做持久化都是可选方案。但我个人偏好轻量级的持久化方式在后端修改一个看起来不起眼的业务接口逻辑让它带上一个访问标记。这个标记不影响正常业务但当我再次访问时可以直接走另外一个验证通道进到系统里。这样做的好处是不会产生明显的异常进程或网络连接易检测性较低。使用某个云平台的定时任务功能也可以但前提是当前账号权限允许申请相关权限。我会选择最稳妥、改动最小、对业务影响最小的方式因为红队的核心目标是模拟攻击行为不是为了破坏对方的业务系统任何可能引发生产故障的操作都应该避免。做完权限维持后需要对入口阶段的整体情况进行一次评估入口是否稳定、权限在哪一层、能接触到哪些数据、下一步横向的起点在哪。这是红队和普通渗透测试在流程上最大的区别我们永远带着“下一步要去哪”的视角在做当前这一步操作而不是单纯为了证明“能打进去”。3. 内网信息收集与权限定位3.1 内网拓扑的快速梳理从Web服务器这个跳板进入内网后第一个动作不是横向乱穿而是先对内网做一次快速梳理。在这个阶段我会优先关注几类信息当前机器所在网段的IP分配情况、DNS服务器和域控服务器的位置、ARP缓存和路由表、以及当前会话能够访问的网络共享资源。这些信息不需要什么高端工具系统自带命令就能收集。看IP配置和路由表能知道当前机器在网络中的位置看域名解析配置能判断域环境的规模看当前建立的会话连接能发现其他机器通过什么协议访问了当前机器。红队判断内网规模大小通常先看三样东西是否存在域控、网段划分是否细致、运维管理是否集中。如果这些信息都能拿到内网横向的基本地图就出来了。这次目标企业的内网规模属于“中型偏上”划分了办公网、生产网、开发网、运维管理网四个区域。但让我诧异的是网络分区分得很细却没有做严格的访问控制。Web服务器所在的区域可以直达运维管理网段的某些主机只是探测时需要绕过一些简单的访问控制列表。内网信息收集阶段最忌讳的就是“无头苍蝇式扫描”。有些测试人员进了内网就开始整个C段大扫端口全扫漏洞全打结果动静太大很快就会被安全设备拦住。红队更讲究“精准制导”通过当前机器已有的信任关系、配置文件里的连接信息、历史命令记录、共享目录的访问日志把真正有价值的横向目标先圈出来再逐一尝试。3.2 凭证获取内网横移的钥匙要说内网横向移动最核心的依赖那一定是凭证。不管是明文密码、哈希值、令牌还是票据内网系统之间的信任本质上是建立在这些密钥材料之上的。你可以在不接触业务数据的情况下仅靠合法凭证在内网里绕一圈看起来就像正常用户一样这是最理想的状态。这次项目中我拿到的最关键凭证来自一个排障脚本。运维人员在服务器上存放了一个用于自动化排查的脚本脚本内部包含了连接多台数据库服务器的账号密码密码是明文写死在脚本里的而且用的是同一个口令。更离谱的是这个口令也被用于若干台Windows服务器的本地管理员账号。这意味着我只要拿到口令就相当于拿到了这个运维团队的一小串钥匙。凭证获取手段在这块区域比较集中一是翻配置文件二是查看进程命令行参数三是转储当前会话的令牌和内存中的凭据四是寻找明文保存在磁盘上的文档。红队在这类操作中有一套优先级先从易到难、从静态到动态尽量避免触发终端安全软件的告警。这里必须提醒做防御的同学别把口令保存在自动化脚本、配置文件、说明文档里更不要把同一个口令用在服务器、数据库、办公系统等多个场景。复用凭证是内网横向移动能够成功的最主要原因没有之一。3.3 权限提升的决策点拿到了弱口令凭证不代表就有了高权限。横向移动过程中会遇到一些操作需要管理员权限比如修改防火墙规则、安装某些工具、读取加密的配置文件。这时候需要做提权决策。在实际操作中我判断是否要提权有一个基本原则能用现有权限做到的事情绝不为了“显得厉害”而去做提权。因为每一次提权都可能引入更大的被感知风险蓝队对提权行为的监测通常比对普通横向登录更敏感。如果当前权限已经可以满足数据访问和目标覆盖那就不需要提权只有当遇到明确的权限边界才会去尝试该找提权路径。提权路径的选取上优先考虑系统自带的合法机制比如利用计划任务、利用服务配置缺陷、利用内核已知漏洞。一般只有在没有现成路径的情况下才会考虑公开漏洞利用。公开漏洞利用虽然效率高但有一个通病攻击载荷容易被杀毒软件识别而且一些漏洞利用代码本身的稳定性并不好可能导致目标进程崩溃这对红队来说是大忌。这次目标机器的权限情况还算顺利。Web服务器虽然是以低权限用户运行但内网中还有一批服务器没有打全补丁我利用一个公开的本地权限提升漏洞拿到了操作系统管理员权限。整个过程没有出现异常报警规则也没有被触发但这并不是因为对方没有监控而是因为我的操作完全模拟了正常运维行为。这本身也是一条值得防御方反思的问题。4. 内网横向移动链路搭建4.1 横向移动的目标优先级横向移动不是“能连多就连多”而是在有限的时间和有限的隐蔽性预算内找到访问核心资产的最短路径。这次项目的核心资产是业务数据库和代码仓库所有横向移动的规划都围绕这两类目标展开。我在内网里的移动策略是“分跳板推进”第一跳从Web服务器到运维管理区的一台跳板机第二跳从跳板机到数据库管理服务器第三跳再从数据库管理服务器访问核心业务库。每一步都尽量使用已有的合法凭证和正常管理协议不做高危操作不在目标机器上放置额外的工具文件。这里有个经验横向移动时尽量少往目标机器上传东西。很多团队习惯把工具打包传上去然后在目标机器上执行这种做法容易触发行程监控和文件扫描。如果目标机器本身有PowerShell、各类系统自带脚本环境就尽量基于现有环境完成操作减少文件落地的痕迹。目标优先级排序我会列一个表格来管理核心资产、关联系统、低价值资产分类清楚然后根据可达性、凭证覆盖情况和权限深度来决定先打哪个、后打哪个。这种表格化管理看起来麻烦但在跨多天、多阶段的红队项目中极为有用能帮你保持思路清晰不会在横移过程中“绕晕”。目标类型典型资产横向优先级说明核心数据资产业务数据库、备份库最高直接决定项目成败运维管理节点跳板机、自动化运维平台高汇聚大量凭证和访问路径代码与配置资产Git仓库、CI/CD平台高代码里往往藏着更多密钥办公协作资产邮件、文档库中可以作为钓鱼和进一步权限跳板通用服务器打印、文件、临时业务低除非需要否则不做重点4.2 从跳板机到核心数据库这次横向移动的关键节点是一台运维跳板机。这台机器上的运维管理平台可以一键连接到多个生产环境的主机而且连接凭证是统一托管的。换句话说只要控制了这个跳板机就等于拿到了整个运维网络的控制权限。从Web服务器到达跳板机的过程不算复杂但每一步都必须谨慎。我先用现有的普通域账号远程登录了几台办公区机器再通过它们作为跳板转到了运维管理区。这个过程中最需要注意的是登录来源的合理性如果一台普通办公机器突然产生了大量到运维区的访问日志蓝队肯定会盯上。进入运维管理区后我发现这个平台在统一凭证管理上有明显的设计缺陷管理员后台存在一个查询功能可以批量获取连接主机的认证信息。虽然不是以明文展示但通过接口直接拿到凭证并不需要调用系统底层接口而且这个行为在平台自己的日志里是正常业务操作。这就是“高级权限滥用”的典型场景。拿到数据库服务器访问凭证后我并没有直接去连核心数据库而是先在跳板机上观察了一段时间确认对方的运维值班规律和告警处理习惯选择了业务低峰时段进行连接。最终的结果是顺利读取了核心业务库中的部分数据以验证访问能力整个过程没有修改任何数据。红队项目的目标不是摧毁而是证明“能到这一步”。4.3 横向移动过程中的痕迹管理内网横向移动做得好不好很大程度上取决于痕迹管理做得到不到位。蓝队排查攻击的时候通常会从三个维度入手登录日志、进程行为、文件变更。对应地红队在横向移动时也要在这三个维度做好“伪装”。登录时间尽量贴近正常运维时间。下班后突然有账号在服务器上登录这种行为本身就是异常信号。我一般在工作日白天操作或者在对方运维人员也有操作的时间段操作这样混在大量正常日志里很难被快速识别出来。认证凭证尽量用真实凭证。前面拿到的那串口令在这里发挥了很大作用因为用合法凭证做事产生的认证日志和真实用户几乎没有区别。进程行为上尽量用系统自带工具。能用PowerShell的一定不用第三方工具能通过标准管理接口操作的一定不额外装客户端。文件层面严格遵守“不落地、不修改、不新增”的原则。需要执行的命令可以即时执行完就返回需要读取的文件只在内存里处理不在目标机器上留副本。有一点我想特别说明这次项目中蓝队其实部署了终端安全管理软件也设置了流量审计规则但为什么还是没能拦住整条链路的推进核心原因不在于工具不够强而在于大部分告警都被当成噪音忽略掉了。红队的整个操作行为和正常的IT运维行为太像了所以蓝队需要投入更多精力去做的不是堆工具而是识别“正常的异常”比如某个账号在短时间内访问了大量本不该访问的主机。5. 攻击链复盘与防御加固建议5.1 攻击链的核心失败点在哪项目结束后我把整条攻击链重新复盘了一遍找出导致目标被攻陷的关键失败点而不是把所有原因都简单归到某个漏洞上。第一失败点是资产不清。旧的人力资源系统不在资产清单里导致它没有纳入常规漏洞管理流程。没有漏洞扫描、没有补丁更新、没有安全基线配置一旦暴露在外就等于给攻击者留了一个稳定的入口。第二失败点是凭证复用严重。同一套口令用在了数据库、服务器、运维平台等多个地方攻击者只要拿到一个点就能横着走。第三失败点是网络访问控制形同虚设。分区分域做得很细但区域之间的访问规则没有真正收敛大量不该通的端口和协议其实是通的。第四失败点是日志告警存在大量漏报。安全设备不是没告警而是告警太多、误报率太高运营团队已经疲劳真正有价值的告警被淹没在噪音里。这四条失败点单独拿出任何一条都未必能导致系统被攻陷。但组合在一起就串成了一条完整的攻击链。这既是红队项目的价值所在也是防御方最需要去反思的地方。5.2 针对本次链路的具体加固清单攻击链复盘之后我整理了一份加固清单分成了几个优先级来处理。第一优先级的动作是收敛入口面。清理所有无主资产关停不用的旧系统统一接入身份认证平台对必须对外开放的服务进行端口收敛和访问控制。入口如果不收后面做再多加固都是白费。第二优先级是解决凭证管理。部署统一凭证管理平台最小化凭证使用范围建立定期轮换机制。尤其是运维场景禁止在脚本和配置文件里出现明文口令。第三优先级是收敛横向移动路径。梳理各区域之间的访问关系建立默认拒绝的访问控制策略。重点收紧运维管理区到生产数据区之间的路径不能因为内部信任就放开所有访问。第四优先级是优化安全运营质量。不只是增加更多安全设备而是把现有的日志数据用好。这包括建立有意义的告警降噪规则、持续改进告警处置流程、做定期的攻击链模拟演练让安全团队能够在真实攻击中更快地识别异常行为。5.3 给防御方的一些实在建议做红队项目这么多年我越来越觉得很多防御团队缺的不是工具而是一种“攻击者视角”的思考方式。不是说你部署了多牛的安全产品就能挡住所有攻击。而是你得知道攻击者会怎么想、怎么做才能提前在那个位置上筑好防线。对于防御方我有几条建议值得参考。第一条是定期做内网可达性审计。内网横移能不能做起来对红队来说取决于每条路径是否可达。可以参考这个方法每年做一次横向路径图谱绘制梳理出所有业务区域之间的可达路径再逐一审视这些路径是否真的需要存在。这比单纯上防火墙规则要有效得多因为你是在控制逻辑层面收敛风险。第二条是高价值资产要优先防护。不是所有服务器都需要同样的安全防护等级核心数据库、备份系统、代码仓库、运维管理平台这些关键资产应该享受最严格的控制和最密切的监控。把防护资源集中到最关键的地方比平均用力要好很多。第三条是告警运营至少要有人真正威胁狩猎。很多安全团队把精力都花在合规检查和告警处理工单上却没有时间去做深度的威胁分析。真正在红队对抗中能发挥价值的往往是那些愿意盯着一整类日志看半天的人。如果你们团队现在还没有人专门做这件事我强烈建议至少安排一个人去试。我个人在实际操作中的一个体会是红队项目最迷人的地方不是在某个漏洞利用上的奇技淫巧而是它可以帮一个组织在最真实的环境里看到自己的安全盲区。每一条完整的攻击链最终都能变成推动安全建设往前走的有效依据。希望这篇复盘里的思路也能给正在做防御建设或者准备做红队演练的同行一点参考。