由于传播、利用本公众号听风安全所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号听风安全及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！公众号现在只对常读和星标的公众号才展示大图推送，
建议大家把听风安全设为星标，否则可能就看不到啦！
----------------------------------------------------------------------
Part1前言
在日常的蓝队溯源工作、感染加密勒索病毒后的应急排查工作中，查找攻击者遗留的webshell是一种常规手段，一旦webshell文件被找到后，可以反推出很多信息，最重要的是能确定攻击者攻击时间，以此攻击时间为轴心开展溯源工作会事半功倍。但攻击者经常会把webshell文件删除，并且清理掉所有的访问日志，这种情况下应该怎么溯源确定上传webshell的攻击时间呢？其实对于jsp型或jspx型webshell来说，还是有办法的，因为java的webshell在编译过程中会生成很多临时文件，一直留存在服务器中。Part2技术研究过程
首先本地搭建一个tomcat，模拟攻击者行为，上传一个jsp的webshell
接下来模拟攻击者行为，把log111.jsp文件删除掉，那么怎么找到这个shell遗留的蛛丝马迹呢？
查看tomcat中间件的\work\Catalina\localhost_\org\apache\jsp 目录，仍然是可以发现这个shell的编译过程中产生的几个文件的，这3个文件攻击者一般不会删除，也不会更改文件的时间属性。所以，这些jsp型webshell文件在编译过程中生成的class文件的时间属性，往往是比较准确的，而jsp文件的时间属性，很多攻击者会改成与web应用部署一样的时间，去迷惑蓝队工作人员。原理：客户端访问某个jsp 、jspx文件时，Tomcat容器或者Weblogic容器会将 jsp 文件编译成java文件和class文件，这两份文件均会存储在容器的某个目录中。
如果需要进一步验证此文件是正常文件还是webshell文件，就需要使用jadx-gui工具对此class文件进行反编译了。如下图所示，很清楚看到了冰蝎webshell的代码特征。
注：虚拟机环境证明，tomcat中间件即使重启后，这些编译产生的临时文件也是会一直存在的。
接下来在weblogic中间件上进行同样的操作，制作一个war包上传到weblogic环境中：
接下来将log.jsp删除后，试着查看在weblogic中间件下还有什么蛛丝马迹可以查询，发现在/jsp_servlet/目录下，还是有几个webshell编译生成的文件，这里与tomcat中间件不同的是，路径中的/hwr7e2/是随机生成的一个目录，需要根据经验具体问题具体分析：
除此之外，还可以找到上传的war包，一样可以确定攻击时间，一般在这个目录下边：\user_projects\domains\base_domain\servers\AdminServer\upload，即使删掉jsp文件，重启weblogic后，这个war包文件也会一直存在。
Part3总结
jsp、jspx型webshell文件被删除后，可以通过查找编译生成的class文件的方式去确定攻击时间。如果攻击者将webshell时间属性改掉，也可以通过此方法获取真实的攻击时间。
对于tomcat、weblogic中间件，除非攻击者删除编译生成的文件，否则重启后这些文件也会一直留存在Web服务器中，成为溯源攻击者的一个重要证据。
即使攻击者非常细心，把这些class文件全部删干净了，那么借助一些取证工具或者专业设备，还是可以溯源出来的，这个将来会专门写一篇文章讲解。