A new Domino Backdoor popped out at the beginning of 2023. Since February, a new malware family coined Domino is used for attack on corporations, having Project Nemesis stealer as a final payload. Analysts say that the new backdoor is controlled and developed by ex-TrickBot/Conti actors and hackers related to the FIN7 group.
Who are Conti and FIN7?
First of all, let’s explain why the presence of actors from FIN7 and the ceased Conti gang is so noteworthy. FIN7 is a cybercrime gang that likely operates from Russia and Ukraine. It is also known under the names of Carbanak (after the backdoor they use), ITG14 and ALPHV/BlackCat. They are most notorious for collaborations with widely-known threat actors, like Ruyk and REvil ransomware, and the release of their own ransomware, called ALPHV. It is still running, and had a couple of noteworthy attacks the past year.
Conti is a similar and different story simultaneously. They have built their image around an eponymous ransomware sample. Same as FIN7, this group of cybercriminals consists of actors from ex-USSR countries. However, the start of the war in February 2022 led to a quarrel among the group’s top-management and further publication of its source code. That, eventually, led to the group’s dissolution. Previous to these events, Conti was a prolific ransomware gang with a major share on the market.
Their collaboration is an expected thing. Nature abhors a vacuum, so after the gang breakup its members promptly joined other groups, or started new ones. However, the collaboration with other gangs on the creation of brand-new malware is a pretty outstanding case. That may be a great start of a new character on the scene, a new threat actor, or just a powerful boost to the FIN7 gang.
Domino Backdoor Description
Domino is a classic example of a modern backdoor that is capable of malware delivery. It is noticed for spreading a separate malware dropper, coined Domino Loader. The former provides only remote access to the targeted system, while the latter serves for malware deployment. This duo is spotted for being used in a pretty unique multi-step malware spreading campaign.
Dave Loader is a classic dropper malware example – the one which serves only to deliver other malware. Its presence in this scheme, however, gives an interesting clue about the possible relations between Domino and Conti ransomware gang. The infection proceeds with the delivery of Domino backdoor and, in a quick succession, its dropper module. Then, at the final stage, Domino drops a Project Nemesis stealer. The latter aims generally at credentials from social networks, VPN clients and cryptocurrency services.
Why, Exactly, a Collaboration?
The key things that point to the fact that Domino backdoor is a collaboration rather than a stand-alone development is the use of Dave Loader as a delivery way, and sharing certain code elements with FIN7’s brainchild Lizar Malware. Dave is an internal product of Conti gang, used exclusively in its cyberattacks. It never leaked, contrary to the Conti ransomware code, thus there’s no way that a third party uses it. Lizar Loader a.k.a Tirion/DiceLoader, on the other hand, is an auxiliary malware used by FIN7. Domino malware shares major parts of code with this loader, including bot ID generation and data package encryption mechanisms. Moreover, the IPs range where Domino’s command servers are hosted is pretty close to the one FIN7 uses for their C2s; both ranges belong to MivoCloud hosting.
Domino Backdoor & Loader Analysis
Analysts from IBM Security Intelligence already got their hands on Domino samples, both backdoor and dropper. First things first – so let’s start from a backdoor.
It arrives to the infected system as a C++ 64-bit DLL file. The form of DLL file makes it easier for crooks to perform a stealth execution. Droppers Domino generally rely on running it using the shellcode embedded into the payload retrieved from the command server. Once executed, Domino starts hashing the system data in order to generate a bot ID value. Primarily, it looks for username and system name; additionally, malware takes its process ID and adds it to the hash. Its final form looks like a648628c13d928dc-3250.
Hashing proceeds with further decryption of the Domino’s code. It carries an XOR-encrypted code in a data section of its binary; the 16-bit decryption XOR key is placed right before this section. This part contains not only further execution instructions, but also C2 communication data.
To secure the data transfer, it generates a 32-bit key and uses an embedded RSA public key to encrypt it. This, however, is used only for an initial connection. After that, malware continues with collecting information about the system. For further C2 connections, the malware uses the AES-256-CBC key, which also comes into the initial package. Same as in the first case, Domino generates a public key on the run and uses it to cipher the data package.
It is also interesting how Domino backdoor picks the C2 address it will use as primary. By design, there are only two C2 addresses in the malware configuration section. If the parent system for the malware belongs to a domain (i.e. LAN or WAN), it uses the second IP as a primary. When the computer is stand-alone, Domino chooses the first one.
To guide the malware, C2 sends it a set of commands and a payload. Same as data that goes from the client, they are encrypted. Commands instruct not only about the action, but also about the preferred way to run the payload. The set of commands is like the following:
|0x1||Copy the payload in the allocated memory. The instructions about allocation are retrieved in 0x5/0x6 commands.|
|0x4||save the retrieved payload to the %Temp% folder. The name for the file is generated with GetTempFileNameA and CreateProcessA functions|
|0x5, 0x6||Instructs malware about allocating the memory for further payload deployment in a certain process.|
|0x7||Asks malware to enumerate the processes and send the output to the server. Precedes the 0x5/0x6, as it supplies the C2 with info about possible processes to use for injection.|
Domino Loader resembles the Domino Backdoor in many ways, so the naming convention there is quite obvious. This malware uses the same methods of C2 requests encryption. However, the amount of data gathered about the system is way less; its capabilities are concentrated around retrieving and running the payload’s DLL. It uses an infamous ReflectiveDLLInjection project – a concept of DLL injection technique. This, however, is not the only possible way of the Loader operations – it can change its behaviour depending on the command from the C2 that comes as a supplementary to a payload. It most definitely depends on the form the payload arrives in.
The commands convention is pretty much the same as in the Domino Backdoor. A single-byte blob that precedes the payload indicates what exactly the malware should do. Aside from that, the payload is succeeded with a value that notifies malware about the preferred method of loading. If the value is >0, malware allocates memory within the process it runs in, and runs the DLL payload at the offset that equals the value. That method, actually, requires the aforementioned ReflectiveDLLInjection technique.
Value 0 corresponds to running the payload as a .NET assembly. This supposes calling for VirtualAlloc for memory allocation, and a PAGE_EXECUTE_READWRITE for securing this area. Assembly.Load function finishes the job by making the payload run.
Once the value is -1, Domino Loader runs a PE loading procedure. First, it allocates memory in its current process – same as in the case of DLL loading. Then, however, it copies the headers and sections to the newly allocated memory area, loads the imports of the PE file, and finally runs it. In this case, malware applies the offsets present within the payload PE sections.
Protection against Domino Backdoor/Domino Loader
This malware is rare enough, so it is quite hard to judge on its counteraction ways. Nonetheless, they are definitely needed, as it promises to be pretty dangerous. First and foremost sources of such instructions – spreading ways – are unclear. It may possibly become more obvious in future when Domino will see more popularity. Thus now only common steps may have significant efficiency.
Use a security solution that features a zero-trust protection policy. Only having no trusted programs at all you can be sure that your security tool will not miss a new cunning malware that hides behind a benign program. Zero-trust has its downsides, but they’re much less critical than a paralysed workflow after a ransomware attack.
Improve your network security. This is Domino-specific advice, as this malware features a pretty limited list of only two C2 servers. It may be changed in future, but currently it is not a big deal to block them. This, however, will be much easier to accomplish by having a Network Detection and Response solution. It automatically weeds out potentially malicious requests, and also offers a lot of analytics information. Stopping malware from contacting the C2 makes it useless, as it cannot deliver payloads and do other unpleasant things.