What should you do if you catch encryption ransomware mid-operation?

Question

You boot up your computer one day and while using it you notice that your drive is unusually busy. You check the System Monitor and notice that an unknown process is using the CPU and both reading and writing a lot to the drive. You immediately do a web search for the process name, and find that it's the name of a ransomware program. A news story also comes up, telling you about how a popular software distribution site was recently compromised and used to distribute this same ransomware. You recently installed a program from that site. Clearly, the ransomware is in the process of doing its dirty work.

You have large amounts of important data on the internal drive, and no backup. There is also a substantial amount of non-important data on the drive.

This question's title says "mid" operation, but in this example we have not yet investigated how far the ransomware might have actually gotten in its "work."

We can look at two situations:

1. You want to preserve as much of your data as possible. However, paying any ransom is out of the question.

2. If possible without risk, you want to know whether the important parts of your data are actually encrypted and overwritten. You also want to try and extract as much of your data as possible without making things worse. You would hate to pay a ransom. But certain parts of the data are so important to you that you would, ultimately, as a last resort, like to still be able to pay for a chance to get them back rather than risk losing any of them.

Step by step, what is the ideal thing to do in situation 1 and 2? And why?

Note: This is hypothetical. It hasn't actually happened to me. I always keep offsite backups of my important data and I've never been affected by ransomware.

Answer 1

Hibernate the computer

If the ransomware is encrypting the files, the key it is using for encryption is somewhere in memory. It would be preferable to get a memory dump, but you are unlikely to have the appropriate hardware for that readily available. Dumping just the right process should also work, but finding out which one may not be trivial (eg. the malicious code may be running inside explorer.exe), and we need to dump it now.

Hibernating the computer is a cheap way to get a memory image¹ Then it could be mounted read-only on a clean computer for

a) Assessment of the damage inflicted by the ransomware

b) Recovery of unencrypted files²

c) Forensic extraction of the in-memory key from the malicious process, other advanced recovery of the files, etc.

Note that by read-only I mean that no write is performed at all, for maximum recovery chances. Connecting normally to another Windows system won't provide that.

For (c) you would probably need professional support. It may be provided free of charge by your antivirus vendor.

Even if you don't manage to recover all your files or you are told it is impossible or too expensive, keep the disk with the encrypted files. What it's impossible today may be cheaper or even trivial in a few months.

I recommend that you simply perform the new install on a different disk (you were going to reinstall anyway, the computer was infected, remember?), and keep the infected one -properly labelled- in a drawer.

--

As for the second question, where you really want to pay the ransom I'm quite sure the ransomware author could give you back your files even if not all of them were encrypted. But if really needed, you could boot from the hibernated disk after cloning it, and let it finish encrypting your (now backed-up) files…

¹ NB: if you didn't have an hibernation file, this may overwrite plaintext versions of now-encrypted files that could have been recovered (not relevant for most recent ransomware, though).

² Assuming they are not infected…

Answer 2

What I would do:

1. Suspend the process. Don't kill it, just pause it.
2. Look in the process tree if there are any parents that might need suspending as well.
3. Pull the network cable and/or turn off WiFi (and if you're paranoid, Bluetooth too).
4. Check open files by those processes to see which one it is currently encrypting. If it's a particularly important one, you might want to copy the file in its current state (while the process is suspended) and then let it move on to the next file, so it won't get corrupted. If the next file also turns out to be important, well, either figure out the pattern and copy a file one step ahead or just start copying all your files already.
5. Google how to make a memory dump of a process on that particular OS, then make that memory dump of the relevant processes. Heck, I might dump all virtual memory from the machine.
6. Close other programs.
7. Sync the disk(s) so there is no write cache anymore.
8. Pull the power. If a laptop: remove battery, then remove power (if plugged in).

You are now in a pretty good position: power is off so noting more can happen, and you have whatever encryption key it was using plus the original program. The trouble is to find that encryption key and the encryption method, but it has to be somewhere in its process memory: just a matter of time. Call your hacker buddies to reverse engineer the program, or perhaps even an antivirus company: they probably have lots of customers with the same ransomware and would be very curious to obtain a memory dump to extract the key.

Hooking up the hard drive to another computer will recover any files that were not encrypted yet, without much risk. Just don't execute any Word macros or open .exe files from the drive or something.

Summary

Pause the ransomware process so we can make a copy of it and its memory to find the encryption key later. Then turn the system off and follow common sense from there. Beware of important corrupted files (halfway encrypted files), so check the one it was currently working on after pausing it.

---

In response to comments

This comment has a few upvotes now:

The "encryption key" would not help in many cases, on startup the ransomware connects to the command and control server and requests a new encryption pair(public and private) to be created. The server creates the pair, stores the private, and sends the public to the infected machine. Then the infected machine uses the public key to encrypt the files, and the only way to reverse it is to use the private key, that is never transferred to the victims machine until a payment is completed. – Anton Banchev

This is a concern I thought of while writing the post, but have not addressed yet.

Nobody ever encrypts data with asymmetric encryption (also known as public key encryption). It's just too slow, so asymmetric crypto is only used in hybrid encryption schemes. Even benchmarks like the one built into openssl report megabytes per second for AES and operations per second for RSA. Not comparable at all. The only hit I've been able to find is this Stack Overflow answer with a source that did not even disclose their methods: asymmetric encryption is 1000 times slower than symmetric encryption.

Thus, the encryption used for each file is almost certainly symmetric encryption (like AES), which means we can also decrypt it with that same key as it is being encrypted with.

Update: it seems at least one of the many ransomware variants uses public key encryption only. Apparently it is just fast enough to be usable, or they would obviously not be using it. I guess you better hope you don't have this variant? End of update.

I don't know of any ransomware that does this, but the only way this could still be an issue is when each file has a unique encryption key. In that case only the current file could be recovered from memory. This would cause a key management issue for them though: each of those keys would either have to be transmitted, or stored in a database which is encrypted with a (symmetric) master key. In the latter case you could probably recover the master key from memory as well, in the former case you got a problem. But this is all just speculation anyway, I don't know any ransomware that does this.

Answer 3

Ransom-ware (or any encryption software for that matter) will not encrypt the file in-place, because the encrypted filesize will not match the unencrypted filesize bit-for-bit (unless it's just an xor shuffle, in which case it's not really encryption). More importantly, a spontaneous abortion of the encryption process (due to a shutdown, running out of battery, etc) would create a corrupt file which cannot be ransomed. Instead, these programs always create a new encrypted file from the old, then delete the old. In fact, most ransom-ware programs have checks to restart half-encrypted large files due to a shutdown/restart.

So if you find out your mid-encryption, you turn your computer off - as soon as possible - and mount the hard drive on an unaffected machine for backup.

Regarding whether or not I pay the ransom - I have no idea. Depends on the size of the ransom and the nature of what's on my hard drive at the time. Since I make roughly $2.50 an hour, and my hard drive mainly contains publicly available scientific data, the answer is most likely no.

EDIT:

Hibernation, as recommended by the other poster, is hypothetically superior to turning the computer off in many ways. However, practically, hibernation may not work. Any process can tell the system that it is busy and cannot be stopped right now -- even a YouTube video of a cat playing a piano can do this. This is true for OSX, Windows, and Linux (depending on how you hibernate for Linux). The only solution in these instances where the process refuses to suspend is to kill the process - which means no memory dump. So personally, i'd rather stop that encryption as soon as possible by yanking out the power chord, because if there's one thing I can guarantee, its that that the ransomware will be putting its key back into memory the next time the system boots, because I didn't let it finish the job.

Answer 4

[Mod Note: This answer is receiving a lot of flags, but is not worthy of deletion. This is a potentially valid course of action, though risky and potentially illegal in some jurisdictions. From a technical standpoint, this has a chance of being a way to preserve the data. Please see Meta for further discussion.]

The best thing to do is nothing. Doing something stupid might lead to data loss or corruption. Let it finish and then contact the people listed there, pay the ransom and you are good to go. We are professionals and will help you get your files back.

_{Disclaimer: I am a ransomware developer.}

Answer 5

The second question may generate a lot of opinions as answers. I will focus on the first question. What do you do to stop a potential ransomed encryption in progress?

Steps:

1. Un-plug your machine from the internet immediately. Use another machine for your internet searches for solutions.

2. Shut down the affected machine with a cold power-down. Do not wait for the machine to complete its normal power-down software inspections.

3. Unplug the hard-drive from the machine.

4. Install a new hard-drive in the machine and install a new, clean OS.

5. Plug the original drive into the motherboard so that the new OS can access the drive.

6. Power up the new OS, access the old drive, and make a backup.

7. Store the backup in a physically secure location that is separate from the original (in case of fire, flood, tornado, etc).

8. Improve your web-browser security. Much of the ransomeware is installed via JavaScript malware.

As for the second question: perhaps you can reconstruct some of the data that got encrypted. The following steps may be helpful, after the steps above are completed.

1. Audit the data on the original drive to determine if any files were successfully encrypted. Note which files were encrypted. (This audit should only be completed from a clean OS.)

2. From memory (since there is no backup), try to recall what the contents of the files are and how important they are.

3. Now, focusing on the most important files that were encrypted, see if file recovery techniques can recover the original file. Since encryption cannot over-write in place (for many reasons), the ransomware would have accessed the original file while creating the encrypted version. Then it may have deleted the original file with varying degrees of success. Contact a file recovery expert to find out if your unlinked original files still exist on your disk.

Remember to protect yourself in the future. Make backups, keep them off-line, and prevent ransomware from installing. See How does ransomware get on people's computers?

Answer 6

Shut the computer down immediately. Provided you're not about to pay the ransom, any data that the virus is processing is lost anyway. So just push down the power button and hold it, or unplug the wire.

Install Ubuntu or another portable Linux distribution onto your USB stick. Last time I did this it did fit on 2GB stick. I was cloning my HDD to SSD with Windows filesystem. Mount your filesystem read-only.

Backup only non-executable data. I'm not sure how many viruses infect other executables, but if I were making a virus, it would also infect Java JAR archives, PHP server scripts, batch and hash scripts and everything else I could think of. Any program that can execute system commands can potentially hold the virus and execute it. It's not likely, but it is possible. You can for example base64 encode binary into bash file...

You will require another hard drive. Fill it with your documents, photos or sourcecode. With regard to the previous point I made, check the sourcecode's status. If you use source control, dump the sourcecode. The process will take long. Carefully pick only what you need. Maybe you'll find out how much of your HDD space was occupied by stuff you don't even remember or need.

Format the infected hard drive. Either do this from the Linux rescue system or insert your preferred OS installation disk and let the installer format the hard drive.

I do not recommend backing up the infected hard drive. You might be inclined to keep a copy of infected hard drive for the sake of the documents you might have forgotten. It's a trap, just let it go. You will find many documents in your mail inbox or sent folder.

Answer 7

In addition to the shutdown & copy approach others have mentioned there's another factor: The ransomware wants to hide what's going on until it's finished it's evil--thus the encrypted files are usually still readable as if they weren't encrypted until it's ready to demand it's ransom.

Once you have located the files that matter and are encrypted put the machine back together not on the internet and try to copy them off. If this works but doesn't get them all put the backup back on the HD and grab some more.

Answer 8

Triage the Situation (invoke the situational-awareness principle)

• Where is the computer now? In the Office? At home? At a hotel? Otherwise on the road?
• What protections are offered here? If you pull the network cable or turn off WiFi, can you move the computer to a more-protected environment? Can you move it to the Office? If so, cut the network now! ASAP!! However, do not close any programs -- leave them all open in the state that they were in. Don't close browser tabs. Don't close a suspect document or email.
• If portable, bring the computer to the office. You ask your infosec team or IT leadership if they have any procedures in place to handle ransomware, such as Data Forensics Incident Response capabilities. You find out if they have any security platforms that prevent malware communications, such as secure-web gateways or Unified Threat Management solutions.

---

Containment Cycle (perform these in order from top to bottom)

• Keep the computer unconnected to the global Internet. Use another computer and USB drives, if available. If not available, find out what you can about the ransomware. Find process names, file extensions (e.g., .zepto for files that are on the Desktop). Use a separate computer to search about the ransomware. Especially visit -- https://www.nomoreransom.org
• Keep all programs open as they were. Do not shutdown or reboot yet. If you can get MalwareBytes installer from a separate machine without turning the network back on, copy the installer over to the computer, but do not run it yet. Do not let it or anything else reboot the computer. MalwareBytes is for either Windows or macOS -- and you should be using a licensed version if you are a Business. If this is an emergency, it may be ethically ok to purchase the license later -- your IT leadership's call.
• Work this as an incident. Document what you found at this point and what you continue to find. A more-mature Data Forensics and Incident Response program (DFIR) will have a few basic things in place. You may want to start on these now. They include: 1) A sinkhole network (such as an isolated hub with a DHCP server, but advanced CSIRTs will have ones with the ability to VPN directly in), with, at the very least, DNS RPZ or DNS Blackhole capabilities -- at most, perhaps a full-honeynet or deceptive-system platform. 2) Could be that this isolated network is your imaging platform (e.g., Microsoft SCCM, CloneZilla, FogProject, Symantec Client Management, formerly Altiris, or Ghost) with PXE-boot capabilities. This would make a great location for a Malware Management Framework (MMF), a mature DFIR capability that aids in these scenarios. If the MMF can manually or automatically identify suspect ransomware processes, files, registry entries, and/or other artifacts then go back into research mode.
• (Optional) Activate any DFIR processes or platforms. A very-mature DFIR program will have a few advanced items in place. Continuing from before (and hopefully on the same isolated network, although these capabilities are great to have in the production networks as well), these might include: 3) A forensics-analysis environment, especially a distributed forensic system, such as Google Rapid Response. Another component found here would be a client-based, remote-imaging capability, such as NBDServer. The primary difference is that GRR is an agent-based, collection-oriented system with a web interface, while NBDServer is a way to attach a Linux forensic workstation to a compromised Windows computer. You may want both, but GRR will also work with macOS (also check out osquery). 4) Forensic tools that grab specific artifacts for processing on forensics workstations. My favorite, and that's included in GRR, is pmem (i.e., winpmem, linpmem, osxpmem). A recent repo for downloading these directly is available here, and there may be later updates here. Open a cmd.exe shell by right clicking into Run As Administrator (or macOS/Linux Terminal shell with sudo/root rights) and then run the pmem utility. Once you've gathered the output, copy the artifacts to your forensics workstation and analyze with rekall and/or the Volatility Framework (both are well-known in the DFIR community). It is nice to gather a second memory dump using BelkaSoft RAM Capturer for comparison, which installs a Windows driver. Another favorite is FTKImager (the Lite version is fine), and I like to start with just the paging file extraction so that I can leverage the page_brute tool. Engage any last-minute DFIR tradecraft.
• Discern what is known good and known bad. Rely on your MMF here. If you don't have one, set up the quickest version of one that you possibly can. Also -- MalwareBytes operates by seeing things in action. This is why it's important to leave everything as it was before. Install and run MalwareBytes for the first time now. Don't allow it to reboot the computer. Instead of closing a browser tab, reload it. Instead of scrolling to another email in your Outlook, reopen the same known-bad document that perhaps was the cause of the ransomware. Do a quick check of browser history and scroll through the email client if open looking for other events (usually within 10-minutes before the end user thinks the infection occurred) and action on those if they appear related. Remember, you're not on the full Internet -- just a network that responds to DNS queries and forwards them to some locally-faked service.

---

Mitigation Cycle (remove the compromise by whatever means and ensure it will not come back. Restore the machine to a working state)

• Hunker down. You haven't rebooted, closed any programs, or connected to the global Internet yet, right? Good. Call the DFIR complete for now and do close all visible programs. You've ran MalwareBytes on a fake network. You've hopefully also gathered artifacts of running memory (including the paging file) with all programs open. You can even kill bad processes now (if MalwareBytes hasn't already). Refer back to your MMF to determine known-good processes and pretty much kill everything except the ones necessary to keep the OS running, unless it has to do with what we're up to next: checking the local or remote backups and Volume Shadow Copy Service (VSS).
• Find out what can be restored and what cannot be. Windows XP creates a System Restore Point every 24 hours. Since Windows 7, however, there is a Volume Shadow Copy mechanism, which also creates backup files and so on. All these actions occur automatically without any user activity. If you can, clone the whole drive. If you can't due to limited time, disk space, or other triaging, then access the built-in OS backup capabilities. Let's assume Win7 or higher for a second, and you can follow along here, but I originally got the ideas from the book Operating System Forensics (and it's also covered in Incident Response & Computer Forensics, Third Edition):

C:\Windows\system32> vssadmin list shadows
[...]
  Contents of shadow copy set ID: {45540ad8-8945-4cad-9100-5b4c9a72bd88}
    Contained 1 shadow copies at creation time: 3/4/2012 5:06:01 PM
     Shadow Copy ID: {670353fe-16ff-4739-ad5e-12b1c09aff00}
      Original Volume: (C:)\\?\Volume{33faab95-9bc6-11df-9987-806e6f6e6963}\
      Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy27
      Originating Machine: funhouse
      Service Machine: funhouse
      Provider: ‘Microsoft Software Shadow Copy provider 1.0’
      Type: ClientAccessibleWriters
      Attributes: Persistent, Client-accessible, No auto release,
Differential, Auto recovered

mklink /D c:\vss \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy27 and you can cd \vss and dir to see if the files that had the ransomware file extension (i.e., the files or directories that were encrypted) are available in an unencrypted state by traversing through that as a root path. You can then rmdir \vss when finished, trying another HarddiskVolumeShadowCopy iteration as you please. Harlan Carvey and the Forensics Wiki have also detailed these methods.

• Ensure you have collected all of the information you need before rebooting. With MalwareBytes installed, it's going to want to reboot. You may want to install a few other packages before rebooting, however. If you had a problem with System Restore or VSS restoration of files, then check out the Arsenal Recon Image Mounter (it is especially important to try this because ransomware may actually go after the restore points and VSS itself, disabling them). Another great thing to do before rebooting is to perform a P2V virtual-machine guest clone operation, usually with VMware vCenter Converter. Because you'll also likely be connecting back to the global Internet after reboot, also ensure that you will be able to update to the OS-level and app-level patches. You may want to check out the free trial of Corporate Software Inspector from Flexera (formerly Secunia) if you have nothing else. Another favorite is the Microsoft Baseline Security Analyzer (MBSA) program. Check a few settings such as the Windows Firewall or the macOS Security & Privacy section of System Preferences. If you want to see a large list of security settings, be sure to check out the free tool, Airlock, from Lunarline (N.B., it only works with Windows OS versions 7, 8, and 8.1 and will only apply security settings to Internet Explorer versions 8, 9, and 10 -- but this tool is fantastic in a secure-configuration regard). Ensure that network shares will not attach/remap when the computer restarts. You can check these in Windows and in macOS.
• Restore; Restore; Restore. The last thing to do before reboot is to check the AutoRuns. For Windows, this means run Autoruns (again, try to get it via USB or lab/recovery network instead of the global Internet). Try to review each item with an expert. In macOS, to review the items that will run at startup, go into System Preferences, Users & Groups, and Login Items. Restore by restarting and paying attention to MalwareBytes if it prompts you. Restore by running MalwareBytes again. Restore by getting approval to connect back to the global Internet. Update MalwareBytes. Run MalwareBytes again. Update your OS and run any built-in or third-party OS-level and app-level update programs. Restore by letting the updates complete and rebooting if they prompt you to. It is now safe to copy the files you restored from backup and overwrite the encrypted files. Ensure that you have restored all service/data to the the state it was prior to the incident ocurring.
• Use the computer. Is it ok? Is everything back to normal? It is ok to kill processes or stop services that you deem still scary-looking. If files were missing or could not be located from backups, then what is the next recourse? My suggestion is to copy all of the still-encrypted files to offline storage, such as a USB drive. Perhaps at a later time a recovery utility will be built for the ransomware files. Does the computer act as if it has any malware (not just ransomware) still? If so, then quarantine it and escalate research, expertise, and DFIR capabilities.
• Be willing to use a different computer even if it appears ok. Be willing to hand over your computer to an expert. Be willing to allow it to sit in quarantine longer. Be aware and prepared that during the next-and-last phase, you could never see this particular computer ever again.

---

Eradication Cycle (gain situational understanding, an after-action review)

• Find out how the ransomware was executed or installed. Review and record what happened, what you've documented, etc. Store the information and work it with a more-formal system, such as Raquet, nightHawkResponse, SOF-ELK, malcom, malcontrol, or MISP. Use any formal SIEM or ticketing system to track this issue or search for related past issues, such as MozDef. Really get to the bottom of how it was installed or executed, though -- you need to understand how it works. If you can't manually do this, at least utilize Automated Malware Analysis (AMA) of some kind. If your UTM at the office is Palo Alto Networks and your company has a license for WildFire, then you already have AMA. Other commercial AMA platforms include: Lastline, Cyphort, Check Point, McAfee Sandbox (Advanced Threat Defense or ATD), Symantec Blue Coat, FireEye, Trend Micro Deep Discovery Sandbox, Fidelis, Cisco ThreatGRID, and Fortinet. I've identified these here so you can ask your InfoSec or IT technology-leader teams if one exists so that they can go see what it found. If nothing, then maybe call the vendor and ask why not?
• Extract the ransomware's features and behavior for correlation. Compare hashes and other Indicators of Compromise (IoCs) with known-bad values more in-depth that what has occurred so far. If the ransomware infection came from a malicious macro in an Office document (or even direct from email), then extract the VBA macros using the Didier Stevens tools: emldump and oledump. For full behavior of an executable that you found in your memory forensics analyses, Cuckoo Sandbox in its many, many iterations (including the online-submit service, Malwr, which is based it) is the go-to tool (even for macOS binaries!). Similar to Malwr are Payload Security, Comodo Camas, Comodo Valkyrie, MalwareViz, ThreatExpert, ThreatTrack, and Vicheck, all pulled from books which cover screenshots and deep analysis techniques with titles like: Advanced Malware Analysis, as well as: Windows Malware Analysis Essentials. For a cheapish commercial tool, check out JoeSecurity, a site that has many useful references about AMA on their blog. If the ransomware made any network connections (or any other malicious communications were found on the computer), find out where they were going and why.
• Know your enemy and respond accordingly. You don't have to be (or assign or hire) a DFIR or Threat Intelligence expert to scrape the surface of your ransomware attack (although it helps). However, if you know that you have APT Ransomware instead of criminally-motivated ransomware, then you have a special kind of problem. Perhaps the ransomware was delivered over the local network, such as through a Microsoft Active Directory Group Policy Object (AD GPO). If you have a suspicion that the attacks are targeted (e.g., only your executive's computers have had ransomware, or only high-profile individuals), then you really need to have someone else grade your homework for you. If you think you can do this yourself, go right ahead -- this site will help you in your quest -- http://www.threathunting.net
• Proactively stem the damage before the next event. If it was just your computer, consider upgrading your OS or enabling the highest-level of UAC as possible (or both). Check your Windows Update Control Panel Settings. If you are an IT or InfoSec professional helping others with ransomware, then it is time to revisit two policies: 1) Your no-admin policy, i.e., regular end users must not have Administrator access, and 2) Your app whitelisting policy. There are a few tricks to app whitelisting that you must know, especially for Windows. Read this slide deck, especially starting with slide 15 -- http://www.info-assure.co.uk/public_downloads/Talk%20is%20cheap-IR%20tools%20can%20be%20too.pdf -- and note that the next ten slides (15-25) will save you from getting ransomware for free, pretty-much permanently. However, I highly suggest that you read slides 29-37 to understand that you need to install PowerShell v5 to every end user computer with the AppLocker app-whitelisting policy. Not an easy task, but if you are interested please ask in the comments and I'll answer there or update my answer here.
• Update; Update; Update. Update all of the unsupported OSes on your network (they reduce your mid-term options and defensive capabilities, including posture). Update to a newer OS. Run your OS updates. Update your apps. Update your plugins. Update your Office suite. If you can update to Office 2016, then you can use a simple AD GPO (similar to the AppLocker one described directly above) to Block macros from running in Office files from the Internet.
• Ensure that you keep staying updated. Don't make it easy to say no to updating (hence why the no-admin policy). Push a GPO to change the Local Computer Policy – Computer Configuration – Administrative Templates – Windows Components – Windows Update items. For example, change Re-prompt for restart with scheduled installations to Enable with 1440 (24 hours) after setting No auto-restart with logged on users for scheduled automatic updates installations to Enabled. Finish with Allow automatic updates immediate installation to Enabled as well. Notify all end users through written policy as well through employee or contractor orientation that the company will assume that if your computer is on, then the company may require them to reboot at least every-other day. This is a fair policy. Some users, especially CAD workers, prefer to leave their computers on for several days or weeks at a time (some even months!). Ensure you have a proper exception process for these end users, but also ensure that they are getting patched to some agreed-upon exception policy with additional agreed-upon alternate or compensating controls. Most won't, so don't let them! Apple computers can have a root-level cronjob that runs softwareupdate -i -a daily. Remember that PXE-boot network used in the Containment Cycle? Ensure that baseline install images are updated according to these same policies (i.e., every-other day), preferably through automation. While you're there, be sure to update any other local software (through Corporate Software Inspector or similar), and in particular: anti-virus software or agent updates. You may have (I certainly have) heard of the stories that a new employee or contractor receives a newly-imaged laptop and gets malware or ransomware on the first day on-the job! Prevent these scenarios from happening by keeping your baseline images up-to date as well -- and this works great along with the MMF system you've built on that same isolated network! Keep those known-good hashes up-to date! It's also a good place to start tracking asset inventory for all users and elements that make up your Enterprise.
• Sharpen the saw. Your InfoSec team and/or your IT management must know what they're really doing wrong here that ransomware is actively in their environment. There are so many free (or already paid-for) options they may have. One I just went through is called Microsoft RAP from their Proactive Premier Services. If the vectors are coming from macros, fix that problem; USB, that one; APT, well -- just do your best to each problem (not the symptom) that you can. The slide deck that I cited in the Proactive Stem section has a lot of immediate-easy, free ideas for things one can implement at the network-level, for log streaming, for system management, or at the organizational-level. Also see this document -- https://www.melani.admin.ch/dam/melani/en/dokumente/2016/technical%20report%20ruag.pdf.download.pdf/Report_Ruag-Espionage-Case.pdf -- which is where I got many of these ideas.

Answer 9

NOTE: As the 'best answer' seem to be more oriented to Advanced users (even to the level of incident response teams), this will be readily doable for any user with knowledge about Linux and Live CDs.

.

.

At risk of sounding ignorant, I'll answer a one-liner:

Turn off the PC and boot Live Linux CD.

---

DETAIL:

If it's a Windows OS, turn the system off and boot a Linux Live CD. Backup your data and then clone the backup. Keep one safe and try running the other one under a clean OS.

If it's Linux then the ransomeware is designed to work under Linux, so same backup process, but then just run it under a different OS (i.e. *BSD, Windows, Android -built on Linux but vastly different in my experience-).

Of course, as the ransomeware developer said, you might as well let it finish. If you stop mid-process, you'll most likely never recover what has been encrypted already. You'll not have an ID to contact the developers with, and they probably might have not yet received your encryption key. Optionally, you can combine both. Use what I said earlier then simply boot the infected system back up and let it finish.

Declaimer: I'm a human potato; i.e. NOT a developer of anything

Answer 10

Ransomware is spreading just because people is paying it, questions and answers help getting Ransomware a reputation that is likely to make people paying. It is much better investing some money in a good anti-virus than having to pay later to recover your data.

If interrupting the process in the middle may be harmful (because developers wanted you not try to stop encryption), there is nothing preventing an abnormal interruption with related loss of data (holding RESET button for some seconds, a blue screen caused by a buggy driver... ). In general encrypted data is no longer tolerant to small error of single bits (a wrong bit makes no difference in a text file, but a wrong bit in encrypted data cause the loss of all the data)

Also the Ransomware developers should actually pay you a small fraction of your hard drive price, because many I/O operations actually reduce lifetime of your hard drive.

Another important point, just reset the password of your accounts, but don't yet enter the reactivation code. Damage of Ransomware can be limited if some data is hosted on cloud services or some kind of server, that means that if the malware get access to your credentials / sessions it can access the safely stored data increasing the damage. Resetting the passwords will block further access to your accounts (provided your smartphone is not infected and the reactivation code is not intercepted).

Many webservices that provide unique login allows also to manage access to devices and to do some action in case of stolen credentials (or supposed stolen credentials).

It is like one of the math problems in game theory, will you pay to get small advantage immediately (recover of your data), or will you just ignore the Ransomware letting it going out of business doing the "good" on the long run for all?