1. 红队测试的思路起点先搞清楚目标到底想要什么做过几年安全测试的人基本都会有一个体会红队测试和传统漏洞扫描完全是两码事。漏洞扫描是拿着工具梭哈一遍出一份报告就完事红队测试是模拟真实攻击者在一个固定时间窗口内围绕某个核心目标去设计一条完整的攻击链路从边界打到内网最终验证的是如果真有人想搞我们他能不能做到。我刚接到这个从入口突破到内网横向的项目时第一反应不是去找工具而是先和委托方确认三件事测试范围边界在哪、核心业务资产是什么、有哪些操作是绝对不能碰的。这三个问题直接决定了后续整个测试方案的走向。先说测试边界。很多团队在启动红队项目时容易忽略一个细节所谓的授权范围不能只在合同里写允许测试目标域名而是要把IP段、域名、云资产账号、无线网络、物理办公区域全部列清楚。我在这个项目里碰到的情况是委托方给了一个主域名和几个业务系统地址但我通过子域名枚举和证书透明度日志很快发现他们还挂了一个不在清单里的测试环境这个测试环境用的是弱口令而且和核心内网段之间没有做严格的访问控制。这种情况下我一般会先停下来把这个情况同步给委托方确认这个测试环境是否在授权范围内。别觉得这是多余的谨慎红队测试翻车往往就翻在这种我以为在范围内的模糊地带。再说核心资产。委托方说的是我们最担心的是核心数据库被拖走听起来很明确但真正执行的时候你会发现数据库往往不是直接暴露在公网的你要先打进某个边缘系统再一步步横向移动到数据库所在的网段。所以红队测试的核心任务可以拆成两个阶段第一步解决怎么进去的问题第二步解决进去之后怎么抵达目标的问题。入口突破考验的是信息收集的深度和漏洞利用的精准度内网横向考验的是对网络拓扑的还原能力和对各种协议特性的理解。这套思路其实和真实攻击者的决策逻辑是一致的只是立场不同。红队做的每一件事本质上都是在回答三个问题这个系统有哪些可触及的入口哪个入口最容易突破突破之后我能在内网走多远下面的内容我会按这个逻辑线展开把整个测试过程拆开讲清楚。2. 入口突破信息收集决定你能走多远2.1 外围信息收集的核心动作入口突破阶段的成功率九成取决于信息收集做得多细。我见过不少人一上来就拿着漏扫工具对着目标IP一顿扫扫出几个高危漏洞就觉得万事大吉。这种做法在红队测试里其实很低效因为目标系统在真正上线前多半已经修过一轮常见的Web漏洞你很难直接扫出那种一键拿权限的洞。我更习惯把信息收集分成三层来做。第一层是域名资产梳理。除了委托方提供的主域名还要通过DNS历史记录、子域名爆破、证书透明度日志、搜索引擎语法去把目标的数字资产地图完整画出来。这个项目里我找到的测试环境子域名就是在证书透明度日志里翻到的——有些团队在申请HTTPS证书的时候会顺手把测试环境的域名也加进证书里这类资产往往防护薄弱、管理松散是很好的切入点。第二层是基于指纹的端口与中间件识别。探测结果不只看开放了哪些端口更要判断端口背后跑的是什么服务、什么版本、什么框架。比如目标对外开放了一个Web应用用的是什么中间件、什么开发框架、有没有接入WAF、WAF是什么品牌这些信息决定了后续测试手法的选择。这一步强烈建议把指纹识别结果做成表格把端口、服务、版本、可能存在的历史漏洞对应起来方便后续筛选优先级。第三层是业务逻辑的梳理。登录入口、找回密码接口、上传点、API接口列表、第三方集成的回调地址这些都是最容易出现逻辑漏洞的地方。红队测试和自动化扫描最大的区别就在这里自动化工具体系不到业务逻辑层面的问题但真实的攻击者会一个接口一个接口地去试。信息收集维度主要手段关注重点资产面子域名枚举、证书透明日志、DNS历史记录隐藏资产、测试环境、过期域名的残留解析技术栈端口扫描、指纹识别、网页源码分析框架版本、中间件类型、WAF特征、开发语言业务面功能清单梳理、请求抓包分析、接口遍历登录鉴权缺陷、越权风险、文件上传、验证码逻辑、API未授权访问三层信息收齐之后就要做攻击路径的优先级排序。我的做法是给每个可能的入口打三个等级A级是一击必中的入口比如未授权访问、弱口令、框架RCEB级是需要配合其它条件的入口C级是概率较低的入口。测试时间有限应该把精力集中在A级入口上这也是实战和演习最大的不同——实战不追求把所有漏洞都测一遍只追求在最短时间内达成目标。2.2 从边缘入口到第一台主机的突破这个项目里最终突破的入口是一个不起眼的文件上传功能。当时做指纹识别的时候发现目标跑的是一个开源CMS的二次开发版本官方已经披露过一个文件上传绕过漏洞。但直接套用公开的利用脚本失败了原因是团队做了两处加固一是给上传目录设置了只读权限二是对文件内容做了MIME类型校验。很多人在这一步就放弃了但事实上这种半吊子加固往往留有死角。我重新翻了一遍文件上传的整个流程发现有一个头像裁剪功能会调用服务端的图像处理库裁剪之后生成的新图片会写到另外一个没有做权限限制的临时目录。思路一下就清晰了不是直接上传WebShell而是上传一个带有恶意代码的图片文件再通过裁剪功能触发服务端对图片的二次处理让恶意代码在代码执行路径中存活下来。整个利用过程并不复杂但有一个关键细节决定成败文件内容校验绕过了但目标服务器装了一个主机安全Agent会对新增的可执行文件做实时检测。所以文件落地之后我没有立刻执行命令而是先观察了一段时间摸清Agent的检测规律再利用一个白名单目录完成了文件落地。这里我要多说一句这个案例不代表所有上传点都能这么打。很多红队报告写到这一步就停了只写发现文件上传漏洞可上传WebShell风险等级高这样的报告其实价值有限。真正有价值的说法是上传点为何可以绕过校验、恶意文件最终落在哪个目录、这个目录为什么能执行脚本、后续能做什么操作、应该怎么修复。攻击链的每一步都要能回推到具体的配置缺陷或代码缺陷上。拿到第一台主机的命令执行权限之后任务只完成了三分之一。接下来要做的事情按优先级排列是收拢凭据、摸清主机在网络中的角色、寻找内网横向的跳板。3. 内网横向的要点不是扫IP是走逻辑链路3.1 把横向移动拆成五个子问题很多文章把内网横向移动写得特别玄乎什么Lateral Movement、Pivoting讲一大堆名词但落到实操层面核心问题其实只有五个。第一当前主机是什么角色是Web服务器、应用服务器、文件服务器、还是开发人员的办公终端不同角色意味着不同的凭据价值。第二当前主机上能拿到什么凭据明文密码、哈希、缓存的Kerberos票据、SSH私钥、数据库连接串、云平台的临时凭证这些都是横向移动的燃料。第三当前主机可以到达哪些网段通过路由表、ARP缓存、会话连接可以快速判断主机在内网里的位置。第四内网里有哪些关键系统域控、核心数据库、备份系统、运维管理平台这些是最终要拿下的目标。第五从当前主机到关键系统之间有哪些路径可能直接相通也可能要经过多台跳板机。如果你把这五个问题想清楚了整个过程就不再是盲目地扫网段、批量尝试密码而是一条有明确逻辑支撑的路径规划。这恰恰是红队和脚本小子的本质区别。3.2 SMB共享、计划任务与横向扩散在这个项目里拿到第一台Web服务器的权限之后我在内存中找到了SQL Server的管理员账号密码哈希同时发现Web服务器可以访问内网里的一台SQL Server。最开始我用的是最经典的哈希传递手法通过SMB协议在SQL Server上执行命令。但第一次尝试失败了原因是目标环境的SMB签名是强制开启的哈希传递被直接拒绝。这里就涉及到一个很重要的排查习惯单点失败要先确认是手法问题、网络问题还是协议问题而不是急着换另外一个工具继续打。排查后确认SMB签名确实开启并且没有域环境可以获取票据所以我换了一个思路改从SQL Server的xp_cmdshell组件下手。这个组件虽然在默认配置下是禁用的但使用数据库账号重新启用并且执行命令只要拥有sysadmin权限就可以做到。执行计划大致分四步。第一步通过已获取的管理员账号连接SQL Server。第二步启用xp_cmdshell这里需要先启用SQL Server的CLR集成支持。第三步通过xp_cmdshell执行系统命令确认当前的执行身份和网络位置。第四步利用这条命令通道向SQL Server上传一个远控工具建立更稳定的控制通道替换脆弱的命令回显通道。整个过程需要特别注意一个时间问题xp_cmdshell启用之后目标环境的数据库日志会记录下这个操作如果对方有数据库审计事件可能很快被察觉。所以我在完成横向移动之后做的第一件事就是检查SQL Server的日志记录级别确认没有开启审计同时清理了执行的痕迹。Wait我把这个过程描述得偏具体了实际上写这篇博时我斟酌了很久要不要写这么细后来还是决定保留思路层面不把完整的工具链和命令放出来因为这篇内容的定位是讲测试方法论而不是做攻击教程。你要是在真实的授权测试中遇到类似场景思路完全可以复用但具体操作细节还是要结合你手上的环境和工具来做。真正重要的不是某个单一命令而是理解整个横向链路是怎么被脉动的全局逻辑搞清楚了工具只是细节问题。3.3 域环境下的权限视角切换这个项目比较幸运的地方在于目标内网是一个Windows域环境。域环境意味着一旦你能控制一台加域主机就能利用域内的信任关系去访问其它加域主机而不需要知道每一台主机的本地密码。在域环境下横向移动的思路会有一次很重要的视角切换从尝试账号密码去登录每台机器切换成利用域内的权限模型去获取更高层级的凭据。前者是点对点的横向移动后者是以域控为目标的权限回收。我在拿到SQL Server主机权限之后用域账号做了一次Kerberoasting攻击。简单解释一下这个手法的工作逻辑域环境里很多服务账号设置了SPN任何用户都可以向域控请求特定SPN的服务票据而这张票据是用服务账号的哈希加密的。如果能请求到一张票据再拿到本地暴力破解一旦密码强度不够就等于直接获得了某个服务账号的明文密码。整个过程不需要高权限普通的域用户就能发起这也是它被用得多的原因。破解这个票据花了将近十个小时因为目标环境的密码策略比较规范字典加规则跑了很久才跑出来最终拿到的是一个运维账号的密码。这个账号在域里属于服务器本地管理员组的成员虽然不算域管但它的权限覆盖了一批服务器足以支撑我继续往核心区域走。这一步有个特别值得强调的经验内网横向移动走到后面你的视野要一直保留一张网络拓扑图权限矩阵的实时清单。每拿下一台机器、每获取一个凭据都要立刻更新这张清单。很多人在内网里迷路不是因为工具不够强是因为做过的路径、获取过的凭据全靠脑子记走着走着就忘了哪些网段去过了、哪些账号试过了、哪些权限已经拿到了。4. 绕行与痕迹管理红队测试里的隐蔽战线4.1 为什么痕迹管理是关键能力很多刚开始做红队的人容易忽略痕迹管理觉得只要把命令执行了、数据拿到了就算成功。但实际上授权测试里最看重的是你是否能在不影响目标系统正常运行的前提下完整地模拟一次攻击并且把过程中的操作记录下来。如果因为你的测试动作导致业务中断、数据损坏、系统崩溃那这个测试基本可以算失败了。更现实的原因在于目标环境很可能部署了EDR、主机Agent、SOC平台你的每一个敏感操作都可能触发告警。如果你刚把WebShell落地就被杀掉刚执行命令就被阻断后面所有的横向路径都无从谈起。所以痕迹管理的本质不是搞破坏后擦屁股而是让整个测试在尽量安静的状态下执行确保测试动作不会提前暴露也不会给目标环境带来额外风险。4.2 实战中常用的降噪策略我把这次项目里用到的降噪策略分成四类它们在真实测试里可以组合使用。第一延迟执行。拿到命令执行权限后不急着做下一步动作先观察目标和目标环境的安全设备的响应周期。比如我上面提到的文件上传场景文件落地后等了一段时间再执行下一步目的就是确认Agent是实时拦截还是定时扫描。如果是定时扫描你就知道自己在哪个时间窗口内操作相对安全。第二白名单软件利用。与其上传一个从来没有见过的远控工具不如利用目标环境里已经安装的合法软件。比如用系统自带的远程管理工具、脚本宿主、云厂商的CLI工具甚至是目标运维人员自己装的远程控制软件。这些软件本身就在白名单里安全设备很难区分是运维在使用还是攻击者在滥用。第三减少主动扫描。在内网里做大范围的端口扫描非常容易被发现。一个更合适的替代思路是依靠已有的凭据和会话连接顺着目标环境正常的通信路径走。比如你已经控制了Web服务器而Web服务器本来就允许访问数据库的3306端口那就不需要额外扫描直接用这条现成路径即可。横向移动也一样能通过现有会话跳转的就不要探测新的网段。第四日志与时间戳的一致性。在做审计规避的时候很多人会直接清空日志或停掉日志服务这反而容易触发告警因为大部分安全基线要求日志服务必须持续运行。更稳妥的做法是只清理与你操作相关的特定日志条目或者退一步把时间戳改到业务高峰期让日志量大溯源难度提升。当然在授权测试里我并不建议大范围删日志一般只需要确保关键路径不被轻易追踪到就够了。这四条策略的核心逻辑是一致的降低异常特征的显著性。安全设备每天都在处理海量告警你的目标不是让告警消失而是让告警显得不突出、不紧急、不值得升级。5. 常见问题与排查技巧实录5.1 入口突破阶段的典型问题问题一漏洞存在但利用不成功。这是最频繁遇到的问题。处理顺序一般是先确认目标是否真的存在对应的漏洞版本再抓包对比公开EXP的实现方式和本地环境是否一致。很多利用失败的原因不是漏洞不存在而是目标对请求格式、编码方式、参数名做了一点小改动。这时候用Burp逐一比对请求包差异比换一个EXP硬试更有效率。问题二目标开了WAF扫描和利用都被拦。WAF拦截并不意味着这条路就断了。可以先识别WAF类型和规则强度有些WAF拦截的是特征明显的Payload但对分块传输、编码绕过、参数污染这些方式防护能力有限。优先级顺序建议是找业务功能点本身的问题比如登录绕过、越权比硬刚WAF更省时间。问题三拿到权限但是是低权限什么都干不了。低权限不等于没有价值。先看进程列表和网络连接你往往能从中发现正在运行的高权限服务、数据库连接串、以及内网会话。还有一种情况是当前拿到的是Web应用的虚拟用户权限但系统里存在提权漏洞或错误的权限配置可以从内核版本、计划任务、服务权限、注册表键值这些方向逐个排查。5.2 内网横向阶段的经典卡点卡点一哈希传递被SMB签名阻断。除了换用其它协议之外还有几个思路可以尝试。比如目标如果开放了WinRM远程管理服务可以走WinRM执行命令如果目标是一台数据库服务器可以通过数据库特性执行系统命令如果当前有域账号可以试试利用计划任务注册在目标上。卡点二拿到了域管哈希但登录不了域控。这种情况多半是域管账号启用了智能卡强制登录或者目标机器开启了受限管理员模式。处理方式是换一台不支持智能卡登录的域管成员主机或者利用域管哈希配合RDP受限管理员模式登录。卡点三内网存在多个隔离网段拿了一台机器只能访问其中一个段。这时候可以先把当前主机做一次完整的信息收集重点关注双网卡、路由表、代理配置、历史连接记录往往能找到跨网段通信的线索。另一个思路是查询目标环境使用的内部DNS很多内网DNS会记录所有内部主机的解析记录相当于一张免费的拓扑图。5.3 容易被忽视的细节清单结合这次实际项目我整理了一份容易被忽视但在关键时候能救命的细节清单拿到WebShell后最先做的事情是确认执行身份、网络位置和可出网协议不要急着弹一个交互式终端回来。内网横向时优先复用已有的SMB会话和已认证的连接而不是重新扫描新IP。在目标环境中执行的每一条命令都假设自己会被审计提前想清楚这条命令会不会带来不必要的噪音。对于获取到的密码和哈希及时更新到统一的凭据管理表里避免重复测试造成目标账号锁定。长耗时任务比如密码破解、大规模扫描一定要设置合理的超时时间并在测试计划里预留缓冲时间不要卡在最后一天才做关键操作。6. 从实战链路回到防御视角做完这套红队测试最有价值的产出其实不是那份漏洞列表而是完整的攻击链还原图。我们在复盘的时候特别强调一个概念一个漏洞打不打得穿目标取决于链条完整度。很多单位单个漏洞看起来都不算严重但串成一条链就能从Web入口一直打到核心数据库。防御的工作重点也因此更清晰——不是修单个漏洞而是打断链条的关键节点。在这套方案里我建议在三个位置优先投入防御资源。第一是入口到第一台主机的跨越处比如文件上传目录的权限控制、Web应用对非预期文件类型与内容的过滤、以及主机Agent对文件落地与命令执行的监控。第二是内网横向的跳板区比如SMB签名强制开启、域服务账号密码策略、不将运维账号加入过多的本地管理员组。第三是末端核心资产的最后一道防线比如核心数据库的访问控制白名单、数据库账号的最小权限原则、以及核心系统日志的独立备份存储。另外还有一个务实的建议每季度做一次针对域的权限配置审计重点查哪些用户或组在域里有本地管理员权限“哪些服务账号的SPN长期未用且密码从未轮换”这两个方向是大量内网横向攻击成功的根源。7. 一点个人心得红队测试做得越多越觉得真正拉开差距的不是工具而是对目标环境的理解深度。每一台主机的角色是什么、网络里如何流转流量、运维团队习惯用什么方式管理服务器、安全设备部署在哪些节点这些信息拼起来才是完整的攻击路径图。这次项目从入口突破到内网横向整个过程大约用了两个星期真正打穿链路只花了不到三天剩余时间基本都花在确认边界、沟通范围、梳理路径和写报告上。不少新人容易把红队想成黑客电影里那种酷炫的技术秀实际上的大头工作是非常枯燥的资产梳理和路径验证但恰恰是这些枯燥的部分决定了测试最终能不能摸到核心目标。最后分享一个我在多次实战里反复验证的经验一次成功的红队测试一定是甲方与测试团队配合的结果。甲方对范围的准确描述、对可疑操作记录的敏感反馈、对风险事项的及时确认都会让整个测试更贴近真实攻防的预期。红队的价值不只在于成功打进去了更在于打完之后大家能坐在一起把防线重新设计一遍。