Solved

CryptoWall SBS2011

Posted on 2014-10-18
19
515 Views
Last Modified: 2014-10-20
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 ?
0
Comment
Question by:adladladl
  • 9
  • 7
  • 3
19 Comments
 
LVL 2

Accepted Solution

by:
FocIS earned 500 total points
ID: 40389553
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

http://www.bleepingcomputer.com/virus-removal/cryptowall-ransomware-information

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)
0
 

Author Comment

by:adladladl
ID: 40389583
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 ?
0
 
LVL 2

Expert Comment

by:FocIS
ID: 40389591
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
0
 

Author Comment

by:adladladl
ID: 40389595
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.
0
 

Author Comment

by:adladladl
ID: 40389598
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.
0
 
LVL 2

Expert Comment

by:FocIS
ID: 40389600
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)
0
 
LVL 38

Expert Comment

by:Philip Elder
ID: 40389619
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.
0
 

Author Comment

by:adladladl
ID: 40389661
Hmmm....  did all the scans, a reboot, deleted decrypt files, ..... still having problems.  Now I can't connect via remote web access....
0
 
LVL 2

Expert Comment

by:FocIS
ID: 40389965
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
0
Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 

Author Comment

by:adladladl
ID: 40389979
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.
0
 

Author Comment

by:adladladl
ID: 40389988
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")

And:

"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.
0
 
LVL 2

Expert Comment

by:FocIS
ID: 40390007
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 ammyy.com or teamviewer.com

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
0
 

Author Comment

by:adladladl
ID: 40390035
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") ?
0
 
LVL 2

Expert Comment

by:FocIS
ID: 40390503
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... www.ammyy.com 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
0
 

Author Comment

by:adladladl
ID: 40390724
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) !!!
0
 
LVL 2

Expert Comment

by:FocIS
ID: 40390737
just make sure she can't re-encrypt everything, sleep tight :)
0
 
LVL 38

Expert Comment

by:Philip Elder
ID: 40391018
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.
0
 

Author Comment

by:adladladl
ID: 40392281
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!
0
 
LVL 38

Expert Comment

by:Philip Elder
ID: 40392307
We have had one CryptoLocker (site to decrypt: https://www.decryptcryptolocker.com/) 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.
0

Featured Post

Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

Have you ever had a hard drive that you can't boot into, but need to change the registry? Here is the solution! This article guides you through accessing and editing a registry of a non-primary drive. To read registry information on a non-prim…
When you upgrade from Windows 8 to 8.1 or to Windows 10 or if you are like me you are on the Insider Program you may find yourself with many 450MB recovery partitions.  With a traditional disk that may not be a problem but with relatively smaller SS…
This video Micro Tutorial explains how to clone a hard drive using a commercial software product for Windows systems called Casper from Future Systems Solutions (FSS). Cloning makes an exact, complete copy of one hard disk drive (HDD) onto another d…
Windows 8 comes with a dramatically different user interface known as Metro. Notably missing from the new interface is a Start button and Start Menu. Many users do not like it, much preferring the interface of earlier versions — Windows 7, Windows X…

706 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now