CryptoWall SBS2011

Help....  logged in to our SBS2011 server today. We have an application that uses a SQL DB. It couldn't open the DB. When looking in the folder that holds the DB files, it looks like we've been hit by CryptoWall. The text file matches all the other one found that contain instructions how to "pay" to get the key to decrypt the files. We run SEP 12 RU1 on the server, so I'm really surprised this made it thru. Anyway, I'm running MalwareBytes now, and we're up to 77 detected objects. Where do we go from here ?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

malwarebytes is not going to fix your problem - your files are encrypted

you can either pay the ransom and fund terrorism, or restore from backup, AFTER you find the infected workstation

we had this happen to 3 clients last month, a user opened an attachment, and encrypted their whole computer, and all files on all mapped network drives they had access to

SEP was at all 3 clients, it's garbage.

after you remove/fix the infected workstation, restore backups, then employ a policy which prevents running EXE files from temporary locations (see the bottom of this link)

note: to find the infected workstation, look at the current OWNER of any encrypted file - then go find that user's desk

note:  paying the ransom will decrypt your files, will not fix the infected machine, and the ransom price will double after a few days

just to clarify, no antivirus on the server would stop this, the files were encrypted most likely from a workstation, by a user who had a mapped network drive to that server.  technically, there encrypted files (and decryption instructions) are not harmful or viruses, so nothing to detect there.  the problem is the workstation/user, it's probably still combing through mapped drives encrypting everything it can

search all the server(s) for any files starting with 'decrypt' - it will list all of the folders which are now encrypted, a good list of what needs to be restored from backup

if you dont have backups, you might be able to restore from offline files or previous versions, but this virus specifically is written to delete those first - they'll only be there if there was some weird fluke which prevented them from getting deleted.

no backups, no previous versions, your only other options are pay the ransom, or wait 8-10 months for a decryption program which MIGHT be able to decrypt them (and only after the creators are busted and the decrypt keys are obtained)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
adladladlAuthor Commented:
Not going to pay, that's for sure...  Yup -- some of the files are definitely owned by one of the client PCs. No data is stored on the PC. but it does map to a share on the server, so this makes sense.  We have backups, that's not a problem.  I'm thinking set the client to a prior restore point, make sure the server is "clean" (via Malwarebyes and SEP), delete the bad files, and restore from a backup prior to the infection. Make sense ?
makes sense but your restore points on the workstation are probably either gone or infected

remember, SEP in my opinion (and that of many others) is garbage - it didnt prevent it in the first place, why would a subsequent scan find and fix it?

hitman pro is a great program to find and fix this issue, as is ESET nod32 antivirus

please take a look at the link i pasted above, near the very bottom it shows a detailed way to prevent this type of infection by group policy, on all workstations, certain users, this user, etc... and there's an automated way to set it up too basically blocking EXE files from temp locations, compressed archives
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

adladladlAuthor Commented:
Okay -- thanks. If we have to, we can reload the PC from scratch... nothing to lose there except some time. I'll look at the group policy setup.
adladladlAuthor Commented:
Does the automated way to block .exe file have to be run on each client PC, or just the server ?  I assume each PC, but I wanted to verify.
the automated program can be ran on each workstation, or pushed through psexec, msi installer, startup script...

i usually do the automated program if just one or two users need to be protected from themselves... otherwise push the settings via group policy applied to certain groups or just everyone

the link also discusses ways you can remove/restrict the built-in file which is always used to create keypairs and encrypt the file - which isn't something that's normally used other than these types of viruses (cryptowall/cryptolocker/clones)
Philip ElderTechnical Architect - HA/Compute/StorageCommented:
Right click on the folder that contains your data and click on Previous Versions. Do any exist? If yes then restore a version that does not show the Decrypt message.

You can always restore from backup.
adladladlAuthor Commented:
Hmmm....  did all the scans, a reboot, deleted decrypt files, ..... still having problems.  Now I can't connect via remote web access....
scanning the server won't find anything (or fix anything)
decrypting the files will work, but unless you fix the workstation they'll get encrypted again

this virus encrypts almost every common file type, and you'll need to be sure to restore everything which was encrypted - for example, even a simple text file directing how IIS should work, would be encrypted if the user had access to it

thankfully, the virus drops "decrypt_instructions" into every single folder where it encrypted anything

so - searching the entire server, do you find any files named decrypt anywhere, and are the files next to them still encrypted?

did you deal with the workstation that caused this?  (it will have a random.exe in the users startup folder, among other folders in c:\ and %appdata%

as you verify the restore worked, delete the decrypt-data files so you can keep track of what you did so far or not...  

one more thing to consider - if your backups OVERWRITE each other and dont keep history, dont let it do another backup - you dont want the encrypted files overwriting the good ones
adladladlAuthor Commented:
I'm sick over this... the timing couldn't be worse.  I don't typically have physical access to the server... I get to it via Remote Web Workplace. After running Malwarebytes yesterday, it found several hundred "problems" and wanted to reboot to finish the cleanup.  Now, when I try to get in via RWA,  I get the initial username/pw screen (and it is coming from the server 'cause it tells me if the username/pw is not correct), but then it won't show me the screen to select which systems I can connect to...  I just get a big red "X" and "Cannot connect to Remote Web Access. Please contact the person who manages the server. "  So I can't get into the server without going to where it's located.

The only other thing I can think of is we run SEP on the server, but the server itself wasn't deployed as a "client" so I couldn't run a Symantec scan on the server. Before the reboot, I deployed Symantec Client to the server, ran a scan, and it found a few things Malwarebytes didn't find. I'm wondering if Symantec is now blocking RWA. Thoughts ?

At any rate, to answer some of your questions:

1) so - searching the entire server, do you find any files named decrypt anywhere, and are the files next to them still encrypted?  Yes -- we found over 400 files that started with "decrypt"... all in the same set of folders used by this one SQL application. We deleted them all. But I can't get back on remotely to search for others.

2) did you deal with the workstation that caused this?   We think so.... the original decrypt file we found was owned by one user. We ran Hitman Pro and other scans on her PC.... they didn't seem to find anything that looked like Crypto, but they did find a bunch of problems that they claimed to fix. I didn't look at other "decrypt" files to see if they had the same username or not. I'm thinking we "unshared" the infected drive until things on the server are back to normal (assuming that can happen).

3) I'll have to check on the backups.... I think it only keeps 3 or 4 days before overwriting, so it's hopefully not too late to stop this.
adladladlAuthor Commented:
Sorry -- I didn't get much sleep last night ... a couple of typos in my prior post:

I get to the server via "Remote Web Access" (not "Workplace")


"I'm thinking we "unshare" the infected drive until....  (not "unshared").

BTW -- the workstation that we think caused this (at least the one pointed to by the original decrypt file) is not currently on the network.  It's easy to reload a workstation from scratch if we need to....  but the server is a different story.
based on what you describe, i think your RWW access server is one server, and the actual remote desktop destination is the SBS server

it sounds like when the server rebooted, something's preventing it from starting back up - maybe missing/corrupt files?

obviously if you have some kind of 'lights out' connection to remotely see the console that would be ideal, but without that it may require looking at the server screen to see why it's not booting (if that's the case)

you could try remote desktop (start > run > mstsc ) and try to get to the same hostname as RWW - maybe someone left that route open... or if you previously installed some 3rd party permanent remote access like or

maybe you can remote into some other workstation, and then remote desktop to the sbs server?

in any case once you get control over the server, look for encrypted files (probably next to 'decrypt' files) - just try to open text/pdf/doc files and see if they open or not... if they report as 'corrupt' they are encrypted still

i would for sure write-protect the backup which has the decrypted versions on it...  even if that means stopping backups until you're sure you have restored everything you need to restore
adladladlAuthor Commented:
Okay -- I drove to get to the server (it is just one SBS 2011 server, not two separate servers).  It boots fine, but when I get into the Remote Web Access from the Dashboard, it shows "the domain name is not working".... there is a "repair" which I can try.... I'm just hesitant to run anything since it's unclear what's been infected.

Also, our backups are set up as "Full Server" (all server data, applications and system state).  Would a "system state" restore or a "entire C volume" restore be a smart thing to try  (from a few days prior to the "attack") ?
if not much has changed since the last full backup, it makes sense to consider doing that, especially if you can't determine what is broken or not... however, only you can make that decision, only you know what happened since the backup.  

there's always a chance of course that the full restore will fail, leaving you with an even-worse situation

what do the windows event logs show, any problems with system files?  ONLY things this user had access to should be encrypted... if they didnt have access to c:\windows\system32 on the server those wont be harmed... consider what they had access to and think what critical files might be affected

you can also look at the date on any of the 'decrypt_instructions' - the date and time will give you an indication of when they were encryped - just search the whole server for any files modified in that time window and see if any of those are (a) still encrypted and (b) critical to the operation of the server

also, set up some kind of permanent remote access for yourself just in case, at least for this incident... can get a bad reputation but it's a very fine program, you can install it as a service and set it with a password so only you can connect
adladladlAuthor Commented:
Fixed, restored, clean, yay !!!  I'll get on here later and explain what we did and award points... but right now, I really need to get some sleep.

Thanks to all (especially FocIS) !!!
just make sure she can't re-encrypt everything, sleep tight :)
Philip ElderTechnical Architect - HA/Compute/StorageCommented:
The Fix My Network Wizard in the SBS Console will fix any issues, or recommend the steps to fix them, on SBS. Did you run that?

If that comes up clean then run the Internet Connection and then Address Wizards to reconfigure everything. If using a third party SSL then run the Third Party Trusted Certificates wizard and choose the "Certificate already on the server" option to reseat.
adladladlAuthor Commented:
Okay -- just to summarize....

First, I'm surprised we got hit by this. Our email is hosted by GoDaddy, and I have to believe they have pretty sophisticated screening tools to look for things like this. We hardly get any Spam or junk email. Second, we run Symantec on all the PCs. Nothing seemed to detect this before it started causing problems.... anyway...

First, we stopped sharing the Server shares until we could clean the workstations.  We have 11 workstations, so on all of them we ran Malwarebytes, Norton Power Eraser, and Hitman Pro. Each tool seemed to find something else. A few of the PCs had email with PDFs that looked like the "Crypto" PDF, so we deleted those. We searched all the PCs for "decrypt*" files, but only found one on the workstation that we thought started this. The file(s) that were encrypted on that workstation were not important as we don't store any user docs, etc. on the workstations, so we just deleted them.

Then we went on to the server. We have SEP on the server, but Symantec Client was never deployed to the server, thus we couldn’t use it to scan the server. We deployed the Symantec client it to the server. Scans with Malwarebytes and Symantec found several dozen "issues" which were deleted or quarantined. To finish the clean, a reboot was required. After the reboot, we could no longer connect via RWA, and there were a few other anomalies such as no longer being able to add, remove, or view_properties for users from the Dashboard. But we figured we’d deal with that once the encryption issue was fixed.

We searched the server for “decrypt*” files and found 203 of them in one directory tree (a directory tree used by one specific application that relies of SQL server that has 203 sub-folders). These folders are shared with the workstations since they run the application on the workstations but the server holds the SQL Server DB. We deleted the entire directory tree, and restored from a backup taken about 12 hours prior to the infection. Viola !  The application that uses SQL Server started as expected !  

I then looked at the RWA setup and it said RWA was unavailable. We tried the “repair”. It kept telling us the username/password for the provider of our Certificate was invalid. Once we remembered what that username/pw was, we entered the correct info and RWA claimed to be fixed showing “available”, but we still couldn’t connect.  I was suspicious of Symantec (since we never had it on the server before), so I uninstalled it. This required a reboot.

We rebooted and EVERYTHING worked… RWA, the user add/delete/view_properties from the Dashboard, the SQL Server application, and no more “decrypt*” files.  We re-ran the Malwarebytes scan and it came up clean. So we turned the shares back on, reconnected the workstations, and everything seems normal.

Next task is to follow some of the recommendations in the articles pointed to above to see if we can set things up to prevent this in the future. So a long 16+ hour marathon session (those scans take forever), but I think we’re good. Thanks again to all!
Philip ElderTechnical Architect - HA/Compute/StorageCommented:
We have had one CryptoLocker (site to decrypt: at one client and one CryptoWall infection at another (no site to work this one out).

In the case of the CryptoWall the machine that seemingly held the malware (based on first touched files and folders after the share feelers) came up clean in our scans. The software finished its encryption routine at 0647 (started 1245Hrs the day before) and then proceeded to clean everything up and delete all traces of itself.

Volume Shadow Copy on Windows (hopefully set up) will be the save or restore from backup.

NOTE: Enable the Recycle Bin on any Linux based NAS! CryptoWall creates a new file that is encrypted then deletes the original. One can be saved by this feature though it is left to be said just how much data can be salvaged.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Legacy OS

From novice to tech pro — start learning today.