快捷搜索:  网络  后门  扫描  渗透  CVE  木马  黑客  as

Ghost Tunnel复现

之前很早就已经看到360关于Ghost Tunnel的研究,那时也一时髦起进行复现。在Mac以及Windows上都做了一系列尝试,证实了理论可行。

后来闲的无聊,并且刚好有学弟也在验证这个隐蔽通道的可行性,就爽性以及他一块儿探讨这方面的完成。以后,GhostTunnel我就推在本人的Github上,经过一段时间的起劲,我以及我同伴一块儿推出了GhostTunnel稳定版。说真话,我不是很清楚360是怎么样做到极其稳定的控制在各个体系上,手艺上难以想象。

在探索GhostTunnel的道路上,我小我私人认为未来在挪移端和蓝牙上,可能都存在类似的要领进行隐蔽传输。传输的效劳以及网卡的功率无比有关系,目前我们测试的有用距离是5m左右,过遥会导致丢帧率增高,不稳定性增添。

行使GhostTunnel配合bashbunny+powershell基本可以完成无感控制。然后遥程加载木马或者绕过,提权都是无比可行的。

自己的设法主张是希翼能够将这个始终迭代下去,开发出多端的隐蔽控制。也希翼有同伙一块儿提出issue或者request进行迭代。

【Github传送门】https://github.com/JcQSteven/GhostTunnel

下面是ReadMe部分。首要表述了我是怎么样行使GhostTunnel完成控制端以及其被控端。

被控端程序逻辑

被控端程序的目的在于接收控制端的指令,并根据指令执行相应的举动。由于控制端与被控端之间通过Probe request帧以及Probe response帧传输,因此被控端逻辑首要分为【帧传输逻辑】以及【帧解析逻辑】两个部分。

帧传输逻辑

Probe request帧由被控端主动发送,并接受控制端发送Probe respense帧。因此,在 windows环境下,其执行的逻辑为:获取会话句柄、获取网卡列表及信息、发送request帧、获取附近收集信息列表、获取指定WLAN端口上的收集基本服务集、获取帧数据。

获取会话句柄

获取会话句柄采用的api为WlanOpenHandle。该 api关上了一个与服务器的连接。只有持有了句柄,才能进行后续才做。

获取网卡列表及信息

获取网卡列表采用的api为WlanEnumInterfaces,通过该函数,可以获得一个网卡列表 pIfList,通过对该列表的解析,可以获取网卡的信息。

发送request帧

在获取网卡信息判定网卡预备无误后,即可通过WlanScan函数发送request帧。发送帧的结构请参见后续部分。

获取附近收集信息列表

在发送request帧后,被控端通过WlanGetAvailableNetworkList 函数最先扫描附近收集信息,检查是否收到response帧。要是没有,则返归第3步,重新发送request 帧,然后再次检测。要是收到response帧,则进入第5步。

获取指定WLAN端口上的收集基本服务服务集

行使WlanGetNetworkBssList函数获取指定收集上的BSS列表并进行解析,根据 response帧的特征值id过滤出有效的的帧。

帧解析

将过滤出的帧并根据帧的定义获取对应的数据,从而实现一次帧传输逻辑。

帧解析逻辑

在实现帧传输逻辑后,即可获取由控制端发送的response帧数据。request帧以及response帧的帧结构以下:

request帧结构:

“acc” (3byte) | Hash (8byte)

名称 作用
“acc” 用来标识该帧为要求帧
Hash 帧第一次发送时间的Hash值
request帧的前三个字节用于标识该帧为要求帧,后面8个字节为当前帧第一次发送时间的Hash值,为接收端提供帧标识,防止重复接收。

response帧结构:

执行指令帧:

”ccc” (3byte) | Hash (8byte) | Co妹妹and (244byte)

名称 作用
”ccc” 用来标识该帧为执行指令帧
Hash 最后一次接收到response帧的Hash值
Co妹妹and 执行指令

执行指令帧的前三个字节用来标识该帧为执行指令帧,后面8个字节为最后一次接收到response帧的Hash值,最后244字节为待执行指令。

传输文件帧:

”F” (1byte) | FilenameLen (2byte) | Hash (8byte) | FileIndex (2byte) | CurrentIndex(2byte) | FileName+FileContext (220byte)

名称 作用
“F” 用来标识该帧为传输文件帧
FilenameLen 用来标识文件内容相对头信息后内容的偏移量
Hash 当前帧第一次发送时间的Hash值
FileIndex 文件总分片数
CurrentIndex 当前接收的分片序号
FileName+FileContext 先为文件名称,然后为详细的文件内容

传输文件帧的第1个字节(“F”)用来标识该帧为传输文件帧,第 2、3字节(FilenameLen)用来标识文件内容相对头信息后内容的偏移量,因为文件名的长度是不定的。第4-11字节(Hash)为当前帧第一次发送时间的Hash值,第十二、13字节(FileIndex)为文件总分片数,第1四、15字节(CurrentIndex)为当前接收的分片序号,第16字节起先为文件名称,然后为详细的文件内容。

根据帧结构,可以很轻易的解析帧所携带的信息。要是帧为执行指令帧,则调用CreateProcess函数创建进程执行指令;要是帧为传输文件帧,则将帧所携带的文件内容写入文件中。

文件说明

1.main.cpp /.h 主程序入口

2.mainProcess.cpp /.h 主函数逻辑

3.Action_ExcuteCmd.cpp /.h 执行命令攻击逻辑

4.Action_Sendfile.cpp /.h 发送文件攻击逻辑

控制端程序逻辑

response帧由控制端在接收到request帧后发送,因此控制端逻辑首要分为解析命令、抓包、发送帧三个步骤。

解析命令

不同的攻击所采用的参数不同。例如:

需要设定自动关机时,所采用的指令是

python main.py -c"shutdown -r -t 60"

需要遥程传输文件时,所采用的指令是

python main.py -f"/root/Desktop/hello.txt"

因此,需要对攻击者所采用的指令进行解析,从而确定所需的帧结构。

抓包

由于reponse帧需要在接收到request帧后对其进行反馈,因此,在python环境下,行使scapy工具包sniff要领对指定网卡进行扫描(注:指定网卡需要切换至monitor模式)。当收到数据包后,根据request帧的特征对数据包的内容进行定位以及解析,要是解析到request帧,则将帧的hash部分存入内陆缓存。

发送帧

根据攻击者的指令,控制端根据定义的response帧结构组织数据包,并按照帧会话逻辑进行发送。

帧会话逻辑

由于采用request帧以及response帧进行的会话是无连接的,因此很容易造成帧的丢失、重复等问题。因此,在需要多帧传输、单帧验证等使用处景下,需要采用一种可靠的会话逻辑来确保帧的顺次传输。帧的会话逻辑以下:

request帧初始状态下Hash值为随机数。在接收到response帧后,将最新接收的response帧的Hash值作为本人的Hash值,从而达到告诉控制端“某帧已经接收到,请发送下一帧”的目的。reponse帧发送的Hash值为第一次该帧发送的时间哈希值,控制端第一次发送500帧,以后每一隔4秒钟再增添50帧发送,直到收到request帧携带的Hash与当前帧的Hash值相同为止,否则不发送下一帧。从而达到“确认帧已经送达”的目的。通过这类逻辑,从而保障帧不会丢失。

此外,被控端每一次会将最新收到的帧的hash存在内陆,每一收到response帧时,会将Hash值与内陆的hash值进行比较,要是不一致,则执行相干动作,否则,则扔弃该帧。通过这类逻辑,从而保障帧丢失、帧缓存等问题。

考虑到帧所携带的数据量有限,且传输距离较短,因此没有对帧数据进行校验,默认接收到的帧都是正确的,实验测试也表明,没有必要对帧数据进行校验。

脚本使用要领

主控脚本采用传统的”参数+指令”要领,其对应参数及含义以下:

-h                脚本帮助

-c”co妹妹and”      遥程执行指令,建议执行的指令使用“”括起来,要是没有使用则只能执行单指令

-f”file path”    传输文件,路径可觉得尽对路径,也可觉得相对于路径

示例:

关上计算器:     

python main.py "cmd /c calc"

传输hello.txt文件:

python main.py "/root/Desktop/hello.txt"

踩过的坑

1.程序的总体逻辑比较简单、清晰。帧结构目前仍旧有可扩大性,如帧头。

2.被控端在收到response帧后,会在内陆进行缓存,导致被控端反复认为接收到该response帧,因此帧头采用hash值进行标识。

3.对于被控端,不同的攻击类型所需采用的执行要领不同,如执行命令攻击需要调用createProcess要领来执行命令,黑客网,而传输文件则需要将帧内容写入文件。因此,对帧头进行了标识,根据标识在客户端采用不同的要领。

4.控制端的网卡需要切换至monitor模式

5.在文件多分片传输的情形下,可能会出现network down,为了解决这个问题,后续将开发续传功能。

6.一次传输实现大约需要3秒,且该时间随着传输距离的增添而增添,因此传输效劳低,该问题有待于解决。

*

您可能还会对下面的文章感兴趣: