The listener tab provides a quick interface to interact with the newly created listeners.
Riot Control provides a unanimous command-line interface where an operator can send commands to multiple badgers simultaneously via a single console. This is something I built to simulate a Bot-net style functionality where you can command multiple badgers at the same time. You can start Riot Control by right clicking a listener and selecting Riot Control.
Riot Control can be extremely helpful when you want to exploit a specific vulnerability on multiple systems, emulate ransomware simulations or for any other reason if you want to run the same command on multiple hosts.
Commander can display pivoted networks in a graphical manner. The graph also displays Metadata of the selected Badger. You can view the graph by right clicking a listener and selecting Pivot Graph.
Listeners provide a functionality to query a bulk exit command which is called as Kill Switch. It can be activated on a listener by right clicking a listener and selecting Activate KillSwitch.
Activating Kill Switch will activate exit command for all active badgers. This will however not initiate exit for any new connection that checks in for the first time after activating the Kill Switch.
Webhook in Brute Ratel is a method of altering the behavior of a Brute Ratel listener with custom callbacks. These callbacks may be maintained, modified, and managed by operators of the BRc4. The BRc4 listeners support webhooks for all types of Badger comms. This can be enabled by right clicking a listener and selecting the ‘Webhook’ option.
Upon enabling a webhook, you will be asked to enter the https/http, host and the port as to where the Badger output should callback to. You can also specify whether to notify the operator via the callback, for only the initial Badger connections as notifications or the full command output of the Badgers.
The below figure shows how the callback for the initial connection and the output of commands look like post webhook is enabled. In the below figure, I enabled webhook for localhost on port 10443. So the listener will forward all the information on initial connection for all the Badgers and their command output to the respective webhook server. One thing worth noting is that the command output will be encoded in base64 inside json.
The Ratel server provides an option to build stages which are around 7-8kb depending upon the configuration of the malleable profile. These stages can be configured to autostop after a certain number of stages are downloaded from the listener, or can be stopped manually. Make note that staging is only supported over HTTP/S and all malleable profiles are supported. To enable staging, you can right click a listener and select Staging.
Similar to the badger, there are two types of stages that can be generated here. The default one which uses indirect syscalls and another ‘stealth’ payload which uses indirect syscalls alongside searching the PEB for loaded DLLs and proxying the loading of DLLs via other legitimate functions, if they are not found in PEB. The ‘stealth’ feature is only available for x64 payloads.
One of the issues found in the releases prior to v1.1 was that the shellcode of badger returned quickly after executing the reflective DLL which caused issues with tools like Macropack. This v1.1 release fixed that issue by providing three different exit methods i.e. return (default), RtlExitUserThread and WaitForSingleObject. The ‘WaitForSingleObject’ was specifically built to work alongside alertable threads where if you spawn an executable which returns quickly (eg.: werfault.exe or searchprotocolhost.exe), the shellcode doesn’t complete it’s execution. When you execute the badger’s shellcode, it spoofs the entrypoint of the stage and stack, executes the stage and then returns quickly. Only the spoofed thread runs in this case. However, if QAPC was used to execute the badger’s shellcode, and if the badger’s shellcode returned after executing the stage, QAPC resumes the main thread of the suspended process allowing it to exit. In order to avoid this issue, WaitForSingleObject was introduced which waits on the thread handle of the spoofed thread, so that the main thread does not resume when used with QAPC.
Listeners can be stopped by selecting Listener Actions->Stop Listener. Keep in mind that this will also remove all files hosted on this listener.
Authentication keys for listeners can be changed or viewed by right clicking the created listener and selecting Listener Actions->Change Authentication/View Authentication. If you select View Authentication, the keys would show up in cleartext in the Scratchpad.
Different types of files can be hosted on the Brute Ratel listener by right clicking a 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.
Hosted files can be viewed by selecting C4 Profiler->Hosted Files.
The payload generator menu provides a quick option to build payloads as per the configuration of the listener selected. The payloads generated here are connected to the profile name generated in the Payload Profiler. This means when you create a listener, say under the name ‘my-https-listener’, then a payload profile will be auto-generated in the Payload Profiler under the name ‘auto-my-https-listener’. This profile will always be linked to the listener. This means if you make any changes to the profile while the listener is active, and if you try to build a payload by right clicking the listener, it will generate the payload as per the configuration of the modified profile. In short, if you want to make any changes to the payload’s configuration after a listener has been created, you can modify that from C4 Profiler->Payload Profiler.
A detailed information on the differences between the payloads were mentioned in the v1.1 release.