- This topic has 2 replies, 2 voices, and was last updated 2 months, 2 weeks ago by
November 27, 2019 at 11:29 am #190675ParticipantTopics: 1Replies: 1Points: 15Rank: Member
Each night I connect from my 2016 Server to a Synology NAS via New-PSDrive to copy nightly backup from the Server to the Synology and this has worked with any issues until a few days ago.
I won’t go into the details of all the things that went wrong in a single day to allow this to happen, but some malware got onto the server and was beginning to encrypt the files. It just so happened by backup script ran, mapped the drive to the Synology and then those files were being encrypted.
In my limited understanding of how these things work, I’m guessing since my backup script mapped the drive, the malware just saw it as another folder and began doing it thing.
In my research I can across an article that says I can use Net Use command to use the UNC Path without having to assign a drive letter. The command I run inside PowerShell is net use \\188.8.131.52\homes\[folder] /user:[user] [password]
Once I run the above code I can access the Synology folder to copy my files. Before it was Z:\Backups and now it’s \\184.108.40.206\homes\Backups. This works for me and I can update my script to use the UNC were needed. After I ran the net use command I checked explorer and didn’t see any signs of a new drive or folder (on the Synology).
So my question is would this change protect the files on the Synology if this were to happen again down the road? Does anyone know of any Consultants in the Raleigh, NC area?
November 28, 2019 at 8:35 pm #190888ParticipantTopics: 10Replies: 119Points: 531Rank: Major Contributor
Yes, you could use the
net usecommand as per your post but there’s really no perfect protection against any zero day, hence, all the alternatives we attempt 🙂
You can store the password in a text file as an encrypted string. The in the script, convert the encrypted string back to a secure string, and then to plain text for use by
net use. Keep in mind that the account running the script must be the same one that created the secure/encrypted string.
Store password as encrypted string in file:
'SomePasswordForNAS' | ConvertTo-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Out-File EncryptedString.txt
Then in script:
$encryptedString = Get-Content -Path EncryptedString.txt | ConvertTo-SecureString $bstr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($encryptedString) $password = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($bstr) net use \\220.127.116.11\homes\Backups /user:domain\user $password ... # transfer backups net use \\18.104.22.168\homes\Backups /delete
Though, outside the scope of this forum, I recommend looking into the proactive security measures of a PAW implementation. The closer it is practiced, the smaller attack surface and better protection you’ll have.
November 28, 2019 at 9:03 pm #190906ParticipantTopics: 1Replies: 1Points: 15Rank: Member
Thanks for help and insight. I must admit my head is still spinning a bit and realize this is a game of least exposure. Backups, Backups, Backups…
- You must be logged in to reply to this topic.