背景
近期的 Apache Log4j 漏洞闹的沸沸扬扬，作为安全门外汉，安安静静躺平即可，奈何波及范围太广，手上管理的部分网络系统也存在一定漏洞，遂加入反漏洞大军，仅对 log4j 的漏洞攻击数据包做下简单分析。
🤣 主要是 log4j 技术分析文章都太专业，看得云里雾里的，勉勉强强凑个热闹。
?
概述
该漏洞是由于Apache Log4j 2 某些功能存在递归解析功能，未经身份验证的攻击者可以构造发送恶意请求数据包，进而触发远程代码执行漏洞，实现在目标服务器上执行任意代码。
?
影响版本：
CVE-2021-44228 Apache Log4j 远程代码执行漏洞：
Apache Log4j 2.x >=2.0-beta9 且 < 2.15.0 （2.12.2 版本不受影响）
?
CVE-2021-45046 Apache Log4j 拒绝服务与远程代码执行漏洞：
Apache Log4j 2.x >=2.0-beta9 且 < 2.16.0（2.12.2 版本不受影响）
?
?
分析
以 https://www.malware-traffic-analysis.net/ 分享的样本数据包 2021-12-11-thru-13-server-activity-with-log4j-attempts.pcap 为例。
该博客站长貌似是 PALO ALTO NETWORKS 的大佬，撰写了很多网络安全的技术博文，同时也上传了不少流量分析练习文件，YYDS~
?
查阅 Apache Log4j 漏洞相关技术分析文章，可得知 log4j 攻击的一个关键词是 jndi （也有包括像是 ${、ldap 等等），通过以下显示过滤表达式均可过滤出相关数据包。
frame contains jndi
ip contains jndi
源可见 Source 列来自于互联网各个攻击源，目的 Destination 列的 198.71.247.91 为测试服务器，一溜的恶意请求。
展开分组详细列表，可以看到不同的 HTTP 请求攻击方式，有的朴实无华，有的精心加工 。。。
以其中一个攻击源 45.137.21.9 为例，在 User-Agent 中携带了恶意攻击代码。
追踪 HTTP Stream 显示
Base64 转码后的 wget sh 命令。
因为被攻击的服务器如果有漏洞，之后会发起新连接去访问 ${jndi:ldap://hostip} 里的 hostip 地址，所以网络过滤检查也比较明确，被攻击服务器会发起 TCP 三次握手连接，之后完成相关漏洞攻击后续过程，本文不再赘述。
ip.src == 198.71.247.91 and tcp.flags == 0x002
获取到 tcp stream 具体 num 后，可以继续过滤分析
tcp.stream == xx
?
也许是这台测试的被攻击服务器并没有相关漏洞（仅作为收集攻击流量分析），因此该数据包文件过滤后并无结果。
转向另一个数据包示例，可以看到被攻击服务器 172.16.10.11 会新发起一条 TCP 流 2 去访问 172.16.10.105 8888 端口，之后获取恶意 class 文件执行代码等一系列过程。
?
总结
说是分析数据包，其实也就是简单走了个过场，专业的事情还是交给专业的同学解决吧，有兴趣的同学可以搭建测试环境好好研究下。
网友总结的绝：一句话，安全圈过年了，运维开发圈过清明了。网络好好吃瓜就好。。。
?
参考
http://www.colasoft.com.cn/news/20211210.php
https://github.com/fengxuangit/log4j_vuln
https://help.aliyun.com/noticelist/articleid/1060971232.html
https://zhuanlan.zhihu.com/p/443796302
https://blog.csdn.net/rpsate/article/details/121867782
https://www.jianshu.com/p/5b3045b9d5d5