C4 Profiler

C4 Profiler in commander provide a variety of ways to configure the payloads, listeners and other commands. Each of these can be found in the respective section below.

Add HTTP Listener

To create a new HTTP/HTTPS listener, select C4 Profiler->Add HTTP Listener. The listener name is autogenerated unless an operator adds it explicitly. The information passed on to create the listener is used to start a listener and create payloads out of them. The listener bind host takes an IP address which it will bind itself to, on the host. The rotational hosts are servers where the payload checks in. Any number of rotational hosts can be added here. These hosts get embedded in the badger when you generate them, and is used to randomly switch domains when they check in. These can also be a combination of IP addresses, fronted domains, redirectors or normal domains.

Multiple headers and URIs can be added here, which will be used when generating the badger. The URIs have to be comma separated which will be randomly used when the badger checks in.

The POST request of the badger can be modified using malleable profiles. To create a malleable post request, click the ‘+ Malleable post data’ button. After clicking this, you will be presented with options to prepend and append data to your badger’s post request.

You can prepend and append json, xml, javascript or anything else to emulate a legitimate network traffic.

There is also an optional proxy input. This proxy field is used by the HTTP and DOH badgers for egress connections.

Brute Ratel servers support two types of authentication mechanism:

  • Common Authentication for all badgers
  • OTA or One Time Authentication

If you select Common Auth, all badgers will have the same authentication key. Any badger that checks in for the first time, will provide an encrypted key to the listener, without which the listener will send a 404 not found to the badger. However, if you are planning to phish, say 10 people, then its better to create 10 OTA keys. In this way when a badger connects for the first time, the key will be authenticated, the badger will receive a token and then the key will be purged from the server. Now say for some reason if the security team gets a hold of the same payload, it will never be able to authenticate to the server and the server will always reject the OTA key since it does not exist anymore.

BRc4 listener provides you the option to either manually type in multiple comma separated keys, or you can select the checkbox ‘Create random set of authentication keys’ and the ratel server will automatically create the specified number of keys for you. If you decide to let the listener create the random keys, you can view them by right clicking the listener and selecting Listener Actions->View Authentication. The authentication key can be changed using Listener Actions->Change Authentication.

The Die if C2 is inaccessible option, when enabled, makes the badger kill itself if it is unable to connect to the provided rotational host.

Add DOH Listener

Unlike the usual DNS payloads where all DNS requests are exposed to a network intrusion detection tool, DNS over HTTPS work over SSL to provide anonymity. DOH badgers send HTTPS request to legitimate HTTP DNS Resolvers such as Google, OpenDns, Cloudfront (as configured by the operator) and sends them a DNS request in post or get data. The HTTP DNS resolvers forward this to the specified domain and resolve the A or the TXT records requested by the badger. This means, if you have a domain, for eg.: evasionlabs.com, then you will have to create a subdomain where the requests would be sent. Lets assume our resolving domain is dns.evasionlabs.com. This means the badger will send a DNS request inside a POST data such as encryptedPayloadBuffer.dns.evasionlabs.com to resolve A records for the subdomain encryptedPayloadBuffer to dns.google. Since dns.google doesn’t know about this domain, it will forward it to our domain evasionlabs.com which will forward it to dns.evasionlabs.com, which will then take in the encryptedPayloadBuffer, decrypt it and read the data sent by the badger, and respond with a valid A record. The DOH listener returns Idle-A records if there is no command to be sent to the badger. If there are any commands added to the server by the operator, then it will send Checkin-A record to the badger which will then request for TXT records instead of A records. Once the TXT record is requested and the server receives it, the server will send encrypted buffer as TXT records to the badger. One important note here is to remember that DNS can only transmit a total of 64 bytes per request per subdomain, unlike post requests where atleast 8192 bytes can be sent at one point of time. This means the DOH badgers will be slower then the HTTP badgers as it will have to send requests and receive responses in multiple chunks. The malleable DOH listener of badger also provide an option to return legitimate TXT record if there is a normal DNS request by a blue teamer or a threat hunter.

To create a DNS Over HTTPS listener, select C4 Profiler->Add HTTP Listener. The listener name is autogenerated unless an operator adds it explicitly. The information passed on to create the listener is used to both start a listener and create payloads out of them. The listener bind host takes an IP address which it will bind itself to, on the host. The rotational hosts are servers where the payload checks in. Any number of rotational hosts can be added here. These hosts get embedded in the badger, when you generate them, and is used to randomly switch domains when they check in. This rotational hosts need to be valid HTTP DNS Resolvers such as dns.google, OpenDns, cloudfront and so on. The DOH listener starts on port 53 by default, and the requests by the badgers are sent to port 443 of the DNS resolver in a POST request in HTTPS. The badger configuration can be changed from the Payload Profiler if you want it to send a request elsewhere.

The DNS Hosts takes in the DNS subdomains/hosts which need to be queried. From the above example, this would be something like dns.evasionlabs.com. Multiple DNS hosts can be added here which need to be resolved. Similarly the rotational hosts also take in multiple dns resolvers like dns.google, OpenDns, cloudfront, mozilla etc. Make sure these resolvers support DOH, else they wont responds to HTTP requests. The URI also has to be specific to the DNS resolvers. Most of the time this will be a static URI i.e. dns-query for all the domains mentioned above.

There is also an optional proxy input. This proxy field is used by the HTTP and DOH badgers for egress connections. The format is basically https://ip:port or http://ip:port.

Brute Ratel servers support two types of authentication mechanism:

  • Common Authentication for all badgers
  • OTA or One Time Authentication

If you select Common Auth, all badgers will have the same authentication key. Any badger that checks in for the first time, will provide an encrypted key to the listener, without which the listener will send a 404 not found to the badger. However, if you are planning to phish, say 10 people, then its better to create 10 OTA keys. In this way when a badger connects for the first time, the key will be authenticated, the badger will receive a token and then the key will be purged from the server. Now say for some reason if the security team gets a hold of the same payload, it will never be able to authenticate to the server and the server will always reject the OTA key since it does not exist anymore.

BRc4 listener provides you the option to either manually type in multiple comma separated keys, or you can select the checkbox ‘Create random set of authentication keys’ and the ratel server will automatically create the specified number of keys for you. If you decide to let the listener create the random keys, you can view them by right clicking the listener and selecting Listener Actions->View Authentication. The authentication key can be changed using Listener Actions->Change Authentication.

The Die if C2 is inaccessible option, when enabled, makes the badger kill itself if it is unable to connect to the provided rotational host.

Below is a quick example to validate whether your DOH listener is working properly. After starting your DOH listener, send in a DNS request for A and TXT records to validate it is responding as per the configured Idle-A, Checkin-A and Spoofed TXT records. If you get the exact response as configured in the DOH listener, it means they are working properly.

dig @8.8.4.4 dns1.evasionlabs.com              # to query A record
dig @8.8.4.4 dns2.evasionlabs.com -t TXT       # to query TXT record

When working around DOH listeners, its a good idea to temporarily enable debug logs for the DOH server. You can enable/disable debug logs by selecting Server->Enable/Disable DOH Debug Logs in Commander.

NOTE: Enabling Debug logs for DOH will slow down the badger’s response and request time. It should only be used for testing the DOH listener and badger, and not during a live assessment.

Hosted Files

Different types of files can be hosted on the Brute Ratel listener (Only HTTP Listeners) by right clicking on the created listener and selecting Listener Actions->Host File. Mime types can also be customized depending upon the type of content you want to show on the target’s proxy server.

View Hosted

If you want to remove or view the list of files hosted, you can select C4 Profiler->Hosted Files.

Root Page Manager

Listener’s root page can be configured using C4 Profiler->Change Root Page.

This opens a dialog box where a user can enter HTML/JavaScript which will be rendered on the root page of all listeners. The HTML/Javascript code will be rendered for anyone who visits the root page. However, it works differently for the badger. The Listeners are configured in such a way that it automatically identifies whether the request has been sent by a person/automation tool or a badger. After differentiating the request, it parses the badger’s response and searches for an authentication key. If it doesn’t have any, then it would return a 404 not found. This works well in hiding your badger’s server behind a legitimate HTML page.

Autoruns

Brute Ratel can automate initial command execution for badgers using the autoruns profiler. These autoruns will automatically execute for every badger that connects for the first time. This feature can be used during red team scenarios when you want the badger to execute a specific set of commands as soon as it connects for the first time. These autoruns can be configured either by adding them manually as well in the C4 profile or from the Commander.

To Add Autoruns from the Commander, select C4 Profiler->Autoruns.

In the Badger Console, the output clearly states which commands were run by a user and which was automated.

Payload Profiles (Commander)

Payload profiles provide a variety of options to configure and build payloads. These payload configurations work independent of the Listener Profiles. This means you can edit, delete or create new profiles and use them dynamically during process injections, profile migration or to create new executable/shellcode/dll/ps1 or service executables out of them. There are 4 types of payload profiles.

  • DOH (DNS over HTTPS)
  • HTTP/HTTPS
  • TCP
  • SMB

You can also store profiles for your backup Command and Control Center in your current C2 and use them to inject the backup-c2’s profile directly in your current payload, thus allowing you to switch C2s without the need to drop a file on disk. To add a new profile, select C4 Profiler->Payload Profiler and then click on the ‘+ Add Profile’ icon.

Here you can select between adding a new profile, editing or deleting an existing one or generating x86/x64 payloads from that profile.

HTTP Profile

The HTTP profile takes in the same type of configuration as that of the HTTP listener. The fields are identical except there is no information required for building the listener here, because the payload profiles are just used to build payloads and are not bound to any specific listener. You can create payload profiles for any other Ratel server, and use them to build payloads or to perform injection/profile switching on the fly using the ‘pcinject’ command. The profiles can also be used alongside the ‘psexec’ command to dynamically generate and run service executables on a target host.

DOH Profile

The DOH profile is also identical to that of the DOH listener.

NOTE: On-the-fly switching of malleable profile only support HTTP listeners for now.

SMB Profile

The SMB profile can be used to connect to other badgers over Named Pipe. Unlike TCP badgers which perform a reverse connection, the SMB badger start a named pipe and waits for another badger to connect to the named pipe. Named pipes can be connected using the pivot_smb command. Named pipes use windows access token for authentication. This means in order to connect to a remote named pipe, the user needs to have privileges on the target host. Provided the operator has the username and password for a target host, that can be used alongside the make_token command to create an access token and access the target host’s named pipe.

TCP Profile

The TCP profile can be used to create reverse pivot TCP badgers. TCP badgers can connect only to other badgers i.e DOH/SMB/TCP or HTTP/HTTPS. In order for the TCP badger to connect to the listener, the operator has to start a TCP listener on the badger which will act as a pivot point for the TCP badger using the pivot_tcp command. Important thing to note is that the authentication key for the TCP badger should be the same as that of the final listener (HTTP or DOH listener) where it reaches in the end on the ratel server.

Below is a quick example of multiple profiles stored in the payload profiler.

PsExec Configuration

The PsExec feature of BRc4 is partially similar to that of Microsoft. It creates a service on a given remote system and starts it using Remote Procedure Calls (RPC). But unlike Microsoft’s PsExec which uses CreateProcess to pipe cmd.exe over SMB, BRc4’s PsExec service contains a shellcode blob for a payload profile provided during the execution of PsExec. This payload can either be SMB, DOH, HTTP or a TCP profile and doesn’t necessarily limit you to just SMB badgers. One of the most important OpSec consideration during lateral movement is to keep yourself disguised as a legitimate service. Several PsExec options such as service name, description, service executable name and the type of payload to execute on the remote host are customizable on-the-go. This can be configured by selecting C4 Profiler->PsExec Config. It allows to change the service names and description when a PsExec Service is created on the host.

Once you’ve configured the description and the name, you can view the configuration from the Watchlist tab by clicking the ‘PsExec Config’ button as can be seen in the image below.

Click Scripts

Click Scripting is a feature which allows users to automate execution of bulk commands. Unlike the ‘Autoruns’ feature which lets a user to auto-execute several commands on the first connection of badger, Click Scripts are basically a list of multiple commands which can be chained together to execute one command after the other at any point of time. This helps with automated execution of commands belonging to different Tactics and Techniques of MITRE ATT&CK which can be pretty useful during Purple Team engagements. Below is an example of some discovery based commands which are grouped into a single click script called ‘Discovery’.

To add a new click script, select ‘C4 Profiler->Clickscripts’. This will open a new dialog box where we can add a new script using the ‘+’ icon. Once a script script has been added, new commands can be added to it by selecting the script and then clicking on the button highlighted in the below figure.

After adding the scripts, the Click Script Runner can be loaded by right clicking a badger and selecting ‘Load ClickScript’. This will open a new tab where different scripts can be run by a single click as shown in the earlier figure. To manually build a Click Script profile in the C4 profiles, check here.