ENGLISH
19.10.2022
DeadBolt ransomware: nothing but NASty
DeadBolt ransomware: nothing but NASty
The Group-IB Incident Response Team investigated an incident related to a DeadBolt attack and analyzed a DeadBolt ransomware sample
- Andrey ZhdanovChief Malware Analyst and Threat Hunter
- Vladislav AzerskyIncident Response and Digital Forensics Analyst
In January 2022, a number of NAS (Network Attached Storage) users found encrypted files with the extension .deadbolt on their systems. Around this time, Bleeping Computer published a news story about 3,600 devices that had also been affected. Since then, reports about attacks on NAS devices involving ransomware from the DeadBolt family have appeared regularly. The DeadBolt ransomware group claims that its members exploit zero-day vulnerabilities in NAS software, and each newly detected vulnerability is often linked to a new series of attacks.
In mid-June 2022, NAS device manufacturer QNAP detected a series of DeadBolt attacks that targeted corporate NAS devices running QTS 4.2.x, 4.3.x, and 4.4.x. In February 2022, various versions of DeadBolt ransomware were used to attack NAS devices belonging to ASUSTOR. In early September 2022, QNAP released another security alert about attacks featuring DeadBolt ransomware (CVE-2022-27593).
The Group-IB Incident Response Team investigated an incident related to a DeadBolt attack and analyzed a DeadBolt ransomware sample. Their investigation was the first full-fledged analysis of DeadBolt and included reverse-engineering the code in full to reveal the ransomware sample’s functionalities and capabilities.
The Group-IB Incident Response Team investigated an incident related to a DeadBolt attack and analyzed a DeadBolt ransomware sample. Their investigation was the first full-fledged analysis of DeadBolt and included reverse-engineering the code in full to reveal the ransomware sample’s functionalities and capabilities.
Key conclusions:
Goal
Gaining financial through by demanding ransoms from victims for unlocking the data stored on their NAS devices, as well as NAS manufacturers for providing technical information about the vulnerability manipulated during the attack and the master key to encrypt client data.
Victims
Small and medium-sized enterprises, schools, individuals.
The threat actors targeted users across the globe, and lacked a specific geographic focus.
The threat actors targeted users across the globe, and lacked a specific geographic focus.
Ransom amount
From victims, the threat actors demanded between 0.03 and 0.05 BTC (< $1,000)
From NAS manufacturers, they demanded between 10 and 50 BTC (between $200,000 and $1,000,000)
From NAS manufacturers, they demanded between 10 and 50 BTC (between $200,000 and $1,000,000)
Activity period
From January 2022 to the present day.
Initial attack vector
NAS software vulnerabilities
Ransomware
Cross-platform ransomware family written in the Go programming language using anti-analysis techniques.
The malware can be used to encrypt or decrypt data. To communicate with victims, DeadBolt uses the web interface of the targeted NAS device.
The malware can be used to encrypt or decrypt data. To communicate with victims, DeadBolt uses the web interface of the targeted NAS device.
Distinctive features
Threat actors do not communicate with victims directly; the victim receives a decryption key in the transaction details after paying the ransom.
Experiencing a breach?
Get Initial analysis of your ransomware incident by Group-IB specialists for free!
Analysis of DeadBolt ransomware
During the incident analyzed, the QNAP NAS device was running QTS 4.3.6.1446 build 20200929, a vulnerable version of the QTS operating system, which made the NAS device a target for threat actors. Perhaps unsurprisingly, the company’s employees one day found a message embedded in the web interface of the NAS device that demanded a ransom for decrypting the data that was stored on it.
DeadBolt ransom message embedded in the web interface of the NAS device
The threat actors demanded a ransom from both the victim of the attack and the vendor of the NAS device on which the vulnerable software was installed.
DeadBolt ransom message addressed to QNAP, the vendor of the NAS device
For a ransom of 10 BTC, the threat actors promised the NAS vendor, QNAP, that they would share all the technical details relating to the zero-day vulnerability that they manipulated, and for 50 BTC they offered to include the master key to decrypt the files belonging to the vendor’s clients who had fallen victim to the campaign. The threat actors were relatively modest, compared to other ransomware groups, when it comes to the ransom demanded from the QNAP’s clients. In general, the amounts ranged from 0.03 to 0.05 BTC, which at the time of writing is equivalent to between $600 and $1,000.
In the event that victims transferred the demanded sum to the provided address, the decryption key — as promised by the threat actors — would be sent in the transaction details, inside the code OP_RETURN bitcoin blockchain. In order to receive the code, the victim needed to track the address of the payment on public blockchain explorers for new transactions containing the text OP_RETURN.
In the event that victims transferred the demanded sum to the provided address, the decryption key — as promised by the threat actors — would be sent in the transaction details, inside the code OP_RETURN bitcoin blockchain. In order to receive the code, the victim needed to track the address of the payment on public blockchain explorers for new transactions containing the text OP_RETURN.
Description of the process of receiving the decryption key
The DeadBolt ransomware sample that was used in the attack analyzed by Group-IB is a 32-bit ELF-format software for Linux/ARM written in Go. The software was obfuscated and archived using the UPX packer, and the Go build ID was removed. Given that analyzing such a sample can be difficult, we will describe the functionality and operating behavior of DeadBolt in detail. We were able to do this after fully reverse-engineering the Go code of the ransomware.
The code of the function main of the DeadBolt ransomware
Depending on the command line arguments, the software either encrypts or decrypts the files.
— Encrypting files: {RANSOM_APP} -e {config} {dir}
— Decrypting files: {RANSOM_APP} -d {key} {dir}
where
— Encrypting files: {RANSOM_APP} -e {config} {dir}
— Decrypting files: {RANSOM_APP} -d {key} {dir}
where
- RANSOM_APP is the path to the DeadBolt ransomware
- dir are the paths for encrypting/decrypting the files, separated by commas
- config is the path to the configuration file
- key is the file decryption key
Encryption
When the ransomware is launched in encryption mode, it loads the list of extensions of the files to be encrypted and the configuration from the JSON text file specified in the command line.
Core structures of DeadBolt
After loading, the configuration file is rewritten with null bytes and deleted.
Initial fragment of the DeadBolt encryption mode function
The DeadBolt configuration file contains the following data:
The fields "client_id", "master_key_hash", and "key" contain hex strings. The length of the “client_id” and “key” fields is 32 symbols, while the "master_key_hash" is 64 symbols long.
The "key" field value is a hex string with a file encryption key. All fields are described below.
To replace the interface page of the NAS device, the software creates the following files:
/home/httpd/index.html
/mnt/HDA_ROOT/update_pkg/SDDPd.bin
/mnt/HDA_ROOT/update_pkg/.SDDPd_required
Next, the software encrypts the files.
The "key" field value is a hex string with a file encryption key. All fields are described below.
To replace the interface page of the NAS device, the software creates the following files:
/home/httpd/index.html
/mnt/HDA_ROOT/update_pkg/SDDPd.bin
/mnt/HDA_ROOT/update_pkg/.SDDPd_required
Next, the software encrypts the files.
Final fragment of the DeadBolt encryption mode function
The file /home/httpd/index.html that existed previously is renamed in advance to /home/httpd/index.html.bak. The file /home/httpd/index.html, which DeadBolt replaces, is a shell script designed to process incoming HTTP requests.
Fragment of the shell script template /home/httpd/index.html contained in the body of DeadBolt
The script checks if the method of the incoming HTTP request is POST. If the URL address contains the query strings "action=decrypt" and "key={KEY}" (where KEY is the decryption key), the shell script checks if the key value matches the hash value of the key used for encryption or the hash value of the master key. If the key value matches one of the hash values, the script runs DeadBolt ransomware in decryption mode, and specifies the key value in the corresponding argument of the command line. If the URL contains the parameter "action=status", the script returns the data in JSON format, including statistics on the file decryption process.
The start of the decryption process is dependent on the contents of the file /tmp/deadbolt.pid, the end of the decryption process is based on the contents of the file /tmp/deadbolt.finish, and the current number of decrypted files is stored in the file /tmp/deadbolt.status.
For other HTTP request methods, the script shows a gzip-archived HTML page, which contains in its body a ransom demand and additional information. Screenshots of the HTML page are shown above, toward the start of this article.
The start of the decryption process is dependent on the contents of the file /tmp/deadbolt.pid, the end of the decryption process is based on the contents of the file /tmp/deadbolt.finish, and the current number of decrypted files is stored in the file /tmp/deadbolt.status.
For other HTTP request methods, the script shows a gzip-archived HTML page, which contains in its body a ransom demand and additional information. Screenshots of the HTML page are shown above, toward the start of this article.
Fragment of the shell script template /home/httpd/index.html contained in the body of DeadBolt
From time to time, the JavaScript code contained in the HTML page checks the decryption status by sending the request POST /index.html?action=status.
When a user enters the correct value of the decryption key in the corresponding field and clicks on the button "Decrypt Files", the page sends the request POST /index.html?action=decrypt&key={KEY}, where KEY is the key value entered by the user.
The Shell script /mnt/HDA_ROOT/update_pkg/SDDPd.bin contains a gzip archive with the contents of the script /home/httpd/index.html, created earlier by the ransomware.
When a user enters the correct value of the decryption key in the corresponding field and clicks on the button "Decrypt Files", the page sends the request POST /index.html?action=decrypt&key={KEY}, where KEY is the key value entered by the user.
The Shell script /mnt/HDA_ROOT/update_pkg/SDDPd.bin contains a gzip archive with the contents of the script /home/httpd/index.html, created earlier by the ransomware.
Extraction function /mnt/HDA_ROOT/update_pkg/SDDPd.bin
The script /mnt/HDA_ROOT/update_pkg/SDDPd.bin is designed to help the threat actors gain a foothold in the system. Upon being executed, it recovers the contents of the Shell script DeadBolt /home/httpd/index.html and blocks any modifications.
Shell script template /mnt/HDA_ROOT/update_pkg/SDDPd.bin contained in the body of DeadBolt
File encryption
The ransomware uses multithreading to encrypt files using the paths specified in the command line. Multithreading is implemented using built-in Go tools.
File extensions encrypted by the ransomware are listed below:
File extensions encrypted by the ransomware are listed below:
DeadBolt ransomware does not encrypt files in the following directories:
/dev
/sys
/proc
/usr/share
/usr/bin
/usr/sbin
/sbin
The ransomware also skips the following files and directories:
.swap
.qpkg
.samba
.@root
.@sys
.ssh
@system
@zlog
.system
.@system
.@ezsync
.@iscsi
.@snapshots
.@thumbnail
.@tmp
.@uploads
.@trashcan
.@plugins
.@CNID
DeadBolt adds the extension ".deadbolt" to the names of any files encrypted. The ransomware creates a text file !!!_IMPORTANT_README_WHERE_ARE_MY_FILES_!!!.txt with a ransom demand in each directory listed in the command line.
/dev
/sys
/proc
/usr/share
/usr/bin
/usr/sbin
/sbin
The ransomware also skips the following files and directories:
.swap
.qpkg
.samba
.@root
.@sys
.ssh
@system
@zlog
.system
.@system
.@ezsync
.@iscsi
.@snapshots
.@thumbnail
.@tmp
.@uploads
.@trashcan
.@plugins
.@CNID
DeadBolt adds the extension ".deadbolt" to the names of any files encrypted. The ransomware creates a text file !!!_IMPORTANT_README_WHERE_ARE_MY_FILES_!!!.txt with a ransom demand in each directory listed in the command line.
Contents of !!!_IMPORTANT_README_WHERE_ARE_MY_FILES_!!!.txt
File contents are encrypted using the AES-128 CBC algorithm. To implement the algorithm, the threat actors use standard cryptographic Go packages "crypto/aes" and "crypto/cipher". The value specified in the configuration file serves as the encryption key; the 16-byte initialization vector IV is chosen randomly for each file. To generate this vector, the standard function rand.Read is used from the Go cryptographic package "crypto/rand".
All files are encrypted fully. Before that, if necessary they are padded with the required amount of null bytes to ensure that the file size is a multiple of the AES block size (16 bytes).
All files are encrypted fully. Before that, if necessary they are padded with the required amount of null bytes to ensure that the file size is a multiple of the AES block size (16 bytes).
Fragment of the DeadBolt file's encryption function
After encrypting the data, DeadBolt adds a 128-byte block of metadata to the end of the file.
End fragment of the file encryption function
Configuration
As mentioned above, configuration data of DeadBolt ransomware is contained in a JSON text file, which is deleted afterwards in order to prevent data recovery.
Configuration parameters:
Configuration parameters:
Decryption
To decrypt the files in the DeadBolt command line, the key and the decryption paths must be specified. However, the user does not require to know all this information. When they obtain the key after paying the ransom, file decryption is launched using the web interface of the NAS device.
The user only has to enter the correct key in the corresponding field. The paths used for file encryption and other parameters are inserted into the Shell scripts when they are created at the beginning of the encryption process.
To decrypt the files, the victim must enter either the key contained in the configuration file or the master key. The meaning of the term "master key" will become clear after the file decryption function is analyzed.
The user only has to enter the correct key in the corresponding field. The paths used for file encryption and other parameters are inserted into the Shell scripts when they are created at the beginning of the encryption process.
To decrypt the files, the victim must enter either the key contained in the configuration file or the master key. The meaning of the term "master key" will become clear after the file decryption function is analyzed.
Decryption mode function
Early in the decryption process, DeadBolt creates the text file /tmp/deadbolt.pid, which contains an identifier of the ransomware process. During decryption, the ransomware updates the number of decrypted files in the text file /tmp/deadbolt.status, and when the decryption is complete, it creates the file /tmp/deadbolt.finish, which contains "1". As mentioned above, these files are used by the DeadBolt Shell scripts to align with the decryption process and display its implementation status.
Before decrypting the files, DeadBolt reads the metadata, checks the marker "DEADBOLT", and receives the size of the original file.
Before decrypting the files, DeadBolt reads the metadata, checks the marker "DEADBOLT", and receives the size of the original file.
Fragment of the file decryption function
After that, the software checks whether the specified decryption key is correct.
Fragment of the file decryption function
If the hash value of the specified encryption key matches the hash value of the key that was used to encrypt the file, it is used for decryption. If the key matches the hash value of the master key, the ransomware uses this key together with the Client ID to calculate the encryption/decryption key. It matches the first 16 bytes of the SHA-256 hash taken from the master key and the Client ID. To carry out a series of attacks, the threat actors must therefore generate a master key and then create unique Client IDs for each attack and each victim, thereby obtaining encryption keys.
When the decryption is complete, the ransomware deletes itself.
When the decryption is complete, the ransomware deletes itself.
DeadBolt's self-delete function
Additional information
The body of the ransomware contains embedded Go files that are used as templates for creating Shell scripts and other supplementary files.
The templates use the following variables to insert values into scripts and supplementary files:
A demo project created by Group-IB containing part of the source code of DeadBolt ransomware is available here.
Conclusion
Our analysis of DeadBolt did not reveal any complex elements such as cryptographic schemes involving asymmetric encryption. Everything is simple and efficient, and this is especially the case for the victims, as the web interface of the ransomware is user-friendly and relatively easy to understand.
The threat actors do not steal client data and therefore do not utilize double extortion, unlike other RaaS (Ransomware-as-a-Service) groups. The scheme does not involve any communication between the victims and the threat actors. The victim either makes a payment to the specified address and receives the key in the transaction details, or they do not. This could partly explain why DeadBolt does not demand huge ransom amounts from their victims.
However, the group follows the rather unusual practice of demanding a ransom from the vendors of NAS devices. DeadBolt has been active for quite a long time, so we assume that this business model is profitable.
Our analysis of a DeadBolt group ransomware attack demonstrates how threat actors use every trick in the book to achieve their criminal goals, and underlines how relentlessly they, in a sense, punish their victims for any deficiencies or vulnerabilities in both their external and internal infrastructure.
The threat actors do not steal client data and therefore do not utilize double extortion, unlike other RaaS (Ransomware-as-a-Service) groups. The scheme does not involve any communication between the victims and the threat actors. The victim either makes a payment to the specified address and receives the key in the transaction details, or they do not. This could partly explain why DeadBolt does not demand huge ransom amounts from their victims.
However, the group follows the rather unusual practice of demanding a ransom from the vendors of NAS devices. DeadBolt has been active for quite a long time, so we assume that this business model is profitable.
Our analysis of a DeadBolt group ransomware attack demonstrates how threat actors use every trick in the book to achieve their criminal goals, and underlines how relentlessly they, in a sense, punish their victims for any deficiencies or vulnerabilities in both their external and internal infrastructure.
Recommendations for companies
To ensure that all their external IT assets are accounted for and secure, organizations can use Group-IB Attack Surface Management. The solution generates an up-to-date IT asset inventory, checks assets for confirmed vulnerabilities, and assesses critical risks, all of which helps to improve the company’s security posture.
Group-IB specialists respond to cybersecurity incidents of any level of complexity, mitigating the damage and helping organizations prevent recurring attacks.
Group-IB specialists respond to cybersecurity incidents of any level of complexity, mitigating the damage and helping organizations prevent recurring attacks.
Recommendations for setting up an NAS device:
- Update all software/firmware installed on your NAS device
- Setup two-factor authentication (2FA) in the administrator account on the NAS device
- Enable system connection logs on the NAS device
- Ensure that event logs (system logs and system connection logs) are sent to the remote Syslog server
- Create strong passwords in accordance with your company’s security policy
- Disable the admin account and create a new account with administrator privileges
- Disable any unused services on the NAS device (e.g., FTP server, Telnet)
- Reassign the ports of the main services (SSH, FTP, HTTP/HTTPS, etc.) by changing the default values
- Disable automated port forwarding in myQNAPcloud (QNAP)
Remaining true to Group-IB’s mission – fighting cybercrime – we will continue to research the tactics, techniques, and practices used by the malicious actor group DeadBolt.
We consider it our responsibility to share our findings with the cybersecurity community and encourage threat analysts to scrutinize advanced threats together, share the data collected, and use our technologies as a way of counteracting threat actors.
If you are interested in our investigations and would like to develop similar skills, we invite you to take part in our training courses on digital forensics, incident response, and threat intelligence. Or, if you want to join the Group-IB team, please check the vacancies on our website.
If you are interested in our investigations and would like to develop similar skills, we invite you to take part in our training courses on digital forensics, incident response, and threat intelligence. Or, if you want to join the Group-IB team, please check the vacancies on our website.
If you found this article helpful, share it with your friends!
Share
Prevention
Response
Investigation
Products
Company
