Important elements of the analysis:
- Using of the Salsa20 algorithm, curve25519xsalsa20poly1305
- XOR encoding operations
- Ransomware configuration attributes
- Skipping functions for files and directories
- Presence of strings related to Windows environment
- Disk wiping functions
- Use of thread pools
Introduction
In the present analysis, a sample of LockBit (macOS variant) with hash abf01633960dd77c6137175a21fccf34 was considered.
The artifact is developed in C++ and compiled with macOS SDK 11.3.0 with ARM architecture.
Below is a detail of the hexadecimal code of the entrypoint address 10000b0d4:
Malware assessment
By examining the assembly instructions of the same, it is possible to be aware of various operations of sub, stp (in order to change the memory address consequential to the storing of data in the registers), mov, ldr (storing in the registers from memory)
Further assembly operations performed, including bl (in order to copy the address of the next instruction), cmn (in order to perform adding operations but with discarding of the result) follow:
In the memory mapping there is the _TEXT segment, which contains references to the dyld library containing cached files.
An inspection of the hexadecimal code of the ransomware reveals references to encryption algorithms and structures, such as Salsa20, keybytes, crypto_stream_salsa20_xor (which also denotes the use of XOR operations), but also references to the Readme file intended for the victim and certain configuration attributes of the ransomware. By way of example, the attributes contained are: SkipByDirName, SkipByFileName (for exceptions in the encryption process), Suspend_VM_ID_ERROR, Suspended_VM_ID.
The _LINKEDIT segment (used for storing raw data, which is then used by the dynamic linker and relocation tables) contains references to multithreading executions and management of mutex objects.
By checking the packing state of the malware, a rather high entropy coefficient for the _TEXT segment can be seen, in fact it stands at 6.93823:
Following the details of the bytes distribution of the threat, there is a bytes confusion of one of its segments:
Static analysis
Suspicious indicators from an assessment operation include references to the presence of services, Base64 encoding, files management (used in the file encryption phase and target folders):
Through the strings that can be extracted from the sample are details concerning encryption and decryption functions, stop and create services objects, the Salsa20 algorithm and, curiously, elements usually referable to a Windows environment, such as ntuser.dat.log (which contains information, details and settings of the system user), autorun.inf:
Following are further strings relating to encryption functions, but also logging strings that would seem to refer to skipping and bypassing during the cyber kill chain phase. In all likelihood, these references are related also to evasion tasks from security solutions.
Through the attributes we can see the first N bytes of the target files to be taken into consideration and a configuration parameter indicating whether to proceed with encryption of the entirety of the files in a folder or not.
LockBit macOS variant makes use of the curve25519xsalsa20poly1305 encryption algorithm as shown below; this algorithm is quite reliable in terms of encryption and securing files.
Here are references to XOR operations and the bytes taken into consideration:
There are also references to eSXi and Linux machines:
In the LockBit’s configuration parameters, we can see evidence of wiping functions (used to destroy data on disk), SSH enablement, esxi_enable, except_folder with the purpose to add folders in “exception” during data encryption:
Below are some details correlated to the public key variables used, random bytes functions executions.
Here evidence of timers, threads but also references to VM management for suspending virtual machines (for example with the attributes “_vmdumper_l” and “_vmdumper_suspend_vm”):
The _CalculateCryptoBlocksShift function takes the variable arg2 as an input argument, which is then used in left shift instructions by means of “lsls” instructions. There are then adding instructions, followed by a bl instruction in order to copy the address of the next instruction.
Here are the details of the _KEYSIZE structure, which contains parameters of type .string. There is also a comparing instruction between the value of register r3 (input argument “arg4”) and the value 0x9b in order to check the size.
The function “_SkypByDirName” takes as input the attributes arg_4h and arg_2f8h, these are then added with the register r1. There is then evidence of comparing instructions, such as blt, bge and bpl in order to allow the folders taken into account to be checked and to “skip” those placed in “exception”.
The _add_node_to_chain function has the following attributes as input arguments: arg1, arg_4h, arg_8h and arg_2f4h. After an lsrs shifting operation of register r0 with the value 0x20, there is a push instruction for registers r0, r1, r2, r3, r4, r5, r7 and lr.
Following is the thread pooling creation function _tpool_create:
The _check_esxi function is used to check the execution environment:
Below are several references to the encryption library referring to “Libsodium”. One of these functions is called “_crypto_box_easy”, which uses the input parameters arg_4h, arg_ch, arg_10h and arg_14h. The particularity of this library is that vulnerabilities have been found relating to an encrypted message exchange context between A and B: if A’s private key is compromised, all messages sent and received by A would be compromised.
Below are the details of the _crypto_box_keypair function, which has the arguments arg1, arg2 and arg4 to define the encryption keys.
In the object definition contexts of crypto_stream, there is evidence of the execution of XOR instructions:
The _do_I_need_to_bypass_this_file function appears to be an additional configuration attribute of the ransomware with the purpose to define whether or not a certain file should be bypassed during the infection phase.
The _do_I_need_to_bypass_this_vms function turns out to be an additional configuration attribute of the ransomware in order to define whether or not a given virtual machine should be bypassed during the infection phase.
The _encrypt_all_files_in_dir function takes the arg1 attribute as input and saves it within the r0 register, followed by the execution of the BHS function, which can be used for the purpose of performing an unsigned comparison with a higher or equal result. The bpl instruction is also used with the purpose of performing a conditional jumping operation.
The _encrypt_file_first_N_bytes function takes the first N bytes of a given file and then proceeds with an encryption action. The various input arguments arg3, arg_4h, arg_8h, arg_ch, arg_10h, arg_14h, arg_18h, arg_1ch and arg_2e8h are added with the registers r1 and r2 with a series of add instructions.
The _get_password function executes the assembly instruction stm in order to store the contents of the register r3 in the consecutive registers r0, r1, r2, r3, r4, r5, r6 and r7.
Here are the details of a reference to the AES decryption functions _mbedtls_aes_decrypt_cbc and _mbedtls_aes_init_encrypt(), which perform various data loading instructions ldr, logical shifting lsls of the registers r2 and r0 in correlation with the other registers. Subsequently, there are comparing instructions between the registers and different hexadecimal values (for example the hexadecimal value 0x68, in decimal 104).
The _pre_encrypt_file function acts as a prelude to the encryption operation, which has similar attributes to the AES functions described above.
Following are the details of the data destruction function _wipe_routine, which adds the input arguments to the register r1 and performs several shifting operations, such as lsls.
By viewing at the start_wiping function, there are details of shifting, comparing and data shifting instructions in the various registers, such as r0 and r3.
IOCs:
abf01633960dd77c6137175a21fccf34
_I_need_to_bypass_this
_SUSPENDED_VM_ID
YARA Rule:
rule LockBitMacRule
{
strings:
$str = “_I_need_to_bypass_this ”
$str1 = “SUSPENDED_VM_ID”
$hex= {5f 49 5f 6e 65 65 64 5f 74 6f 5f 62 79 70 61 73 73 5f 74 68 69 73}
$hex1 = {53 55 53 50 45 4e 44 45 44 5f 56 4d 5f 49 44}
condition: $str or $str1 or $hex or $hex1
}
CONCLUSIONS:
LockBit, with this macOS variant, demonstrated how, starting from the structure of the source code of the Windows variant threat, it is possible to construct a multiplatform threat, though not without presenting problems relative to bugs and programming errors that can be deduced from assessment operations and strings extraction, such as the fact that encryption functions derivable from Libsodium libraries are used, which in certain types of circumstances can present potential vulnerabilities. The hypothesis that the Windows source code base has been used to develop the macOS variant can be strengthened by the fact that, curiously, through the strings that can be extracted from the sample there are actually details that usually relate to the Windows environment.
Also regarding to the macOS variant there are attentions to the development of a threat configuration system that provides for the inclusion of specific attributes for the infection chain that indicate, for instance, the encryption of all or certain files within a given folder, wiping disk attributes and IDs inherent to virtual machines.
The development by the authors of LockBit of such a macOS variant may mean that threat actors are moving more and more towards a multi-platform perspective, and such a scenario may entail certain considerations: the risk of infection by such threats is higher, malware developers will have as their main goal to widen the boundaries of vulnerability hunting to target more operating systems, and such behaviour may also be related to other types of threats, not only ransomware threats.
