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

[yemartin]

I've just been checking the BTC address given to users...

I believe you checked the BTC address given to one user (and reported on Bleeping Computer). There is no reason for that address to be the same for everyone: BTC addresses don't cost anything to create, they are (almost) just random numbers. And on the other hand, there are good reasons for the address to be different for each NAS:

1) Since the hackers are not asking for any other data, there is a high chance that the decryption key is derived from the BTC address itself, using the master key that the hackers are trying to ransom QNAP for 50 BTC. If that's the case, then you can be pretty sure that each address is unique. Otherwise a single decryption key would decrypt everyone's data, and the hackers would not make much money once it is published.

2) Another reason for different addresses is laundering the money: all BTC transactions are public. So if all the ransoms went to the same well-known address, it is easy to track where that money goes afterwards, so it takes extra effort to launder. But if the addresses are all different, unless the victims come forward, there is no way to identify the ransom payment transactions.

Here is an example BTC address that, reportedly, got someone a working decryption key:
https://www.blockchain.com/btc/address/ ... yylj65fvdm

You can see the OP_RETURN at the bottom of the transaction details:
https://www.blockchain.com/btc/tx/b0653 ... aab804cddf

So their decryption key was 5f144b4c18e8794587b60c8f60c49372

[Comy86]

I've just been checking the BTC address given to users... it's not showing any transactions (which seems odd as a few people say they've paid).

https://www.blockchain.com/btc/address/ ... qm93j9jcul

Is anyone here familiar with BTC transactions who knows why?

Every infected user/NAS has a different(unique) BTC address allocated from what I gather.
Here is a post on pg 2 of this topic
viewtopic.php?p=808594#p808594

[OneCD]

I believe you checked the BTC address given to one user (and reported on Bleeping Computer). There is no reason for that address to be the same for everyone: BTC addresses don't cost anything to create, they are (almost) just random numbers. And on the other hand, there are good reasons for the address to be different for each NAS:

1) Since the hackers are not asking for any other data, there is a high chance that the decryption key is derived from the BTC address itself, using the master key that the hackers are trying to ransom QNAP for 50 BTC. If that's the case, then you can be pretty sure that each address is unique. Otherwise a single decryption key would decrypt everyone's data, and the hackers would not make much money once it is published.

2) Another reason for different addresses is laundering the money: all BTC transactions are public. So if all the ransoms went to the same well-known address, it is easy to track where that money goes afterwards, so it takes extra effort to launder. But if the addresses are all different, unless the victims come forward, there is no way to identify the ransom payment transactions.

Here is an example BTC address that, reportedly, got someone a working decryption key:
https://www.blockchain.com/btc/address/ ... yylj65fvdm

You can see the OP_RETURN at the bottom of the transaction details:
https://www.blockchain.com/btc/tx/b0653 ... aab804cddf

So their decryption key was 5f144b4c18e8794587b60c8f60c49372

Ah, I'm beginning to understand. Thank you.

I only checked that single address as the previous malwares I'd followed provided only a single address to victims. But, I think they received their decryption key via a different method to this one.

Welcome to the forum.

[OneCD]

Every infected user/NAS has a different(unique) BTC address allocated from what I gather.
Here is a post on pg 2 of this topic
viewtopic.php?p=808594#p808594

Got it. Cheers!

[Zeroes1gnol]

I'm beginning to get spooked by how often QNAP is in the news with security flaws lately. I was hoping someone could shed a light on my situation. I have two NAS devices, on separate locations. They remote replicate to each other for backups. I checked them this morning, no sign of any ransomware.

I'll sum up my security situation:
-Security, Allow/Deny list is set to 'Allow connections from the list only'. So IP whitelist. Only trusted IP addresses are added. I figure this would be enough to keep ransomware at bay, but can't find any conclusive evidence that it does.
-Web server is not running
-WebDAV service is running on one of the two devices. It uses a dedicated port, which is opened on my modem, only https, port 435
-NAS to NAS remote replication is running on port 22, SSH

Will this be enough?

[Hulli]

Hello, I have seen this morning that I got infected, luckily it seems that no file have been encrypted yet. So i'm trying to remove it before it can do any harm. I have succeded to restore index.html by connecting in ssh.

I have tried what was suggested in earlier page of this post, remove file in mnt/HDA_ROOT:

Code: Select all

[/mnt/HDA_ROOT] # ls -la
total 1016
drwxr-xr-x  9 admin administrators   4096 2022-01-27 04:49 ./
drwxr-xr-x 17 admin administrators    360 2022-01-27 08:02 ../
-rwxr-xr-x  1 admin administrators 960896 2022-01-25 16:58 13813*
-rw-r--r--  1 admin administrators    501 2021-11-12 15:02 .conf
drwxr-xr-x 61 admin administrators  12288 2022-01-27 08:20 .config/
drwxrwxrwx  2 admin administrators   4096 2022-01-27 04:54 .inited/
drwxr-xr-x  9 admin administrators   4096 2022-01-27 08:13 .logs/
drwx------  2 admin administrators  16384 2019-10-26 18:00 lost+found/
-rw-r--r--  1 admin administrators   5062 2020-07-08 17:40 md_backup_2020-07-08_17.40.08
-rw-r--r--  1 admin administrators   5065 2020-07-08 18:06 md_backup_2020-07-08_18.05.17
-rw-r--r--  1 admin administrators      0 2019-11-02 11:39 .nfs_fix_check
-rw-r--r--  1 admin administrators      0 2019-10-26 11:05 .QTS.installed
-rw-r--r--  1 admin administrators      0 2019-10-26 11:05 .QTS.installed.notice
drwxr-xr-x  2 admin administrators   4096 2022-01-27 04:41 ssl_lib/
lrwxrwxrwx  1 admin administrators     24 2020-04-10 16:28 twonkymedia -> /mnt/ext/opt/twonkymedia
drwxr-xr-x  2 admin administrators   4096 2021-03-17 12:49 update/
drwxr-xr-x  3 admin administrators   4096 2022-01-27 04:57 update_pkg/

But,

Code: Select all

[/mnt/HDA_ROOT] # rm -f 13813
rm: can't remove '13813': Operation not permitted

I can't remove this file.

And there is no process with this PID:

Code: Select all

[/mnt/HDA_ROOT] # kill 13813
-sh: kill: (13813) - No such process

I have also looked that what process looked suspicious to me, but nothing it using CPU or writing intensively to the drive.

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

So if someone has idea on how to find it and remove it before it can do any harm I would be thankful.

Also, if it can help, my nas rebooted during the night, maybe that's what prevent it from acting?

Try the following:

kill -9 13813
chattr -i 13813
rm 13813

should work...


brgds

Hulli

[FSC830]

I guess, problem here is that PID is not always the same at each NAS!
If no process exists with the PID, the command will run into the output as seen above: "No such process".

Regards

[swisshuttles]

I've just been checking the BTC address given to users...

I believe you checked the BTC address given to one user (and reported on Bleeping Computer). There is no reason for that address to be the same for everyone: BTC addresses don't cost anything to create, they are (almost) just random numbers. And on the other hand, there are good reasons for the address to be different for each NAS:

1) Since the hackers are not asking for any other data, there is a high chance that the decryption key is derived from the BTC address itself, using the master key that the hackers are trying to ransom QNAP for 50 BTC. If that's the case, then you can be pretty sure that each address is unique. Otherwise a single decryption key would decrypt everyone's data, and the hackers would not make much money once it is published.

2) Another reason for different addresses is laundering the money: all BTC transactions are public. So if all the ransoms went to the same well-known address, it is easy to track where that money goes afterwards, so it takes extra effort to launder. But if the addresses are all different, unless the victims come forward, there is no way to identify the ransom payment transactions.

Here is an example BTC address that, reportedly, got someone a working decryption key:
https://www.blockchain.com/btc/address/ ... yylj65fvdm

You can see the OP_RETURN at the bottom of the transaction details:
https://www.blockchain.com/btc/tx/b0653 ... aab804cddf

So their decryption key was 5f144b4c18e8794587b60c8f60c49372

Are there any other users here with a successful transaction confirmation?

[Hulli]

I guess, problem here is that PID is not always the same at each NAS!
If no process exists with the PID, the command will run into the output as seen above: "No such process".

Regards

of cause, every NAS has its own PID generated by the ransomeware.
In the case above the PID was as it is..


brgds

Frank

[swisshuttles]

I paid the ransome but I never got the decryption key. Horrible

Hey Vogstar do you have a transfer confirmation like this one? https://www.blockchain.com/btc/tx/b0653 ... aab804cddf

A a prove to the other users that payment doesn't work?

[genmaitya]

Code: Select all

[/mnt/HDA_ROOT] # ls -la
total 1016
drwxr-xr-x  9 admin administrators   4096 2022-01-27 04:49 ./
drwxr-xr-x 17 admin administrators    360 2022-01-27 08:02 ../
-rwxr-xr-x  1 admin administrators 960896 2022-01-25 16:58 13813*
-rw-r--r--  1 admin administrators    501 2021-11-12 15:02 .conf

"13813" is filename.
The command "kill" sends the specified signal to the specified process ID.
File name and process ID are different.
Please check the process ID with the "ps" command.

[Comy86]

I don t know much about crypto, blockchain etc., but i think that the transaction indicated with the green error is the commission fee (and with red arrow is the amount of 0.03)
https://www.blockchain.com/ru/btc/addre ... yylj65fvdm

[sanke1]

My ISP has CG-NAT on IPv4 so port forwarding is not possible. I had disabled My QNAP Cloud and UPNP. However, my NAS on latest firmware 5.0.0.1891 was exposed to internet using Stativ IPv6.

Thankfully, not infected...... yet. I promptly blocked my QNAP's IPv6 in Asus router's firewall. Anything else I need to do ?

[atrentin]

Buongiorno,
come posso ripristinare la pagina iniziale del QNAP?
Sto provando a killare il processo, ma non ci riesco.
Chi mi può aiutare?
Grazie

[SimonKenoby]

Hello, I have seen this morning that I got infected, luckily it seems that no file have been encrypted yet. So i'm trying to remove it before it can do any harm. I have succeded to restore index.html by connecting in ssh.

I have tried what was suggested in earlier page of this post, remove file in mnt/HDA_ROOT:

Code: Select all

[/mnt/HDA_ROOT] # ls -la
total 1016
drwxr-xr-x  9 admin administrators   4096 2022-01-27 04:49 ./
drwxr-xr-x 17 admin administrators    360 2022-01-27 08:02 ../
-rwxr-xr-x  1 admin administrators 960896 2022-01-25 16:58 13813*
-rw-r--r--  1 admin administrators    501 2021-11-12 15:02 .conf
drwxr-xr-x 61 admin administrators  12288 2022-01-27 08:20 .config/
drwxrwxrwx  2 admin administrators   4096 2022-01-27 04:54 .inited/
drwxr-xr-x  9 admin administrators   4096 2022-01-27 08:13 .logs/
drwx------  2 admin administrators  16384 2019-10-26 18:00 lost+found/
-rw-r--r--  1 admin administrators   5062 2020-07-08 17:40 md_backup_2020-07-08_17.40.08
-rw-r--r--  1 admin administrators   5065 2020-07-08 18:06 md_backup_2020-07-08_18.05.17
-rw-r--r--  1 admin administrators      0 2019-11-02 11:39 .nfs_fix_check
-rw-r--r--  1 admin administrators      0 2019-10-26 11:05 .QTS.installed
-rw-r--r--  1 admin administrators      0 2019-10-26 11:05 .QTS.installed.notice
drwxr-xr-x  2 admin administrators   4096 2022-01-27 04:41 ssl_lib/
lrwxrwxrwx  1 admin administrators     24 2020-04-10 16:28 twonkymedia -> /mnt/ext/opt/twonkymedia
drwxr-xr-x  2 admin administrators   4096 2021-03-17 12:49 update/
drwxr-xr-x  3 admin administrators   4096 2022-01-27 04:57 update_pkg/

But,

Code: Select all

[/mnt/HDA_ROOT] # rm -f 13813
rm: can't remove '13813': Operation not permitted

I can't remove this file.

And there is no process with this PID:

Code: Select all

[/mnt/HDA_ROOT] # kill 13813
-sh: kill: (13813) - No such process

I have also looked that what process looked suspicious to me, but nothing it using CPU or writing intensively to the drive.

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

So if someone has idea on how to find it and remove it before it can do any harm I would be thankful.

Also, if it can help, my nas rebooted during the night, maybe that's what prevent it from acting?

Try the following:

kill -9 13813
chattr -i 13813
rm 13813

should work...


brgds

Hulli

Thank you. I still could not kill the process, don't exist, but I could remove the file.
After looking with find in SSH I could find somefiles that had been encrypted, but is seems that it stop after my nas rebooted tonight, I also looked in crontab to see of there was anything automatic at startup and didn't found anything suspect, but I don't have enough experience with that to be sure of it.