The removal procedure, and why its order is the thing being examined

Why this matters

CompTIA publishes a malware removal procedure as an ordered list, and the order is the content. Every step exists because doing it later, or not at all, produces a specific failure that people actually hit — a machine reinfected from its own restore point, a network infected while a machine was being cleaned, a user who does the same thing again next week.

So this lesson is the procedure with the reason attached to each step. Learn it as a sequence with causes and the exam questions answer themselves, because they are almost always "what do you do next" or "what did they skip".

The lesson

Identify and verify the symptoms, before touching anything

Step one: identify and verify the symptoms.

Before touching anything, establish what is actually happening. Ask the user three questions:

• What are you seeing? In their words, not yours.
• When did it start, and what changed around then? New software, an attachment, a website, a USB stick, a phone call.
• Did you enter any credentials, or approve anything? This determines whether the credentials lesson later in this domain applies, and it is much better asked now than discovered later.

Then verify it yourself. Reproduce the symptom if you can. A large share of reports are misremembered, and a fault you have not seen is a fault you cannot confirm you fixed.

Then write down what you found before you change it: running processes, startup entries, scheduled tasks, installed programs by date, browser extensions, network connections. Five minutes, and it is the only record of the machine's state.

Why this is first: everything afterwards destroys evidence. If the machine turns out to matter — regulated data, a business email compromise, anything with a legal dimension — the operational procedures domain requires that evidence to be preserved, and the decision to stop and escalate is one you can only make if you looked first.

Quarantine the machine: why disconnecting comes before cleaning

Step two: quarantine the infected system.

Disconnect it from the network — unplug the cable, turn off the wireless — and disconnect any external storage. Do this before cleaning, and the reasons are specific:

• Worms spread while you work. A machine left connected during a thirty-minute scan is a machine attacking its neighbours for thirty minutes.
• Ransomware encrypts network shares using the user's own permissions. Time connected is damage.
• Command and control. Many infections take instructions. Cutting the connection stops it receiving new ones, including instructions to destroy evidence.
• Exfiltration continues until the connection is cut.
• Other machines may already be affected, and quarantine is what stops you carrying it between them on a USB stick.

The practical points: disconnect the network, not the power — pulling the power loses the memory state and can damage the file system, and there is rarely a reason for it. Tell the user why, because a machine that has been taken off the network is a machine somebody cannot work on and they will want to plug it back in. And if you need to download a tool, download it on a different machine.

The exam's version of this step is short: disconnect before you clean. The common wrong answer is to start scanning immediately, which is the instinct and which lets everything above continue while you watch a progress bar.

Disable restore points, and the reason a clean machine can reinfect itself

Step three: disable System Restore.

The reason is exact. System Restore takes snapshots of system files and the registry, and those snapshots can contain the infection. If a restore point created while the machine was infected is kept, three things can go wrong:

• The scanner cannot clean files inside protected restore data, so detections keep reappearing.
• A later restore — by the user, or automatically after a failed update — reinstates the infection onto a cleaned machine.
• The machine appears to reinfect itself for no reason, which is exactly what is happening.

So the step is: turn System Protection off for the system drive, which deletes the existing restore points, then proceed with cleaning. The restore points are lost, and that is the intended cost: they are contaminated and worth nothing.

Two related places with the same problem and the same reasoning: previous versions and shadow copies on the volume, and the hibernation file, which holds a memory image from while the machine was infected.

The half of this step people forget is the other end — turning protection back on afterwards and creating a fresh restore point, which is step five. A machine left with System Protection disabled has had a recovery feature silently removed, and nobody will notice until the day it is needed.

Remediate: scan from a trusted environment, then update, then scan again

Step four: remediate. This is the step everybody thinks is the whole procedure, and it has its own internal order.

1. Update the scanner's definitions — but from a controlled position. The machine is disconnected, so either update it before disconnecting, use rescue media that fetched its definitions on another machine, or connect briefly and deliberately.
2. Scan from a trusted environment. Safe mode limits what starts, which is better than a normal boot; bootable rescue media is better still, because nothing on the disk is running. The detection lesson explains why this matters.
3. Quarantine rather than delete on the first pass. Quarantine is reversible; deletion of a false positive is not.
4. Scan again with a different product. No scanner finds everything, and agreement between two is much stronger evidence than a clean result from one.
5. Check the places scanners are weakest: browser extensions, scheduled tasks, services, startup entries, proxy settings, hosts file, and DNS settings. Several common infections leave nothing a file scanner will find and everything a person would notice in those six places.
6. Then update the operating system and applications. If it arrived through a vulnerability, cleaning without patching leaves the door open.

And then the honest check: if the scans disagree, if something keeps coming back, or if anything from the rebuild list in the detection lesson applies, the answer is to stop cleaning and rebuild. Repeating step four a fourth time is not a plan.

Re-enable protection, create a fresh restore point, and educate the user

Step five: re-enable protection and create a restore point. Step six: educate the user.

Re-enabling matters because step three deliberately broke something:

• Turn System Protection back on and create a fresh restore point, so the machine has a known-good state that is actually known-good.
• Confirm the security software is running, updated, and set to start automatically. Something disabled it once.
• Confirm the firewall is on and its rules are what you expect — an infection may have added one.
• Reconnect to the network and confirm ordinary things work.
• Change any credentials that were used on the machine while it was infected, which is the subject of the next lesson.

Then the education step, which is genuinely part of the procedure and is usually skipped.

• Tell the user how it arrived, if you know. Specific beats general: "this came from the download on that site" is actionable; "be careful online" is not.
• Give them one change to make, not five. The most valuable single one is usually where they get software from.
• Tell them what to report and to whom, and make reporting feel safe.
• Write it in the ticket, because the next occurrence will be handled by someone else.

The reason this is the last step and not an optional extra: the machine has been returned to the same user, in the same environment, with the same habits. Without this step, the procedure has fixed a symptom and scheduled a repeat.