Offline Malware Remediation & Data Recovery
SOP: Offline Malware Remediation & Data Recovery (The "Crash Kit" Protocol)
Department: IT / Comfac Group of Companies
Effective Date: 2025-12-06
Reference ID: SEC-OPS-04
1. Overview and Asset Classification
This procedure outlines the standards for using Linux-based boot environments to isolate, diagnose, and repair compromised workstations.
To ensure hardware longevity and operational security, we utilize two distinct tiers of bootable media. Staff must select the appropriate tool for the task based on resource availability and required privileges.
Tier 1: Standard Live USB (LUSB) - The "Disposable"
- Hardware: Standard USB Flash Drive (16GB+).
- Configuration: Read-Only Ubuntu Live ISO (Amnesiac).
- Target Audience: OJTs (On-the-Job Trainees), General Staff, Minor Troubleshooting.
- Context: We maintain a high volume of LUSB units for daily maintenance and simple diagnostics. These units are low-cost and expendable.
- Use Case: Quick hardware checks, memory testing, or one-off file access. No data or logs are saved after reboot.
Tier 2: Persistent Crash Kit (PCK)
- Hardware: 2.5" SATA SSD (128GB+) in USB 3.0 Enclosure.
- Configuration: Full Ubuntu Installation (Persistent) with encrypted /home directory.
- Target Audience: IT Staff & Administrators ONLY.
- Context: Strictly Limited Quantity. PCKs contain paid, licensed software (Bitdefender Endpoint Security Tools) and are restricted due to licensing costs. They are not to be issued to OJTs.
- Use Case: Deep forensics, malware removal, large data recovery, and evidence logging.
- Why SSD? Flash drives cannot handle the "write amplification" of a persistent OS running antivirus updates and logs. Using a flash drive for a PCK will result in hardware failure within days/weeks.
2. PCK Security Protocols (CRITICAL)
The Persistent Crash Kit (PCK) is a privileged security tool. Misuse can compromise the kit itself or the data being recovered.
- Root vs. User Separation:
- The PCK has a Root (Superuser) account and a standard User account.
- Rule: Never operate the GUI as Root. Log in as the standard user. Use
sudoexplicitly for scanning or mounting drives. - Privilege Hygiene: Do not grant executable permissions (
chmod +x) to any file recovered from a Windows host.
- Chain of Custody:
- PCKs contain sensitive logs and potentially recovered PII (Personally Identifiable Information). They must be encrypted (LUKS) and stored securely when not in use.
3. Theory of Operation: Kernel Isolation
Understanding why this technique is safe is required for all IT staff handling infected machines.
- Kernel (Operating System): https://en.wikipedia.org/wiki/Kernel_(operating_system)
- User Space: https://en.wikipedia.org/wiki/User_space_and_kernel_space
3.1 The "Dormant State"
When a compromised Windows PC boots from a PCK:
- BIOS Handover: The BIOS loads the Linux Kernel from the USB SSD, not the Windows Kernel from the internal HDD.
- Inert Malware: Windows malware files (.exe, .dll) rely on the Windows API to execute. In the Linux environment, these files are merely static data. They cannot run, self-replicate, or hide.
3.2 The Executable Barrier (ELF vs. PE)
- Windows: Uses PE (Portable Executable) format. https://en.wikipedia.org/wiki/Portable_Executable
- Linux: Uses ELF (Executable and Linkable Format). https://en.wikipedia.org/wiki/Executable_and_Linkable_Format
- System Call: execve - https://man7.org/linux/man-pages/man2/execve.2.html
If a user accidentally double-clicks a Windows virus inside the PCK, the Linux Kernel checks the file header, sees it is not ELF, and rejects the execution request (execve error).
4. Operational Workflow
Phase 1: Isolation Boot
- Disconnect Network: Unplug the ethernet cable to prevent lateral movement (Worm behavior).
- Boot PCK: Insert the PCK SSD, power on, and enter the Boot Menu (F12/Del). Select the USB SSD.
Phase 2: Diagnosis & Scanning
Once the internal Windows partition is mounted (e.g., /media/admin/WindowsVolume), proceed with multi-engine scanning using the licensed tools on the PCK.
Primary Engine: Bitdefender Endpoint Security Tools (Linux)
- Update:
sudo /opt/bitdefender-security-tools/bin/bduitool update -ps - Scan:
sudo /opt/bitdefender-security-tools/bin/bduitool scan -s -f custom /media/admin/WindowsVolume
Secondary Engines (If Licensed/Available on PCK):
If the primary scan is inconclusive, utilize secondary licensed Linux agents installed on the PCK:
- ESET SysRescue / Endpoint Antivirus for Linux: Good for detecting Potentially Unwanted Programs (PUPs).
- Sophos Antivirus for Linux: Useful for cross-verification of signatures.
- ClamAV (Open Source):
clamscan -r /media/admin/WindowsVolume(Useful for a "second opinion" if licenses are maxed out).
Reporting & Knowledge Sharing (Mandatory)
Detection is only the first step. The incident must be documented to drive Corrective and Preventive Actions (CAPA) and build institutional knowledge.
- The Scientific Report Structure: Technicians must document the incident in the IT Team Channel/Wiki using the following structure:
- Observations: List physical or digital symptoms (e.g., "User reported slow performance," "Unknown process utilizing 90% CPU").
- Hypothesis: State the suspected cause (e.g., "Likely a cryptocurrency miner installed via browser extension").
- Testing & Verification: Detail the steps taken to prove or disprove the hypothesis (e.g., "Mounted drive in PCK, scanned with Bitdefender, identified Trojan.Generic.Miner in AppData").
- Evidence Collection:
- Screenshots: Capture scan logs, error messages, and directory structures.
- Sample Isolation: If a unique malware sample is found, compress it into a Password Protected ZIP (Password:
infected). - Quarantine: Upload the ZIP to the designated Cloud Quarantine Folder. DO NOT email samples.
- Wiki Knowledge Base:
- Add the findings to the IT Wiki.
- Goal: Make the lesson searchable. Staff are not expected to memorize every threat, but they must be able to retrieve the solution if the issue recurs.
Phase 3: Preservation & Extraction
Policy: We do not simply "Format and Reimage" if data recovery is possible. However, we strictly prohibit restoring "loose" files which may reinfect the network.
- Compression as Quarantine:
- Action: Select the user's critical data (Desktop, Documents, Pictures).
- Method: Create a Password Protected Zip/Tar Archive.
- Tool: https://man7.org/linux/man-pages/man1/zip.1.html
- Command:
zip -e -r user_recovery_date.zip /media/admin/WindowsVolume/Users/JaneDoe/Documents - Why: This encapsulates the data. If a virus was missed, it is now locked inside a password-protected container that cannot auto-execute when placed back on a Windows machine.
- Integrity Verification:
- Open random non-executable files (PDF, JPG, TXT) inside the Linux environment using native tools (Evince, Image Viewer).
- Goal: Confirm files are not encrypted by Ransomware.
- Safety: Opening a .doc in LibreOffice is safe as it cannot execute Windows Macros.
Phase 4: Reformatting & Re-imaging
Once data is extracted to the Password Protected Archive:
- Wipe Partition Table:
- Use GParted or fdisk to delete all partitions on the infected drive.
- Deep Wipe (Optional for high-risk infections): Use
ddorshredto overwrite the first 500MB of the drive to destroy the Master Boot Record (MBR) and Partition Table. - Command:
sudo dd if=/dev/zero of=/dev/sdX bs=1M count=500(Where sdX is the internal drive). https://man7.org/linux/man-pages/man1/dd.1.html
- Reinstall:
- Boot from a clean Windows Installation Media (Standard LUSB or separate installer) and proceed with a fresh OS install.
- Restore:
- Copy the Password Protected Archive back to the new Windows installation.
- Scan the archive again with the fresh Windows Antivirus before unzipping.
5. BIOS/UEFI Level Threats
In rare cases, malware may reside in the motherboard firmware (UEFI/BIOS), surviving drive replacement and reformatting.
- Rootkit: https://en.wikipedia.org/wiki/Rootkit
- Unified Extensible Firmware Interface (UEFI): https://en.wikipedia.org/wiki/UEFI
- LoJax (Example): https://en.wikipedia.org/wiki/LoJax
5.1 Indicators of BIOS Compromise
- Persistence: Malware reappears immediately after a full disk wipe and fresh Windows install.
- Settings Lock: BIOS settings are password protected (and IT did not set the password) or settings revert automatically.
- Boot Order: The boot order changes automatically to prioritize an unknown network path or hidden partition.
5.2 Testing & Remediation
Directly scanning BIOS firmware is difficult without specialized hardware tools (e.g., Chipsec). We rely on Behavioral Diagnosis.
- The "Wipe Test": If a machine is wiped (Phase 4), reinstalled, and immediately alerts for the same malware upon first boot (before network connection), assume BIOS compromise.
- Remediation (Reflash):
- Download the latest BIOS firmware from the vendor website (using a clean PC).
- Save it to a clean FAT32 USB.
- Boot into BIOS and use the "Flash Utility" to overwrite the current firmware.
- Note: This does not guarantee removal of advanced persistent threats (like BlackLotus), but is the standard first-line defense.
- Escalation: If reflashing fails, the motherboard hardware is considered compromised and must be physically replaced.
6. Ransomware Policy & Legal Compliance
Warning: Strict Adherence Required
If the diagnostic reveals active Ransomware (files encrypted with extensions like .locked, .enc, etc.):
- NO PAYMENT PERMITTED: Under no circumstances will the Comfac Group of Companies pay a ransom.
- Legal Basis: Paying a ransom allows funds to flow to criminal syndicates. This is a potential violation of the Anti-Money Laundering Act (AMLA) of the Philippines (Republic Act No. 9160). Facilitating such payments can expose the company and individual staff to criminal liability.
- Procedure:
- If data is encrypted and no backups exist, the data is considered Lost.
- Preserve the encrypted drive image ONLY if required by Legal/HR for investigation.
- Proceed to wipe and reimage.
End of SOP