pattern utilization of deserialization

Posted by barello at 2020-04-12

(360 A-Team recruits senior security researchers and apt attack and defense personnel for a long time, please contact [email protected])

Today, at the regular internal sharing meeting of the Department, Luan @ 360 A-Team shared with you the basic knowledge of windows NTLM and his NTLM proxy (pass the hash tool for network version). I've shared with you the tips mentioned in this article.

Boasting in the circle of friends

Running Java webshell on a target without a web service

No documents landed in the whole process

No web access logs will be generated

No HTTP traffic accessing webshell will be caught in the network


The target has a native Java deserialization vulnerability and can be echoed in one way or another. This requirement also makes the technique of this article appear to be not too practical, because in general, when there is deserialization, you usually just need a command to pop up a shell to get back to the next thing. So look at the scene.

Potential goals

This technique can be used by any target that has a Java Native deserialization vulnerability and can be echoed. For example, Weblogic / JBoss / WebSphere / RMI registry. I only implement RMI registry here.

General idea of realization

Create three classes httprequest / httpresponse / httpsession manually, and implement the necessary methods, such as httprequest.getparameter, httpresponse.getwriter, httpsession.setattribute, etc.

Let these three classes implement the serializable interface.

Transform jspy.jsp into jspy class, and transform its dependency on Java EE API into the three classes defined above. (this step realizes that Java webshell does not need to be run by web services, and web access logs will not be generated naturally. It's not exactly a "Web" shell in this case.)

Make jsspy realize the serializable interface, make it serializable, and in its readObject method, judge and execute the operation to be executed according to httprequest.

Using the deserialization vulnerability of RMI registry, combined with the applicable payload, upload the four classes httprequest / httpresponse / httpsession / jspspy to the target java process, and generate the classes of these four classes in the process (by calling classloader.defineclass by payload) (this step realizes file free landing)

After the above four classes are defined in the target java process, we can directly transfer the objects of those four classes to RMI registry.

Start a Tomcat locally and use a filter to intercept the request to jspspy. JSP.

After intercepting the HTTP request, the filter encapsulates the HTTP request as an httprequest object and a jsspy object. The two objects are sent to the target through a serialized channel, deserialized in the target process, and the corresponding webshell operation is performed. The result of the operation will be encapsulated as httpresponse, which will be returned to Tomcat's filter through deserialization.

The filter converts the httpresponse to a real HTTP response and sends it back to the client browser. (this step and the previous step realize that HTTP traffic cannot be caught in the network, because HTTP protocol is not used at all.)


Target machine: Kali, IP, runs RMI registry, but does not open any web.

Native: MAC, using exp to attack the target Kali machine, get webshell, the access address is http://localhost: 8080/jspspy.jsp

Although the access address of webshell is http://localhost: 8080/jspspy.jsp, the shell actually runs on the Kali machine without web service. See below: