Antivirus generations, and diagnosing an infected host

Prevention first, and the mapping that makes it memorable

The four elements of malware prevention are policy, awareness, vulnerability mitigation and threat mitigation. What makes them memorable rather than arbitrary is that the concrete measures map one-to-one onto the three propagation mechanisms: patching answers vulnerability exploitation, access control limits what infected content can reach, and awareness training answers social engineering. If prevention fails, the sequence is detection → identification → removal, and if identification or removal fails, restore from a clean backup — with a wipe and rebuild from known-clean media for severe infections.

The four generations of antivirus

This is the ordinal question the paper likes, so anchor the list by what each generation matches on:

1. Simple scanners. Require a malware signature — a known bit pattern, possibly with wildcards. Limited to known malware. A second first-generation technique records program lengths and looks for changes.
2. Heuristic scanners. No specific signature: rules that look for probable infection — recognising the start of a polymorphic virus’s decryption loop, for example, and recovering the key. This generation also includes integrity checking: a checksum appended to each program, and to stop malware simply recomputing it, an encrypted hash with the key stored separately from the program, so the malware can neither generate a valid new hash nor adjust the program to reproduce the old one.
3. Activity traps. Memory-resident programs that identify malware by its actions rather than its structure. The advantage is economy: you need only identify the small set of actions that indicate malicious activity, rather than signatures for a vast and growing population of specimens.
4. Full-featured protection. Packages combining scanning and activity-trap components plus access control, limiting malware’s ability to penetrate and then to modify files in order to propagate.

The anchor sentence: 1 = signature (structure), 2 = heuristics and integrity (still structure), 3 = behaviour, 4 = everything plus access control. Generations 1 and 2 both look at what the code is; generation 3 is the first to look at what it does.

Two related techniques sit alongside. Sandbox analysis runs suspect code in an emulator or virtual machine, and its power is that encrypted, polymorphic and metamorphic malware must transform itself into real machine instructions in order to run — so the unpacked code can then be scanned, which is how signatures for previously unknown malware get made. Its hard design question is how long to run each sample, and the evasion is direct: malware detects the sandbox, sleeps past the analysis window, or uses a logic bomb keyed to a date or network location the sandbox does not match. Behaviour blocking integrates with the host operating system and monitors in real time, so unlike a sandbox it can block an action before it takes effect. Its limit is the mirror image: the code must run before its behaviour is visible, so some harm precedes the block.

Worked example — the host that is busy doing nothing

A workstation has become noticeably slow, and the network gateway shows a heavy volume of traffic to and from it — even though the user has closed the mail client, the browser and every other network application.

What kind of malware fits? The discriminator is the volume. Something is generating sustained traffic while nothing the user launched is running, which means an independent program is doing it — not anything parasitic waiting on a host program. Three candidates fit:

• A bot in a botnet, sending spam or contributing to a DDoS. This is the best fit for sustained high volume.
• A mass-mailing worm, propagating copies of itself to harvested addresses.
• Spyware or another exfiltration payload, shipping data out — although a keylogger filters to text near keywords, so its volume is normally low, and low volume would point away from a bot and toward theft.

And note what the volume rules out: a backdoor alone is quiet. It listens and waits, and produces essentially no traffic until someone uses it. So "high traffic" is evidence for an active agent, not merely for compromise.

How would you check? In order, because an unordered tool list earns little:

1. Confirm the traffic and find its endpoint. Read the gateway’s own counters and take a packet capture at the gateway, not on the host — an out-of-band view that the machine cannot influence.
2. Map the connections to a process. ss -tunp or netstat -b on the host, or lsof -i, to name the process holding each socket.
3. Check persistence. Autostart entries, services and scheduled jobs: systemctl list-unit-files, cron, and the equivalents on Windows via Autoruns. Malware that survives reboots has to be written down somewhere.
4. Check for hiding. Boot the machine from live rescue media and compare the file and process picture it shows against what the running system reported. A discrepancy is the rootkit finding.
5. Scan offline. Run an up-to-date engine from that rescue medium, and preferably a second engine as well.

Step 4 is the one that is easy to skip and is not optional. Steps 1–3 all run on the suspect machine, and every one of them asks the possibly-subverted kernel a question.

How did it get in? At least three plausible vectors, drawn from the propagation axis: a drive-by download from a compromised or ad-serving page; a trojanised installer the user downloaded; an e-mail attachment opened by the user; an unpatched network service exploited directly; or an infected removable device.

How would you restore it safely?

• Disconnect from the network first, to stop exfiltration and spread.
• Capture evidence before cleaning — a disk image and the volatile state — because cleaning destroys the answer to "how did this happen".
• Scan and clean from rescue media, never from the running system.
• If a kernel-mode rootkit is present, do not clean — rebuild. Reinstall the operating system from a trusted image. This is the only fully trustworthy answer, and the reason is the layer-below argument: a tool running above the rootkit cannot verify the absence of the rootkit.
• Restore data from backups taken before the compromise, which requires knowing when the compromise began — another reason for step 2 of this list.
• Patch the vector, and rotate every credential that was typed on or stored on that machine, from a different device.