企业官网建设流程全解析

简介：这份PDF资料面向Java Web安全方向的学习者与求职者，系统梳理了红队面试中高频出现的漏洞知识点与攻防思路，适合已有一定Web安全基础、准备安全岗位面试或希望查漏补缺的中级人员。内容围绕Java反序列化、Shiro、Fastjson、Weblogic等常见漏洞展开，并延伸至IIOP、T3协议、SSRF、权限绕过、Java RMI与JRMP通信机制，同时覆盖横向渗透、命令执行、密码抓取及域内攻击方法等实战话题。资源包内仅含1个PDF文件，大小约184KB，篇幅紧凑，以问答形式呈现，便于快速定位与复习。目前已有265人学习下载。读者可借助其中的面试问答与利用原理梳理，快速建立Java Web漏洞知识框架，理解Shiro RememberMe判断、Fastjson @type利用、Weblogic T3反序列化等关键细节，并补充域内委派、NTLM Relay等进阶攻击面，适合作为面试前的速查清单与知识串联材料。

1. 从一份红队面试复盘说起：Java Web 打点到底在考什么

很多人第一次翻这份《某亭红队面试.pdf》，注意力都放在“面试题”三个字上，觉得背完答案就完事。真上手做项目才发现，面试里问的每一条——Shiro 的 rememberMe 字段怎么判断、Fastjson 的 @type 怎么触发、Weblogic 的 T3 协议怎么走——都是实战里绕不过去的卡点。这份资料的价值不在于“押题”，而在于它把 Java Web 打点这条链路拆成了可验证的知识点：从反序列化入口识别，到不出网情况下的回显与正向连接，再到横向渗透和域内攻击的衔接。适合已经能看懂请求包、但一遇到 Java 站点就不知道从哪下手的从业者，也适合想系统梳理自己知识盲区的人。下面我按“先认漏洞、再谈利用、最后说边界”的顺序，把这份资料里真正能落地的部分拆开讲。

2. Java 反序列化打点：Shiro、Fastjson、Weblogic 的识别与触发

2.1 为什么 Java Web 打点优先盯反序列化

Java Web 程序跑起来基本都是高权限，部分场景会降权，但多数中间件和框架在启动阶段就以较高权限驻留。这意味着一旦反序列化入口被打开，攻击者拿到的往往不是普通用户权限，而是接近服务账户的权限。常见做法是先把 Shiro、Fastjson、Weblogic 这三类入口过一遍，因为它们覆盖面广、公开利用链成熟、回显方案也相对完整。用资料里的话说，就是“优先以 java 反序列化这些漏洞进行打点，随后再找其他脆弱性易打进去的点”。这个顺序不是拍脑袋，而是因为反序列化漏洞的利用链一旦打通，后续横向和权限维持的成本会低很多。

2.2 Shiro RememberMe 的四种返回包状态

Shiro 的识别核心在 rememberMe 字段和 deleteMe 的返回组合。资料里把四种情况列得很清楚，我按实际抓包顺序重新整理一遍，方便对照：

这四种状态是判断目标是否使用 Shiro 的第一手依据。实战里我一般先发一个不带 Cookie 的请求，看返回包有没有 deleteMe；再模拟一次失败登录，确认 deleteMe 是否稳定出现。如果返回包里始终没有 deleteMe，那大概率不是 Shiro，或者被前置代理改写了响应头。资料里还提到用 shiroScan 做被动扫描，这个思路在批量资产梳理时比较省事，但单点确认还是手动抓包更可靠。

2.3 Shiro 550 与 721 的利用差异

资料里把 Shiro 漏洞归为 shiro 550 和 shiro 721 两类。550 的核心是 rememberMe 的 AES 密钥硬编码，攻击者可以构造恶意序列化数据，让服务端在反序列化时执行命令。721 则是在特定版本下对 Cookie 处理逻辑的绕过，利用条件更苛刻，但同样能打到反序列化入口。实际利用时，550 的 payload 生成工具比较多，但要注意目标 JDK 版本和依赖库是否在利用链上；721 则需要先确认版本范围，不能拿 550 的 payload 直接套。我一般会先跑一遍版本识别，再决定走哪条链，避免在 721 目标上浪费时间试 550 的 payload。

2.4 Fastjson @type 的触发逻辑

Fastjson 的问题出在对 @type 字段的过滤不严。资料里的描述很直白：请求包里发恶意的 JSON 格式 payload，漏洞在处理 JSON 对象时没有对 @type 做过滤，攻击者可以传入恶意的 TemplatesImpl 类，这个类有一个 _bytecodes 字段，部分函数会根据 _bytecodes 生成 Java 实例，从而在类被生成时执行构造函数。用代码表示就是：

{ "@type": "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl", "_bytecodes": ["恶意字节码的Base64"], "_name": "a", "_tfactory": {}, "_outputProperties": {} }

这段 payload 的关键在于 _bytecodes 里放的是编译好的恶意类字节码，Fastjson 在反序列化时会尝试实例化 TemplatesImpl，进而触发 defineClass 和 newInstance。参数上要注意 _name 不能为空，_tfactory 要给一个空对象，_outputProperties 是为了让 getter 被调用。实际打的时候，目标 Fastjson 版本决定了是否需要开启 Feature.SupportNonPublicField，这个在构造 payload 时就要确认，否则会一直报错但看不出原因。

2.5 Weblogic 的 T3、XML 与权限绕过

Weblogic 的入口比 Shiro 和 Fastjson 更杂。资料里提到基于 T3 协议的反序列化、基于 XML 解析的反序列化，还有 SSRF 和权限绕过。T3 协议是 Weblogic 独有的通信协议，默认端口 7001，攻击者可以直接发 T3 握手包，然后在序列化数据里塞利用链。XML 解析的反序列化则常见于 WLS 的某些管理接口，利用方式与 T3 类似，但入口在 HTTP 层。权限绕过方面，资料里提到用./进行绕过，这个思路在 Weblogic 的某些路径校验场景下有效，比如访问/console/./css/..这类路径时，前置校验可能被绕过，但后端仍然能解析到目标资源。实际测试时，我一般先用 T3 协议探一遍，如果端口不通再走 HTTP 层的 XML 入口，权限绕过则放在最后作为补充。

3. 不出网与横向渗透：回显、正向连接与命令执行选择

3.1 不出网时反序列化漏洞怎么回显

资料里问“这几个漏洞不出网情况下怎么办”，答案是让漏洞回显。反序列化漏洞的回显通常有两种思路：一种是利用目标本身能发起的网络请求，把执行结果带出来；另一种是直接修改响应内容，让命令执行的结果出现在当前 HTTP 响应里。常见做法是构造一个能读取命令输出并写入 response 的利用链，比如在 TemplatesImpl 的字节码里直接操作 response 对象。但这种方式依赖目标中间件的上下文，不是所有版本都能通用。我一般会先确认目标是否真的完全不出网，有时候只是 DNS 出不去，但 HTTP 能通，那就还有回显空间。

3.2 Webshell 不出网的正向连接与协议探测

拿到 webshell 但不出网时，资料里给的方向是“reg 上传去正向连接，探测出网协议，如 dns、icmp”。正向连接的意思是让目标主动连回来，而不是等攻击者连过去。reg 上传通常指通过注册表或者文件上传的方式把正向连接工具传上去，然后让目标执行并监听某个端口，攻击者再连过去。协议探测则是判断目标能不能发 DNS 或 ICMP，因为这两种协议在很多限制环境下仍然可用。DNS 出网的利用方式，资料里提到“将域名解析指向自己的 vps，然后设置 ns 记录”，这个思路是通过 DNS 查询把数据带出来，但配置起来比较繁琐，需要有自己的域名和 NS 记录控制权。

3.3 横向命令执行：psexec、wmic、smbexec、winrm 的取舍

横向渗透的命令执行手段，资料里列了 psexec、wmic、smbexec、winrm、net use 共享加计划任务加 type 命令。它们的区别主要在日志记录和隐蔽性上：

资料里特别提到“psexec 会记录大量日志，wmic 不会记录下日志，wmic 更为隐蔽”。这个结论在实际项目里很关键，因为横向阶段一旦触发告警，整个链路都可能被切断。我一般会先用 wmic 做命令执行验证，确认通道可用后再根据目标环境决定是否用 psexec 做批量操作。

3.4 Dcom 与抓取密码的实操边界

Dcom 的操作资料里说“通过 powershell 执行一些命令，命令语句比较复杂”，这个描述很真实，因为 Dcom 的利用确实依赖具体的 COM 对象和权限配置，不是一条命令就能搞定。抓密码方面，资料提到 procdump 加 mimikatz 转储后离线读取，以及 Sam 获取后离线读取。Windows Server 2012 之后，内存中的明文密码默认不再保留，所以抓不到明文时，资料给的方向是“翻阅文件查找运维等等是否记录密码，或者 hash 传递，或者获取浏览器的账号密码”。这个思路是对的，因为当内存抓不到时，配置文件、脚本、浏览器保存的凭据往往才是突破口。

4. 域内攻击与协议细节：IIOP、RMI、JRMP 的常见混淆点

4.1 IIOP 与 Java RMI 的关系

资料里问“IIOP 听说过吗，和什么类似”，回答是“java RMI 通信，也就是远程方法调用，默认是使用 jrmp 协议，也可以选择 IIOP”。这里容易混淆的是 JRMP 和 IIOP 的定位。JRMP 是 Java 原生的远程方法调用协议，默认走这个；IIOP 则是 CORBA 的互联网内部对象请求代理协议，Java RMI 可以基于 IIOP 实现，以便和非 Java 系统互通。实际打点中，IIOP 入口常见于 Weblogic 的某些版本，因为 Weblogic 同时支持 T3 和 IIOP。如果目标只开了 IIOP 没开 T3，那就需要走 IIOP 的利用链，而不是硬套 T3 的 payload。

4.2 域内攻击方法的分类

资料里列了 MS14-068、Roasting 攻击离线爆破密码、委派攻击、非约束性委派、基于资源的约束委派、ntlm relay。这些方法可以按利用条件分成几类：MS14-068 是 Kerberos 协议层面的漏洞，利用条件比较苛刻，但一旦成功可以直接拿到域管权限；Roasting 攻击分为 AS-REP Roasting 和 Kerberoasting，前者针对不需要预认证的账户，后者针对有 SPN 的服务账户，都是离线爆破密码；委派攻击则分为非约束性委派、约束性委派和基于资源的约束委派，非约束性委派最危险，因为被委派的主机可以获取任何用户的 TGT。实际项目中，我一般先跑一遍 AS-REP Roasting 和 Kerberoasting，因为这两类不需要高权限，拿到 hash 后离线爆破，成本低且不容易触发告警。

4.3 会话劫持的前提条件

资料里问“桌面有管理员会话，想要做会话劫持怎么做”，回答是“提权到 system 权限，然后去通过工具，就能够劫持任何处于已登录用户的会话，而无需获得该用户的登录凭证”。这个描述基本正确，但有一个前提：攻击者需要先拿到目标主机的 system 权限，否则无法访问其他用户的会话令牌。终端服务会话可以是连接状态也可以是未连接状态，这意味着即使管理员断开了 RDP，会话仍然可能保留在内存中，攻击者依然可以劫持。实际利用时，我一般先用 whoami /priv 确认当前权限，再决定是否走会话劫持这条路。

5. 避坑与排查：这份资料里没写全但实战常翻车的地方

5.1 Shiro 返回包被代理改写导致误判

现象：抓包时返回包里始终看不到 deleteMe，但目标确实用了 Shiro。原因：前置代理或 WAF 改写了响应头，把 set-Cookie 里的 deleteMe 过滤掉了。解决：换一个不经过代理的直连地址，或者用 shiroScan 的被动扫描模式，从请求特征而不是响应特征来判断。

5.2 Fastjson payload 版本不匹配导致静默失败

现象：发送 @type payload 后没有任何回显，也没有报错。原因：目标 Fastjson 版本不支持某些 Feature，或者依赖库不在利用链上。解决：先确认目标 Fastjson 版本，再根据版本选择是否需要开启 SupportNonPublicField，以及换用不同的利用链。不要拿一个 payload 反复试，浪费时间且容易触发告警。

5.3 Weblogic T3 协议被防火墙拦截

现象：T3 握手包发出去没有响应，但 HTTP 端口是通的。原因：防火墙只放行了 HTTP，T3 协议被单独拦截。解决：改走 HTTP 层的 XML 反序列化入口，或者用权限绕过先进入管理后台，再从后台找其他入口。不要死磕 T3，先确认端口和协议是否可达。

5.4 不出网时 DNS 出网配置错误

现象：配置了 NS 记录但目标仍然无法把数据带出来。原因：NS 记录没有生效，或者目标环境的 DNS 查询被强制走内部解析。解决：先用 nslookup 确认目标能否解析外部域名，再检查 NS 记录是否指向正确的 VPS。如果 DNS 完全不出网，那就只能走 ICMP 或者正向连接。

5.5 抓密码时忽略配置文件

现象：procdump 和 mimikatz 都抓不到明文密码，以为没戏了。原因：Windows Server 2012 之后默认不保留明文密码，但配置文件和脚本里可能写了密码。解决：翻一遍 web.config、app.config、脚本文件、浏览器保存的凭据，很多时候这些地方的密码比内存里的更好用。

6. 从面试复盘到实战验证：我习惯用的一套检查顺序

这份资料最后提到“面试的攻击手法其实也就这些，懂了就 ok”，但真到项目里，懂了和能打下来是两回事。我自己的习惯是，拿到一个 Java Web 目标后，先按固定顺序过一遍：第一步，抓一个不带 Cookie 的请求，看返回包有没有 deleteMe，确认是不是 Shiro；第二步，如果确认是 Shiro，先跑版本识别，再决定走 550 还是 721；第三步，如果目标不是 Shiro，就试 Fastjson 的 @type 探测，发一个带 @type 的 JSON，看返回包有没有报错或者延迟；第四步，如果目标开了 7001，直接发 T3 握手包，确认 T3 是否可达；第五步，如果以上都不通，再走 HTTP 层的 XML 入口和权限绕过。

这套顺序不是固定的，但有一个原则：先确认入口是否存在，再确认利用链是否可用，最后才考虑回显和横向。很多新手一上来就构造 payload，结果目标根本没有对应的漏洞，白白浪费时间和流量。我一般会在每一步都留一个判断依据，比如 Shiro 看 deleteMe，Fastjson 看报错信息，Weblogic 看 T3 握手响应。这些依据比 payload 本身更重要，因为它们决定了下一步往哪走。

验证方法上，我习惯用本地搭一个模拟环境，把 Shiro、Fastjson、Weblogic 各装一个版本，然后按资料里的知识点逐个复现。比如 Shiro 550 的 payload 在本地打一遍，确认返回包状态和命令执行结果；Fastjson 的 @type payload 在本地跑一遍，确认版本和 Feature 的对应关系；Weblogic 的 T3 握手在本地抓一遍，确认协议格式和响应特征。本地环境的好处是可以随便试，不用担心触发告警，而且能看清每一步的细节。

从那以后我每次拿到新目标，都强制走一遍“入口确认、版本识别、利用链选择、回显验证”这四步，不再跳步。这份资料里的面试题，本质上就是这四步的问答版，把它当成检查清单用，比当成题库背更有效。希望帮到你。

本文还有配套的精品资源，点击获取