In the event a system compromise is suspected or confirmed, the ultimate goal is to re-establish a trusted, private environment for future activities. This is essential to protect yourself and other parties that are communicated with.
This entry assumes you still have or have regained access to your digital property. In order to move forward, it is necessary to adopt a reasonable compromise recovery technique that poses an acceptable trade-off between difficulty and security. The possible methods outlined below are listed in order of increasing security:
- 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 threat models below currently utilize the "powered on, LAN-connected compromised machines" method. Community contributions to outline additional techniques are most welcome.
This threat model assumes a host compromise has been confirmed or is strongly suspected. In this case, it is important to remember that hardware is expendable, but data is precious. Consider your current hardware and everything attached to it as compromised.
Kicksecure Compromise without Virtual Machine Escape
This threat model assumes a Kicksecure ™ VM compromise has been confirmed or is strongly suspected, but there has not been a VM escape (breakout).
1. Transfer the data out of the Kicksecure ™ VM via a shared folder.
2. Apply steps 9 and 10 from the section above.
3. Discard the infected Workstation snapshot or VM image.
More complex ideas for recovering from an AppVM compromise on Qubes can be found here. However this may not be necessary because the steps above should equally apply to any hypervisor and are easier to grasp. Qubes does not have the concept of shared folders, so it is best to draw inspiration from ideas suggested in that link.
- Risk of booting a malicious VM without an Internet connection:
- If disconnected from the Internet for too long, malware might be programmed to trigger the deletion or malicious editing of files (adding fabricated evidence), or perform actions which damage the hardware.
- Malware could load more code which might include capabilities to infect more hardware or perform a VM escape.
- The possibility of exfiltration may not be a simple binary (yes or no) proposition. For example:
- Imagine a scenario whereby the attacker is using malware to remotely search images/videos/other files in succession (there are screenshots/videos available about malware features).
- Not all attackers will immediately fetch a whole image dump.
- Malware might upload more files over time; upload over Tor is slow.
- Depending on when the compromise was noticed, everything may not be in the hands of the attacker yet. This is particularly true with large files such as video recordings.
- The attacker might upload illegal files (non-torified) somewhere that result in a raid by authorities.
- The attacker might come up with a new strategy, such as uploading false evidence files to the victim’s computer followed by authority tip-offs that result in a police raid and false accusations.
- When a malicious computer is connected, it might perform illegal activities like becoming part of a spam botnet.
- The longer a compromised machine is connected to the Internet -- imagine a user following poor advice and taking days to search for all relevant data and making backups -- it is harder to explain away a decision to continue operating it. For example, stating “my computer was compromised, it wasn’t me” is hard to reconcile with evidence that it was used in an attack for days on end.