OP 24 October, 2024 - 04:23 PM
source : https://habr.com/ru/articles/345056/
A year ago, within our DEF CON group DC7812, purely for the sake of "fun and profit" and for the benefit of the community, we set ourselves the task of solving this problem and making a normal DNS tunnel in the Metasploit transport for the Meterpreter agent (for now only for MS Windows). In other words, so that Meterpreter itself would use this tunnel, natively. Obviously, this also implied the creation of a stager load (shellcodes), so that this same Meterpreter (or another MSF payload) would load via the same DNS directly from the embedded process. Thus, we will have standard native transport support, which will add additional capabilities to pentesters. Well, I am glad to announce that we have finished the development and now anyone can use it or at least test it. Under the cut you can read about the interesting features and capabilities of our development (which we talked about at the ZeroNights conference held in Moscow in November).
![[Image: qq84koww4m79rw1irw1gew-dlkk.png]](https://i.ibb.co/c22Lwd8/qq84koww4m79rw1irw1gew-dlkk.png)
Meterpreter is a 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 that allows you to create your own plugins and modules. But unfortunately, features such as transport are part of the core engine, and this means that we won’t get by with a module here. At the moment, Meterpreter supports the following types of “network” level transport:
TCP port binding
Reverse connection over TCP/IP
Reverse connection over HTTP
Developed components
In our current "pre-release" version, we have made DNS transport support only for Windows OS (for x64 and x86), which is implemented in the following components:
DNS MSF Bridge (essentially a "proxy") : https://github.com/defcon-russia/metaspl..._server.py
Meterpreter DNS transport (transport implementation in the agent) : https://github.com/defcon-russia/metaspl...t_windns.c
MSF stager payloads (shellcodes, x64/x86) : https://github.com/defcon-russia/metaspl...rse_dns.rb
DNS MSF Bridge is one of the key components of the system. In essence, it 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, this same service will open a regular TCP port for a connection from the Metasploit console via regular TCP. Thus, the pentester does not need to think about how to make the MSF handler and laptop accessible to DNS. The whole task comes down to throwing this script on your server (AWS Ec2), creating your own domain, NS records on it and not worrying about where and how the pentester works - extremely convenient (in my opinion). In addition, this solution allows several pentesters to work with one DNS, but with different loads at the same time. The current version supports up to 26 simultaneously open meterpreter sessions. At the moment we don't have native support for Ruby DNS service in MSF itself, but work on it is already underway by the Metasploit community (specifically RageLtMan ).
![[Image: 6mmmjoa5if-poeyoan5fdwxyel0.png]](https://i.ibb.co/gD75bxW/6mmmjoa5if-poeyoan5fdwxyel0.png)
The tunnel itself is organized through two types of RR records (optional): DNSKEY RR and AAAA RR. This means that all these implementations are hacked into all components, including shellcodes.
![[Image: yul-czrtpipenfbla3mayemghk.png]](https://i.ibb.co/8gLQzzG/yul-czrtpipenfbla3mayemghk.png)
The transport actually works like this: MSF handler (pentester) connects to our service, sends a payload (for example, meterpreter body) to our DNS and waits... Then, hypothetically, an exploit is triggered somewhere and someone and our shellcode, using the DNS tunnel, downloads meterpreter, runs it in the context of the same process, and meterpreter itself, using the same transport and DNS, organizes a duplex connection with the MSF handler (pentester). Then the pentester can do whatever he wants - migrate to another process, open an interactive command shell, use mimikatz, etc. - all this will be hidden by our tunnel. At the entire killchain stage (after exploitation), we use the same transport and we do not need to upload additional DNScat2 binaries to the target machine or run Powershell, we are hidden by the tunnel from the very beginning. In addition, we do not have an overhead for tunneling TCP/IP itself (headers), only meterpreter TLV packets and data.
I will separately add a few words about the organization of the tunnel from the shellcode and meterpreter side. If, for example, DNSCat2 uses its own name resolution implementation (i.e. it implements the TCP/UDP connection itself), then in our case we use the Windows API: DnsQuery, which allows us to shift the implementation of the network connection to MS DNSCache, i.e. the network connection will be implemented directly by svchost.exe, and not by a hacked process or backdoor (meterpreter). This is a very good "feature" that will allow us to bypass a number of problems with EPP/AV and personal firewall, which are actively running on the "victim's" workstation and monitoring new suspicious connections. This is what it looks like:
![[Image: gvvib-e4lyy-phlvbhojqk30coo.png]](https://i.ibb.co/cL3XxK3/gvvib-e4lyy-phlvbhojqk30coo.png)
Well, and the classic tunnel theme - the connection in any case does not go to the Internet, but to a local DNS server, that is, to a router or whatever is registered in the corporate network (AD). In fact, this also allows you to gain control over machines that cannot directly go to the Internet. Separately, here I can recall that in my experience there were stories when this pulled out a pentset - a sploit with a DNS tunnel with a trapport for a payload, allowed sending emails and receiving breakthroughs from targets in "especially isolated zones". In addition, I recently tested a feature of one NextGen product - "isolation of a compromised host", so meterpreter with DNS tunnels this isolation turned out to be nothing 8) In short, there are many bonuses and goodies, but there is also a negative side - speed and network anomalies. About the speed — it depends greatly on the environment and local DNS, and can vary greatly. I took measurements in a home network and in a corporate network and here 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 uploads the body at the moment of splitting in 2 seconds, which is very acceptable in my opinion. Nevertheless, there are minor lags and freezes in general (from experience). The AAAA tunnel is more invisible on the one hand = more fragmented requests, and the AAAA requests themselves are not uncommon in the logs.
HowTo
git clone and budle install github.com/defcon-russia/metasploit-framework
You need to have a domain, something shorter, like: msf.ws
Need a place for hosting with static IP (let's say IP 1.2.3.4)
Let's configure NS records on msf.ws and our IP
Let's upload DNS MSF Bridge to the server and launch it
Let's prepare a stager payload (shellcode)
Let's create a sploit with our shellcode
Let's run MSF handler
We will deliver the sploit to the target and wait for 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 creating a native DNS handler. We think that next year this will no longer be just a cool fork, but will become part of the project.
As soon as this transport becomes part of the project "officially", we 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 IRC (freenode.org #Metasploit, ask max3raza and RageLtMan for the tunnel there ).
If you are interested in the topic of information security at all, then our DC 7812 group telegram chat
t.me/DCG7812 sometimes we hold group meetings and online streams, if you have ideas or want to participate in the action - welcome!..
Project sources (MSF fork with our features):
https://github.com/defcon-russia/metasploit-framework
https://github.com/defcon-russia/metasploit-payloads
Slides from ZeroNights. : https://defcon-russia.ru/meetups/zn2017/ms.pdf?dwl
This is the end of the article, I will emphasize on my own behalf that MSF is one of my favorite C2, and I am very glad that DNS transfer support has appeared (although not in the official version).
We hope that such a function will soon be added to the official version.
A year ago, within our DEF CON group DC7812, purely for the sake of "fun and profit" and for the benefit of the community, we set ourselves the task of solving this problem and making a normal DNS tunnel in the Metasploit transport for the Meterpreter agent (for now only for MS Windows). In other words, so that Meterpreter itself would use this tunnel, natively. Obviously, this also implied the creation of a stager load (shellcodes), so that this same Meterpreter (or another MSF payload) would load via the same DNS directly from the embedded process. Thus, we will have standard native transport support, which will add additional capabilities to pentesters. Well, I am glad to announce that we have finished the development and now anyone can use it or at least test it. Under the cut you can read about the interesting features and capabilities of our development (which we talked about at the ZeroNights conference held in Moscow in November).
Meterpreter is a 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 that allows you to create your own plugins and modules. But unfortunately, features such as transport are part of the core engine, and this means that we won’t get by with a module here. At the moment, Meterpreter supports the following types of “network” level transport:
TCP port binding
Reverse connection over TCP/IP
Reverse connection over HTTP
Developed components
In our current "pre-release" version, we have made DNS transport support only for Windows OS (for x64 and x86), which is implemented in the following components:
DNS MSF Bridge (essentially a "proxy") : https://github.com/defcon-russia/metaspl..._server.py
Meterpreter DNS transport (transport implementation in the agent) : https://github.com/defcon-russia/metaspl...t_windns.c
MSF stager payloads (shellcodes, x64/x86) : https://github.com/defcon-russia/metaspl...rse_dns.rb
DNS MSF Bridge is one of the key components of the system. In essence, it 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, this same service will open a regular TCP port for a connection from the Metasploit console via regular TCP. Thus, the pentester does not need to think about how to make the MSF handler and laptop accessible to DNS. The whole task comes down to throwing this script on your server (AWS Ec2), creating your own domain, NS records on it and not worrying about where and how the pentester works - extremely convenient (in my opinion). In addition, this solution allows several pentesters to work with one DNS, but with different loads at the same time. The current version supports up to 26 simultaneously open meterpreter sessions. At the moment we don't have native support for Ruby DNS service in MSF itself, but work on it is already underway by the Metasploit community (specifically RageLtMan ).
The tunnel itself is organized through two types of RR records (optional): DNSKEY RR and AAAA RR. This means that all these implementations are hacked into all components, including shellcodes.
The transport actually works like this: MSF handler (pentester) connects to our service, sends a payload (for example, meterpreter body) to our DNS and waits... Then, hypothetically, an exploit is triggered somewhere and someone and our shellcode, using the DNS tunnel, downloads meterpreter, runs it in the context of the same process, and meterpreter itself, using the same transport and DNS, organizes a duplex connection with the MSF handler (pentester). Then the pentester can do whatever he wants - migrate to another process, open an interactive command shell, use mimikatz, etc. - all this will be hidden by our tunnel. At the entire killchain stage (after exploitation), we use the same transport and we do not need to upload additional DNScat2 binaries to the target machine or run Powershell, we are hidden by the tunnel from the very beginning. In addition, we do not have an overhead for tunneling TCP/IP itself (headers), only meterpreter TLV packets and data.
I will separately add a few words about the organization of the tunnel from the shellcode and meterpreter side. If, for example, DNSCat2 uses its own name resolution implementation (i.e. it implements the TCP/UDP connection itself), then in our case we use the Windows API: DnsQuery, which allows us to shift the implementation of the network connection to MS DNSCache, i.e. the network connection will be implemented directly by svchost.exe, and not by a hacked process or backdoor (meterpreter). This is a very good "feature" that will allow us to bypass a number of problems with EPP/AV and personal firewall, which are actively running on the "victim's" workstation and monitoring new suspicious connections. This is what it looks like:
Well, and the classic tunnel theme - the connection in any case does not go to the Internet, but to a local DNS server, that is, to a router or whatever is registered in the corporate network (AD). In fact, this also allows you to gain control over machines that cannot directly go to the Internet. Separately, here I can recall that in my experience there were stories when this pulled out a pentset - a sploit with a DNS tunnel with a trapport for a payload, allowed sending emails and receiving breakthroughs from targets in "especially isolated zones". In addition, I recently tested a feature of one NextGen product - "isolation of a compromised host", so meterpreter with DNS tunnels this isolation turned out to be nothing 8) In short, there are many bonuses and goodies, but there is also a negative side - speed and network anomalies. About the speed — it depends greatly on the environment and local DNS, and can vary greatly. I took measurements in a home network and in a corporate network and here 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 uploads the body at the moment of splitting in 2 seconds, which is very acceptable in my opinion. Nevertheless, there are minor lags and freezes in general (from experience). The AAAA tunnel is more invisible on the one hand = more fragmented requests, and the AAAA requests themselves are not uncommon in the logs.
HowTo
git clone and budle install github.com/defcon-russia/metasploit-framework
You need to have a domain, something shorter, like: msf.ws
Need a place for hosting with static IP (let's say IP 1.2.3.4)
Let's configure NS records on msf.ws and our IP
Let's upload DNS MSF Bridge to the server and launch it
Let's prepare a stager payload (shellcode)
Let's create a sploit with our shellcode
Let's run MSF handler
We will deliver the sploit to the target and wait for 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 creating a native DNS handler. We think that next year this will no longer be just a cool fork, but will become part of the project.
As soon as this transport becomes part of the project "officially", we 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 IRC (freenode.org #Metasploit, ask max3raza and RageLtMan for the tunnel there ).
If you are interested in the topic of information security at all, then our DC 7812 group telegram chat
t.me/DCG7812 sometimes we hold group meetings and online streams, if you have ideas or want to participate in the action - welcome!..
Project sources (MSF fork with our features):
https://github.com/defcon-russia/metasploit-framework
https://github.com/defcon-russia/metasploit-payloads
Slides from ZeroNights. : https://defcon-russia.ru/meetups/zn2017/ms.pdf?dwl
This is the end of the article, I will emphasize on my own behalf that MSF is one of my favorite C2, and I am very glad that DNS transfer support has appeared (although not in the official version).
We hope that such a function will soon be added to the official version.
FOR SALE
