Ex-Conti and FIN7 Actors Collaborate with New Backdoor

Dave Loader, which we have linked to the Trickbot/Conti syndicate and its former members.

Minodo’s code shows overlap with the Lizar (aka Tirion, Diceloader) malware family, leading us to suspect that it was created by current or former ITG14 developers.

One of Minodo’s final payloads is the Project Nemesis infostealer. Project Nemesis was first advertised on the dark web in December 2021, though has been rarely used since then.

Analysis

Ex-Conti members deploy Minodo in recent campaigns

Former members of ITG23 (aka the Trickbot/Conti syndicate) are likely behind recent campaigns using the Dave Loader to load Minodo Backdoor and probably collaborated with current or former ITG14 developers to purchase or use the new malware family. X-Force previously assessed that Dave is one of several loaders or crypters developed by members of the Trickbot/Conti group. Although the group has fractured, many of its loaders/crypters — including Dave — have been maintained and continue to be used by factions composed of former Trickbot/Conti members, including Quantum, Royal, BlackBasta, and Zeon.

• The Dave Loader has been used recently with several Cobalt Strike samples with the watermark “206546002,” which X-Force and other security researchers — here and here — have associated with groups composed of former members of the Trickbot/Conti syndicate, including Quantum and Royal. X-Force observed Dave-loaded Cobalt Strike samples using this watermark in suspected Royal attacks in fall 2022.
• Dave Loader has also been used this year to load IcedID and Emotet, both of which serve as initial access vectors for ransomware attacks from former Trickbot/Conti-affiliated factions.

Recently observed Dave samples were discovered loading a new malware, which we have named Minodo Backdoor. This new backdoor gathers basic system information, which it then sends to the C2, and in return receives an AES encrypted payload.

In most instances, the received payload was a second loader that was found to have code overlap with Minodo Backdoor, and as such we have dubbed it Minodo Loader. This loader contains an encrypted payload within its resources, which it decrypts using AES. The decrypted payload is a .NET infostealer, which identifies itself as ‘Nemesis Project.’

The Minodo Backdoor is designed to contact a different C2 address for domain-joined systems, suggesting a more capable backdoor, such as Cobalt Strike, will be downloaded on higher value targets instead of Project Nemesis.

Minodo’s connections to ITG14

Analysis revealed that both the Minodo Backdoor and Loader share code overlap with the Lizar Malware, also known as Tirion and DiceLoader, which is attributed to the threat group ITG14 (FIN7). In addition to having similar coding styles and functionality, both Minodo and DiceLoader share the same configuration structure and have similar bot ID formats. Lizar was reportedly first used in March 2020, when it was originally named Tirion, and has been observed in numerous ITG14 campaigns up to the end of 2022. Minodo has been active in the wild since at least October 2022, which notably is when Lizar observations began to decrease.

X-Force researchers found additional evidence connecting Minodo Backdoor to ITG14’s Carbanak Backdoor. We identified Minodo Backdoor samples from December 2022, which used a different loader that we have dubbed NewWorldOrder Loader. The samples used the name ThunderboltService.exe and downloaded and loaded the Project Nemesis Stealer.

Around the same time, we also uncovered NewWorldOrder Loader samples, with the same filename ThunderboltService.exe, used to load the Carbanak Backdoor. Carbanak has been used by ITG14 since late 2015.

Finally, X-Force analysts also observed that two of the Minodo Backdoor C2 addresses belonging to MivoCloud: 94.158.247[.]72 and 185.225.17[.]202 are very close to C2 addresses ITG14 has used previously for SSH-based backdoors such as 94.158.247[.]23 and 185.225.17[.]220. While such overlap is insufficient for attribution, it is nonetheless consistent with other evidence linking Minodo to an ITG14 developer and may indicate the latter’s preference for MivoCloud for at least some of their C2 addresses. MivoCloud has also been used to host Diceloader and Carbanak C2 servers.

Collaboration between members of ITG14 and former members of ITG23 is not without precedent. Other researchers — here and here — observed ITG14 attacks using Ryuk ransomware in 2020, which has been attributed to the Trickbot/Conti cybercrime syndicate, while others have also identified connections between a FIN7 developer and tools used by the BlackBasta group, whose members also have ties to the former Trickbot/Conti syndicate.

Project Nemesis

The Project Nemesis infostealer has been active in the wild since December 2021, when it was offered for sale on several Dark Web forums. It can collect data from a range of web browsers, as well as applications including Steam, Telegram, Discord, cryptowallets, and VPN providers.

Minodo has been used to install Project Nemesis since at least October 2022 — prior to its use in late February 2023 by ex-Conti actors. This leads us to assess that the ITG14 members responsible for developing Minodo probably had a relationship with Project Nemesis and offered Minodo and the infostealer to the ex-Conti threat actors as a package. The ex-Conti members in turn likely used the Project Nemesis infostealer against lower value targets.

The use of infostealers by former Trickbot/Conti members and their distributors is not without precedent — other security researchers observed the Vidar infostealer delivered during DEV-0569 Batloader campaigns that also led in some cases to Cobalt Strike and Royal ransomware. We assess that infostealers may often be deployed during lower priority infections, e.g., on personal computers or those not belonging to an Active Directory domain, while higher priority infections receive other backdoors such as Cobalt Strike.

Malware deep dive

This section contains a deeper look at the Dave Loader, Minodo Backdoor, Minodo Loader, and Project Nemesis Infostealer malware.

Dave loader

The sample analyzed for the purpose of this report is a 64-bit executable with MD5 hash 2CC79806701F1A6E877C29B93F06F1BB and a reported compile date of 28 February 2023. This sample is identified as a variant of Dave Loader, a crypter linked to threat group ITG23 and more commonly observed with payloads such as Emotet.

This sample has two encrypted resources within a resource directory named “XKLKLCRTE.” Dave Loader loads the resources using the API calls LdrFindResource_U and LdrAccessResource, and decrypts them using XOR and the key mh8ZqMlTsaDYBZe7max00.

The smaller payload, with resource ID 3412, is a shellcode blob that contains code designed to load a PE file. The second payload, with resource ID 6732, is a PE file. Dave Loader executes the decrypted shellcode and passes the PE payload to it, which the shellcode then loads and executes.

Minodo backdoor

The loaded payload is a 64-bit DLL written in Visual C++, with MD5 hash CDBE0FEB82B1CAF164C7DA42CB9A20BE. The payload was found to be a hitherto unknown backdoor, which will be referred to as Minodo Backdoor.

Upon execution, Minodo Backdoor starts by generating a Bot ID for the infected system by gathering the username and hostname and creating a hash of the collected data, to which it then appends its current process id. For example, a648628c13d928dc-4480. This bot ID format is similar to that generated by Lizar, which also used a checksum of system information, combined with the process ID. However, Lizar used a CRC algorithm to create its hash, whereas Minodo uses a custom algorithm which XOR’s multiple values together. Interestingly, Lizar used a similar XOR-based algorithm as part of its encryption mechanisms during communication with the C2.

Fig 1 — Minodo Backdoor system ID generation

The malware then proceeds to decrypt its configuration block, which is stored in the data section of the binary. The config is decrypted using XOR and a 16-byte key which is stored immediately before the encrypted config block. In this case the key is {03 9B 54 72 17 D3 5E E6 E0 E9 EF E0 DF 36 0D 79}.

Fig 2 — Minodo Backdoor config decryption

In the analyzed sample the decrypted config contains two pipe-delimited IP addresses, 88.119.175[.]124 and 94.158.247[.]72. This is the same format used by Lizar to store its configuration.

Scroll to view full table

A second config block, which is decrypted separately, contains an RSA public key.

The malware generates a random 32-byte key, which it encrypts using the RSA key. It then attempts to connect to the C2 via TCP port 443 and send the encrypted key. Prior to the C2 connection, the malware checks whether the host system is connected to a domain. If the system is detected as being domain joined, then the malware uses the second IP address from the config to connect to the C2, otherwise, it defaults to the first.

If the initial connection is successful, the malware then proceeds to gather basic system information, including username, computer name, and OS version, which it then encrypts using AES-256-CBC and the generated, shared key (null bytes used for IV).

An example of the unencrypted data structure, which the malware sends to the C2, can be seen below.

Scroll to view full table

This structure breaks down as follows:

Scroll to view full table

The malware first sends 4 bytes to the C2 that contain a XOR-encrypted value, which is the size of the data to follow, and then sends the AES-encrypted system data.

The malware then begins a loop of checking in with the C2 by first sending a 4-byte encrypted size, followed by a 16-byte AES-encrypted block, which decrypts to the following 5 bytes {01 00 00 00 ff}. It continues this every second until it receives a response from the C2.

When it receives a response, the malware expects the C2 to send 4 bytes containing the payload size, followed by the payload itself. The malware then decrypts the received payload using AES and the shared key.

The decrypted data consists of a 4 byte size, followed by a single byte indicating either a command or the load method that the malware should use for the payload, followed by the payload data itself, if applicable.

If the command byte is 0x3, then the malware exits.

If the command byte is 0x7, then the malware enumerates the running processes on the system and compiles a list of process names and IDs. This data is then encrypted using AES and returned to the C2.

Otherwise, the malware proceeds to load and execute the received payload using the method indicated by the load/command byte. The following methods are supported:

• 0x1 — Copy the payload into allocated memory within the current process and create a new thread to execute an export named ReflectiveLoader within the payload DLL.
• 0x4 — Save the payload to the %Temp% directory with a filename generated via GetTempFileNameA, and execute the file using CreateProcessA.
• 0x5, 0x6 — Open process with process id provided with the downloaded data. Allocate space within the process and write the payload data to the process memory. Then create a new thread in the remote process to execute an export named ReflectiveLoader within the copied payload DLL. This method is likely intended to be used following command 0x7.

In the case of the analyzed sample, the received payload contained a DLL binary, and command 0x1 was specified.

Fig 3 — Minodo Backdoor command structure

Overlap with Lizar toolkit

Minodo Backdoor shares a lot of overlap with malware associated with the Lizar Toolkit, which is attributed to threat group ITG14. The Lizar Toolkit consists of a backdoor/loader, a collection of modules/plugins which can be executed by the loader, and C2 client and server applications. A detailed report on the Lizar Toolkit can be found here.

In addition to having similar coding styles and utilizing similar API calls, Minodo Backdoor uses the same configuration structure as the Lizar Loader. In both cases, a configuration block containing a pipe-delimited list of IP addresses is decrypted using XOR and a 16-byte key which is stored immediately before the encrypted config.

Both malware families also generate system IDs in very similar manners. In the case of Minodo Backdoor a hash is generated from the system username and hostname and the process ID is appended. For example, a648628c13d928dc-4480. The hashing algorithm is custom and appears to be based on an encryption algorithm used previously in the Lizar Loader.  Lizar Loader also generates a system ID which consists of a hash of system data followed by the current process ID, however, it uses a CRC algorithm to create its hash.

Minodo Backdoor also incorporates elements that appear in some of Lizar’s plugins. For example, the system information gathered by Minodo Backdoor and sent to the C2 matches the reported functionality of Lizar’s Info32/Info64.dll plugin. Also, the function within Minodo Backdoor to enumerate running processes and send a list of process names and IDs back to the C2 is very similar to the functionality of Lizar’s ListProcesses32/ListProcesses64.dll plugin.

Finally, Lizar’s Jumper32/Jumper64.dll plugin resembles the code within Minodo Backdoor, which is able to load a payload using several different methods, with the required one specified using a command ID number.

Minodo loader

The payload received by the Minodo backdoor from the C2 during this analysis was a 64-bit DLL, written in C++, with MD5 hash 2373BE26018075847AEA51636B739F66 and an internal filename of MultiRunDll64.dll. The payload was found to be a Loader with similarities to Minodo Backdoor, and will be referred to as Minodo Loader.

Minodo Loader has one export named ReflectiveLoader that contains code taken from the well-known ReflectiveDLLInjection project. When run, this code performs the steps needed to properly load the DLL into memory, and allows for DLL payloads to load themselves directly from memory into a host process.

Once loaded, Minodo Loader starts by loading an encrypted payload from its resources and decrypting it using AES-256-CBC and a hardcoded key. The Microsoft WinCrypt library is used for AES encryption and decryption by both Minodo Backdoor and Loader.

The decrypted data consists of 4 bytes containing the payload size, followed by a further 4 bytes containing either the entry point offset for the payload or a value indicating the load method which should be used, followed by the payload itself.

If the entry point/load field contains a positive value, then the loader allocates memory within the current process space, copies the payload data to it, and then executes it at the specified offset indicated by the field value. This option is most likely used for shellcode payloads or further DLLs with ReflectiveLoader exports.

If the value of the load field is -1 then the loader allocates memory within the current process and then loads the PE payload into it using the full PE loading procedure. It copies the headers, maps the individual PE sections,  processes any relocations,  loads the PE’s imports, and then executes the PE from its internally specified entry point.

Finally, if the load field is equal to zero or another negative number, the payload is loaded as a .NET assembly.

Nemesis project infostealer

The final payload loaded by Minodo Loader is a .NET assembly with MD5 hash D9FFB202D6B679E5AD7303C0334CD000 and identified as a ‘Project Nemesis’ infostealer. Project Nemesis is a commodity malware written in .NET which was first advertised for sale on the dark web in December 2021, though it does not seem to be widely known and it is not frequently observed in the wild.

The sample was initially advertised with the following text:

Scroll to view full table

Data collected by Nemesis can be accessed by the operator via a web-based control panel.

Fig 4 — Nemesis Control Panel Login Screen

Fig 5 — Nemesis Dashboard

Static analysis

Upon execution Nemesis starts by creating a mutex to ensure only one instance of the malware is running: Local751E355F-B066-4547-B13E-B185D9176390

The malware keeps a log of its activity, mostly written in the Russian language, and the following is written upon its startup:

Scroll to view full table

Fig 6 — Nemesis Start-up Code

Nemesis then immediately proceeds with infostealing activities, and collects the following data in order:

1. Chromium-based browsers: Steals stored credentials, cookies, credit cards, bookmarks, autofill data, and history.
   Browsers include:
   “ChromiumUser Data”,
   “GoogleChromeUser Data”,
   “Google(x86)ChromeUser Data”,
   “Opera Software”,
   “MapleStudioChromePlusUser Data”,
   “IridiumUser Data”,
   “7Star7StarUser Data”,
   “CentBrowserUser Data”,
   “ChedotUser Data”,
   “VivaldiUser Data”,
   “KometaUser Data”,
   “Elements BrowserUser Data”,
   “Epic Privacy BrowserUser Data”,
   “MicrosoftEdgeUser Data”,
   “uCozMediaUranUser Data”,
   “Fenrir IncSleipnir5settingmodulesChromiumViewer”,
   “CatalinaGroupCitrioUser Data”,
   “CoowonCoowonUser Data”,
   “liebaoUser Data”,
   “QIP SurfUser Data”,
   “OrbitumUser Data”,
   “ComodoDragonUser Data”,
   “AmigoUserUser Data”,
   “TorchUser Data”,
   “YandexYandexBrowserUser Data”,
   “ComodoUser Data”,
   “360BrowserBrowserUser Data”,
   “Maxthon3User Data”,
   “K-MelonUser Data”,
   “SputnikSputnikUser Data”,
   “NichromeUser Data”,
   “CocCocBrowserUser Data”,
   “UranUser Data”,
   “ChromodoUser Data”,
   “Mail.RuAtomUser Data”,
   “BraveSoftwareBrave-BrowserUser Data”
2. Gecko-based browsers: Steals stored credentials, cookies, bookmarks, and history.
   Browsers include:
   “MozillaFirefox”,
   “ComodoIceDragon”,
   “MozillaSeaMonkey”,
   “Moonchild ProductionsPale Moon”,
   “Waterfox”,
   “K-Meleon”,
   “Thunderbird”,
   “8pecxstudiosCyberfox”,
   “NETGATE TechnologiesBlackHaw”
3. CryptoWallet data from browser extensions MetaMask, TronLink, and Binance
4. Clipboard data

The following data collection tasks are then all set to run in parallel.

1. CryptoWallets on disk from apps including: Electrum, Electrum-Dash, Ethereum, Exodus, Atomic, Jaxx, Coinomi, Guarda, Armory, Zcash, Bytecoin
2. System info, including both hardware and OS info.
3. Enumerates running processes
4. Enumerates IDs from Steam application
5. Enumerates files under Steam application directory
6. Gets a list of installed browsers by looping through entries under registry key SOFTWAREClientsStartMenuInternet and SOFTWAREWOW6432NodeClientsStartMenuInternet, and then recording the contents of subkey shellopencommand for each.
7. Enumerate files on desktop
8. Discord Tokens
9. FoxMail data
10. DynDNS credentials
11. FileZilla connection credentials + hosts.
12. NordVPN credentials
13. OpenVPN files
14. KerioVPN files
15. Proton VPN credentials
16. User-agents
17. Pidgin credentials
18. Telegram data files
19. Telegram portable files
20. RDP connection files (.rdp)

The malware then collates all the data and adds it to a Zip archive which it then transfers back to the C2.

Fig 7 — Nemesis waits for data collection tasks to complete, then adds the data to a zip archive to be sent to the C2

Fig 8 — Nemesis uploads data to the C2 via a HTTP POST request

The C2 address for the analyzed sample is https[:]//es-megadom[.]com

Fig 9 — Nemesis Configuration

A tangled web provides opportunities

This analysis highlights the intricate relationships between cyber criminal groups and their members. Minodo Backdoor shares code overlap with the Lizar (aka Tirion, Diceloader) family of malware, developed by ITG14. Since late February 2023, former members of ITG23 have been observed using Dave Loader with Minodo Backdoor during their campaigns, suggesting at least some level of collaboration between the two groups. The use of malware with ties to multiple groups in a single campaign — such as Dave Loader, Minodo Backdoor and Project Nemesis Infostealer — highlights the complexity involved in tracking threat actors but also provides insight into how and with whom they operate.

Indicators of compromise

Scroll to view full table

Continue Reading