Malware and Viruses

A precise taxonomy starts from two orthogonal questions: how does the code get from one machine to the next (propagation), and how does the code survive reboot and evade removal once it is there (persistence). Historically, malware is named for its answer to the propagation question. A virus is code that inserts a copy of itself into a legitimate host program or document; it cannot execute or spread on its own — it requires that host to be run or opened by a person. A worm, by contrast, is a standalone program that actively seeks out and infects new machines over a network, with no human triggering each new infection. This distinction — dependent on a host and a human versus self-propagating — is the single most important axis in the taxonomy, and it explains why worms can achieve orders-of-magnitude faster spread than viruses. A trojan horse (or trojan) is malware that misrepresents its purpose: it presents itself as something desirable — a game, an invoice, a security update — while carrying out unauthorized actions. Trojans do not self-replicate at all; their propagation mechanism is entirely social, making them the purest expression of exploiting human trust rather than a software vulnerability. A rootkit is not defined by propagation but by persistence and concealment: it is a set of techniques for hiding the presence of malicious code, files, processes, or network connections from the operating system's own reporting mechanisms, typically by operating at or below the privilege level of the tools that would detect it (kernel-mode, hypervisor-mode, or firmware-level). Two further terms sharpen the picture. Payload is the malicious action carried out once malware executes — data exfiltration, encryption for ransom, keystroke logging, or destructive wiping — and is logically independent of propagation mechanism; the same payload (say, a ransomware encryptor) can be delivered by a trojan, a worm, or a virus. A dropper or downloader is a small first-stage program, often delivered via a trojan or a code injection exploit, whose only job is to fetch and install a larger, more capable payload — separating the moment of initial compromise from the moment the real malicious logic arrives, which frustrates both static analysis and early detection.

Virus mechanics. A file-infecting virus locates a target executable, appends or prepends its own code, and rewrites the entry point so its code runs first, then jumps to the original program so the infection appears transparent to the user. ``` PSEUDOCODE: Simple file-infector virus function INFECT(target_file): if IS_ALREADY_INFECTED(target_file): return # avoid re-infecting; conserves file size, avoids detection original_entry = READ_ENTRY_POINT(target_file) virus_body = READ_OWN_CODE() APPEND(target_file, virus_body) new_entry = OFFSET_OF(virus_body, target_file) PATCH_ENTRY_POINT(target_file, new_entry) STORE(virus_body, "saved_original_entry", original_entry) function ON_EXECUTION(infected_file): RUN(virus_body) # payload / further propagation runs first candidates = SCAN_DIRECTORY(CURRENT_DIR()) for f in candidates: INFECT(f) # spread requires this file to be executed JUMP_TO(saved_original_entry) # resume host program, user notices nothing ``` The crucial line is `ON_EXECUTION`: propagation only happens when a human runs the infected file. This is the defining bottleneck of viruses — their spread rate is bounded by human behavior (file sharing, email attachments, USB drives), not network bandwidth.

Worm mechanics. A worm removes the human bottleneck entirely by scanning for vulnerable machines and exploiting them directly, typically via a buffer overflow or injection vulnerability in a network-facing service. ``` PSEUDOCODE: Network worm propagation loop function PROPAGATE(): targets = GENERATE_CANDIDATE_IPS() # random scan, local-subnet scan, or hit-list for ip in targets: if PORT_OPEN(ip, VULNERABLE_SERVICE_PORT): success = SEND_EXPLOIT(ip) # e.g. crafted overflow payload if success: UPLOAD_SELF(ip) REMOTE_EXECUTE(ip, self_copy) # new copy begins its own PROPAGATE() loop SLEEP(scan_interval) PROPAGATE() # recursion / loop: fully autonomous ``` No human ever runs anything: the worm authenticates its own spread by exploiting a flaw in listening software. This is why worm outbreaks (Morris 1988, Code Red 2001, SQL Slammer 2003, WannaCry 2017) can saturate a network in minutes to hours rather than the weeks or months typical of virus outbreaks.

Trojan mechanics. A trojan's "algorithm" is almost entirely social engineering plus a payload; the interesting engineering is in disguise and delivery. ``` PSEUDOCODE: Trojan delivery and execution function BUILD_TROJAN(payload, disguise_asset): wrapper = PACKAGE(disguise_asset, payload)

# disguise_asset: legitimate-looking installer, PDF icon, "invoice.pdf.exe", etc. return wrapper function ON_USER_EXECUTION(wrapper): RENDER_DISGUISE(wrapper) # show fake UI: installer wizard, document viewer SILENTLY_RUN(payload) # drops rootkit, keylogger, ransomware, backdoor if NEEDS_PERSISTENCE(payload): INSTALL_PERSISTENCE(payload) # registry run key, cron job, launch agent ``` The only "vulnerability" exploited is human judgment — there is no code-execution flaw to patch, which is precisely why trojans remain effective against fully patched, sandboxed systems and foreshadow the human-factor material ahead.

Rootkit mechanics. A rootkit's core technique is interception and falsification of the queries that detection tools make to the operating system. ``` PSEUDOCODE: Kernel-level rootkit hiding a process (hooking system call table) function INSTALL_ROOTKIT(): original_getdents = SYSCALL_TABLE[SYS_GETDENTS] # directory listing syscall original_readdir_ptr = SYSCALL_TABLE[SYS_READDIR] SYSCALL_TABLE[SYS_GETDENTS] = HOOKED_GETDENTS # replace pointer in kernel memory STORE(original_getdents) # keep original to call through function HOOKED_GETDENTS(...args): real_result = CALL(original_getdents, args) filtered = [entry for entry in real_result if not MATCHES(entry.name, HIDDEN_PREFIX)] return filtered # userland tools never see hidden files function HOOKED_PROCESS_LIST(...args): real_result = CALL(original_process_enum, args) return [p for p in real_result if p.pid != HIDDEN_PID] ``` Because the hook sits in the kernel, every userland tool — `ls`, `ps`, antivirus scanners, even the shell — receives the falsified result. This is the structural reason rootkits are categorically harder to detect than trojans: detection tools trust the very layer that has been subverted, a direct violation of the isolation assumptions studied in Sandboxing and Isolation.

Virus spread as a discrete branching process. If an infected file is run with probability $p$ per unit time and each execution infects on average $k$ new files before detection, the expected number of infected files after $t$ generations is $O(k^t)$ — exponential in principle, but throttled hard by the human-execution factor $p \ll 1$ and by the fact that files, unlike network hosts, are not globally reachable. This is why historical virus outbreaks (Melissa, ILOVEYOU) took days to weeks to peak, bounded by email-forwarding behavior rather than computational limits.

Worm spread as logistic growth. Classical worm epidemiology (used to model Code Red) treats the internet as $N$ vulnerable hosts and models the fraction infected $I(t)/N$ with the differential equation ``` dI/dt = β · I(t) · (N − I(t)) ``` where $\beta$ is the pairwise infection rate (a function of scan rate and exploit success probability). This is the logistic equation; its solution is ``` I(t) = N / (1 + ((N − I₀)/I₀) · e^(−βNt)) ``` The key qualitative fact, provable by inspecting $dI/dt$: growth is slow while $I(t) \ll N$ (few targets found), accelerates once a critical mass of infected scanners exists, and saturates as $I(t) \to N$ (running out of susceptible hosts). This S-curve explains the empirically observed pattern in real worm outbreaks: an initially unnoticed "quiet phase," then a sudden explosive phase — SQL Slammer infected an estimated 75,000 hosts within ten minutes once past the inflection point — followed by saturation. The complexity of full network saturation is $O(\log N / \beta N)$ time-to-saturation under this model, meaning that doubling the scan rate ($\beta$) roughly halves the time-to-compromise, which is why network-level rate-limiting of anomalous outbound connections is a first-order defense.

Rootkit detection lower bound (informal argument). Let $L$ be the privilege layer at which a detection tool $D$ runs, and $L'$ the layer at which the rootkit $R$ operates. If $L' \le L$ (rootkit is at or below the tool's layer, e.g., kernel rootkit vs. user-space antivirus), then every system call $D$ issues to gather evidence can, in principle, be intercepted and falsified by $R$, because $R$ controls the interface $D$ relies on. Formally: detection from inside a compromised trust layer cannot be sound unless $D$ possesses information $R$ cannot tamper with — this is why robust rootkit detection requires either (a) a strictly lower layer (hypervisor introspection, a hardware root of trust, offline disk analysis from a clean system), or (b) cryptographic integrity measurement anchored below $L'$, such as a measured boot chain rooted in a TPM. This is the same trust-boundary reasoning underlying Sandboxing and Isolation: a sandbox is only meaningful if the enforcement layer sits strictly below what it constrains.

Tradeoffs. Signature-based detection is $O(1)$ per file scan against a hash/pattern database but is blind to novel or polymorphic malware. Heuristic/behavioral detection catches novel variants but costs continuous runtime monitoring overhead and produces false positives. Full-system integrity measurement (measured boot, remote attestation) gives strong correctness guarantees against low-level persistence but cannot itself prevent a legitimate-looking trojan from being voluntarily executed by a user — no purely technical layer defeats a sufficiently convincing lie, which is exactly the gap explored in Security Engineering and the Human Factor.

Trace a concrete (simplified, historically grounded) scenario combining several mechanisms, as real intrusions do.

Scenario: An attacker sends a phishing email with an attachment `invoice_Q3.pdf.exe`.

Applying the logistic model from the previous section with $N = 500$ hosts on the corporate subnet, $I_0 = 1$, and an estimated $\beta = 0.02$ (per-host-pair infection rate per minute, chosen to match observed WannaCry-class spread), the S-curve predicts:

Computed from `I(t) = N / (1 + ((N−I₀)/I₀)·e^(−βNt))` with `βN = 10`: the network stays under 3% infected for the first hour (the "quiet phase" that lets IDS false negatives go unnoticed), then crosses 50% infection between minute 130 and 140 (the explosive phase), and saturates by minute 180. This single trace shows why the first thirty minutes after initial compromise — while the trojan and rootkit stages are still setting up — are the highest-leverage window for detection, before the worm module's exponential-then-saturating spread makes containment a subnet-wide incident-response problem rather than a single-host cleanup.

Fred Cohen, then a graduate student, formally defined the computer virus and demonstrated the first true self-replicating program under laboratory conditions in 1983, proving mathematically that no algorithm can perfectly detect all possible viruses — a direct analog of the halting problem. Robert Tappan Morris's 1988 worm, though intended as a research experiment in counting internet hosts, contained a propagation bug causing repeated reinfection, and it inadvertently produced the first large-scale demonstration of logistic-style network saturation, leading directly to the founding of the first CERT (Computer Emergency Response Team).

Enterprise endpoint detection and response (EDR) tools are built directly on this taxonomy: they combine signature databases (fast, cheap, blind to novel malware), behavioral heuristics (catch worm-like scanning and trojan-like persistence installation), and kernel-integrity monitoring (catch rootkit-style hooking) as layered defenses, because no single layer defeats every category. Cloud providers isolate customer workloads with hypervisor-level Sandboxing and Isolation precisely because it sits below where a guest-OS rootkit could operate, satisfying the lower-privilege-layer requirement for sound detection derived above. Secure boot and TPM-based measured boot chains in modern laptops and phones exist specifically to defeat firmware- and bootloader-level rootkits, anchoring trust in hardware that malware cannot rewrite. Email security gateways and browser sandboxing target the trojan vector by neutralizing the social-engineering delivery mechanism before a human ever makes the fatal click — and because that click is the one link in the chain no technical control fully removes, this taxonomy sets up the deeper question of Security Engineering and the Human Factor: how systems should be designed for the humans who actually operate them.

Ask the tutor: How does the logistic worm-spread model change if the network is segmented into isolated subnets rather than one flat address space?