Files Locked Behind a White Padlock: A Warning from WhiteLock Ransomware

If files start getting locked one by one and even remote access tools stop working, your system may already be infected with ransomware. The recently identified WhiteLock ransomware encrypts key files on Windows systems and then generates a ransom note demanding payment. A key characteristic of this ransomware is that it communicates with external servers during the encryption process and terminates Services related to remote access tools—such as AnyDesk and TeamViewer—to prevent victims from responding remotely. In this article, we’ll examine the main operating mechanisms of WhiteLock ransomware and the security considerations to keep in mind when responding to a ransomware attack.

WhiteLock is a typical ransomware that performs file encryption on the victim’s system and then demands a ransom for decryption. Encrypted files are appended with the .Fbin extension, and a ransom note named c0ntact.Txt is created on the infected system.

The WhiteLock ransom note demands that the victim pay the ransom within a specified time limit and provides instructions on how to access the Tor-based negotiation page and enter the victim’s identification information. While demanding the ransom, the threat actors pressure the victim by warning that decryption will be impossible if they fail to contact the threat actors or make the payment by the deadline.

WhiteLock has also been linked to specific threat campaigns. Some reports have confirmed cases where information theft malware was used for Initial Breach, followed by the deployment of WhiteLock ransomware. Therefore, WhiteLock should not be viewed merely as a standalone executable file but understood as a ransomware threat that can be deployed following Initial Breach, information theft, and internal propagation.

Therefore, to counter WhiteLock, it is necessary not only to detect the ransomware files themselves but also to continuously monitor for phishing, account compromise, remote access exploitation, abnormal external communications, and signs of internal propagation.

1. Analysis

1.1 Initial Routine

Upon execution, the WhiteLock ransomware collects the MAC address of the compromised device. The collected MAC address is then converted into a SHA-256 hash value, which is used in communications with an external server to identify the compromised device.

This process can be viewed as a preparatory step for the ransomware to distinguish infected devices and subsequently perform encryption key processing and victim-specific identification procedures.

If communication with the external server fails, WhiteLock repeatedly attempts to re-establish the connection. As a result, in environments where communication with external networks is restricted, some subsequent behaviors may not proceed normally. However, in actual infection scenarios, behavior may vary depending on network policies, configuration of security equipment, and the threat actor’s deployment methods; therefore, the likelihood of infection should not be determined solely by whether communication is blocked.

After registering an infected device, WhiteLock checks whether AnyDesk and TeamViewer are installed on the victim’s device. If these tools are present, it terminates the relevant Services in subsequent stages. This behavior is interpreted as an attempt to prevent security personnel or administrators from isolating the infected system or responding in real time through remote access tools.

1.2 Encryption Preparation

Encryption Key Generation

After executing the Initial Routine, WhiteLock generates a key to be used for file encryption. During this process, 32-byte and 16-byte random numbers are generated, which are used as the AES key and initialization vector (IV) for file encryption, respectively.

WhiteLock then communicates with an external server to obtain an RSA public key and encrypts the previously generated AES key using the RSA-2048 algorithm. This is a key protection structure frequently used in ransomware: a symmetric key, such as AES, is used for the actual file encryption, and that symmetric key is protected by a public-key-based structure controlled by the threat actor.

The encrypted AES key is transmitted to an external server. In this structure, it is difficult to recover the AES key without the RSA private key held by the threat actor; therefore, the system is designed so that victims cannot recover their files without negotiating with the threat actor.

Selection of Files for File Encryption

After completing the encryption key generation and key protection procedures, WhiteLock compiles a list of files and folders to be excluded from encryption. Like typical ransomware, it targets most user files on the system for encryption; however, it includes exceptions such as paths essential for operating system operation, already encrypted files, ransom notes, and certain system files, thereby skipping their encryption.

The table below summarizes the items that WhiteLock excludes from encryption.

Category	Exclusions
Folder Paths	$Recycle.Bin, \AppData, \ProgramData, \Windows, \System Volume Information, \Google, \Windows\servicing, etc.
File name	C0ntact.Txt, DumpStack.Log.Tmp, pagefile.Sys, swapfile.Sys, hiberfil.Sys, desktop.Ini, ntuser.Dat, etc.
File extension	.Fbin
Keywords	Keywords related to major antivirus and security products

The purpose of this exclusion list appears to be to exclude key files that are essential for operating system functionality—and which could otherwise be encrypted and affect system operation—while also preventing duplicate processing of files that have already been encrypted. Furthermore, the exclusion of keywords related to security products can be interpreted as an attempt to avoid exceptions or conflicts during the file encryption process.

Termination of Remote Access Tools Service

WhiteLock searches for and terminates AnyDesk and TeamViewer-related services—whose presence on the victim’s device it confirmed in an earlier stage. Remote access tools can be used by security personnel to access an infected system to assess the situation, terminate processes, or block the network.

Therefore, this behavior by WhiteLock can be viewed as an attempt to hinder the victim’s remote response following a ransomware infection and to buy time until encryption is complete.

1.3 Encryption Execution

Ransom Note Generation

Following the encryption preparation phase, WhiteLock creates a ransom note named “c0ntact.Txt” in the root Path of each drive.

The ransom note details the file encryption on the victim’s system and Information Theft. It also contains threats stating that if the ransom is not paid within the specified time limit, the attackers will notify the victim’s contacts, sell the stolen information, and publish it on the dark web and the internet.

Finally, it instructs the victim on how to access the negotiation page through the Tor Browser and provides instructions for entering victim identification information. This appears to be a method the threat actor uses to individually identify victims and manage the negotiation process.

[Figure 1] Content of the WhiteLock ransomware ransom note

File encryption

Once the ransom note is generated, WhiteLock begins the actual file encryption process. The encryption process uses the previously generated AES key and IV, and files and paths included in the exclusion list are excluded from processing.

WhiteLock reads the data from the target files and encrypts it using the AES-CBC method. Once file encryption is complete, it appends the .Fbin extension to the original file name. This extension not only alerts the victim that the file has been encrypted but also serves to distinguish files that have already been processed by the ransomware, preventing them from being re-encrypted.

WhiteLock’s encryption workflow combines symmetric-key-based file encryption with a public-key-based key protection mechanism. This is a method commonly observed in many ransomware strains; since decryption is difficult once infection occurs, preemptive backups, behavior-based detection, and early containment measures are crucial.

Wallpaper Change

Once encryption is complete, WhiteLock changes the victim’s device wallpaper. The new wallpaper displays a message stating that the system has been compromised and important information has been encrypted, and instructs the victim to check the c0ntact.Txt file.

The wallpaper change is used as a means of pressure to ensure the victim immediately recognizes the infection and to prompt them to view the ransom note and access the negotiation page.

[Figure 2] Wallpaper changed by WhiteLock ransomware

2. AhnLab Response Overview

AhnLab provides file-based detection, behavior-based detection, and EDR detection for WhiteLock ransomware and related activities.

AhnLab V3 detects malicious files and suspicious ransomware-like behaviors associated with WhiteLock ransomware. Additionally, through MDP-based detection, it can identify suspicious behaviors such as file encryption, autorun, and ransomware-like behaviors.

AhnLab EDR detects suspicious ransomware behavior and key events during the infection stages, enabling security administrators to verify the infection flow and respond accordingly. In particular, bulk file modifications, generation of ransom notes, termination of services related to remote access tools, and abnormal external communications are behaviors that require close monitoring during the ransomware infection process.

To effectively respond to ransomware, organizations must not only keep their antivirus software engines up to date but also implement behavior-based detection through EDR, monitor the usage of remote access tools, back up critical data, and review policies governing external communications.

Conclusion

WhiteLock ransomware can be described as a threat that combines file encryption, communication with external servers, termination of remote access tool services, creation of ransom notes, and desktop background changes. It performs the encryption process based on the identification information of the infected device and uses an AES-CBC and RSA-2048-based key protection structure to make it difficult for victims to recover their files. Additionally, it appends the .Fbin extension to encrypted files and pressures victims to pay a ransom by displaying the c0ntact.Txt ransom note and changing the desktop background.

In particular, the action of terminating services related to AnyDesk and TeamViewer can be interpreted as an attempt to hinder remote response efforts following infection. Accordingly, to counter ransomware such as WhiteLock, it is necessary to detect not only known malware signatures but also key behaviors such as mass file modification, abnormal encryption activity, ransom note generation, and the termination of remote management services. Furthermore, organizations must establish a response system capable of responding in the early stages of a ransomware infection by backing up critical data, monitoring external communications, and reviewing the usage status of remote access tools.