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 HKLMSYSTEMCurrentControlSetControl, 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.

Source: https://www.mandiant.com/resources/blog/rm3-ldr4-ursnif-banking-fraud