跳转至

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