By Juan Andres Guerrero-Saade, Amitai Ben Shushan Ehrlich, and Aleksandar Milenkoski
The term ‘Magnet of Threats’ is used to describe targets so desirable that multiple threat actors regularly cohabitate on the same victim machine in the course of their collection. In the process of responding to a series of tangled intrusions at one of these Magnets of Threats, SentinelLabs researchers encountered an entirely new threat actor. We dubbed this threat actor ‘Metador’ in reference to the string “I am meta” in one of their malware samples and the expectation of Spanish-language responses from the command-and-control servers.
Our research on Metador was presented at the inaugural LABScon in Arizona. In this post, we offer a short summary of our full findings, which include a detailed report, threat indicators, and an extensive Technical Appendix.
The Magnet of Threats in question contained a redundant layering of nearly ten (10) known threat actors of Chinese and Iranian origin, including Moshen Dragon and MuddyWater. Among them, we noticed the use of an unusual LOLbin, the Microsoft Console Debugger
cdb.exe. CDB was the root of an intricate infection chain that would yield two in-memory malware platforms and indications of additional Linux implants.
The intrusions we uncovered were located primarily in telcos, ISPs, and universities in the Middle East and Africa. We believe that we’ve only seen a small portion of the operations of what’s clearly a long-running threat actor of unknown origin.
Throughout our analysis, we retrieved and analyzed examples of two different malware platforms used by Metador–‘metaMain’ and ‘Mafalda’. These Windows-based platforms are intended to operate entirely in-memory and never touch disk in an unencrypted fashion, eluding native security products and standard Windows configurations with relative ease. The internal versioning of Mafalda suggests that this platform has been in use for some time, and its adaptability during our engagement alone highlights active and continuing development.
We also found indications of additional implant(s):
Part of the difficulty in tracking the breadth of Metador’s operations involves their strict adherence to infrastructure segmentation. The attackers use a single IP per victim and build.
Attributing Metador remains a garbled mystery. We encountered multiple languages, with diverse idiosyncrasies indicative of multiple developers. There are indications of a separation between developers and operators, and despite a lack of samples, the version history for at least one of the platforms suggests a history of development that extends far beyond the intrusions we’ve uncovered.
The Magnet of Threats in question deployed our XDR solution after they’d been infected by Metador for several months. As such, we have no indication of the original infection vector employed in this or other infections.
Once on the target, the Metador operators can choose between multiple execution flows to load one or more of their modular frameworks. The execution flow used on our Magnet of Threats combines a WMI persistence mechanism with an unusual LOLbin in order to kick off the decryption of a multi-mode, in-memory implant we named ‘metaMain’.
metaMain is a feature-rich backdoor, but in this case the Metador operators used the metaMain implant to decrypt a subsequent modular framework called ‘Mafalda’ into memory.
Mafalda is a flexible interactive implant, supporting over 60 commands. It appears to be a highly-valuable asset to the Metador operators, with newer variants exhibiting intense obfuscation making them challenging to analyze.
metaMain is an implant framework used to maintain long-term access to compromised machines. It provides operators with extensive functionality, like keyboard and mouse event logging, screenshot theft, file download and upload, and the ability to execute arbitrary shellcode.
The backdoor is keenly aware of its own execution context and runs in one of two modes as a result. The developers designate these modes by writing out either “I am meta” or “I am main” to a log. We chose to name the platform ‘metaMain’ in reference to these two modes.
metaMain supports multiple start_method’s (i.e., execution flows), with the backdoor’s operations differing slightly per method. The methods supported are CDB_DEBUGGER, HKCMD_SIDELOADING, and KL_INJECTED. We briefly describe CDB_DEBUGGER below, the execution flow seen on our Magnet of Threats. A fuller description of this and additional start_methods, configuration artifacts, and supported commands are available here.
As the name suggests, this execution scheme relies on CDB, the Microsoft Console Debugger, to carry out the execution process. Within this method, there are two possible variations based on whether the implant is invoked in meta- or main-mode. We witnessed its use in meta-mode, turning the metaMain implant into a glorified loader for a Mafalda implant.
In this case, metaMain’s persistence relies on the abuse of WMI Event Subscriptions. The operators register an event consumer named
Five to six minutes after booting up, the event triggers the execution of a LOLbin,
The attackers used the following command line:
cdb.exe -cf c:\windows\system32\cdb.ini c:\windows\system32\defrag.exe -module fcache13.db
A debugging script,
cdb.ini, is used to inject a small amount of shellcode into the debugged process in order to load metaMain. The shellcode reads, decrypts, and executes metaMain’s reflective DLL Loader from
c:\windows\system32\Speech\Speech02.db. The DLL’s sole purpose is to then read, decrypt, and load the metaMain orchestrator, stored as
When invoked in meta-mode, metaMain serves as a loader for the payload provided as an argument following
-module. In our observed case, the executed module was
fcache13.db, an encrypted Mafalda payload.
The Mafalda implant extends the backdoor functionalities that metaMain provides and is an actively maintained, ongoing project. We observed two variants of the Mafalda backdoor::
The newer Obfuscated Mafalda variant extends the number of supported commands from 54 to 67 and is rife with anti-analysis techniques that make analysis extremely challenging.
Interestingly, we noted that Mafalda prints encrypted debugger messages if the name of the host is WIN-K4C3EKBSMMI, possibly indicating the name of the computer used by the developers.
If Mafalda successfully establishes a connection to the C2 server, it builds and sends an initial packet containing information about the host environment and the version of Mafalda being run. Mafalda then executes in a loop, exchanging packets with the C2 server.
Each packet is of a given type and subtype, uniquely identified by identification numbers, internally refered to as
outer OPC and
inner OPC, respectively:
The Mafalda backdoor has a total of 67 commands, with 13 of these added in the newer variant, indicating that the Mafalda implant is a maintained, ongoing project.
The full unobfuscated list of commands, along with the developer’s descriptions, are available from our full report. Some of the more interesting commands only available in the newer Mafalda variant include:
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Local State
and sends the content to the C2 with a name prefixed with
The functionalities of the backdoor commands have a very broad scope and include credential theft, data and information theft, command execution, system registry and file system manipulation, and Mafalda reconfiguration.
When the TCP KNOCK communication method is enabled, the metaMain and Mafalda implants can establish an indirect connection to the C2 server through another implant. On Windows systems, this implant is internally referred to as ‘Cryshell’. metaMain and Mafalda authenticate themselves to Cryshell through a port-knocking and handshake procedure.
Mafalda also supports retrieval of data from Linux machines with another implant that sends data to the C2 as part of a packet with a name prefixed with
loot_linux\. Though it’s possible that this unnamed Linux implant and Cryshell are the same, Mafalda authenticates itself to the Linux implant through a different port-knocking and handshake procedure.
In all Metador intrusions we’ve observed, the operators use a single external IP address per victim network. That IP is utilized for command-and-control over either HTTP (metaMain, Mafalda) or raw TCP (Mafalda). In all confirmed instances, the servers were hosted on LITESERVER, a Dutch hosting provider.
In addition to HTTP, external Mafalda C2 servers also support raw TCP connections over port 29029. We also observed some of Metador’s infrastructure host an SSH server at an unusual port. While SSH is commonly used for remote access to *nix systems, we find it hard to believe that a mature threat actor would expose their infrastructure in such a way. Instead, it’s likely those were used to tunnel traffic through Mafalda’s internal portfwd commands.
We were able to identify one additional server we believe is operated by Metador actors, also hosted on Liteserver –
5.2.78[.]14. This IP hosts what appears to be a malicious domain,
networkselfhelp[.]com, which might have been used as a C2 for Metador intrusions. If so, it’s an indication that Metador operators not only utilize IPs for their intrusions, but also domains.
The limited number of intrusions and long-term access to targets suggests that the threat actor’s primary motive is espionage. Moreover, the technical complexity of the malware and its active development suggest a well-resourced group able to acquire, maintain and extend multiple frameworks.
Metador was observed mainly in Telecoms, Internet Service Providers (ISP), and Universities in the Middle East and Africa, and appears intended to provide long-term access in multiple redundant ways.
Mafalda internal documentation suggests the implant is maintained and developed by a dedicated team, leaving comments for a separate group of operators.
Running into Metador is a daunting reminder that a different class of threat actors continues to operate in the shadows with impunity. Previous threat intelligence discoveries have broadened our understanding of the kind of threats that are out there but so far, our collective ability to track these actors remains inconsistent at best. Developers of security products in particular should take this as an opportunity to proactively engineer their solutions towards monitoring for the most cunning, well-resourced threat actors. High-end threat actors are thriving in a market that primarily rewards compliance and perfunctory detections.
From the perspective of the threat intelligence research community, we are deeply grateful for the contributions of the research teams and service providers who have willingly shared their expertise and telemetry for this research.
We hope that this publication will incentivize further collaboration and provide us with answers to the mystery of Metador, and to that end we urge interested researchers to read the full version of this report, where a list Indicators of Compromise can also be found, and its extended Technical Appendix.