攻守道—流量分析的刀光剑影(上)


这是 酒仙桥六号部队 的第 23 篇文章。

全文共计3915个字,预计阅读时长12分钟

前言

又到了一年一度的HW时刻,各家都在为HW积极筹备着,一些厂商也在做着攻防演练的工作,此时,有些真正的攻击者也在利用这个档口对一些网站进行攻击,浑水摸鱼,这样,对于防守队员来说,分析流量做应急的工作就会变得更加困难。

这不,某公司内网网络被黑客渗透,接下来,我们就借助wireshark来对流量包进行分析,来还原查找黑客留下的蛛丝马迹,还原攻击的现场。

wireshark作为流量分析神器,在开始之前,先来简单科普一下它的一些常用的过滤命令。

  • 过滤查看包含某字符串的http数据包:http contains “string”(tcp同理)

  • 过滤查看请求某一url的流量:http.request.uri == “path”或 http.request.uri contains “path”

  • 过滤出某一ip的流量:ip.addr == ip 或 ip.src == ip 或 ip.dst == ip

  • 跟踪显示http请求包与返回包可以Fllow HTTP Stream

第一问 扫描器

首先来看第一个:黑客用什么扫描器进行的扫描?

在开始这个问题之前,我们先来说一说在应急、流量分析的时候,如何快速发现是不是有扫描器扫描的痕迹。

一般最常用到的扫描器有WVS、nessus、APPscan、绿盟极光、sqlmap、dirsearch等等,所以我们就要了解这些扫描器本身的一些特征。

  • WVS扫描器通常默认情况下,会在请求的数据包中带有wvs、acunetix_wvs_security_test、acunetix、acunetix_wvs等字样。

  • Nessus扫描器默认情况下会包含nessus字样。

  • APPscan默认情况下会包含APPscan字样。

  • 绿盟极光扫描器一般会包含nsfocus、Rsas字样。

  • sqlmap大多情况下也会包含有sqlmap字样。

以上情况均为一般、默认情况,但是大多数情况下攻击者都会对自己的行为进行隐藏,如果人家对自己使用的工具做了修改,就为了隐藏让你不好分析,那你就只能另辟蹊径了。

好了,了解了一般情况下扫描器的特征,我们就来找找看,一共一个多G的pacp包,一个请求一个请求的来找,怕是找到黑人抬你的时候都找不完,这时就要用到wireshark的命令了,通常情况下,扫描器扫描web应用的流量都是http流量,筛选过滤走起,先来找找看有没有wvs的扫描流量,过滤命令:

http contains wvs

很明显用了WVS,再搜一搜其他扫描器的特征字符,并没有搜到,看来这个黑阔只用了wvs来扫描。从这个流量中也能确定使用扫描器的攻击者的ip地址,可以先将此ip记录下来,再看看还有没有其他的扫描IP,用到的命令:

http contains wvs and not ip.addr==192.168.94.59

可以看到过滤之后没有其他的数据包,可以确定只有这一个ip在发起攻击,明确了攻击ip,之后的分析就会轻松一些。

第二位 后台

黑客扫描到的网站后台是什么?

从这个问题出发,我们先确定三个要素:黑客、扫描、后台。从前面我们已经确定了黑客的攻击IP,也确定了扫描器是使用的wvs,那么我们只需要找到后台就可以,我们先假设一些可能的后台关键字:admin、login、administrator。

在实际情况中,真正攻击者会隐藏自己的攻击行为,所以不必要过于在意是不是使用的扫描器,只要是这个IP发出的请求,我们都认为他是攻击行为,这样可以尽可能的减少我们分析过程中出现的遗漏。

我们先过滤数据包,来看看攻击者访问的登录地址有哪些。这里我们用到的命令:

http contains login and ip.addr==192.168.94.59

从筛选出来的数据包中,能够看到一个/admin/login.php的请求,我们来跟踪看一下。

从前边小箭头的关系就能看出来第一个数据包是request数据包,下边的是response数据包,该请求的请求地址是/admin/login.php,返回状态是200。从这里难道就能确定黑客找到的后台就是它吗?不能直接确定,万一是网站做了统一错误页面呢,也可能是返回状态200,但请求文件不存在。所以我们只能看一下这个数据包具体的内容了。来Fllow HTTP Stream看一下。

看到这个返回包的内容,我们可以肯定了,这个地址是存在的,并且可以确定是后台登录地址了。你以为到这里就结束了吗?并没有,我们还需要看看其他的数据包,看看是不是还有其他的后台。通过筛选分析,没有发现有其他存在的后台地址,所以确定黑客攻击的后台地址为/admin/login.php。

第三问 账号

攻击者使用什么账号登录了后台?

上一问中,我们知道了网站的后台地址,现在,我们可以先通过该后台地址了解一下这个网站登录成功的特征。先筛选POST提交账号密码的数据包。这里看到有一个登录数据包,跟踪这个流量来看一下。

可以看到这个网站正常登陆后会返回302数据包跳转到/admin/index.php页面,应该就是登录成功了。这个会是攻击者登录的吗?本着不信任任何数据包的信念,把这个登录者的行为来分析一下。先看看他发起了多少次登录请求。

登录请求只有三次,而且每次使用的账号密码都相同,如果是攻击者,那么他在发起攻击之前就已经获得了此后台的账号。再来看看除此之外他还有哪些请求。

筛选这个ip的请求发现他请求了一个backup.php文件,看看关于这个backup文件还有哪些操作。

这里有个对backup文件的POST请求,从请求的内容中分析可以看出来这个backup.php文件的功能是进行数据库备份,再返回来看看这个登录者执行备份操作后还有什么后续的行为。寻遍所有的请求,都只有正常的操作请求,一点点的恶意攻击操作都没有,看来这个ip是正常的员工登录使用。

那就再返回来,根据这个登录跳转特征我们来分析一下,来找找攻击者所使用的是什么账号登录的。过滤出来返回包状态302,包含跳转地址为/admin/index.php。

只有两个ip登录成功跳转到了后台,我们已经确定了192.168.94.233是正常用户,那么另外这个就应该是攻击者了,来跟踪看一下这个登录所使用的账号信息。

再来筛选一下这个ip发起的登录请求,发现存在大量的登录请求,登录成功的数据包就夹杂在这些登录请求中,那么就实锤了,攻击者通过登录爆破的方式爆破出了admin账号的密码,然后使用这个账号密码登录成功后进入后台执行下一步的攻击。

第四问 webshell

黑客上传的webshell文件名是什么?内容是什么?

从前面我们也已经知道,这个网站是PHP的网站,所以上传的webshell也可以先从php后缀文件开始判断,根据PHP一句话webshell的特征先来看看有什么。

前边两个GET请求应该是扫描器行为,直接看后边POST请求的a.php文件,跟踪一下这些文件的请求内容和返回包,查看是否为完整的webshell请求。

毫无疑问,这个a.php就是我们要找的webshell了。在实际的应急处置过程中,一般我们都需要对攻击进行溯源分析,找到黑客的攻击途径,那么这个webshell是如何被传进来的,我们来分析一下。

从http流量中搜寻了半天,始终没有发现上传a.php文件的痕迹,猜测可能上传的数据包在记录时并没有记录为http流量,可能为tcp流量,于是改变策略,来从攻击者发起的所有的流量来寻找一番。根据上边攻击者访问a.php执行的代码,来搜索一下$_POST内容,看看有什么结果。

搜索一番,发现了这个数据包,看起来是上传了一个一句话木马,但是跟上边a.php的webshell不一样,来跟进去分析一下。

这个是直接上传了一个1.php的一句话,看来可能还不止有a.php这一个webshell,我们再来分析看一下。寻遍所有的流量包,只发现有上传1.php的数据包,没有成功请求1.php的数据包,猜测可能被杀软干掉了,那么继续寻找a.php上传的途径。

从这个数据包中,我们可以发现a.php文件的上传时间,我们来根据时间查看一下上传的数据包。查看之后发现提供的数据包没有覆盖到上传a.php的时间,这样看来,似乎就无法定位攻击者的攻击途径了。但是呢,这里对比一下上传的1.php的内容跟a.php请求传输的内容,是不是已经发现了关联,1.php获取的参数密码是1234,a.php传输的内容也是1234为参数名,那么a.php的webshell内容就应该与1.php一样,不过这个a.php传输的内容也不复杂,也可以反推出来a.php的内容。

那么我们这里就能基本判断出来攻击者是如何getshell的了,大致的攻击流程就是:扫描后台—>爆破密码—>登录后台—>上传webshell—>持久控制。

拓展

通常,攻击者获得主机权限后为了进一步持久化控制主机,会使用一些较为隐蔽的方法来控制主机,经常会用到CobaltStrike,在CS中提供的有http隧道、https隧道、DNS隧道、SMB隧道。在流量分析的视角下,这些流量会是什么样的一个状态,我们一起来看一看。

HTTP隧道

首先我们使用CobaltStrike生成一个beacon模式的HTTP协议木马,将木马放在widonws主机下执行,然后同时使用wireshark来抓包查看整个通信过程。(这里我所使用的CobaltStrike版本为4.0)

执行木马主机上线后,这里我执行了ipconfig、net user、dir命令,来看一下cobaltstrike远程控制主机执行这些命令后,teamserver与远控主机之间是如何进行通信的。

对远控主机与teamserver之间的所有通信流量进行分析查看,在数据传输上均没有直接传输的明文数据,对这些数据包传输的数据都分析一下,来看看CobaltStrike的HTTP隧道远控的特征。

一共执行了4次命令,每次执行之后,都会从远控主机向teamserver发送一个POST请求,请求的文件为submit.php。

跟踪数据包后可以看到,所有的POST请求内容都是乱码,所以在进行流量分析的时候也无法直接判断是不是远控的请求流量。

可能与CobaltStrike的版本相关,CobaltStrike 4.0版本中的HTTP隧道传输的数据内容均被加密。使用CobaltStrike 3.12进行尝试,使用HTTP隧道执行命令时,分析整个过程的流量包,对比中可以发现3.12版本中木马将执行命令的结果回传至teamserver服务器时,传输的数据为明文方式传输,这种方式较容易判断。对比可以发现,无论是什么版本,在回传数据时,都会由被控主机发起一个请求路径为submit.php的POST请求,并且Content-Type为application/octet-stream。这个特征可以作为使用CobaltStrike的HTTP隧道进行远程控制的一个特征。对比来看,在进行攻击使用远控时,相对来说较高版本的CobaltStrike的隐蔽性还是比较强的。

HTTPS隧道

与http隧道相同,我们先使用CS创建一个基于HTTPS隧道的木马,同时进行抓取流量包,主机上线就可以看到有很多握手包。

通过CS执行命令,这里我执行了net user、whoami、ipconfig、dir命令,来看看执行这些命令的流量数据包。

由于是走的HTTPS隧道,所以整个数据包也都被加密了,通过这些数据包,从中也提取不到有价值的特征字符。基于HTTPS隧道的远程控制相对来说还是比较隐蔽,所以要想单纯通过流量来判断是不是有CS的远控流量,是非常非常困难的。

小结

HW时攻击方手段百出,防守方也需要明察秋毫。通过对流量的分析,发现攻击痕迹,还原攻击现场,掌握攻击者意图,才能更好的完成HW任务。

第一部分的流量分析就到这,更多精彩内容请继续关注我们的公众号。


本文作者:酒仙桥六号部队

本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/139473.html

Tags:
评论  (0)
快来写下你的想法吧!

酒仙桥六号部队

文章数:105 积分: 865

提前看好文,搜索-微信公众号:酒仙桥六号部队

安全问答社区

安全问答社区

脉搏官方公众号

脉搏公众号