The removal of malware can be challenging due to its ability to infect a variety of file types, including data files such as images and text files, in addition to executable files. Even if the hard drive is completely wiped and the malware appears to be removed, there is a risk of re-infection with the same malware as it may have previously infected a non-executable file. This makes it difficult to completely eradicate the malware from the system.

In the event of a system compromise, users to have a plan in place to contain and recover from the a malware infection while preventing re-infection.

Introduction[edit]

In the event of a system compromise, users to have a plan in place to contain and recover from the a malware infection while preventing re-infection.

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.

Threat Models[edit]

Host Compromise[edit]

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.

It is strongly recommended to no longer use the hardware, other than to salvage existing data. It is safest to assume all private data has been seized, copied, scrutinized and maliciously altered. Unless precautions are taken, the continued use of data from compromised hosts/VMs in clean systems risks reinfection.

1. Acquire a new laptop/desktop and external storage with cash from a store.

2. Set up Debian with Kicksecure.

3. The compromised computer should never be allowed to connect to the Internet again; see footnote. ^[1]

4. Change the WiFi access point password.

This step 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. Also bear in mind that infected cellphones might be another exfiltration vector via ultrasound. For this reason it is safest to turn them off and keep them in a Faraday Cage like a microwave for the duration of this procedure. Use a LAN connection only for the next steps.

5. 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 (file synchronization program) on that machine by transferring the package offline from the new computer via a fresh USB.
Afterwards, discard the USB.
Start the Syncthing session.
It is recommended to keep the compromised machine in another room far away from the new computer. This will minimize the risk of hardware electromagnetic side-channel leaks that can expose key material and the information on your screen to the infected device.

6. Start Syncthing in a Debian VM on the uninfected machine.

Connect both machines to a LAN only connection and initiate a transfer session -- copy over everything that needs to be salvaged. Once finished, move these files out of the Debian VM via a shared folder.

7. Connect new external storage to the uninfected machine and format it with encryption following the Kicksecure guidelines.

Move the files back onto the storage device without opening them. Files are innocuous if not opened, so they can be copied over safely to the backup device. Since you cannot be sure if some file types 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.

8. Once data from the old computer has been backed up, shut it down and permanently discard it along with the infected storage.

9. Consider any and all passwords as compromised.

Immediately change all passwords following the recommendations outlined on the Passwords page.

10. Revoke all keys and generate new key pairs.

Announce this key migration action to all contacts and the reason behind it. Put notices on your code repositories to alert potential users so they can inspect them for foul play and take necessary precautions.

11. Study your failures to prevent similar situations reoccurring in the future.

If/when a host compromise occurs in the future, you may not be lucky enough to detect it. Understanding why your system was infiltrated is a crucial piece of information that should be gathered and shared with others.

Kicksecure VM Compromise without Virtual Machine Escape[edit]

This threat model assumes a Kicksecure VM compromise has been confirmed or is strongly suspected, but there has not been a VM escape (breakout) or Hyperjacking.

1. Disconnect the internet to the infected VM or to the entire host.

2. Transfer the data out of the Kicksecure VM via a shared folder.

3. Apply steps 9 and 10 from the section above.

4. 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.

Forum Discussion[edit]

Document recovery procedure after compromise

Attribution[edit]

Kicksecure is an Implementation of the Securing Debian Manual. This chapter has been inspired by: Securing Debian Manual, chapter After the compromise (incident response)

Footnotes[edit]

↑
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.
Risk of maintaining an Internet connection when compromised:
- 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.
  - 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 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.
Refer to the following image to understand what compromised computers can be used for: https://krebsonsecurity.com/wp-content/uploads/2012/10/HackedPC2012.png It is far safer to avoid these risks, so do not connect a compromised VM or machine to the Internet.

Kicksecure

A secure by default operating system with the latest security research in place.

Dark mode

Supported by Power Up Privacy

Kicksecure is proudly supported until 2025 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint

2012- 2024 ENCRYPTED SUPPORT LP

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

[1] 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.
Risk of maintaining an Internet connection when compromised:
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.

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 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.
Refer to the following image to understand what compromised computers can be used for: https://krebsonsecurity.com/wp-content/uploads/2012/10/HackedPC2012.png It is far safer to avoid these risks, so do not connect a compromised VM or machine to the Internet.

[2] 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.

[3] Malware could load more code which might include capabilities to infect more hardware or perform a VM escape.

[4] 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.

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.

[5] 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).

[6] Not all attackers will immediately fetch a whole image dump.

[7] Malware might upload more files over time.

[8] 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.

[9] The attacker might upload illegal files somewhere that result in a raid by authorities.

[10] 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.

[11] When a malicious computer is connected, it might perform illegal activities like becoming part of a spam botnet.

[12] 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.

[1]

Compromise Recovery

Contents

Introduction[edit]

Threat Models[edit]

Host Compromise[edit]

Kicksecure VM Compromise without Virtual Machine Escape[edit]

Forum Discussion[edit]

See Also[edit]

Attribution[edit]

Footnotes[edit]

Navigation menu

Compromise Recovery

Introduction[edit]

Threat Models[edit]

Host Compromise[edit]

Kicksecure VM Compromise without Virtual Machine Escape[edit]

Forum Discussion[edit]

See Also[edit]

Attribution[edit]

Footnotes[edit]

Navigation menu

Search