Mechanisms

How antivirus detection actually works

Four mechanisms sit behind every scanner sold today. Following one file from download to verdict shows what each one contributes, and where each one fails.

Product pages describe detection in layers of adjectives. Underneath the adjectives the field is narrow: a scanner can compare a file to things it already knows, judge a file by its characteristics, watch a program's behaviour once it runs, or ask a remote service what it thinks. Every feature name in this category is one of those four, or a combination, or a piece of packaging around them.

Matching against what is known

The oldest mechanism is comparison. A vendor's analysts collect malicious samples, extract something that identifies each one — commonly a hash of the file, or a distinctive sequence of bytes from inside it — and publish these as signatures. The scanner on your device holds a large set of them and checks files against it.

The appeal is precision. A signature match is not an opinion; the file either matches or it does not, so there is almost no risk of flagging something clean. It is also cheap enough to run constantly on ordinary hardware.

The limit is structural rather than a matter of quality. A signature can only describe a sample someone has already analysed. Malicious code that changes its own encoding on each copy, or that was compiled an hour ago, matches nothing. This is why the definition update exists and why it runs so often, and it is also why no serious vendor has relied on signatures alone for a very long time.

Judging by characteristics

Heuristic detection asks a different question: not "have I seen this file before?" but "does this file look like the kind of thing that turns out to be malicious?" The scanner examines structure — how the file is packed, which system functions it imports, whether its code is obfuscated, how closely it resembles families already catalogued — and produces a score.

This is what lets a product stop a variant released after the last update. It is also where false positives come from, and the reason is worth stating plainly: the characteristics that make a file suspicious are not exclusive to malicious files. Installers compress and obfuscate their contents for legitimate reasons. Small utilities written by one person, and scripts written inside an organisation, have none of the signals of established software and frequently get flagged.

Why aggressiveness is a setting, not a quality

A vendor choosing where to set heuristic sensitivity is choosing a position between two costs, not choosing between good and bad. Turn it up and more genuine threats are caught along with more clean files. Turn it down and the reverse. A product flagging something a competitor ignores is not evidence that either one is broken.

Watching what a program does

The third mechanism gives up on deciding in advance. Behavioural analysis lets the program start, and monitors what it does: whether it begins reading and rewriting documents in sequence, whether it installs itself to run at startup, whether it reaches out to an address associated with command and control, whether it tries to interfere with the security software itself.

Its advantage is that behaviour is harder to disguise than appearance. Code can be repacked to look like anything; encrypting a user's documents looks like encrypting a user's documents. Most of what is marketed as ransomware protection is behavioural — a rule that halts a process which starts systematically rewriting files, sometimes with a copy-on-write protection over particular folders.

Its cost is that something has already run. Behavioural detection is a contained failure rather than a prevented one, and the containment is not always complete. This is the mechanism-level reason why a current backup is treated by the Australian Cyber Security Centre as the central protection against ransomware rather than as a fallback.

Asking a remote service

The fourth mechanism is cloud lookup. Instead of consulting only what is stored on the device, the product sends a hash of a file — and often metadata such as its name, size, source and digital signature — to the vendor's servers, which answer from a far larger and far fresher dataset than could be shipped to every customer.

It genuinely shortens the gap between a sample being analysed anywhere in the world and being recognised on your device, from hours to minutes. It also means two things worth being explicit about. The product's verdict on a file can change without anything on the device changing. And information about the files you handle leaves your device and goes to the vendor.

What to check before accepting that trade

The vendor's privacy policy is the document that says what is sent, how long it is kept and whether it is used for anything besides detection. For a reader in Australia, the relevant question is where that data goes and who else receives it. The Office of the Australian Information Commissioner explains the Australian Privacy Principles, including the rules on disclosing personal information overseas, and handles complaints about how personal information is managed.

One file, end to end

The mechanisms are easier to hold together as a sequence. Take a single downloaded installer.

  1. The browser writes the file to disk. That write triggers on-access scanning — the thing product pages call real-time protection. Nothing has been run yet.
  2. A hash is calculated and matched. If it matches a known signature, the process ends here: the file is blocked or moved to quarantine, and a notification appears. Most detections are this ordinary.
  3. No match, so the file is examined. Heuristics look at its structure, its imports, whether it is signed and by whom, whether it resembles a catalogued family. A score comes out.
  4. The hash goes to the vendor's service. The answer may be that the file is widely seen and trusted, that it is known bad, or — commonly for a new installer — that it is rare and unknown, which raises the score without settling anything.
  5. The file runs, under observation. If the score was inconclusive, behavioural monitoring watches what the program does. An installer writing to its own folder and registering an uninstaller is unremarkable. The same program enumerating documents and rewriting them is not, and that is where the process is stopped.
  6. A verdict is recorded either way. If it was stopped, the file sits in quarantine, recoverable in case the judgement was wrong. If it was cleared, the hash is remembered so the same work is not repeated.

Two things follow from the sequence. Most of the work happens before anything runs, and the decision at each step is provisional — a file cleared on Tuesday can be flagged on Thursday because the vendor's dataset changed, not because your device did.

The trade-off nobody escapes

Every increase in sensitivity raises both the number of threats caught and the number of clean files flagged. There is no setting that raises one and lowers the other, and no vendor has an exemption from it. Claims that a product catches everything with no false positives describe an impossibility, and are worth reading as advertising rather than as measurement.

The four mechanisms, and what each one gives up
MechanismDecidesStrengthCost
Signature matching Before the file runs Exact; almost no false positives Blind to anything not yet analysed
Heuristic analysis Before the file runs Catches variants and new samples Main source of false positives
Behavioural monitoring While the program runs Hard for code to disguise its actions Acts only after execution has begun
Cloud lookup Before the file runs Fresh data; updates without a download Sends file data to the vendor; needs a connection

What independent testing measures

Laboratories exist that test security products against collections of samples under a published methodology, and the useful ones publish the methodology alongside the results so the numbers can be interpreted. Two long-running European laboratories are AV-TEST and AV-Comparatives; both put their test reports on their own sites.

This site publishes no test results of its own, because it runs no tests. Reading the laboratories directly is better than reading anyone's summary of them, and three habits make that reading worthwhile: check the date, because results older than a year describe software that no longer exists; check that the false positive figure is reported next to the detection figure, since a detection rate alone is not a result; and check whether the tested configuration matches the product actually sold, because the tested edition is often not the entry-level one.

What detection cannot reach

A scanner examines files and processes. A large share of what actually costs Australians money never becomes a file on a device at all. Phishing messages ask for a credential; investment and romance scams ask for a transfer; a fake support call asks for remote access that the person grants deliberately. In each case the software is working as designed and the decision was made by a person.

The National Anti-Scam Centre's Scamwatch service publishes what current approaches look like, which is the closest thing to a countermeasure for this category. Account protections such as multi-factor authentication reduce the value of a stolen password, and prompt patching removes the flaws that exploits depend on. Detection is one layer among several, and the layers do not substitute for each other.

For which product to put that layer in place with — including what the operating system already provides at no cost — see choosing antivirus software in Australia.