[RANSOMWARE] >>READ 1st Post<< Deadbolt

[domanm]

I had the opportunity to analyse the operation of this ramsomware a bit, so I will be happy to share some information, maybe it will be useful to someone.
The attack looks like that: in directory /mnt/HDA_ROOT/ is loaded an encryption program whose name is a number (e.g. /mnt/HDA_ROOT/18136) in the processes you will see the process with this name and if you have SSH access to the shell then you will be able to see it with ps or top. If only through a browser then in the resource monitor.

process.png

If in this directory you can see other files with a number in the name, it is probably a configuration file for the encryption program and it contains additional information, including information about the password or the password that encrypts the files.
If you've already shut down the server, you've already stopped encryption, and after turning on, deadbolt won't do anything else.

A separate element of the attack is the replacement of the /home/httpd/index.html file. This file is responsible for displaying the encryption message and blocks access to the server via the browser, additionally it executes scripts to decrypt the disk, but you need to know the 32-character decryption key. The program /mnt/HDA_ROOT/18136 is required for decryption. So we can't delete it if we want to decrypt the server.
There is one more /mnt/HDA_ROOT/update_pkg/SDDPd program that generates and replaces the index.html file on your server.
Below is a dump from the file /home/httpd/index.html

index.png

In order to enter the server through the browser and the message about the server encryption was not displayed, it is enough to add /cgi-bin/ to the url address
e.g. https://192.168.1.100/cgi-bin/

What to do (I assume you have shell access via ssh as admin):
1. If encryption is still in progress, view the running process
ps | grep HDA_ROOT
2. preview the contents of the /mnt/HDA_ROOT/ directory and find files with a number in the name on the list
ls -al /mnt/HDA_ROOT/
if there is also a file that was given as an argument after the -e parameter, be sure to copy or view it (there may be a password)
3. If the process is still running and we do not have a password, it is worth searching the files of this process in /proc/PID, where PID is the process identifier from point 1.
4.Stop the process (if you don't want to mess with setting a password, you can start right from this point)
kill -9 PID
where PID is the process number
5. Restore normal access to the server via the browser, i.e. restore the original file /home/httpd/index.html
mv /home/httpd/index.html.bak /home/httpd/index.html
DeadBolt leaves the original file with .bak in it, so there is no problem with restoring it
6. You can delete files all malicious files (but it is worth saving them somewhere on the side)
Some files have an additional non-deletable attribute and must be unlocked first.
chattr -i / mnt / HDAROOT / 18136
rm / mnt/HDA_ROOT/18136

chattr -i /mnt/HDAROOT/updatepkg/SDDPd.bin
rm /mnt/HDAROOT/updatepkg/SDDPd.bin

chattr -i /mnt/HDAROOT/updatepkg/.SDDPdrequired
rm /mnt/HDAROOT/updatepkg/.SDDPdrequired
7. Restart QNAP

By the way, I have a question if you have VPN PPTP enabled on your servers?
I have a strong suspicion that there is a software vulnerability there and that a session is being established without proper authorization.
I am monitoring the server and I have evidence that foreign addresses established sessions with my server and then entered the server as random users.

If in fact all attacked servers had VPN PPTP enabled, the problem is with this service, not with access via www, myQNAPCloud or HBS 3.

[FSC830]

@Theliel: one of the best and shortest summary about internet security I have seen! Great

Regards

[kspsystems]

By the way, I have a question if you have VPN PPTP enabled on your servers?
I have a strong suspicion that there is a software vulnerability there and that a session is being established without proper authorization.
I am monitoring the server and I have evidence that foreign addresses established sessions with my server and then entered the server as random users.

If in fact all attacked servers had VPN PPTP enabled, the problem is with this service, not with access via www, myQNAPCloud or HBS 3.

Our affected NAS was not running PPTP or any other VPN on it.
Please share more info regarding the foreign addresses you have discovered. Country of origin would be helpful for us.

[krzychos7]

I've decided to pay the ransom. I know that's not how we should deal with this kind of situations, but I have no choice, the information that I had is essential. Unfortunately, it's a hard-learned lesson.
I'll let you know how it goes.
After it will decrypt the files, I'll copy them on another HDD and then deal with the NAS and the NAS HDD's (while I'll keep the NAS disconnected from the internet)
After this, I'll come back and ask advices on how to protect&back-up my NAS

Did you recive valid key?
Tell more. Let me know if it was possible to decrypt it, or whether the swindlers.

[nimblefinger5]

i noticed that in the post above there is a few references to SDDPd. could the way in be through the SDDP app on QNAP as i believe it holds open port udp 1902

i know of SSDP which gets used a lot but SDDP being third party to Control4 surprised me as i thought they were the same but appear to be different but do similar things with upnp

as ssdp has had vulns in past such as:
https://blog.cloudflare.com/ssdp-100gbps/
makes me wonder is sddp has similar as it operates in similar manner for discovering devices:
https://www.c4forums.com/topic/29328-control4/

This from control4 wiki article:
In 2012, Control4 released its Simple Device Discovery Protocol (SDDP), which makes products embedded with the code automatically discoverable on a Control4 network.[22] The company licenses the protocol to other vendors for their products,[19] with more than 7,500 SDDP-embedded products as of June 2019

Makes me curious as it's a third party app i wonder if it can bypass the upnp settings in the nas

[Theliel]

Our affected NAS was not running PPTP or any other VPN on it.
Please share more info regarding the foreign addresses you have discovered. Country of origin would be helpful for us.

I doubt it, we have reports of infected users without having any VPN server up. The only common factor between all of them is the main administration port/service. That leaves us with only one way in. Another different thing is that the bug is not really in the main web service, but in some installed application that they manage to reach through it.

On the other hand, PPTP is today a fairly "broken" protocol, vulnerable from the base. I would never recommend using PPTP today, especially when considering alternatives like OpenVPN, and much better, WireGuard

At this point it would be very interesting to know the installed applications of each user and if all of them are up to date. In any case, with the information that is available right now, I would dare to say that the attacked port is 8080/443. There are also no reports of users infected with the changed port.

All this with the information that is currently available, we can always find something else.

[nimblefinger5]

Our affected NAS was not running PPTP or any other VPN on it.
Please share more info regarding the foreign addresses you have discovered. Country of origin would be helpful for us.

I doubt it, we have reports of infected users without having any VPN server up. The only common factor between all of them is the main administration port/service. That leaves us with only one way in. Another different thing is that the bug is not really in the main web service, but in some installed application that they manage to reach through it.

At this point it would be very interesting to know the installed applications of each user and if all of them are up to date. In any case, with the information that is available right now, I would dare to say that the attacked port is 8080/443. There are also no reports of users infected with the changed port.

All this with the information that is currently available, we can always find something else.

I thinks it's the SDDP app

[Theliel]

I thinks it's the SDDP app

If you say it because of the resemblance of the names, it may simply be a way to "hide" it. In any case, it would be very simple to know if those affected tell us about. Its also an application that is not installed by default, so the range of the attack would be quite limited.

I'm sure we'll get out of doubt very soon

[Centaurx]

hello everyone.

i got the ransware too.
I noticed that the files are not really encrypted.
If you rename the file with the original extension it comes back as before.
Es.

file.jpg.deadbolt
rename
File.jpg
the file opens normally

I know, it sounds stupid but it works.

[kspsystems]

I thinks it's the SDDP app

SDDP app is not installed on the affected NAS.

Given how widespread this hack is, if it's an app, it would probably be one of QNAP's built in factory apps.

Our affected NAS was only running one program that was not provided by QNAP. However, that one app relies on web server. Maybe the issue is the web server bit.

[nimblefinger5]

I thinks it's the SDDP app

If you say it because of the resemblance of the names, it may simply be a way to "hide" it. In any case, it would be very simple to know if those affected tell us about. Its also an application that is not installed by default, so the range of the attack would be quite limited.

I'm sure we'll get out of doubt very soon

mainly because of the names as sometimes things get hidden in plain sight but like you say it might be a way to hide it.
My only other reason is that as it's basically a upnp server i wonder if it has open ports or could be an additional part of a way in.

am just throwing out ideas in the hope it can be pieced together as QNAP will just eventually stick it in malware remover and not give us the full info

Looks like its back to the admin/web server as likely suspect

[QNAPDanielFL]

In addition, it seems that indeed my snapshoot have been deleted.

Would it be possible to make a support ticket and tell me the ticket number so we can look into this right away?

[domanm]

Recently, such addresses appear in VPN logs
91.191.209.234, 91.191.209.235, 91.191.209.236, 78.128.113.68, 78.128.113.67, 78.128.113.66, 78.128.113.70, 80.66.88.60
These addresses include attempts to log in to random users, recorded in the logs as "login failed".
It wouldn't be surprising, but every now and then I see a pppd process on my system with a connection set up for these addresses. This is confirmed by the netstat command.

For example, IP 78.128.113.68 in logs (login attempt on January 19)

log.png

The same IP address is visible on another day in the processes (January 20)

ps.png

and in netstaton on January 20

netstat.png

Login attempts do not coincide with pppd sessions (sometimes they are one day earlier and sometimes later).
Jednak w ostatnich kilku tygodniach nawiązywane sa płączenia z serweram z usługą pppd, która ma uprawnienia roota.

[Comy86]

I've decided to pay the ransom. I know that's not how we should deal with this kind of situations, but I have no choice, the information that I had is essential. Unfortunately, it's a hard-learned lesson.
I'll let you know how it goes.
After it will decrypt the files, I'll copy them on another HDD and then deal with the NAS and the NAS HDD's (while I'll keep the NAS disconnected from the internet)
After this, I'll come back and ask advices on how to protect&back-up my NAS

Did you recive valid key?
Tell more. Let me know if it was possible to decrypt it, or whether the swindlers.

Yes, i've received a valid key
I've managed to decrypt 7746 files before QNAP forced an update and I couldn't stop it. After update, i searched for files with the extension *.deadbolt and found 10234 files, but my luck is that out of all of those, 9606 files i can copy from the server at work, 527 files we're in the Recycle folder (so old files) and another 101 files that don't have much value. I managed to recover the essential.

Regarding the steps i took, you can follow this steps
https://www.bleepingcomputer.com/forums ... try5313557

I paid with coinbase. Be sure to have more than just 0.03 btc, otherwise the commission for the transaction will be deducted from the sum you are paying (0.03 btc)

[domanm]

By the way, I have a question if you have VPN PPTP enabled on your servers?
I have a strong suspicion that there is a software vulnerability there and that a session is being established without proper authorization.
I am monitoring the server and I have evidence that foreign addresses established sessions with my server and then entered the server as random users.

If in fact all attacked servers had VPN PPTP enabled, the problem is with this service, not with access via www, myQNAPCloud or HBS 3.

Our affected NAS was not running PPTP or any other VPN on it.
Please share more info regarding the foreign addresses you have discovered. Country of origin would be helpful for us.

Recently, such addresses appear in VPN logs
91.191.209.234, 91.191.209.235, 91.191.209.236, 78.128.113.68, 78.128.113.67, 78.128.113.66, 78.128.113.70, 80.66.88.60
These addresses include attempts to log in to random users, recorded in the logs as "login failed".
It wouldn't be surprising, but every now and then I see a pppd process on my system with a connection set up for these addresses. This is confirmed by the netstat command.

For example, IP 78.128.113.68 in logs (login attempt on January 19)

log.png

The same IP address is visible on another day in the processes (January 20)

ps.png

and in netstaton on January 20

netstat.png

Login attempts do not coincide with pppd sessions (sometimes they are one day earlier and sometimes later).
Jednak w ostatnich kilku tygodniach nawiązywane sa płączenia z serweram z usługą pppd, która ma uprawnienia roota.