IP溯源
溯源思路
没有进攻和威胁的被动防守,是注定失败的
源捕获
- 安全设备报警,如扫描IP、威胁阻断、木马、入侵事件等
- 日志与流量分析,异常的通讯流量、源目标等
- 服务器资源异常,异常的文件、账号、进程、端口,启动项、计划任务和服务等
- 邮件钓鱼,获取恶意文件样本、钓鱼网站URL等
- 蜜罐系统,获取者行为、意图的86799iukhjgkgbv相关信息
溯源反制手段
IP定位技术
根据IP定位物理地址—代理IP
溯源案例:通过IP端口扫描,反服务器进行分析,最终定位到者相关信息
ID追踪术
ID追踪术,搜索引擎、社交平台、技术论坛、社工库匹配
溯源案例:利用ID从技术论坛追溯邮箱,继续通过邮箱反追踪真实姓名,通过姓名找到相关简历信息
网站url
域名Whois查询—注册人姓名、地址、电话和邮箱。—域名隐私保护
溯源案例:通过IP历史解析记录/域名,对域名注册信息进行溯源分析
恶意样本
提取样本特征、用户名、ID、邮箱、C2服务器等信息—同源分析
溯源案例:样本分析过程中,发现者的个人ID和QQ,成功定位到者。
社交账号
基于JSONP跨域,获者的主机信息、浏览器信息、真实 IP及社交信息等
利用条件:可以找到相关社交网站的jsonp接口泄露敏感信息,相关网站登录未注销
者画像
路径
目的:拿到权限、窃取数据、获取利益、DDOS等
网络代理:代理IP、跳板机、C2服务器等
手法:鱼叉式邮件钓鱼、We、水坑、近、社会工程等
者身份画像
虚拟身份:ID、昵称、网名
真实身份:姓名、物理位置
联系方式:手机号、qq/微信、邮箱
组织情况:单位名称、职位信息
思路总结
1.首先通过系统日志、安全设备截包等从中分析出者的ip和 2.通过webshell或者木马去微步分析,或者去安恒威胁情报中心进行ip检测分析,是不是云服务器,基站等, 3.如果是云服务器的话可以,看看开放端口,域名,whois等进行判断,获取姓名电话等丢社工库看看能不能找到更多信息然后收工 4.获取到IP后,先试用IP反查,查询此IP是否存在邮箱,手机信息泄露之类的,通过邮箱,手机号去获取者信息。在获取到手机号,邮箱的情况下,使用各种社交软件,者可能使用的手机号,邮箱就是自己正在使用的,因此购物平台搜索是否存在此用户。最终还原出者身份画像,找到者姓名、物理位置、家庭住址、手机号、单位名称、职位信息。
rdns
http://www.ipip.net/ip.html
备案信息查询
ipwhois.cnnic.net.cn
地址查询
高德地图
修改X-F头的IP,可以定位到地址
http://www.ipip.net/ip.html
C段查询
https://search.censys.io/
正常静态网址会分配四个IP给购买者,这四个IP是连续的
国外网站
https://myip.ms/
https://www.virustotal.com/gui/home/upload
身份ID溯源
百度ID溯源具体方法
- 蜜罐抓取到百度的ID
- 通过百度的私聊功能(修改ID)查看百度的名字
- 通过个人主页功能(修改ID),可以查看到他的主页
- 通过主页信息,查找有用的信息(学校、公司)
- 去相关的学校、公司查询最有可能是的人员
- 再通过一些新闻咨询去查找这者一些相关的咨询
- 再通过找到的者的博客去进行访问,查找有用的信息(QQ、手机号、邮箱等等)
HTTP包分析
http数据包分析
host:带着访问的域名
x-forawrded-for(XFF)
透明代理
带着真实IP
负载均衡
者伪造xff地址,但是负载均衡会自动在后面添加访问机器的真实IP
use-agent:者的操作系统和浏览器的信息
判断工具:nmap、awvs、蚁剑、python
accept-charset:网页编码
SMB协议分析
smb协议流程
1、客户端回向服务端发送一个请求,带着协议的版本
2、服务端会回给客户端一个支持的版本
3、客户端向服务端发起认证
4、服务端确认建立认证
5、客户端向服务端发送一个请求路径
6、服务端回应
smb协议分析(内网)
明文的
乱码的
寻找关键字
冰蝎和蚁剑的流量特征
冰蝎
冰蝎其最大特点就是对交互流量进行AES对称加密,且加密秘钥是由随机数函数动态生成,因此该客户端的流量几乎无法检测 1、通过密钥协商的过程中的一些特征来检测其他 老版冰蝎工具在连接Webshell的时候会存在一个密钥协商的过程,这个过程是纯明文的数据交换,冰蝎存在这样的特征:发起一共两次的密钥协商,通过比较两次密钥协商的返回包中内容的不同部分来获取其中的密钥。 在这个协商过程中,防护设备可以结合URL、请求包和返回包的内容以及头部信息来综合进行判断,这种类型检测的优势是这部分的流程是冰蝎内置的实现,者不太好进行修改绕过。而劣势是在大流量的环境下很容易引起大量的误报。 2、通过Shell交互过程中的HTTP请求特征来检测 冰蝎在发送HTTP请求时存在一些特征,例如其工具中内置了17个User-Agent头,在用户没有自定义的情况下会随机选择一个发送。但是这些User-Agent头大部分是一些老版本的浏览器或设备。这个类型检测的优势是检测方式比较简单,但是在大流量的环境下很容易引起误报,一般使用多个特征相结合的方法来改善误报的情况,并且这部分的特征通常是一些弱特征,者可以通过定制请求头、使用代理等方式修改冰蝎的请求包很轻易的来绕过这类的检测。 3、通过Webshell上传时的流量特征来检测 在真实的场景下,者通常是通过文件上传、文件写入等方式来写入冰蝎的Webshell,所以流量设备也可以通过检测场景的数据包来发现冰蝎的存在。这部分的流量形式主要取决于Web应用,是者不好控制的,而且通常都是以明文形式进行传输,所以比较易于检测。 但是这种检测方式在遇到非文件上传等时,有可能无法捕捉到Webshell的特征。 冰蝎3.0 从防守方的角度看,这些改动中对防御设备影响最大的是第1点,也就是说,3.0版本的冰蝎不在有密钥协商的过程,从原理上直接绕过了大量流量检测设备(大部分设备是通过握手的行为来检测冰蝎的流量)
蚁剑
1、编码器改造 蚁剑在数据包中实际上是将解码函数一同发送到服务端,那几个解码函数是没法加密的,所以产生一个很明显 的流量特征,蚁剑也支持使用者自定义编码器和解码器 2、请求头修改 蚁剑默认的数据包里都携带了特别明显的请求头信息:User-Agent: antSword/v2.1,对WAF来说这简直 是自报家门
总结
冰蝎改造将动态的AES密钥写死在webshell里,可以减少很多特征。
蚁剑就是将解码函数写死在webshell 里,也可以有效绕过WAF检测
fastjson流量特征
fastjson主要功能
将Java Bean序列化成JSON字符串,这样得到字符串之后就可以通过数据库等方式进行持久化了。
流量特征
1、数据包体里面带着相关的数据包
2、数据包体里面会有@type
使用 SerializerFeature.WriteClassName进行标记后,JSON字符串中多出了一个@type
字段,标注了类对应的原始类型,方便在反序列化的时候定位到具体类型