一些基础的入侵绕过姿势案例分析

0x0 背景

    谈论起溯源本质上是安全人员对多源数据的一些关联分析，结合自己的经验对攻击者手法路径的还原。所谓的数据来源主要还是流量层面的安全告警(依赖于WAF、IPS一类的设备的检出能力)、流量层面设备的审计记录(记录所有的网络行为)、主机层面的日志(系统日志、中间件日志、数据库日志等)，简单分享一些在实际场景中遇见的一些比较有意思的场景；

0x1  Shiro场景

   Apache Shiro Java反序列化是今年比较热门的漏洞之一；Shiro提供了记住我（RememberMe）的功能对rememberMe的cookie做了加密处理，但是AES加密的密钥Key被硬编码在代码里，意味着每个人通过源代码都能拿到AES加密的密钥。因此攻击者构造一个恶意的对象并且对其序列化，AES加密，base64编码后，作为cookie的rememberMe字段发送。Shiro将rememberMe进行解密并且反序列化最终造成反序列化漏洞，具体原理不再多余赘述。

   于是在一次应急响应过程中突出推测是秘钥泄露，但是用户一再确认自己用的不是默认秘钥，而且对应的流量层面安全设备并没有告警；补充一下，流量层面的安全设备对此类攻击的主要检测手法同样是收录了目前互联网上常用、默认的秘钥，由于是对称加密算法也公开然后依葫芦画瓢然后对相应的字段进行解密就可能看到明文；

开始排查溯源首先排查了一下access.log的日志（用户做了备份），由于一天的日志访问量比较大(GB数量级)所以还是找了很久，为了加快效果就简单写了一个python脚本筛选出了POST类型，并且返回码为200的访问记录，结果一无所获。由于缺乏一些必要的信息，一时间有点陷入僵局于是主动协调了真实的业务环境SSH登录上去，在web目录下的image文件夹却发现了隧道通信样本和webshell(由于是用户的生成环境主要是手工多一些没有借助其他工具)；

 

借此为线索突破口于是又开始搜索access.log的日志，最后找到真实的webshell的链接记录。果然还是不能偷懒，攻击者应该是自定义的请求头、返回头和响应码302。由于真实访问的流量比较大，导致这些关键的信息被淹没在了没有用的信息当中。如果不是请求频率比较高，还真的不要容易注意到这条记录。

后续通过流量层面的设备当中，按照对应的时间、访问请求等信息在网络层面的设备当中顺腾摸瓜逐步发现了真实写入webshell的数据包，后续结合对网络环境内的其他数据进行分析逐步还原到真实的攻击路径；

这样的案例在真实环境当中还是经常出现，能够快速突破的原因还是依赖于攻击者留在web目录下的脚本文件，本质上还是有一些运气成分在里面的。由于流量层对此攻击的行为无法识别(加密流量)并通过RCE写入webshell能够较好的bypass流量层的安全设备，一条完整的供给链当中缺少一些蛛丝马迹，对于access日志的话也是数量太大分析起来花费的时间成本太高。于是复盘一下觉得整个攻击项目当中有2个点依然可以优化一下：

第一这里写入的冰蝎马太明显（没有免杀D盾可以直接杀）且路径也很明显(image目录下突然多个jsp)，命名也非常随意(1.jsp).后续研究了一下用户识别的网络层设备并不具备行为异常的检测能力，对此类敏感行为的访问没有识别，且未安装终端安全软件。

第二 链接该shell的时候请求的频率太快，打开日志的时候发现有大量针对此shell的访问都返回302，过程中应该利用VPS开启一些漏洞扫描器之类的软件混淆视听，从而提高溯源的技术成本与时间成本。于是接下来有几个案例继续该文章的

0x2  图片马执行

由于最近几年安全意识普遍提高了不少，很多开发者在上传接口普遍会做一些过滤白名单或者黑名单模式，很多成熟的框架往往会重点限制web脚本的文件上传，或者针对上传的文件进行重命名等方式进行修改，不返回文件路径等操作。就算攻击者伪造了一个图片马传递上去服务器之后，也需要借助解析漏洞、文件包含等方式进行利用，这个也有颇有运气成分在里面了。前段时间却遇见这个一个事件，发现有很多异常的流量访问主要是一些访问的资源都是ico文件

由于孤陋寡闻一开始的时候甚至开始怀疑攻击者是不是更改了http.conf配置了不同类型的文件解析成脚本格式的规则，但是回头一想应该没有这个高的权限，通过看一下这个URL的请求格式99.99%的概率是reGeorg的HTTP隧道通信流量。但是这个favicon.ico跟了这么多参数是怎么回事，解析规则？不对还可以用htaccess文件，虽然普遍用法应该是用来做网站资源目录的访问控制、报错界面重定向，但是也可以配置Sethander来控制解析规则。还是有点吃惊样本以为知识一些CTF小技巧，没有想到出现在了实际的对抗场景当中。

 

 

仔细想想后突然又觉得细思极恐，毕竟HTTP协议应用是如此的广泛在整个流量层面识别攻击行为普遍还是使用规则引擎多一些，要么要如何从访问行为上来识别一个图片就是一个图片，一个脚本就是一个脚本，一个rar压缩包是不是一个PE文件？那些没有文件后缀或者自定义格式文件访问到底是不是恶意的请求？只要伪装的足够好看起来和正常流量没有什么差异性就可以做到用户的无感知。但是依然避不开二个问题，即使流量层面的数据没有办法检测到始终绕不开终端层面的检测，毕竟文件在这里，就算做过免杀工具无法识别，就一个文件项目的文件对比，就很轻易的发现最近新增、修改时间、创建时间都不一样的文件，还是比较容易被发现只是时间成本会高一些罢了。于是，借助于前几年在windows端的比较热门的无文件攻击的思路，只有没有文件落地直接写入内存就可以完美避开这个问题。

0x3 无文件攻击-内存马

近几年在操作系统层的无文件攻击手法越来越多，最终目的都是想躲过安全设备的查杀。针对文件威胁普遍还是使用特征码扫码、启发式扫描、文件hash之类的手法进行全盘扫描，最常见的就是yara引擎，所谓的快速扫描就是针对一些恶意文件常见的目录进行扫描比如appdata、windows、font、temp目录之类。但是扫描的文件普遍是有实体的，无论是隐藏文件也好，伪造的格式的PE文件也还是绕不开。无文件就比较好的解决了这个问题利用Powershell、Mshta、Certificate等系统进程，从互联网直接执行恶意代码也没有文件落地，利用定时任务、WMI实现权限维持。

最开始有关注到是因为rebeyond作者2018年的一个叫Memshell的开源项目https://github.com/rebeyond/memShell公布了一个基于Java服务器的内存马项目。2020年在某次重要的攻防演练时候又放出来Godzilla Shell大杀器支持了内存shell模块实现了在tomcat中注册、卸载内存马；直接注册一个哥斯拉的马或者冰蝎、菜刀的马，甚至是regeorg；

由于之前没有怎么接触过这类技术于是花了点时间找各种资料学习了一波目前主流的内存主要有3种实现方式：

 

1.servlet-api类：filter型、servlet型

2.spring类  拦截器、controller型

3.Java Instrumentation类   agent型

Filter型内存马首先是一个Filter类同时它在目录上没有对应的class文件。若dump出的class还有恶意代码那是内存马无疑，主要使用的方法java.lang.Runtime.getRuntime、defineClass、invoke。

关于查杀：

由于内存马没有实体要识别只能从内存当中出发，单纯依靠文件查杀肯定是不现实的。所以重点思路还是在内存扫描这一块。

大师傅的一个专杀工具：https://github.com/LandGrey/copagent

Java运行状态监测工具带操作指南：https://github.com/alibaba/arthas