When gaining initial access on a host in a secure zone with restricted outbound traffic, establishing a command and control channel for an implant can be a challenge.

Using DNS for peer-to-peer command and control can be the solution, making the internal DNS servers your redirectors on the target network.

TL;DR

By adding NS records via ADIDNS and forwarding DNS traffic from a compromised host to the team server via other C2 channels, it is possible to use DNS for peer-to-peer C2 between implants inside the target network, which could allow traversing security zones and possibly “flying under the radar”.

Command and Control Protocols

There are four protocols that are commonly used for command and control:

  • HTTP(S)
  • DNS
  • SMB
  • TCP Socket

Many APTs and red teams abuse other protocols in creative ways, but none are as prevalent as the above.

Generally, HTTP and DNS are more suitable for egress C2 traffic, while TCP and SMB are more suitable for implant-to-implant traffic inside the target network. However, situational awareness and context are always key for blending-in and maintaining stealth.

DNS C2 has had its glory days, but it is commonly detected nowadays and is best reserved only for low-traffic long-haul channels.

DNS C2 with a Twist

DNS can also be used as a peer-to-peer C2 channel by leveraging ADIDNS. The default configuration allows any domain user to create an internal NS record. The easiest way to do that is using Kevin Robertson’s (@NetSPI) Powermad.

For example, let’s say we have a beacon running on a host called “HostA”, connecting back to our team server over HTTP, and we want to launch a beacon on a host called “HostB”, which will connect to “HostA” over DNS and then over to our team server via the first beacon’s C2 channel.

DnsTunnelDiagram.png

First, we create a NS record for “RogueDNS” and point it at a compromised host, which is “HostA” in this example.

New-ADIDNSNode -DomainController DC1.Shenanigans.Labs -Node RogueDNS -Type NS -Data HostA.Shenanigans.Labs

Next, we want to forward the incoming DNS traffic to our team server through our short-haul or interactive channel. This is a bit of a challenge, because DNS traffic is transmitted over UDP, and we use Cobalt Strike, which supports reverse port forwarding for TCP only.

To get around it, we wrote a simple C# program that tunnels incoming DNS traffic from UDP port 53 to a TCP port that we forward from the compromised host to our team server. On the team server, we can use socat to forward it to our DNS listener.

The following diagram describes the chain: DnsTunnelDiagram2.png

And the result is a DNS Beacon from “HostB”: DnsTunnelCS.png

Note that on Microsoft DNS servers, recursion is enabled by default, and so the internal DNS servers act as “internal redirectors”.

What is It Good For?

Because the C2 traffic is forwarded through the DNS servers, it could allow traversing segregated networks and security zones.

Stealth?

Over the years, I’ve learned that there is no such thing as “stealthy” tradecraft; every little thing we do has indicators. However, detection varies from organisation to organisation, due to differences in the availability and quality of data, the maturity level of the blue team, budget, etc. Therefore, we need to tailor our tradecraft to the operational environment to hide in the blindspots or blend-in.

While this tradecraft is simple to detect in several different ways, it usually flies under the radar for two primary reasons:

  1. Internal DNS traffic is not analysed
  2. The blue team would generally not find something they are not looking for

Variants

You can also use individual parts of this chain to achieve a different behaviour or avoid certain indicators; however, I haven’t tested those in real environments yet:

  • Skip the ADIDNS abuse by pointing a public NS record to an internal host that is running your implant. The DNS server will initially resolve the NS record from the internet, but the subsequent queries will be directed to the implant.
  • Abuse ADIDNS to create an internal NS record to an external IP address. In some cases, internal DNS names may be excluded from certain alerts, or the blue team may shrug it off.

Author

Elad Shamir (@elad_shamir)

References

This post was also published on eladshamir.com.