halbaradkenafin

Happy Birthday @ZeroHour and @DalekSec

GPP is the best way, plus it means that if the files are deleted (due to rebuild or something) then they'll be recreated on next boot.

No but the Office GPOs will allow you to restrict the running of macros. Plus I'd imagine that the macro just downloads the exe for it and runs that rather than having the main payload itself.

Isn't this the sort of thing ECDL was created for? I'm not sure if it's still around but finding the materials that were used to teach it should be easy enough

That's a good point. It's something I've got to look into and narrow down where we've got stuff installed on our machines, I think the only thing not in Program Files or Windows is Python due to it's default install being in the root. It's on my list of things to look into fixing soon, and it's either that method or AppLocker. I'll probably go with the GPO option as it's a little easier to manage for both of us here (AppLocker is probably very easy to manage and has Powershell access but we've already got GPOs in place). Edit: Skimming through our GPO again and it looks like we've got at least one which is %appdata%**.exe, no idea if that would work for nested folders though so I'll probably still give it try doing white listing rather than black listing.

You can do it in GPO using Software Restriction Policies, and using things like %temp% and %appdata% so it will work whether you redirect appdata or not.

For those who requested it: http://www.edugeek.net/forums/how-do-you-do/159149-cryptolocker-prevention.html#post1359677

[h=1]CryptoLocker Prevention[/h] This document will cover the various safeguards that have been put in place to prevent, or limit the effects of, Cryptolocker and its variants in their current forms. It will be updated as best as possible as new strains are discovered and researched by the wider security community. As the severity of a Crypto* infection is very high it’s necessary to use a multi-layered approach to protecting the network, this includes a GPO for software restriction policies, file screen rules for executable files and a file screen rule for the “ransom” files that are created should it get through the other layers. [h=2]Software Restriction Policy GPO[/h] The primary delivery methods of Crypto*, for the currently known variants, is either via email attachment (zip files or macros in Office documents mostly) or via Flash ads/banners on websites. Most of these methods will not actually contain the Crypto* executable itself but will download it from some central site (or sites) that it’s hosted on, this is primarily to get around the blocking of exe files in emails and attachments that almost every email provider does as standard. This means that the exe will almost always try to run from either the temp directory or the appdata directory, to combat this the following Software Restriction Policies are in place to apply to all computers on the network: Set to Disallowed: %appdata%*.exe %appdata%*.bat %appdata%*.ps1 %Application Data%*.exe %Application Data%*.bat %Application Data%*.ps1 %temp%*.exe %temp%*.bat %temp%*.ps1 %temp%*.zip*.exe %temp%\7z\*.exe %temp%\rar\*.exe %temp%\wz\*.exe %userprofile%*.bat %userprofile%*.exe %userprofile%*.ps1 This should cover the primary locations (and aliases) that the exes can run from. A more restrictive policy would be to prevent any executables outside the Windows and Program Files directories running, or to use AppLocker to further limit what end users can run. We currently don’t implement either of these options but they should be considered for investigation in the future to improve the security of the network. [h=2]File Screen Rules – Executables[/h] These file screen rules are primarily to prevent users from saving various executable files to the network drives but have the added benefit of also limiting Crypto*’s impact, particularly in cases where users may save untrusted files from any external drives they have or emails they receive. To configure the File Screens, open File Server Resource Manager (fsrm.msc) and configure the File Screen Template for the Block Executable Files template. By default it is already mostly configured but some modifications can be made, such as setting the email address to send notification emails. Once that is configured it’s necessary to assign the template to a location, right click File Screens and choose “Create File Screen”. Choose the path you want to assign it to, choose the template to use (“Block Executable Files”) and click create. We currently have two in place on each file server, one at the root of the Shared drive folder (Staff Shared and Student Shared) and one at the root of each user drive folder (Staff Users and Student Users). If you use separate folders for the profile and home folders of the users and they aren’t stored within another folder, such as D:\Staff\Home and D:\Staff\Profile or similar, then you’ll need to create a File Screen for each folder. [h=2]File Screen Rules – Ransom Files[/h] As part of Crypto*’s encryption process it creates some text files in the folders it encrypts to let the user know how to recover their files, at the cost of a few bit coins usually. The actual encryption of the files can’t be detected directly once it’s started (other than trying to open an encrypted file) but the creation of these files can be detected using File Screen Rules. The process for creating a new File Group is very straight forward, though a little long winded when specifying more than a few file names. There is a short Powershell command below that will create the file group for you with all the keywords I’ve found so far. Ensure you give it a meaningful name, I use “Cryptolocker Variants”. New-FSRMFileGroup –Name “Cryptolocker Variants” –IncludePattern @(”*.*AES256”,”*.*cry”,”*.*crypto”,”*.*darkness”,”*.*enc”,”*.*encrypted”,”*.*exx”,”*.*kb15”,”*.*kraken”,”*.*locked”,”*.*nochance”,”*.*oshit”,”*@gmail_com_*”,”*@india.com*”,”*cpyt*”,”*crypt*”,”*decipher*”,”*install_tor*.*”,”*keemail.me*”,”*qq_com*”,”*ukr.net*”,”*.*enc*”,”*restore_fi*.*”,”*help_restore*.*”,”*how_to_recover*.*”,”*.ecc”,”*.exx”,”*.ezz”,”*.frtrss”,”*.vault”,”*want your files back.*”,”confirmation.key”,”enc_files.txt”,”last_chance.txt”,”recovery_file.txt”,”recovery_key.txt”,” vault.hta”,”vault.key”,”vault.txt”,”*.aaa”,”help_restore*.*”,”how_to_recover*.*”,” install_tor*.*”) Once the file group is created you need to create a File Screen Template, right click the File Screen Templates and choose “Create File Screen Template”. Give it a meaningful name, tick the box for “Cryptolocker Variants” (or whatever you named yours) within the File Groups box. On the Email Message tab set an email address to send to and update the Email Message as you see fit, the one we use is: This will give us a short email with the full path and user who tried to save the ransom file. On the Command tab tick the box for running a command and browse to the location of Powershell.exe (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe) and within the Command Arguments box type: Change the path of the ps1 file to wherever you decide to save the file. I’ve set the command to run as Local System to ensure the minimal amount of permissions problems. With that done click Okay and create a File Screen to apply that template to the root of the drive holding your shares, or multiple if they are spread across many drives. The last thing that needs to be doing is adding in the credentials for the script to use when contacting other file servers. This can be handled one of two ways; either specify the credentials directly in the PowerShell file (not recommended) or encrypt the password in another file and access it in the script (how it currently functions). For specifying the credentials in the PowerShell script modify the $Pass variable to the following: [i]$pass = “PasswordHere” | ConvertTo-SecureString –AsPlainText –Force[/i] For encrypting the password in another file then run the following from a PowerShell prompt while logged in as the user who the script will run as (Domain Admin preferred but anyone who can successfully run the Block-SMBShareAccess command on file servers). [i]“Passwordhere” | ConvertTo-SecureString –AsPlainText –Force | ConvertFrom-SecureString | Out-File “C:\File.ini”[/i] Change the file.ini to wherever you wish to store the password file and update the script to point to the same location. It’s necessary to do this as the user specified in the script due to the way PowerShell handles SecureString values and their encryption, they can only be correctly decrypted and used by that specific user on that specific machine. Once this is completed it’s worth testing this using one of your test accounts, create a file that contains the word “crypto” in its name and you should then receive and email and find that user’s access to the server has been blocked. If you’re satisfied that the process works correctly then repeat this process for each file server you have. NOTE: Both the following scripts will need to be modified to match your environment, if you've got less file servers (or servers with shares on them) then remove the extra Invoke-Commands, if you've got more then duplicate them and change the names. Disconnect-SMBShares.ps1 <# .Synopsis Removes a users access to all network shares from file and app servers .DESCRIPTION This script will remove all access a user has to the SMB shares from the file and app servers and is run as part of the cryptolocker mitigation structure by the FSRM passive rule when detecting the decrypt.txt files (and variants). .EXAMPLE .\Disconnect-SMBShares.ps1 -Username "Bloggs.J" This will remove access to all SMB shares for bloggs.j #> param( [string]$username = "" ) $ShareDescription = ("Remote Admin","Remote IPC","Default Share") $Pass = Get-Content C:\File.ini | ConvertTo-SecureString $Cred = new-object -typename System.Management.Automation.PSCredential -argumentlist "wsh\administrator",$pass if ($env:computername -eq "Fileserver01") { Get-SmbShare | Where { $ShareDescription -notcontains $_.Description -and $_.Name -ne "MTATempStore$"} | Block-SmbShareAccess -AccountName $username -Confirm:$false invoke-command -ComputerName "Fileserver02" -Credential $Cred -scriptblock {Get-SmbShare | Where { $Using:ShareDescription -notcontains $_.Description -and $_.Name -ne "MTATempStore$"} | Block-SmbShareAccess -AccountName $using:username -Confirm:$false} invoke-command -ComputerName "AppServer01" -Credential $Cred -scriptblock {Get-SmbShare | Where { $Using:ShareDescription -notcontains $_.Description -and $_.Name -ne "MTATempStore$"} | Block-SmbShareAccess -AccountName $using:username -Confirm:$false} } elseif ($env:computername -eq "FileServer02") { Get-SmbShare | Where { $ShareDescription -notcontains $_.Description -and $_.Name -ne "MTATempStore$"} | Block-SmbShareAccess -AccountName $username -Confirm:$false invoke-command -ComputerName "FileServer01" -Credential $Cred -scriptblock {Get-SmbShare | Where { $Using:ShareDescription -notcontains $_.Description -and $_.Name -ne "MTATempStore$"} | Block-SmbShareAccess -AccountName $using:username -Confirm:$False} invoke-command -ComputerName "AppServer01" -Credential $Cred -scriptblock {Get-SmbShare | Where { $Using:ShareDescription -notcontains $_.Description -and $_.Name -ne "MTATempStore$"} | Block-SmbShareAccess -AccountName $using:username -Confirm:$false} } elseif ($env:computername -eq "AppServer01") { Get-SmbShare | Where { $ShareDescription -notcontains $_.Description -and $_.Name -ne "MTATempStore$"} | Block-SmbShareAccess -AccountName $username -Confirm:$false invoke-command -ComputerName "FileServer01" -Credential $Cred -scriptblock {Get-SmbShare | Where { $Using:ShareDescription -notcontains $_.Description -and $_.Name -ne "MTATempStore$"} | Block-SmbShareAccess -AccountName $using:username -Confirm:$false} invoke-command -ComputerName "FileServer02" -Credential $Cred -scriptblock {Get-SmbShare | Where { $Using:ShareDescription -notcontains $_.Description -and $_.Name -ne "MTATempStore$"} | Block-SmbShareAccess -AccountName $using:username -Confirm:$false} } Connect-SMBShare.ps1 This is the script I run after I've investigated the possible infection and am sure that it's cleaned up completely. In the case of a real infection (which I haven't had yet thankfully) I'd reimge the PC, restore from Shadow Copies or other back ups any effected files (and probably a folder or two around them just to be sure). This doesn't have to be run from a server and can just be run for any PC with Powershell, but it does need sufficient credentials to actually make the changes to the fileserver permissions. <# .Synopsis Returns a users access to all network shares from file and app servers .DESCRIPTION This script will return all access a user has to the SMB shares from the file and app servers and is run as part of the recovery from cryptolocker. This should only be used after the effected PC has been removed from the network and rebuilt, and the effected files restored using Shadow Copies or other backups. .EXAMPLE .\Connect-SMBShares.ps1 -Username "Bloggs.J" This will Return access to all SMB shares for bloggs.j #> param( [Parameter(Mandatory=$True)] [string]$username ) $ShareDescription = ("Remote Admin","Remote IPC","Default Share") $Cred = Get-Credential invoke-command -computername "Fileserver01" -Credential $Cred -ScriptBlock {Get-SmbShare | Where { $Using:ShareDescription -notcontains $_.Description -and $_.Name -ne "MTATempStore$"} | Unblock-SmbShareAccess -AccountName $Using:username -Confirm:$false} invoke-command -ComputerName "FileServer02" -Credential $Cred -scriptblock {Get-SmbShare | Where { $Using:ShareDescription -notcontains $_.Description -and $_.Name -ne "MTATempStore$"} | Unblock-SmbShareAccess -AccountName $using:username -Confirm:$false} invoke-command -ComputerName "AppServer01" -Credential $Cred -scriptblock {Get-SmbShare | Where { $Using:ShareDescription -notcontains $_.Description -and $_.Name -ne "MTATempStore$"} | Unblock-SmbShareAccess -AccountName $using:username -Confirm:$false} Sources: Generally helpful info: Stop CryptoLocker (and copy-cat variants of this badware) before it ruins your day - Samples - JPELECTRON.COM Some more file screen keywords: File Screening List for Ransomware - Pastebin.com Plus various comments on reddit.com/r/sysadmin when searching for cryptolocker Improvements and suggestions are welcome.

File Screen rules are your friend for this. Server 2012R2 comes with an already defined Block Executables template and I'd guess 2008R2 does as well.

I'm in the process of documenting it for our own records and will post it up to the "How do you do it" forum once that's done. I'll also include various links that I've used to compile the information. There are some strains that are delivering through Flash ads/banners as well, which is just one more reason that Flash needs to be shoved into a very deep hole and forgotten about.

I will say that it's not really worth buying packs on their own unless they are on special. It's more efficient to use the gold for Arena entry, even if you scrub out at 0-3 then you get a pack, if you get at least 7 wins then you should be making a profit from the rewards.

We've got some GPOs (main thing was not allowing files to run from the Temp file locations) but also some file server rules that check for the creation of the ransom files, once they find them it pings off an email to myself and the network manager with username, file name and location and also runs a Powershell script to kill that users access to all file shares on all the file servers. Testing has shown that access is cut within seconds of the files appearing, thankfully we haven't been hit with it yet and I don't really want to either.

This thread has reminded me that I haven't posted a quick guide for the various Cryptolocker prevention I've put in place. If all goes well and it works as intended (touch wood) then we'll at worst have to restore one folder on one share and that's all (and image the machine of course). I'll try to get it posted today or tomorrow.

I log in sometimes, play a few games (usually Tavern brawl) to get my quests done and then log off. I keep meaning to play more arena with the gold I've built up but never feel in the mood for it.

Cunninghams and biostore used to partner for their cashless catering and provided a good service, we've got them here and things work well (better than Vericool in my experience of both). I'm not sure what the products that they are both providing separately are like but I'd suspect they are pretty good. Support from both has been very good, a quick phone call and they'll solve most of your problems quickly.

CryptoWall/Locker/etc go through each mapped drive and encrypt each folder in turn, after it encrypts a folder it drops those files in it to let people know how to recover their data.

And because battleship mining fills up too quickly, plus I had a freighter alt sitting on a spare account and figured I'd put it to some use.

Need to decide where to go with my Orca alt after they get that and various fitting skills. Possibly top off the mining skills to get an exhumer for when I'm on alone (Hal has basically no mining skills) and then I don't know where to go from there.

That should work fine. That's what we do with leavers here. You'll have to delete the leavers work to get the storage back. But I'd assume the school will want to keep hold of it for a little while in case any of them come back asking for work. Our policy is just keep the work for around a year and delete it then, we've still got a copy on backup if they really need it but we assume that after a year they probably would have come to get it if it was that important.

Comment of the night from TS: @LiamHaith: I think I'm getting high on Duct Tape.

That doesn't sound as fun.

More people are always welcome. Just over a week and my alt will be in an Orca, just over a month and my main can be in a Golem (or a few days and he can be in a Paladin) but those things are pretty expensive so I'll stick with my Raven for now.

Or if you've got the AD module on your exchange box then you can do this: Get-ADUser -SearchBase OU=OUNAME,DC=DOAMIN,DC=LOCAL' -Filter '*' | % { [color=#333333]Get-Mailbox -identity $_.Samaccountname | Set-Mailbox -HiddenFromAddressListsEnabled $true} [/color]

Working from the last year and moving them to Leavers then working from there is definitely the best way to handle it. I'd look at the group policies to make sure any folder redirection will still work for those groups. Moving home folders will be reasonably easy after that as it will be the same process as for AD, but will probably take a while longer depending on how much they save in the folders. Edit: You could easily script this with Powershell but I'd probably get the manual process out of the way first and then work on that separately. Moving to a system using intake year is probably a good idea though, I'm not sure why many schools use year group OUs rather than intake years since the amount of work to start a new year is considerably more than is really needed.

Jump on TS some time and I'm sure @LiamHaith and @Garacesh will convince you too. Or save yourself and run far from this thread. I'm not sure which is the wiser course of action.