欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

一次网络流量分析引发的思考

来源:本站整理 作者:佚名 时间:2018-09-03 TAG: 我要投稿

闲来无事,做了做最近安恒8月比赛的流量包,发现有些题目给的分析不够详细。本着学习知识的心态,重新梳理下思路,稍加扩展,再谈谈个人对网络流量取证方面的一些见解。
 
题目分析
ps:这是详细的比赛题目和分析详见这个网站(此处建议详细看看,最好数据包自行下载分析一遍),下面介绍下题目背景,再挑出几道题目深度分析下。
题目背景
某公司内网网络被黑客渗透,黑客首先攻击了一台web服务器,破解了后台的账户的密码,随之利用破解的密码登录了mail系统,然后获取了vpn的申请方式,然后登录vpn,在内网pwn掉一台打印机。
题目线索总分析
根据题目背景,我们把握下总体脉络,顺着黑客的思路走一番:
首先,黑客攻击公司的一台web服务器。走的是以tcp为载体的http请求,所以过滤http数据分组,成为解题最基本的分析思路。
接着,黑客破解了后台的账户的密码,随之利用破解的密码登录了mail系统。通过这点,我们追踪http,发现更多的线索,比如黑客破解的是哪个账号的哪个密码、登录了mail系统后获取的vpn是什么等等内容。
最后,黑客获取了vpn的申请方式,然后登录vpn,在内网pwn掉一台打印机。至此,黑客登录了vpn,那么是否通过分析此时的流量推出黑客登录时所用的ip,亦或者其他信息呢?
至此,基本脉络分析完毕。当然,以上脉络在没有具体分析数据包前,都只是靠推测去模拟出黑客的种种行为,具体如何分析才是最值得深究的一块。这时,可能又会有人问到,黑客就一定按照你想的去做吗?请注意,凡事没有证据(流量包)之前,我们都不能确定事情的真相如何,分析前的推测更多地是指引我们可以从什么角度去分析,而不是说黑客按照我们怎么想的去怎么做。推测不一定都成立,同样,成立的不一定是推测,推测更多的是给我们一个取证的方向。这也正是数据包取证分析的有趣之处,处处悬疑,步步惊心,但真相出来之际,又有恍然大悟之感的喜悦之情。
迷之坑点
疯狂踩坑—tcp重传机制
某公司内网网络被黑客渗透,请分析流量,得到黑客上传的webshell文件名是,内容是什么,提交webshell内容的base编码
这个问题,比赛时,死活找不到答案,但是在浏览webone.pcap数据包的末尾,发现a.php里面有1234为传递值,自己构造了个一句话木马: @eval($_POST[1234]);?>,然后base64提交完成的。

当然,得到了此题比赛的分数,但是,不是为了比赛而做题,而是通过以赛督学。比赛结束后,细细分析,上传shell需要提交POST的请求,于是http的POST请求包浏览一遍,发现目录为/admin/article.php?rec=update的请求页面非常可疑,但是,却始终没有找到含有一句话木马的上传页面?怎么办呢?苦苦思想,咦,有没可能tcp这个载体漏传了,造成了包丢失?随后,过滤语句tcp contains " @eval"一试,终于找到了正确答案,再试http contains " @eval"依旧没找到,十有八九是丢包了,但这到底是为什么,还需进一步分析。

随后我追踪了下tcp流,发现了在http中没找到的一句话木马上传页面。

仔细分析了下这个tcp流的来往,我想我找到了真相。

首先,看看上图的733791序号分组,我们可以看到"TCP Previous segment not captured",提示“存在没有抓到的数据包”,也就是意味着:在当前包的捕获中,缺少了本应出现的某些包。紧接着733793序号分组,"Tcp Retransmission",提示“Tcp包重传”。很明显,存在了丢包,引发了TCP的重传机制。

随后我寻找了下tcp重传的相关文档rfc2001,该文档是描述TCP慢启动,避免拥塞,快速重传和快速恢复算法相关机制的文档。其中快速重传有这么一句描述

[1] [2] [3] [4]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载