攻守道—流量分析的刀光剑影（上）

前言

又到了一年一度的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任务。


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