A manufacturing client called us on a Tuesday morning with a problem that didn’t add up. Their endpoint agent had flagged and quarantined a suspicious executable on three workstations. Good. Except the same three workstations kept reinfecting themselves after every cleanup pass. Wipe the file, reboot, infection back within ninety minutes. That’s the calling card of a multipartite virus — malware that refuses to live in just one place on disk, and the exact scenario that separates a textbook cleanup from a three-day incident response engagement.
This is the story of that engagement. What we saw, what we got wrong the first time, and the detection logic we ended up shipping as part of their managed environment.
Why Multipartite Malware Is Still a Threat in 2026
Multipartite viruses are an old concept with a modern problem. The technique dates back to the early 1990s — Tequila, Invader, Ghostball — but the core idea never stopped working. A multipartite sample infects both executable files and the boot sector (or today, the UEFI firmware region, MBR backup, or hypervisor-layer persistence). You remove one payload, the other reinfects.
Most defenders are trained to think of malware as a file. One hash, one quarantine, one win. Multipartite samples break that mental model. MITRE ATT&CK tracks the relevant techniques under T1542.003 (Bootkit) and T1547 (Boot or Logon Autostart Execution), and if you’re not hunting for both in parallel, you will miss half the infection every time.
I’ll say the uncomfortable part out loud. Most mid-market EDR deployments I see are blind to boot-sector persistence. The agent runs in userland or kernel-land on a booted OS. It doesn’t see what wrote itself to sector 0 before Windows loaded.
How a Multi-Vector Infection Actually Spreads
The source material I teach from puts it bluntly: a multipartite virus spreads using multiple methods simultaneously, and the method of infection varies based on applications, OS version, and how the author intended it to operate. That’s not marketing language. That’s the operational reality.
Here’s the typical kill chain we modeled for the client:
- Initial access — usually a file infector dropper delivered via phishing attachment or USB (T1091).
- File execution — the payload attaches itself to executables the user touches (T1547.001 persistence via common binaries).
- Boot sector write — the same payload drops a second stage into the MBR or an EFI partition (T1542.003).
- Cross-reinfection — if AV removes the file infector, the boot-stage rewrites it on next reboot. If you rewrite the MBR, the file infector re-drops the boot code.
The two components watch each other. That’s the entire trick, and it’s why cleanup scripts that only target one vector fail.
Day One: The Scoping Mistake I Made
When we took over containment on day one, I did what most analysts do. I pulled the file hash, searched EDR telemetry, got a clean list of the three affected hosts, and recommended reimaging. Standard playbook.
The SOC team at the client flagged a problem twelve hours later. Two of the three machines had been reimaged from a trusted Windows 11 golden image. Both were reinfected by the next business day.
That was the moment the word “multipartite” moved from a theoretical category in training slides to a very real operational problem. The reimage process wrote a new OS partition but preserved the existing MBR. The boot-stage payload survived. It then reinfected the freshly deployed OS the moment it ran.
Lesson learned the hard way. For any suspected multipartite infection, your disk hygiene has to be total — zero the entire drive with diskpart clean all on Windows, or dd if=/dev/zero of=/dev/sdX bs=1M on a Linux recovery environment, before reimaging. If you only wipe the OS partition, you’ve done half a job.
The Memory Forensics Pivot That Cracked the Case
Once we realized we were dealing with a dual-persistence sample, we pivoted to memory analysis. The Windows Forensics reference I keep on my desk makes a point that applies directly here: most antivirus software runs within the operating system, not in the boot sector, and that gap is exactly what boot-stage malware is designed to exploit.
We used Volatility 3 against captured RAM images from all three hosts. The command was straightforward:
# Detect injected code regions and hooking behavior
# malfind surfaces memory pages marked PAGE_EXECUTE_READWRITE with no backing file
vol -f host01.mem windows.malfind
# Confirm suspicious kernel modules for bootkit persistence
vol -f host01.mem windows.modules | findstr /i "unknown"
# Compare process lists to catch rootkit-style hiding
vol -f host01.mem windows.psscan > psscan.txt
vol -f host01.mem windows.pslist > pslist.txt
fc psscan.txt pslist.txtThe deltas between psscan and pslist gave us the first concrete evidence of a hidden process. That process was the file-infector component being re-launched by a scheduled task that itself was re-registered on every boot by the boot-stage.
Building a Detection Rule That Actually Works
Signature-based detection on the file hash was useless within forty-eight hours — the sample mutated its file body between infections, consistent with a polymorphic wrapper around a multipartite core. The source I reference on this describes polymorphic malware as samples that rewrite themselves over time to avoid matching prior detections. We had both behaviors stacked on each other.
So we shipped behavior-based detection instead. Here’s a simplified Sigma rule we pushed to their SIEM. It looks for the telltale pattern of a userland process issuing raw writes to physical drive handles, which is what MBR-writing code has to do:
title: Suspicious Raw Write to Physical Drive (MBR Tampering)
# Detects processes opening \\.\PhysicalDrive0 for write access
# MITRE ATT&CK: T1542.003 (Bootkit)
logsource:
product: windows
category: file_event
detection:
selection:
TargetFilename|contains: '\\.\PhysicalDrive'
Image|endswith:
- '.exe'
# Exclude signed Microsoft and OEM disk utilities
filter_signed:
Signed: 'true'
Publisher|contains:
- 'Microsoft'
- 'Dell'
- 'HP'
condition: selection and not filter_signed
level: highWe paired that with a scheduled baseline check of the MBR against a known-good hash, run nightly. If the MBR hash drifts on any endpoint that isn’t in a sanctioned patch window, the SOC gets paged. If you want the broader context for how we map these rules into an analytic stack, I wrote up the approach in MITRE ATT&CK mapping in Sentinel detection rules.
The Eradication Runbook We Shipped
After the incident closed, we wrote the client a permanent runbook for suspected multipartite or bootkit activity. The short version:
Step 1: Isolate before you investigate
Network-quarantine every affected host. Multipartite samples frequently carry worming components that scan SMB (T1021.002) and RDP (T1021.001), and you do not want lateral movement during triage.
Step 2: Capture memory first, then disk
Use WinPMEM or FTK Imager from a known-clean USB to grab RAM before shutdown. The boot-stage is only fully visible in memory once the OS is running — shut down too early and you lose the process hollowing evidence.
Step 3: Wipe at the device level, not the partition level
This is the mistake I made on day one. diskpart clean all or equivalent full-drive zero pass. No exceptions.
Step 4: Reimage from signed media only
Verify the hash of your deployment ISO against the vendor value. Polymorphic multipartite malware has historically been observed infecting network deployment shares — if your SCCM or WDS source is compromised, reimaging is reinfection.
Step 5: Re-baseline MBR and firmware
Capture the MBR hash and UEFI firmware version post-deployment, store it in your CMDB, and alert on drift. We use PowerShell for this, and if you’re new to the cmdlets that make this practical, the approach in PowerShell Select-Object covers the property filtering you’ll need.
The Caveat Every Honest Analyst Should Admit
Multipartite detection is not a solved problem. The rule I showed you catches loud implementations. A careful attacker can write to the MBR through signed, living-off-the-land binaries, or drop persistence in the EFI System Partition via signed bootloaders, and those evade the raw-write heuristic entirely. The reference material I work from explicitly points out that attackers now combine malware types — worms for initial access, Trojans for control, multipartite techniques for persistence — and each combination forces you to retune detection.
If your environment doesn’t have Secure Boot enforced with measured boot attestation, you are one clever dropper away from a multipartite infection that survives reimaging. That’s not a vendor pitch. That’s the current state of endpoint security in mid-market networks.
Practical Takeaways You Can Act On This Week
If you run endpoints in production — anyone’s, including your own — do these three things before Friday. Enable Secure Boot on every managed device and audit for systems where it’s disabled. Add a nightly MBR hash check to your configuration management. Write one behavior rule for raw writes to \\.\PhysicalDrive handles by unsigned binaries and ship it to your SIEM.
Multipartite malware isn’t exotic. It’s a forty-year-old technique that still works because most of us clean up half an infection and call it done. Don’t be that analyst.
If you’re staring at an endpoint that keeps reinfecting itself after cleanup, that is not normal and it will not fix itself. Reach out to our incident response team and we’ll walk the environment with you.
