The four stages, in the order they run
When a file is written to disk, opened, or executed on a machine with real-time protection enabled, the operating system hands the scanner a moment to inspect it before the action completes. That moment has to be short, because everything the user is doing waits for it. The stages are therefore arranged from cheapest to most expensive, and most files never reach the later ones.
Stage one: matching what is already known
The first check is arithmetic. The scanner calculates a hash of the file and compares it against a list of hashes known to be malicious and a list known to be safe. If the file is on either list, the question is settled in a fraction of a millisecond. Beyond exact hashes, vendors ship signatures that match distinctive byte sequences inside a family of related files, so that small variations still match.
This stage carries the whole reputation of antivirus for being fast and reliable, and it has one absolute limit: it recognises only what the vendor has already catalogued and distributed as a definition update. Malware that alters itself between copies, or that was assembled an hour ago, has no entry to match. That limit is not a defect in a particular product; it is what the technique is.
Stage two: reading the file without running it
If nothing matched, the scanner examines the file's structure. This is static analysis, and the rules it applies are heuristics: is the executable compressed or obfuscated in a way that conceals its contents; does it import functions associated with keystroke capture or process injection; does a document contain a macro that reaches out to the network; is the file claiming to be one type while its header says another.
Each of these observations is suggestive, not conclusive. Plenty of legitimate software is compressed to reduce download size, and plenty of legitimate documents automate something useful. The scanner scores the observations and acts above a threshold set by the vendor, which is precisely where false positives come from — and why products differ on the same file without either being broken.
Stage three: asking the vendor's servers
Where the local checks are inconclusive, the product can consult the vendor's infrastructure. Typically it sends a hash, and sometimes metadata such as the file's size, its digital signature, or where it was downloaded from. In return it receives a reputation: seen on millions of machines for two years, or seen eleven times in the last hour, all in one country.
Rarity is informative. Widely distributed legitimate software has a long, broad history; targeted malware does not. This is also the stage that makes a product's behaviour depend on connectivity, and the stage with privacy implications, because something about your files is leaving your machine. What exactly is transmitted, how long it is retained and where it is processed are set out in the vendor's privacy documentation, and reading that before installation is reasonable diligence. In Australia the handling of personal information is governed by the Privacy Act 1988 (Cth) and the Australian Privacy Principles, explained by the Office of the Australian Information Commissioner.
Stage four: watching what the program does
The final stage happens after the file has started running. Behaviour monitoring observes the live process: whether it writes itself into start-up locations, injects code into other processes, contacts an address with no history, disables recovery features, or begins reading and rewriting documents in bulk. Some products first run the file in a sandbox to observe it without consequence.
This is the only stage with any chance against a zero-day, because it does not need to have seen the code before — only the pattern of activity. It is also the stage that interrupts unusual legitimate software, such as a backup tool that legitimately reads every document on the disk, or a developer's build script. Behaviour monitoring necessarily intervenes after something has begun, so the question it answers is how much happened first.
What each stage buys and what it costs
| Stage | Catches | Misses | Cost |
|---|---|---|---|
| Signature and hash | Known malware, exactly identified, with a name. | Anything new, and anything that changes itself between copies. | Negligible time; storage for the definition set; frequent updates. |
| Static and heuristic | New variants that resemble known families or use suspicious structures. | Well-crafted code that looks ordinary until it runs. | Some delay on first access, and a real rate of false positives. |
| Cloud reputation | Rare and newly distributed files that no local rule flags. | Everything, when the machine is offline or the service is unreachable. | Metadata about files leaves the device; dependence on a connection. |
| Behaviour monitoring | Malicious activity regardless of whether the file was recognised. | Slow or subtle activity that stays below the thresholds. | Continuous overhead; interruptions to unusual legitimate programs. |
What happens after a detection, and what to do about it
A verdict is not the end of the process. The product moves the file to quarantine, records a log entry with the detection name, and in most cases shows a notification. The detection name matters more than it appears to: a name that reads like a specific family is usually a signature match, while a name containing words such as generic, heuristic or suspicious indicates an inference from stage two or four.
- Read the detection name and the file path before doing anything. A detection inside a downloads folder is a different situation from one inside an application you installed deliberately.
- Leave the file in quarantine. It cannot run from there. Deleting it immediately removes the ability to recover if the verdict was wrong.
- If the file belongs to software you trust, check with that software's own vendor. Legitimate vendors publish notices when their releases are flagged in error.
- If the detection came with the file arriving unexpectedly, treat the delivery as the event. An attachment nobody mentioned, or a download from a site that was not the vendor's, is worth reporting as phishing to Scamwatch.
- Only restore a file from quarantine once you have confirmed it independently, and never by turning protection off to make the warning stop.
Why two products disagree about the same file
Users often check a file against a second scanner and find a different answer. This is expected. The vendors maintain separate definition sets, write their own heuristics, set their own thresholds, and take different positions on the boundary category of potentially unwanted programs. A product that flags an aggressive system optimiser and a product that ignores it are applying different definitions of unwanted, not different levels of accuracy.
The corollary is that running two real-time products at once is not twice the protection. Each will inspect the other's file access, and the contention commonly produces slow file operations, repeated prompts and occasional failures that look like a hardware fault. Where a second opinion is wanted, an on-demand scanner run by hand and left switched off between runs avoids the conflict.
What none of these stages address
Every stage above examines code. None of them examines a decision. If a person is persuaded to enter a password into a convincing copy of a bank's sign-in page, no file has been created and no process has misbehaved — the transaction is, technically, the user doing what they intended. The same is true when someone is talked through granting remote access on a phone call, or approves a sign-in prompt they did not initiate.
This is the ceiling on what any antivirus product can do, and it is the reason two-factor authentication, a current backup and a habit of verifying requests through a channel you chose yourself carry more weight than the choice between one scanner and another. Device security basics sets those out in order of effect.