Listener Management

The next step is to setup a "listener", which will listen for incoming connections from our Beacons.

"Beacon" is the name of Cobalt Strike's payload - because it "beacons" out to the team server from a compromised endpoint.

\

There are two main types of listeners: egress and peer-to-peer.

Egress Listeners

An egress listener is one that allows Beacon to communicate outside of the target network to our team server. The default egress listener types in Cobalt Strike are HTTP/S and DNS, where Beacon will encapsulate C2 traffic over these respective protocols.

To manage your listeners, go to Cobalt Strike > Listeners or click on the headphone icon. This will open the Listeners tab, from which you can add, edit, remove and restart listeners.

\

HTTP

The HTTP listener allows Beacon to send and receive C2 messages over HTTP GET and/or POST requests.

To create a new HTTP listener, click Add. Make sure Beacon HTTP is the selected payload type and give the listener a name. The listener's name is used throughout many of Cobalt Strike's CLI commands, so choose one that allows you to easily recognise which listener this is.

Click the little + button next to the HTTP Hosts box. Here, you provide the IP addresses and/or domain names that the Beacon payload will call back to. By default, it will auto-populate with the IP address of the Attacker Linux VM, but it's more realistic to use proper DNS names. There is a DNS resolver in the lab that you can use to create arbitrary DNS records, which can be accessed via the Apps menu in Snap Labs.

\

\

There is a domain name already created - nickelviper.com, but feel free to create your own. You may also create and use multiple domain names, as long as they all point to 10.10.5.50.

\

\

After clicking Save, you will see a message appear on the team server and port 80 will now be listening.

[+] Listener: http started!
attacker@ubuntu ~> sudo ss -lntp
State            Recv-Q           Send-Q                       Local Address:Port                        Peer Address:Port           Process
LISTEN           0                50                                       *:80                                     *:*               users:(("TeamServerImage",pid=1967,fd=7))

\

DNS

The DNS listener allows Beacon to send and receive C2 messages over several lookup/response types including A, AAAA and TXT. TXT are used by default because they can hold the most amount of data. This requires we create one or more DNS records for a domain that the team server will be authoritative for. In the case of nickelviper.com, I have setup the following:

\

The DNS Beacon can then perform lookup requests, such as <c2data>.pics.nickelviper.com, which will then be routed over the Internet's DNS infrastructure. It will eventually reach our team server, because we've setup the appropriate records to say that the DNS server ns1.nickelviper.com is authoritative for the pics subdomain.

\

\

After clicking Save, we can test the records by performing an arbitrary lookup. The team server's default response is 0.0.0.0.

ubuntu@DESKTOP-3BSK7NO ~> dig @ns1.nickelviper.com test.pics.nickelviper.com +short
0.0.0.0

OPSEC Since 0.0.0.0 is the default response (and also rather nonsensical), Cobalt Strike team servers can be fingerprinted in this way. This can be changed in the Malleable C2 profile.

\

Peer-to-Peer

Peer-to-peer (P2P) listeners differ from egress listeners because they don't communicate with the team server directly. Instead, P2P listeners are designed to chain multiple Beacons together in parent/child relationships. The primary reasons for doing this are:

  1. To reduce the number of hosts talking out to your team server, as the higher the traffic volume, the more likely it is to get spotted.

  2. To run Beacon on machines that can't even talk out of the network, e.g. in cases of firewall rules and other network segregations.

The two P2P listener types in Cobalt Strike are Server Message Block (SMB) and raw TCP. It's important to understand that these protocols do not leave the target network (i.e. the team server is not listening on port 445 for SMB). Instead, a child SMB/TCP Beacon will be linked to an egress HTTP/DNS Beacon, and the traffic from the child is sent to the parent, which in turn sends it to the team server.

\

SMB

SMB listeners are very simple as they only have a single option - the named pipe name. The default is msagent_## (where ## is random hex), but you can specify anything you want. A Beacon SMB payload will start a new named pipe server with this name and listen for an incoming connection. This named pipe is available both locally and remotely.

OPSEC This default pipe name is quite well signatured. A good strategy is to emulate names known to be used by common applications or Windows itself. Use PS C:\> ls \\.\pipe\ to list all currently listening pipes for inspiration.

\

\

TCP

A Beacon TCP payload will bind and listen on the specified port number. You may also specify whether it will bind to only the localhost (127.0.0.1), otherwise it will bind to all interfaces (0.0.0.0).

\

\

Last updated