跳转至

STEELCOFFEE

题目

## 2020-04-24 - TRAFFIC ANALYSIS EXERCISE - STEELCOFFEE

ASSOCIATED FILES:

NOTES:

  • All zip archives on this site are password-protected with the standard password. If you don't know it, look at the "about" page of this website.

## SCENARIO

LAN segment data:

  • LAN segment range: 10.0.0.0/24 (10.0.0.0 through 10.0.0.255)
  • Domain: steelcoffee.net
  • Domain controller: 10.0.0.10 - SteelCoffee-DC
  • LAN segment gateway: 10.0.0.1
  • LAN segment broadcast address: 10.0.0.255

## QUESTIONS

There are three clients in this month's exercise pcap.

  • Which two clients are Windows hosts, and what are the associated user account names?
  • Which one of these two Windows clients was infected?
  • What type of malware was that Windows client infected with?

## ANSWERS

  • Click here for the answers.

调查过程

~~时间紧张,详细步骤后续补充,直接记录一些重要的发现。~~

分析可疑的HTTP流量

观察URL特征,发现有不像普通的图片ID等请求,类似于后门执行的活动

看到伪装成PNG下载的exe,八成恶意。

导出对象,分析文件:

$ file 8888.png

8888.png: PE32 executable (GUI) Intel 80386, for MS Windows

疑似为Qbot木马,银行木马的一种。

确认受攻击资产的情况

  • 资产IP:10.0.0.167
  • 外部IP:119.31.234.40
  • 外部IP的域名:alphapioneer.com

追溯受攻击资产的信息

查看资产IP10.0.0.167的HTTP活动情况:

ip.addr == 10.0.0.167 and http

按照时间从头看起,可以看到资产IP10.0.0.167有访问一个play.astrite.ga的域名,其IP为159.69.28.93,follow详细信息,发现其下载了一个doc文件,我们尝试导出文件,放入沙箱进行分析。

检测出其为一个VBS木马(在“补充”中有写特征)

继续追溯,发现资产IP:10.0.0.167与外部IP:104.24.111.29进行通讯。发现其server显示为cloudflare,可能是攻击者的这个钓鱼站点使用了CDN,因此我们尝试绕过CDN查到真实的IP:

使用Censys搜索外部IP:104.24.111.29,确定其为CloudFlare的资产,该目标站点使用的CloudFlare的CDN:

绕过CDN查询真实IP

获取域名:atn24live.com签名证书的sha1值,并将暴露出来的SSL证书信息置于Censys搜索:

找不到详细信息。使用其他几种方式尝试获取真实CDN后依然无果。

看答案后补充

需要对资产进行梳理

答案中给出了对资产的整理,是我没有做的部分,在进行应急响应处置的开始,首先是要对资产情况进行一个了解和清查。

1) The two Windows clients and their user account names are:

10.0.0.149 - DESKTOP-C10SKPY - alyssa.fitzgerald 10.0.0.167 - DESKTOP-GRIONXA - elmer.obrien

NOTE: The client on 10.0.0.202 is a host running Ubuntu

补充

VBS木马

特征

  • 通常使用HTTP通讯
  • 使用Wscripts.exe作为解释器
  • 通讯时使用字符串<|>作为信息的分隔符

如何透过CDN查询到真实IP

利用子域名

由于成本问题,可能某些厂商并不会将所有的子域名都部署 CDN,所以如果我们能尽量的搜集子域名,或许可以找到一些没有部署 CDN 的子域名,拿到某些服务器的真实 ip/ 段

然后关于子域名搜集的方式很多,就不一一介绍了,我平时主要是从这几个方面搜集子域名:

1、SSL 证书

2、爆破

3、Google Hacking

4、同邮箱注册人

4、DNS 域传送

5、页面 JS 搜集

6、网络空间引擎

工具也有很多厉害的,平时我一般使用 OneForALL + ESD + JSfinder 来进行搜集,(ESD 可以加载 layer 的字典,很好用)[1]

一些运维较好的站点,不容易出现这种情况,此时可以查询一些历史的子域名解析记录,将这些历史的子域名进行网络空间搜索。

查询DNS历史解析数据

使用工具:SecurityTrails可查询DNS历史解析数据,同样的,使用微步在线等也可以:

查找使用Cloudflare前,该域名使用的云主机提供商,可以猜测为真实IP。

利用邮件探测(MX记录)

常在登入注册点,但在测试时应该在一些可能的地方抓去邮件服务相关的信息,例如订阅服务等。同样的,也应该在收到邮件后,对目标站点发送的邮件进行IP、域名探测。

因为邮件服务的特性,一般除了Web服务外,高防服务不覆盖邮件服务。如果此时目标站点的邮件服务器就是主站的主机,则可通过对邮件发包信息的截取来获得原始IP。

从邮件header的Return-Path可获取发件的host,我们使用host命令即可探测到发件host的真实IP:

$ host xxx.net

利用SSL证书进行探测

搜索”SHA1 fingerprint”

将签名证书的sha1值置于Censys搜索。

搜索SSL证书信息

利用SSL状态检测工具(例如MySSL),获取SSL证书的详细信息,将其中的一些其他信息置于网络空间搜索工具中进行搜索。

利用多地ping工具

在偏远地区的服务器访问时,可能不会访问到 CDN 节点,而是直接访问服务器真实 ip

所以我们可以搞一个偏远地区的代理池,来访问目标域名,有概率就可以拿到真实 ip[1]

常用的比是站长之家的多地ping检测,但如今的CDN覆盖面都挺广,直接通过这种方式获取的概率不大,但也很省力,可以一试。

favicon_hash匹配

利用 shodan 的 http.favicon.hash 语法,来匹配 icon 的 hash 值, 直接推:https://github.com/Ridter/get_ip_by_ico/blob/master/get_ip_by_ico.py 5 [1]

原理是favicon(网站图标)是站点独有文件的,进行hash搜索,可以获得网络空间的关联信息。

CloudFlare Bypass

消耗防DDoS流量

免费版的 cf,我们可以通过 DDOS 来消耗对方的流量,只需要把流量打光,就会回滚到原始 ip[1]

利用 HOST 来判断

还有利用 cloudflare 的改 host 返回示例:

https://blog.detectify.com/2019/07/31/bypassing-cloudflare-waf-with-the-origin-server-ip-address/ 15

里面给了详细的介绍,我们可以通过 HOST 来判断是否是真实 ip, 具体看文章即可

利用老域名

在换新域名时,常常将 CDN 部署到新的域名上,而老域名由于没过期,可能未使用 CDN,然后就可以直接获取服务器真实IP。[1]

这个场景虽然听起来玄乎,但其实常常发生,运维人员又要背锅。

暴力匹配

找到目标服务器 IP 段后,可以直接进行暴力匹配 ,使用 masscan 扫描 HTTP banner,然后匹配到目标域名的相同 banner[1]

在明确IP段后,也可以通过遍历0.0.0.0/0:443的方式,因为使用IP进行HTTPS连接时,会显示证书信息,便又可使用以上所说的SSL证书进行探测。

利用网站源码泄漏进行获取

是否存在网站源码信息泄露,如 phpinfo() 指令中可能包含的IP地址等泄露。[2]

Web层面信息泄漏的一些利用。

社工平台

利用一些社工库。

References

[1] 绕过 CDN 寻找真实 IP 地址的各种姿势,xazlsec,(https://forum.90sec.com/t/topic/524#)https://forum.90sec.com/t/topic/524

[2] 使用高防后,服务器还是会受到攻击这是为什么?,https://cloud.tencent.com/developer/news/400870