Was hit with Ransomware - now everything is a mess

[jesseasi]

I was hit with with a ransomware virus.  Phobos.  They wanted $20K USD to decrypt everything.  Over 15 years of data lost.  I am not paying that.

 

I have started the process of restoring what I have from backups and downloading stuff again.

 

But I was so worried about my server still being infected.   Data transfers were painfully slow - only 20mb/s.  I removed the parity drive and it got up to 38mb/s.  But back before this virus I was able to transfer to 110mb/s to my cache drive and much faster than 20-38mb/s to non-cached shares.  So I became worried maybe there was still a virus....

 

I found a post there this command was to be run: 

 

docker run --name ClamAV -v /mnt/user:/scan:ro tquinnelly/clamav-alpine -i

 

I did it - it did some stuff.  But suddenly all my drives and shares started disappearing and reappearing.  I did a shutdown and rebooted.

 

Now all my drives and shares show up - everything looks ok.  But I can't access any shares over the network.  I have no idea what is going on.

 

Where do I start - what do I do?

 

tower-diagnostics-20221009-0702.zip

[Frank1940]

Where was the Ramsomware running from?   Most of the time, it is a Windows PC.   You want to try to figure out the actual source of the problem as opposed to the target.  (which in you case --most likely-- is your Unraid server.)

 

Were all the shares affected?

 

Were you using Windows 'mapped' drives to access the shares?

50 minutes ago, jesseasi said:

I did it - it did some stuff.  But suddenly all my drives and shares started disappearing and reappearing.  I did a shutdown and rebooted.

 

Now all my drives and shares show up - everything looks ok.  But I can't access any shares over the network.  I have no idea what is going on.

 

 

In your syslog is this:

 

Oct  9 07:00:22 tower  smbd[5067]:   exit_daemon: daemon failed to start: smbd can not open secrets.tdb, error code 13

....

....

Oct  9 07:00:22 tower  winbindd[5080]:   Failed to open /var/lib/samba/private/secrets.tdb
Oct  9 07:00:22 tower  winbindd[5080]: [2022/10/09 07:00:22.661969,  0] ../../source3/winbindd/winbindd.c:1578(main)
Oct  9 07:00:22 tower  winbindd[5080]:   Could not initialize domain trust account secrets. Giving up

 

I did a Google search on this  error  and found this post:

 

https://forums.unraid.net/topic/38469-smbd-fails-to-start/

 

See If that resolves the problem.

 

I did a quick look at your share settings and the ones I sampled were all set to 'Public'.    After you have things straighten out, I would recommend that you consider tightening your security up.  Read these two threads:

 

           https://forums.unraid.net/topic/110580-security-is-not-a-dirty-word-unraid-windows-10-smb-setup/

and

           https://forums.unraid.net/topic/58374-secure-writing-strategy-for-unraid-server-using-write-once-read-many-mode/

 

I realize that these suggestions are a bit of locking the barn door after the horse has been stolen....

    

[jesseasi]

The computers that were the source was a windows 10 VM  running on an ESXi Server.  yes shares were mapped - this is my fault.  I have since turned off that VM.  I deleted every encrypted file from unraid that I could find.

 

I will look into that secrets suggestion.  

 

Thank you so much for the response - I will report back later.

 

[jesseasi]

Ok.  I can’t even find this file to rename / delete it.  

[Frank1940]

Look here:

 

(Apparently, the location of the file has been changed...)

[jesseasi]

Thank you so much!   Renaming that secrets file has got me back online.  Still dealing with slower than normal transfer rates.  But I am making progress again.  

[Frank1940]

1 hour ago, jesseasi said:

Still dealing with slower than normal transfer rates.  But I am making progress again.  

 

6 hours ago, jesseasi said:

I removed the parity drive and it got up to 38mb/s

 

I assume you are still in this configuration.  If so, let me say that Unraid does not have fast write performance.  Particularly if you are dealing with User Shares.  The file creation process for User Shares is long and slow.  (Remember that Unraid was originally designed for a 'write_once/read_many' type of environment.)  The problem can be further compounded by writing large numbers of small files where the slowest of the file creation problem is compounded by the disk head movement time between the file tables and data sections of the hard disk.  To this, you also have to add the track latency to get to the proper sector for the write.  (This ignores the SMR type hard drive slow write issues that can occur during large transfers of data to a single disk which will slow things even slower.)

 

I know that when I make my monthly data backups (tens of thousands of small files) of my Windows computers, the write speeds will drop to about 50MB/s to an SSD cache drive.  When I copy a 20+GB mkv file that transfer speed will be about 110MB/s.