攻击流量特征总结

攻击流量特征总结

本篇长期更新,如果我记得住的话。

工具

中国菜刀

TCP协议与C&C服务器通信
数据包流量特征:
1,请求包中:ua头为百度,火狐
2,请求体中存在eavl,base64等特征字符
3,请求体中传递的payload为base64编码,并且存在固定的
4,连接服务器的IP地址往往采用动态DNS转换,较难通过IP直接检测
5,连接端口不固定,需要扫描检测。一般扫描20000-30000端口范围可以检测出菜刀活动
6,连接建立后发送”knife”或”dadan”等验证码进行验证,可以通过检测这些关键词实现检测
7.会存在QGluaV9zZXQ攻击的开头部分后面的部分需要base64解码

蚁剑

数据包流量特征:
一般的一句话木马都存在一下特征:
1.每个请求体都存在@ini_set("display_errors", "0");@set_time_limit(0)开头。并且后面存在base64等字符
2.响应包的结果返回格式为:随机数—-响应内容—随机数
3.连接服务器IP地址也常采用动态DNS,通过IP地址检测难度大
4.连接端口常使用443或8080等常用端口,稍难检测
5.连接时发送字符串”yyoa“进行验证,这是它的特征标志,可以通过检测这个关键词实现检测
6.请求中可以检测到的关键字:"eval""eVAL"
7.在命令执行时有目录标记[S]、[E]、[R]、[D]、等,说明已经拿到shell了(在执行系统命令)

冰蝎

使用的UDP端口常为53、123、161、162等,这些端口较难引起注意
数据包的长度一般在120-140字节左右,可以作为判断标准。
数据包的内容以0x01开头,以0x00结尾,中间含有蝎子协议特征数据,这是检测的重要标志。

冰蝎2.0流量特征:
第一阶段请求中返回包状态码为200,返回内容必定是16位的密钥
请求包存在:Accept: text/html, image/gif, image/jpeg, ; q=.2, /; q=.2
建立连接后的cookie存在特征字符
所有请求 Cookie的格式都为: Cookie: PHPSESSID=; path=/;

冰蝎3.0流量特征:
请求包中content-length 为5740或5720(可能会根据Java版本而改变)
每一个请求头中存在
Pragma: no-cache,Cache-Control: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image

冰蝎4

1.流量特征,Content-type: Application/x-www-form-urlencoded。
2.Connection字段:
Connection: Keep-Alive(冰蝎默认使用的长连接是为了避免频繁的握手造成的资源丢失
3.Accept字段:
请求头中存在Accept: application/json, text/javascript, */*; q=0.01
也有可能Accept: text/html,image/gif, image/jpeg, *; q=.2, */*; q=.2 Content-Type: application/octet-stream ***\***q=0.8

哥斯拉

哥斯拉流量分析:
1.使用的全是ICMP协议数据报文,而ICMP流量本身就不高,所以较难在大流量中检测
2.ICMP数据报文的载荷部分Length值固定为92字节,这是它的重要特征
3.所有请求中Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
4.所有响应中Cache-Control: no-store, no-cache, must-revalidate
5.强特征:cookie字段,最后一个Cookie的值出现;(尾值出现分号)

CS

1,基础特征:心跳包
2,请求特征:下发的指令,url路径,老版本固定的ua头
3,源码特征:checksum8 (92L 93L)

MSF

1,端口号:msf默认使用4444端口作为反向连接端口
2,数据内容:msf数据包通常包含特定字符串:("meterpreter"、"revshell"等)

内存马的原理&判断和清除

原理:
其原理是先由客户端发起一个web请求,中间件的各个独立的组件如ListenerFilterServlet等组件会在请求过程中做监听、判断、过滤等操作,内存马利用请求过程在内存中修改已有的组件或者动态注册一个新的组件,插入恶意的shellcode达到持久化的控制服务器。

判断方式:
先判断是通过什么方法注入的内存马,可以先查看 web 日志是否有可疑的 web 访问日志,如果是 filter 或者 listener 类型就会有大量 url 请求路径相同参数不同的,或者页面不存在但是返回 200 的,查看是否有类似哥斯拉、冰蝎相同的 url 请求,哥斯拉和冰蝎的内存马注入流量特征与普通 webshell 的流量特征基本吻合。通过查找返回 200 的 url 路径对比web 目录下是否真实存在文件,如不存在大概率为内存马。如在 web 日志中并未发现异常,可以排查是否为中间件漏洞导致代码执行注入内存马,排查中间件的 error.log 日志查看是否有可疑的报错,根据注入时间和方法根据业务使用的组件排查是否可能存在 java 代码执行漏洞以及是否存在过 webshell,排查框架漏洞,反序列化漏洞

清除方式:1.利用条件竞争把shell内容改写或者清除比较好用 2.重启服务 3.提前占用他的目录名

sqlmap

(AND 1=1 UNION ALL SELECT 1,NULL,'<script>alert("XSS")</script>',table_name FROM information_schema.tables WHERE 2>1--/**/; EXEC xp_cmdshell('cat ../../../etc/passwd')#)
对数据库类型、XSS漏洞进行监测,而这句话几乎每次注入都是不变的,所以可以将这句话作为sqlmap的攻击特征之一

漏洞

log4j

原理:该漏洞主要是由于日志在打印时当遇到${后,以:号作为分割,将表达式内容分割成两部分,前面一部分prefix,后面部分作为key,然后通过prefix去找对应的lookup,通过对应的lookup实例调用lookup方法,最后将key作为参数带入执行,引发远程代码执行漏洞特征:${jndi:rmi

struts2

Struts2漏洞是由于攻击者可以利用Struts2系统中没有恰当的输入验证机制,导致攻击者可以构造恶意请求,从而绕过Struts2的控制机制,访问服务器上的敏感资源,造成数据泄露的可能性。

流量特征:遇到之后先进行url解码在查看总体含义URL
action文件与.jsp文件
conten-type:context
请求体中:Memberaccess

redis未授权:6379

原理:redis使用了默认配置,使端口绑定在了0.0.0.0:6379并且暴露在公网的话此时我们任意一台带有redis-cli的机器就可以直接访问,跳过登陆验证,从而可以写shell,写入shell的话使用config参数

thinkphp:

5.x通杀原理:路由url从Request::path()中获取,由于var_pathinfo的默认配置为s,我们可利用$*GET['s']来传递路由信息,也可利用pathinfo来传递,但测试时windows环境下会将$*SERVER[‘pathinfo’]中的\替换为/。结合前面分析可得初步利用代码如下:index.php?s=index/\namespace\class/method正则没写好

weblogic:7001

基于 T3 协议的反序列化;基于 xml 解析时候造成的反序列化,还有ssrf,权限绕过等等,

开放7001端口;传递参数到wls-wsat;数据包有bash或dnslog字段

weblogic ssrf

反弹shell的时候,会有特征关键字 crontab /dev/tcp

shiro

利用过程:
1、检索RememberMe Cookie的值
2、Base64解码
3、AES解密(加密密钥硬编码)
4、进行反序列化操作(未过滤处理)
5、攻击者可以使用Shiro的默认密钥构造恶意序列化对象进行编码来伪造用户的Cookie,服务端反序列化时触发漏洞,从而执行命令

shiro550与shiro721的区s别:
1、这两个漏洞主要区别在于Shiro550使用已知密钥碰撞,只要有足够密钥库(条件较低),不需要Remember Cookie
2、Shiro721的ase加密的key基本猜不到,系统随机生成,可使用登录后rememberMe去爆破正确的key值,即利用有效的RememberMe Cookie作为Padding Oracle Attack的前缀,然后精心构造 RememberMe Cookie 值来实现反序列化漏洞攻击,难度高

流量特征:
1.rememberme字段长度异常
2.请求包Cookie的rememberMe中会存在AES+base64加密的一串java反序列化代码。
3.返回包中存在base64加密数据,该数据可作为攻击成功的判定条件。

fastjson

请求报文中查找json格式的数据,重点看有无rmi或者出网的一些行为


转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。后续可能会有评论区,不过也可以在github联系我。