Monitoring the DNS traffic, we see the following: # tcpdump -l -n -s 5655 -i eth0 udp port 53 However, any further communication fails. The initial installation works, and we see the ghost Beacon in the team server. We can execute a straight SOCAT, and launch a Beacon pointed to our redirector, which will be executing the following: # socat udp4-listen:53 udp4::53 Let’s attempt a naive approach to a DNS channel redirector. Naive SOCAT Redirectorīefore we jump into the solution, we should try to see the problems. This tool can do the same thing as netcat but is more versatile. A DNS redirector also has these problems, but they can be kept bounded.įor these tests, we are going to use SOCAT, a UNIX tool used to connect multiple types of inputs and outputs together. Anyone with experience with any of these tools will also know that redirecting UDP traffic is sometimes problematic. Anyone can do it using netcat or an equivalent tool. We are all familiar with the concept of piping from a network port. There are two ways of achieving this goal: piping ports together and NAT. Our redirectors will be based on the concept of diverting a UDP flow from the redirector’s local port to the team server in a way that the team server has to send the response back to the redirector, which will relay it to the Beacon. We won’t touch on these options in this article, but will instead focus on simple redirectors that can be installed on minimal Linux systems and have a very small footprint. There are several choices for these, with differing features. The obvious solution for building a DNS redirector would be to use a DNS server. UDP is more challenging, since without a way of directly sensing the DNS transaction state, SOCAT cannot know when to release the connection resources. This connection can transmit EOF messages, so the proxy would always be aware of the state of the connection and would unambiguously know when it should release the connection resources. In a TCP proxy operation, a connection is clearly defined. UDP is handled very differently from TCP in userland.UDP is stateless and keeping track of UDP “connections” requires second guessing the “connection” state.UDP is packet oriented, while TCP is byte/connection oriented.The situation is radically different for UDP. Options for secure proxying of TCP connections are also available (stunnel and SSH port forwarding are two well-known examples). SOCAT) that can simply proxy TCP connections on the user space. The state is explicit and can be easily determined from the packet stream. There is a very delimited set of data that clearly defines what constitutes a network connection (or flow). Redirecting TCP traffic is straightforward. We will not cover these aspects here, as we’ll be concentrating on the redirection part. In the case of DNS, redirectors are just one part of the solution, as alternative domains are also necessary in case the original domain is taken down. Just as HTTP redirectors can be used to hide the team server from outside scrutiny, a DNS redirector can be used for the same thing. This would mean exposing the team server to the Internet, which is not desirable. In theory, the team server should be referenced in the DNS records so that all queries for the Command and Control (C2) domain are delivered properly. Unlike HTTP Beacons, DNS Beacons do not contact the team server directly, but use the DNS infrastructure for carrying messages. This is one of the recommended mechanisms for hiding Cobalt Strike team servers and involves adding different points which a Beacon can contact for instructions when using the HTTP channel. This post, from Ernesto Alvarez Capandeguy of Core Security’s CoreLabs Research Team, describes techniques used for creating UDP redirectors for protecting Cobalt Strike team servers.
0 Comments
Leave a Reply. |