From RM3 to LDR4: URSNIF Leaves Banking Fraud Behind

Written by: Sandor Nemes, Sulian Lebegue, Jessa Valdez

A new variant of the URSNIF malware, first observed in June 2022, marks an important milestone for the tool. Unlike previous iterations of URSNIF, this new variant, dubbed LDR4, is not a banker, but a generic backdoor (similar to the short-lived SAIGON variant), which may have been purposely built to enable operations like ransomware and data theft extortion. This is a significant shift from the malware’s original purpose to enable banking fraud, but is consistent with the broader threat landscape.

Mandiant believes that the same threat actors who operated the RM3 variant of URSNIF are likely behind LDR4. Given the success and sophistication RM3 previously had, LDR4 could be a significantly dangerous variant—capable of distributing ransomware—that should be watched closely.

Brief History

Being one of the oldest banking malware families still active today, it is no surprise that there is a long and adventurous history behind URSNIF (aka. Gozi or Gozi/ISFB), which is sometimes intertwined with other malware families and variants. Its source code was leaked at least twice since the first major version appeared in 2016, resulting in other variants, from which multiple are still in circulation today (e.g., IAP). This means neither Gozi nor URSNIF is a single malware family, but more like a set of related siblings (usually called variants). Most researchers today have standardized on the malware family name Gozi, but for mainly historical reasons, other researchers and vendors—including Mandiant—still reference these variants as URSNIF (the older malware from which Gozi originated from back in the mid-2000s with Haxdoor) or even ISFB (which is technically the latest living branch of this banking malware family). Just to make things clear, we use URSNIF (capitalized, according to Mandiant’s naming scheme) throughout this blog post when referring to the current variants that are still active today.

In recent years, multiple variants of URSNIF, based on ISFB, have been observed in the wild including:

• Dreambot – One of the most successful variants
• IAP – The most actively developed and distributed ISFB branch with frequent malware campaigns coming from CUTWAIL and targeting Italy
• RM2 – Also widely known as GoziAT, started its activity years ago with the Chanitor malware (aka Hancitor)
• RM3 – Due to its custom executable file format, it is the most sophisticated version to date, which has mostly impacted Oceania and UK since 2017

As of writing this, our research indicates ISFB might be the last and only active branch of the infamous URSNIF banking malware. Over the past three years, this banking malware has seen some interesting changes, which suggest a major paradigm shift and that the entire project was redesigned.

From a malware developer’s perspective, it is a complicated task to provide updates for so many different projects (or forks in this case), which inevitably leads to dead-ends and mistakes. Mandiant believes that IAP 2.0 & RM2 builds over version 2.50.000 and RM3 builds over version 3.00.700 focused on removing unnecessary features and merges all forks and development branches into a single main branch. Some of the notable changes intended to support this unification effort include

• The RSA public key is now encrypted with a very specific embedded decryption key, and this has been progressively pushed into all variants
• AES encryption replaced the older Serpent encryption
• Merging and simplification of fields in the beacon requests

The year 2020 was highly unsuccessful for the RM3 variant, with decreasing reliable distributions and multiple backends that collapsed (mostly in Europe). Furthermore, this specific variant failed to take the opportunity to grow its popularity to obtain market share with the disruption of TRICKBOT and EMOTET. One of the greatest winners of this was the ICEDID malware family, which managed to leverage the shrinking competition on the banking malware landscape, putting RM3 into a difficult situation. It was extremely unusual for URSNIF’s ISFB variant to not receive any updates after June 2020, thus some researchers hypothesized that the only way for this banking malware to return was to do some major refurbishing on its code. In June 2022, with Internet Explorer finally being fully removed from Microsoft Windows, the RM3 variant was officially seen as a “dead” malware from a technical point of view, as RM3 was reliant on this browser for some of its critical network communication.

Distribution

Mandiant first observed LDR4 in the wild on June 23, 2022, via a recruitment related lure, resembling RM3’s distribution reported back in April 2021 (Figure 2). The email contains a link to a compromised website that redirects to a domain masquerading as a legitimate company (Figure 3). A CAPTCHA challenge is presented to download an Excel document purported to contain information related to the email lure (Figure 4 and Figure 5). This document then downloads and executes the LDR4 payload. A similar chain leading to LDR4 was later observed but with a lure pertaining to an accounting software instead (Figure 6).

In addition to HR/recruitment, Mandiant also observed RM3 in the more conventional payment/invoice lures that leverage XLM 4.0 macros in Excel document attachments to download the payload. In April 2022, we observed its last distribution via UNC2420 as a downloaded payload of the MOTEISLAND document. Mandiant tracks UNC2420 as a distribution threat cluster that uses malicious Microsoft Word documents as attachments in campaigns using subjects that appear to be replies to legitimate email chains.

Static Analysis

The LDR4 variant appears as a DLL module on the infected computer, which is invoked via the DllRegisterServer function, but there are often other randomly named decoy functions exported to confuse sandboxes. Some of the binaries were using valid code-signing certificates (e.g., NAILS UNLIMITED LIMITED and ANGOSTONE GROUP LTD LIMITED). The binaries can have either a 32-bit or 64-bit architecture and are packed with various PE crypters. One of the crypters, tracked by Mandiant as SPELLBOOK, has an interesting property that it leaves the signature “|SPL|” in memory after unpacking the core malware. We identified overlaps in the usage of this crypter between URSNIF LDR4 and SNOWCONE.GZIPLOADER (ICEDID’s loader component). The unpacked core for the analyzed URSNIF LDR4 sample has the internal name LOADER.dll.

URSNIF LDR4 is a mix of code refactoring, regressions and interesting simplification strategies.

We made the following major observations:

1. The PX era is now over.
   The LDR4 variant no longer uses the custom PX executable format, that was first introduced by the RM3 variant. We believe this choice was made to avoid overcomplicating the troubleshooting of software issues. From a developer’s point of view, spending more time that is supposed into some superficial layer of issues and refocusing into more important pipelines of requested features are crucial for your reputation. Equally important, given the notoriety of the PX format among analysts and AV/EDR products, it was only a matter of time for that path to come to an end. From the attacker’s perspective, investing in a product that everyone knows how to detect, is not a very efficient use of resources, so going back to the roots with a classic PE format is in fact a rational choice on their side.

2. FJ.exe gone or reworked?
   Since the beginning of ISFB, a steganography tool called FJ.exe (File Joiner) is used for hiding multiple files into a single payload. This one isn’t unique to ISFB but forked from another notorious banking malware called CARBERP. By comparing the code of those two, there are no doubts this same program is used in both.

FJ.exe is the tool responsible for creating the JJ, J1, J2, or WD fields on URSNIF payloads based on the variant. But in LDR4 those magic bytes are missing, and the hidden files usually hardcoded at the end of the payload are now gone.

• LDR4 is a backdoor.
  URSNIF is the latest malware following the same path that EMOTET and TRICKBOT did before, by focusing into a new strategy and leaving behind its banking fraud legacy. LDR4 is the proof of that statement by removing all its banking malware features and modules and only focusing into getting VNC and/or remote shell into the compromised machine.

Obfuscation

It is a common practice in offensive software operations to apply some sort of obfuscation to the code itself or at least to API calls to thwart analysis efforts. URSNIF historically did not use this (except for the outermost crypter layer used for AV evasion). However, this new LDR4 variant incorporated obfuscation for the Windows API calls. First, it builds a hash lookup table from the export names and addresses of the Windows modules used by the malware (kernel32, ntdll, crypt32, advapi32, ws2_32), that maps the JAMCRC32 checksum (JAMCRC32 is the modification of the regular CRC32 algorithm, where all the bits of the final checksum are flipped) of the function names to their respective virtual addresses in memory. Later in the code, any invocation to the Windows API functions will just look up the checksum value in the table to quickly retrieve the function address. Apart from this, no further code obfuscation is leveraged in the compiled binaries, making LDR4 a relatively easy family to reverse engineer.

Behavior

One of the most noticeable things during analysis was that the developers had simplified and cleaned up various parts of the code, compared to previous variants. Most notably, its banking features were totally scrapped.

The malware first locates the .bss section in the executable, and decrypts it using a simple XOR-based algorithm. This is performed with a key that is constructed of the PE Timestamp, and the section’s PointerToRawData and SizeOfRawData fields. To ensure that the decryption was successful, it calculates a checksum on part of the decrypted data, which must match the checksum of the UTF-16 encoded string "All rights reserved.". This checksum will be used in later operations as a XOR key (similar to the XOR cookie value used in leaked source code, which refers to this value as CsCookie).

Next, it gathers a list of system services by enumerating the subkeys under the registry key HKLM\SYSTEM\CurrentControlSet\Control, and it generates two separate IDs: a System ID, which is derived from the creation date of pagefile.sys or hiberfil.sys – which is exactly the way how the RM3 and SAIGON variants did it; and a User ID, which is simply the MD5 hash of the current user’s username.

To ensure that only one instance of the malware is active at a time, it creates a mutex with a randomized name, where the System ID created in the previous step is used as a random seed value. Then the decrypted configuration (from the .bss section) is validated to see if it contains both the required bot configuration and an RSA public key that is used for decrypting data from the command and control (C2) servers. This is followed by launching the main communication thread via the QueueUserAPC () function.

The main communication loop retrieves the C2 server information from the embedded bot config.

• If the IdleTime option is present in the configuration, then the code waits for this many seconds before starting communication with the servers.
• If the RunCommand option is present, its value is executed in a separate thread with the output of the command redirected to a temporary file. All the binaries we encountered contained two embedded commands: “echo Commands” and “dir”.

The C2 servers are contacted one by one trying to download the file TASK.BIN which contains a list of commands to perform. The list of potential commands is detailed in the Capabilities section.

Network Communication

The communication protocol used by LDR4 does not differ too much from the protocol used by the older RM3 variant. It uses POST requests over HTTPS, with beacon URLs ending in /index.html. The User Agent string depends on the exact Windows version and architecture with the following format:

Mozilla/5.0 (Windows NT %d.%d; %s) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36

The use of an outdated Chrome version in the User Agent string provides a good detection opportunity in environments where a proxy server oversees outbound HTTP/HTTPS connections, and can block or alert based on the User Agent string.

The beacon request’s query string uses the following format (which is almost the same as RM3’s beacon format):

version=%u&user=%s&group=%u&system=%s&file=%08x&arc=%u&crc=%08x&size=%u

The meaning of the parameters is detailed in the following table:

A fake parameter consisting of a random name and value is prepended to the aforementioned query string, every time a request is made, then the entire request string is encrypted using AES-256 in CBC mode, with an embedded key (see ServerKey in the Configuration section) and an initialization vector (IV) consisting of sixteen “0” characters, then encoded using Base64 (any ending “=” characters are stripped from the end of the encoded string), and then sent as the payload of a POST request.

Example query string of an initial beacon (file ID 0x8fd8a91e corresponds to the filename TASK.BIN):

clypnrkl=wsktexbmn&version=100123&user=f2472a25a2e15c3d&group=202208152&system=18245c7ff14d7902&file=8fd8a91e&arc=0&crc=00000000&size=0

Example query string for subsequent beacons (existing TASK.BIN size is 320 bytes, and the checksum of its contents is 0x3e3edc47):

chjm=kckhu&version=100123&user=f2472a25a2e15c3d&group=202208152&system=18245c7ff14d7902file=8fd8a91e&arc=0&crc=3e3edc47&size=320

Example network beacon (with the request string encrypted with AES, and encoded as Base64):

POST /index.html
Host: logotep[.]xyz
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Type: multipart/form-data; boundary=9808fdecfe274c1d
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36
Content-Length: 285

--9808fdecfe274c1d
Content-Disposition: form-data; name="rcgmbh"
QgrHabeBs9/vsorhqEP2jV88dSwmgvyxepEZczkNSFXt89yV2nH9/7A5QYcIslSIoimlOmGG53oykoFVIfc
rge6eCwchr62tLGsho13OHolmwJBYFYH0+sxqa1AH8qV4CEjKX+UwyioMNnv0QlW9pagvAc6JMo1JoTHjrq
aci07r/dByQSndma/MhZU1aIrI
--9808fdecfe274c1d--

All of the control servers that we identified used domain names consisting of 5-10 letters, were registered under the .xyz, .cyou or .com top-level domains, and used Let’s Encrypt TLS certificates. The domain names are registered with Namecheap, and the infrastructure is hosted at a company named Stark Industries Solutions Ltd., registered in the UK in February 2022. This company is listed on the website for Perfect Quality Hosting (aka. PQ Hosting).

Configuration

As mentioned, in the LDR4 variant of URSNIF, the configuration storage was significantly reworked. Previous URSNIF variants used magic markers to locate additional files that were embedded into the binary, called joined files. The magic markers varied between different URSNIF variants, i.e. JF, JJ, J1, J2, or WD.

This new LDR4 variant introduces a new data structure for storing joined files, which are now merged with the strings in the encrypted .bss section.

The data structure has an 8-byte header, and has the following fields:

There are two joined files that must always be present, otherwise the malware will not operate: the bot configuration, and the RSA public key that is used to decrypt and verify responses from the command server. Like in other URSNIF variants, the configuration options are identified by a hexadecimal number, which is the JAMCRC32 checksum of the option’s uppercase name. Note, that the name of the option is not referenced anywhere in the binary or in the configuration, and it is only possible to find it out by brute-forcing the checksum.

List of currently known configuration options:

Capabilities

The following commands are implemented in the malware:

This supports our current understanding that expro is the nickname of the web developer responsible for the bot panel for both the RM3 and LDR4 variants.

rule URSNIF_LDR4 {
    strings:
        $str1 = "LOADER.dll" fullword
        $str2 = "DllRegisterServer" fullword
        $str3 = ".bss" fullword
        $x64_code1 = { 3D 2E 62 73 73 74 0A 48 83 C7 28 }
        $x64_code2 = { 8B 17 48 83 C7 04 8B CA 8b C2 23 CB 0B C3 F7 D1 23 C8 41 2B CA 44 8B D2 41 89 08 41 8B CB 49 83 C0 04 83 E1 07 FF C1 41 D3 C2 41 83 EB 04 79 }
        $x64_code3 = { 41 0F B6 01 49 FF C1 8B C8 8B D0 83 E1 03 C1 E1 03 D3 E2 44 03 C2 41 83 C2 FF 75 }
        $x64_code4 = { 45 8D 45 08 48 8D 8C 24 [4] BA 30 00 FE 7F E8 }
        $x64_code5 = { 48 8D 8C 24 [4] BA 30 00 FE 7F 41 B8 08 00 00 00 E8 }
        $x86_code1 = { 81 F9 2E 62 73 73 74 09 83 C6 28 }
        $x86_code2 = { 8B 06 8B D0 23 55 0C 8B D8 0B 5D 0C F7 D2 23 D3 2B D1 8A 4D 08 80 E1 07 83 C6 04 89 17 83 C7 04 FE C1 D3 C0 83 6D 08 04 8B C8 79 }
        $x86_code3 = { 8A 0E 0F B6 D1 8B CA 83 E1 03 C1 E1 03 D3 E2 46 03 C2 4F 75 }
        $x86_code4 = { 6A 08 8D 45 F8 68 30 00 FE 7F 50 E8 }
    condition:
        5 of them
}