Post-Incident Malware Scrub

Part of the RECOVER Playbook ← Return to Hub

Phase: Recover All vessels

Satisfies: E26E27IMO MSC-FAL.1BIMCO v5

Post-Incident Malware Scrub

This guide covers the systematic removal of malware following a cyber incident — including evidence collection before remediation, where to look for persistence mechanisms on maritime OT workstations, the data sanitisation workflow, and post-scrub verification. Under IACS UR E26 §4.5.1.2, recovery actions must not inadvertently destroy evidence. This means collection always precedes remediation.

Malware often uses “Living off the Land” techniques — hiding inside legitimate Windows tools, startup scripts, or scheduled tasks rather than obvious executable files. Re-importing backed-up data without scrubbing can cause an immediate re-infection loop. The scrub procedure must be thorough and must follow a specific sequence: collect evidence first, then remediate, then verify.

Step 1 — Evidence collection before any scrubbing

Per E26 §4.5.1.2, this step must happen before any file deletion or system wipe. Evidence collected here feeds the Post-Incident Debriefing and supports insurance and Class documentation.

Export syslog and firewall logs — Last 7 days minimum, exported to a clean USB drive not connected to the OT network. These logs are destroyed when the system is wiped.

Document running processes — On any responsive Windows workstation: open Task Manager (Ctrl+Shift+Esc), screenshot the Processes and Services tabs, and run netstat -an in CMD and save the output. This captures RAM-resident malware before shutdown.

Record all identified malicious files — File name, full path, file size, date modified. Use the evidence log table format below. This record becomes the threat intelligence entry in the updated SCSRP.

Quarantine — do not delete yet — Move identified malware to an isolated quarantine folder on a separate USB drive, not in the recycle bin. The shore-side SOC or OEM may need the file for analysis. Confirm with DPA before permanent deletion.

Step 2 — Where to look for persistence mechanisms

On maritime Windows CBS workstations, malware commonly hides in these locations. Check every location on every affected system — do not assume that removing the obvious payload is sufficient.

Startup and scheduled execution

Startup folder

C:\Users\[user]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

All users startup

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

Scheduled tasks — check for unknown entries

schtasks /query /fo LIST /v | more

Services — look for unknown display names

sc query type= all state= all

Registry persistence locations

Run keys — auto-execute on login

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

Run once key

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

WinLogon — hijacked shell entry

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Any entry in these keys pointing to an unfamiliar path or executable must be quarantined and investigated before the system is returned to service.

Maritime-specific risk: OEM vendor scripts and PLC configuration tools are sometimes installed directly in startup locations for convenience during commissioning and never removed. Before flagging an entry as malicious, confirm with the OEM whether it is a legitimate installer left behind. Document the confirmation in the scrub log either way.

Step 3 — Sandbox scan method

Never scan backup data or recovered files on the live OT network. Use an isolated standalone scanning station — a dedicated laptop in the ETO office — completely disconnected from all vessel networks.

Dual-engine scan

Use two different AV engines. One signature-based for known malware families, one behavioural/heuristic to catch zero-day variants and fileless malware. Single-engine scans miss behavioural threats that have no known signature.

Macro and script inspection

Disable macros in all recovered Office documents before scanning. Any macro-enabled file (.xlsm, .docm) used on CBS workstations must be manually inspected by shore-side IT or OEM before being returned to service.

Step 4 — Data sanitisation workflow

Follow this sequence for every piece of data returning to the OT network after an incident. Do not skip steps under time pressure — an incomplete scrub is worse than a delayed return to service.

Identify high-risk file types — Filter recovered data for executable and script extensions: .exe .bat .ps1 .vbs .wsf .js .docm .xlsm .cmd .msi .dll. Any file with these extensions requires individual inspection before return to service — not just an AV scan.

Offline sandbox scan — Run full disk scan on the sandbox station using both AV engines. Document scan results including engine version, definition date, and any detections. Update AV definitions before scanning if the sandbox station has internet access via a clean connection.

Quarantine detections — confirm with DPA before deletion — Move any detected file to the quarantine USB. Do not delete without DPA sign-off. The shore-side SOC or OEM may need the file to identify the malware family and advise whether other systems are at risk.

Incremental import with monitoring — Return clean data to the CBS workstation in batches — not all at once. Monitor CPU usage, network traffic, and syslog for anomalies after each batch. A sudden CPU spike or outbound connection after import indicates re-infection from a file that passed the scan.

OEM database verification — For PMS, AMS, or SCADA historian databases — contact the OEM before re-importing. Many OEMs can provide a verification script to check data structure integrity before re-entry. Corrupted database entries can cause silent failures weeks after recovery.

Evidence log — malware scrub record

Every identified and actioned file must be logged. This record is submitted with the Post-Incident Review report and retained in the vessel’s SMS records.

File / entry	Location found	Threat type	Action taken	DPA sign-off
engine_logs_2026.xlsx	C:\Users\ETO\Documents	Trojan.Downloader.W97M	Quarantined · restored from archive	✓
manual_update.exe	C:\Temp — unknown origin	Suspicious heuristic	Quarantined · sent to shore SOC · deleted after SOC confirmation	✓
HKCU\…\Run\svchost32	Registry Run key — bridge workstation	Persistence mechanism	Registry key deleted · target executable quarantined	✓

OEM coordination note

When restoring PMS, AMS, or SCADA historian databases, coordinate with the OEM before re-importing. They can often provide a clean verification script to check data structure integrity. Do not re-import OEM-proprietary database files without OEM guidance — a corrupted configuration file can cause a CBS to behave unexpectedly weeks after recovery with no obvious link to the original incident.

Document all OEM communications during the scrub — including the date, name of OEM contact, and any guidance received. This documentation is part of the evidence package for Class and insurance.

PREVIOUS:
Integrity Verification

Next Section

Post-Incident Debriefing

Post-Incident Debriefing This guide provides a structured debrief process following a cyber incident — capturing lesso...

Post-Incident Debriefing →