Active since 2016, Trickbot is one of the most prevalent modular banking trojans. The botnet’s modules carry out objectives such as credential harvesting, propagating via the network, web injection and others. Being an actively developed botnet, we often come across updated modules and in some cases new tools that are added as part of its arsenal.
Recently we have discovered a relatively new module that goes by the name
masrv. The module is a network scanner that incorporates the Masscan open-source tool. Additionally, the module contains an unreferenced Anchor C2 communication function and a list of hardcoded IPs which have previously been associated with Anchor and Bazar 12.
We believe this module is used as one of Trickbot’s network reconnaissance tools to gather more information about the victim’s network.
The masrv module
The module arrives as either a 32-bit or 64-bit DLL, depending on the Windows OS version of the victim machine the bot is running on. Both DLLs we observed are debug builds and log their execution into standard output.
As with other Trickbot modules, the module is executed via its export functions
Commands for the Module’s C2
The module makes requests to the C2 to receive information that it requires to pass as parameters to Masscan.
|freq||GET||Get frequency for running Masscan|
|domains||GET||Get a List of IP address ranges followed by port range|
|over||GET||Signal to the C2 that scan is complete|
|rate||GET||Get rate value for transmitting packets|
|npcap.exe||GET||Get Nmap’s packet sniffing library installer|
The URI construction for the GET requests follows this format:
At the time of researching this module, we were unable to pull down the config associated with
masrv. So, in order to observe a dynamic run, we have implemented a mock server on
localhost at port
8080, to be able to feed responses back to the module. Below is an example of one of the GET request being made for the command
Network capture of the Module traffic
At first, the module makes GET requests for information from the commands
rate. If successful, the module executes Masscan’s main function routine which is compiled within the DLL. Below we can see the execution result of the log from standard output. The date mentioned in the logs is that of when the module was compiled.
The Masscan tool has its own network stack and doesn’t rely on that of the OS. In order for it to be able to retrieve the results, Masscan requires a low-level packet filter and on a Windows OS it attempts to load
Packet.dll doesn’t exist, then the module makes a request to download the
NPcap executable from the C2.
NPcap is silently installed on the machine by passing the parameter
/S. It gets executed by invoking
ShellExecuteExA (if the first API is unsuccessful).
The Masscan tool also attempts to initialize the network adapter. If the tool fails to detect any interface, a module-specific function is called that tries to get a MAC address from the ARP table, to pass to Masscan as
--router-mac <mac>. For each ARP entry in the
MIB_IPNETTABLE5, the module finds the corresponding index of the IPv4 entry in the
MIB_IPADDRTABLE6. It leverages the APIs
GetIpAddrTable respectively to retrieve this information. If successful, it gets the dotted-decimal format of the IPv4 address and logs the results of the
ping command that is run on the target
18.104.22.168 from that IPv4 address. If the ping ran successfully, the module gathers the ARP type information and logs the ARP entry of the IPv4 address. Then it queries for the MAC address from the
MIB_IPNETROW entry. Below is an example of the
The module sends results from the Masscan run if it has discovered open ports on any of the IP ranges that were provided. Results are aggregated by calling a module-specific function from the Masscan function
output_report_status which adds discovered ports to a global string. These results are posted back (via the
81 message) regularly, with the frequency, in seconds, determined by the
freq value queried at the beginning.
Both the 32-bit and 64-bit DLLs have an unreferenced function that share similarities to Anchor’s C2 communication subroutine. It is not uncommon for this actor to be seen sharing code between its toolset. Additionally, this function references a list of hardcoded IPs from the binary which have previously been associated with both Anchor and Bazar.
This content was originally published here.