Disaster Recovery


The goal is to protect others and to re-establish a trusted environment from which future activities will be made private once again. Assuming you are still whole in life and limb and have regained access to your digital property, you can now move forward.

There is a range of techniques for disaster recovery that are a trade-off between difficulty and security:

Starting with the least secure up to the most secure way:

  • powered on internet connected compromised machines
  • powered on LAN connected compromised machines
  • powered on machines without connectivity (shared folder for VM or USB for host)
  • powered off machines and mount
  • the Qubes method

The Guides below are currently based on the "powered on LAN connected compromised machines" method. Contributions welcome.


Threat model: You know or highly suspect that the host is compromised.

0. Hardware is expendable, but data is precious. Consider your current hardware and everything attached to it compromised. Do not use it any longer it's only good for salvaging data. Understand what's done is done. Your private data has been seized, copied, scrutinized and maliciously altered. Continuing to use data from compromised hosts/VMs in clean places risks reinfection if caution is not taken.

1. Acquire a new laptop and external storage with cash from a store. Set up Debian with Whonix.

2. The compromised computer should never be allowed to connect to the internet again.[1] Change the WiFi access point password. This is not foolproof as an intelligent virus can attempt to connect from open hot-spots, but that might be a rare occurrence in your area to be a problem. Bare in mind that infected cellphones might be another exfiltration vector via ultrasound, so it's best to turn them off an keep them in a Faraday Cage like a microwave for the duration of this procedure. Use a LAN connection only for the next steps.

3. Turn on your compromised machine and connect any infected external USB or HDDs to that device and copy everything over to the main disk. Install Syncthing on that machine by transferring the package offline from the new computer via a fresh USB. Discard USB. Start Syncthing session. It is recommended to keep the compromised machine in another room far away to minimize risk of hardware EM side-channel leaks that can expose key material and the info on your screen to the infected device.

4. Start Syncthing in a Debian VM on the uninfected machine. Connect both machines to a LAN only connection and initiate a transfer session, copying over everything you want to salvage. Once done, move these files out of the Debian VM via shared folder.

5. Connect new external storage to your uninfected machine and format it with encryption following our guidelines. Move the files back onto it without opening them. Files are innocuous if not opened and so you can copy them over normally to the backup device. Since you cannot be sure if some types of files were infected (PDFs, media) it is recommended you always copy the data you will be working on into the Workstation shared folder and execute it there from within the VM.

6. Once you backed up your data from the old computer, shut it down and permanently discard it along with the infected storage.

7. Consider any and all passwords compromised. Immediately change them using recommended means as per our password page.

8. Revoke all keys and generate new pairs then announce to all contacts your key migration and the reason behind it. Put notices on your code repos to alert potential users so they can inspect them for foul play and take precautions.

9. Study your failures to prevent similar situations in the future. The next time you may not be so lucky to realize that security has been broken. Knowing why your cover was blown is one of the most pieces of information you can gather and share with others. If you follow everything on this wiki diligently and have not left your stuff unattended, then you are down to software vulnerabilities as the only plausible possibility. Post your Tor logs and report what Tor guard you were connected to so the community can piece together if it was part of a coordinated attack on the network. Disclose what hypervisor you used to the upstream security team and explain the situation in detail to bring it to their attention.

Threat model: You know or highly suspect that the Workstation is compromised, but there was no VM breakout.

1. Transfer your data out of the Workstation via shred folder.

2. Apply steps 7 and 8 from above.

3. Discard the infected Workstation snapshot or VM image.

More complex ideas for recovering from AppVM compromise on Qubes can be found here. However it may not be necessary as the steps above should be applicable to any hypervisor and are easier to grasp. Qubes does not have the concept of shared folders so it is best to draw on ideas suggested in that link.

Threat model: You know or highly suspect that the Gateway is compromised, but there was no VM breakout.

A compromised Gateway has no access to the host resources.

A compromised Gateway doesn’t automatically lead to a compromised Workstation.

Let’s say a remote code execution vulnerability was found in Tor. That would compromise Tor but a compromised Tor only leads to the following breaches for the workstation:

  • reading (non-https) clearnet traffic originating from the workstation (unless the workstation is using a user -> Tor -> VPN -> destination tunnel configuration)
  • reading onion traffic originating from the workstation
  • loss of anonymity

The Gateway is no more privileged position to exploit the Workstation than a Tor exit. Well, it doesn’t have to find a specific target, but it still needs to compromise the Workstation through another vulnerability.

A compromised Gateway shouldn’t lead to a compromised (as in unwanted code, malware running) Workstation. So the Workstation shared folder should be safe along with any data locally stored and never transmitted unencrypted over the internet. So any OpenPGP encrypted messages from the Workstation sent through a compromised Gateway should still be confidential.

The recovery process is similar to the section on Workstations above, except the steps that involve key revocation. The main reasons for such a security failure can be caused by:

  • Installing third party software on the Gateway.
  • Browsing the clearnet from software installed on the Gateway on purpose.
  • Installing vulnerable services on the Gateway like DHCP that a malicious Workstation can have access to and compromise.
  • Using a vulnerable version of apt to perform software updates (this happens occasionally and we notify users).
  • A remote code execution vulnerability in Tor itself or pluggable transports (extremely improbable according to their track record).


  1. Risk of booting a malicious VM without internet connected:
    • if internet is considered off for too long: malware might react on this trigger such as by deleting files or maliciously editing files (adding fabricated evidence) or do some action to damage the hardware
    Risks of keeping internet connected when being compromised:
    • malware can load more code and the newer code might include stuff for infecting more hardware or VM breakout
    • exfiltration may not be a binary yes/no. Could be something in between. Imagine a malware where the attacker remotely is searching one by one (there are screenshots/videos available about malware features). Not all attackers straight fetch a whole image dump. Malware might upload more files: upload over Tor is slow. Depending when one noticed the compromise, specifically with lots of data (lets say video recordings) not everything may be in the hands of the attacker yet.
    • the attacker might upload illegal files (non-Torified) somewhere that result in a police raid
    • the attacker might come up with a new strategy such as uploading false evidence files to the victim’s computer and then tip the authorities resulting in a police raid and false accusation
    • when a malicious computer is connected, it might do nefarious work such as for a spam botnet
    • the longer it’s connected to the internet (image a user following that advice and taking days for searching all the data and making backups) it’s harder to explain (think in front of a judge) that “my computer was compromised, it wasn’t me” vs “your computer was used in an attack for days”.
    See this image to see what compromised computers are used for: You’ll want none of this. So: don’t connect a compromised VM or machine to the internet.

No user support in comments. See Support.

Comments will be deleted after some time. Specifically after comments have been addressed in form of wiki enhancements. See Wiki Comments Policy.

Add your comment
Whonix welcomes all comments. If you do not want to be anonymous, register or log in. It is free.

Random News:

We are looking for maintainers and developers.

https | (forcing) onion

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.

Whonix is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Libre Software license as Whonix itself. (Why?)

Whonix is provided by ENCRYPTED SUPPORT LP. See Imprint.