Detecting an infection without trusting the machine you are standing at

Why this matters

Detection sounds like a product question — run a scanner, read the result — and it is not. The machine you are scanning is the machine that may be lying to you, and the exam tests whether you understand what follows from that.

There is a second, less dramatic problem that takes up more of a technician's week: most machines reported as infected are not. They are old, or full, or running fourteen startup items. Telling the two apart quickly matters, because treating every slow laptop as an incident wastes everyone's time and treating every incident as a slow laptop is how a compromise spreads.

The lesson

Why a compromised system is an unreliable narrator, and what follows from that

The principle first: a compromised system reports on itself using components that may have been modified.

Every ordinary tool asks the operating system. The file explorer asks for a directory listing. Task Manager asks for a process list. A scanner asks to open files. If something has changed the answers, all three report a clean machine truthfully, in the sense that they are faithfully reporting what they were told.

What follows:

• A clean scan on a running, possibly-compromised machine is weak evidence. It is worth doing, and it is not proof.
• The stronger evidence comes from outside — a scan from separate media, the disk read in another machine, or observations from the network, which the machine cannot edit.
• Corroboration beats any single tool. Two sources that disagree is itself a finding: a file that one tool sees and another does not, or a connection the router logs and the machine denies.

How far to take this is a judgement about what is at stake. For a home laptop with adware, a scan from the running system is a reasonable first move. For a machine that handled regulated data, or one showing signs of something that hides, the offline route is the only one worth trusting — and if the machine matters enough, the right answer may be to stop and escalate rather than to investigate, which is what the operational procedures domain says about incidents.

The symptoms that are worth acting on, and the ones that are just an old laptop

Two lists, and having them straight saves a great deal of time.

Worth acting on:

• Security software disabled, or refusing to start or update.
• New accounts, or an account's rights changed.
• Browser search provider, home page or extensions changed without the user.
• Certificate warnings on sites that should have none.
• Outbound network traffic when nobody is using the machine.
• Files renamed or unopenable, or a ransom note.
• Programs installed that nobody installed.
• Credentials used from somewhere the user has never been — usually reported by a service rather than noticed on the machine.
• Sustained full processor load with no process the user recognises.

Usually just an old or neglected machine:

• Slow startup with many startup items.
• A mechanical disk in a machine expected to feel modern.
• A nearly full disk.
• Fans running under genuine load — a scan, an update, a video call.
• Pop-ups inside a browser on advertising-heavy sites.
• A browser with forty tabs and not enough memory.

The discriminators that push something from the second list to the first: it changed suddenly, it survives a restart, it is happening when nobody is using the machine, or something that should be running is not. That last one is the strongest single signal available: security software that will not start did not fail by accident.

Scanning from outside: recovery environments, bootable media and a second machine

Three ways to look at a machine without asking it, in increasing order of effort.

The recovery environment. Windows' own recovery environment runs from a separate image, giving a command prompt without the installed system running. It is enough to inspect the disk, copy files off, look at startup entries in the registry hives, and run some tools. It is quick and it is much better than nothing.

Bootable rescue media. A scanner on a USB stick that boots its own small operating system and scans the disk offline. Most major vendors publish one. This is the standard answer for suspected rootkits and for a machine that will not boot, and it has the important property that nothing on the disk is running while it works.

A second machine. Remove the disk, attach it to a known-good machine, and scan it there. The most thorough option and the one to use when the answer matters. Two cautions: attach it read-only where you can, and do not open files from it casually on the good machine — you have moved the disk, not disarmed it. Full-volume encryption also makes this route harder, which is a reason the recovery environment is often the practical choice.

Whichever route, the discipline is the same: capture evidence before changing anything. A list of running processes, startup entries, scheduled tasks, network connections and recently installed software, written to a file you keep. That list is what lets you say afterwards what was actually wrong, and if the incident turns out to matter, it is the only record that will exist.

Reading what a scanner reports, including the false positive and the 'cleaned' file

A scanner's output needs reading rather than accepting, and three cases come up constantly.

A detection with a name. The name is a starting point, not a conclusion. Vendors name the same thing differently and generic names cover broad families. What is useful is the path: where the file is tells you a great deal about how it arrived and what else to look at.

A false positive. These are real and reasonably common, especially for administrative tools, scripts, software developed in house, and anything packed or obfuscated for legitimate reasons. The signals: a file that has been there for years, a file belonging to software the organisation wrote, a detection with a generic heuristic name. The response is to check with a second opinion rather than to delete, and a file deleted in error from a line-of-business application is an outage you caused.

"Cleaned" or "removed". This is the one to be careful with. It means the scanner did something to the file it found. It does not mean:

• that the machine is now trustworthy;
• that it found everything;
• that the way in has been closed;
• that anything taken from the machine has been recovered.

So a clean second scan is a necessary condition and not a sufficient one. The questions that remain are how it arrived, what else it installed, and what it had access to — and the last of those is the subject of the credentials lesson later in this domain.

Deciding whether a machine can be repaired or should be rebuilt

This is a judgement call and it has a defensible framework.

Repair is reasonable when:

• The finding is adware, a browser hijack, or a single known trojan.
• It was caught early and the user reported it promptly.
• No credentials were entered and no administrative action was taken by it.
• The machine holds nothing sensitive.
• Offline scans come back consistent with each other.

Rebuild when:

• A rootkit or boot-level persistence is suspected or confirmed.
• Something ran with administrative rights.
• Security software was disabled by it.
• There are multiple unrelated findings, which usually means something installed a collection.
• Remote access tooling was installed.
• The machine handled regulated data, or belongs to someone whose access matters.
• You cannot establish how it arrived. An unexplained infection is an unclosed route.

Rebuild means rebuild: a clean installation from trusted media, not a reset that keeps files, and a restore of data rather than of applications and settings. Restoring an image taken after the infection reinstates it.

The two things to say to whoever decides: rebuilding takes hours and is certain, while cleaning takes less and is not; and the cost of getting it wrong is not a repeat visit but a machine that was trusted while it was not. When the stakes are low, clean. When they are not, the hours are cheaper than they look.