Payloads: corruption, attack agents, information theft, stealthing

Four classes of payload

System corruption. An attack on the integrity of software, hardware or data, usually gated by a logic-bomb trigger: a named file or device being present or absent, a chosen date or weekday, a particular software version, or a particular user running the program. The absent-file trigger is the elegant one — it fires when the author’s own record disappears from the payroll. Damage reaches hardware: a virus that rewrites the BIOS so the machine will not boot until the chip is reprogrammed, and Stuxnet driving industrial equipment outside its operating range until it failed.

Ransomware belongs here: it encrypts the victim’s data and demands payment for the key. The technical turning point is worth knowing precisely. Early ransomware used weak or purely symmetric cryptography, so the key could often be recovered without paying. Later versions encrypt under a public key whose private half never leaves the attacker, and against a large key that is not recoverable. The countermeasure is therefore not cryptographic: it is good backups plus an incident response and disaster recovery plan. Paying is not a countermeasure.

Attack agent (theft of service). The machine becomes a resource for the attacker. A bot is a covertly taken-over Internet-attached machine — and not only a PC: servers, routers and cameras are all bots — used to launch attacks that are hard to trace back to their author. A coordinated collection is a botnet. Uses include DDoS, spam, spyware distribution, click fraud, file sharing, spreading further malware, and cryptocurrency mining.

The single distinguishing property: a bot awaits command and control; a worm self-activates. That is the line, and the command-and-control channel is also the arms race — IRC channels, then covert HTTP, then peer-to-peer, then domain generation algorithms that produce enormous numbers of candidate server names, so seizing one name achieves nothing and defenders must reverse the generator and pre-register the candidates. Fast-flux DNS rotates the addresses behind a name every few minutes. The effective countermeasure is not cleaning individual bots; it is taking over or shutting down the command-and-control network.

Information theft. Keyloggers capture keystrokes at the endpoint, because credentials are typed in the clear before the encrypted channel gets them, and they filter to text near keywords such as "login" — which is why a keylogger’s outbound traffic is small, a useful discriminator when diagnosing a host. Spyware monitors browsing, redirects requests to fake sites, and modifies data exchanged with specific sites in flight; it escalated when banks moved credential entry into graphical applets that defeated simple keylogging. Data exfiltration is the general case: the unauthorised transfer of data out of a system.

Stealthing. A backdoor is a secret entry point that bypasses the normal security checks. Its legitimate ancestor is the maintenance hook a developer uses to skip authentication during development — the same mechanism with different intent, which is exactly why backdoors are so hard to find in code review. The modern form is a network service listening on an unexpected port.

Worked example — one host, four payloads

Follow a single workstation as it accumulates payloads, and watch each one defeat a different defence.

1. A logic bomb is dropped first, set to corrupt a database on a date months away. Nothing detects it, because it does nothing: there is no behaviour to observe yet.
2. A bot joins the machine to a command-and-control network. Now there is behaviour — outbound connections to an address nobody chose — so a network monitor could see it. The attacker answers that by moving command and control to ordinary HTTPS on port 443, where it looks like everything else.
3. A keylogger is added. It sends very little data, deliberately, so volume-based detection does not fire. But it is a running process with an open file, so a process listing and an autostart audit would find it.
4. A kernel rootkit is installed last, and it answers exactly that: it removes the bot and the keylogger from the kernel’s list of active processes and filters their files out of directory listings. The process listing now shows nothing, and it is not lying to you by accident — the tool is faithfully reporting what the kernel tells it.

Each payload closed the door the previous one had left open, and the last one closed the door on the tools.

Rootkits and the layer-below arms race

A rootkit is a set of programs that maintains covert root-level access while hiding its own presence, by subverting the mechanisms that report on processes, files and registry contents. Six classes, in two useful pairs:

• Persistent (survives a reboot, so it must be stored somewhere and activated at start-up — which is precisely what makes it easier to detect) vs memory-based (cannot survive a reboot, and is therefore harder to detect while it runs).
• User mode (intercepts API calls and edits the results — a directory listing simply omits its files) vs kernel mode (intercepts native calls; can hide a process by removing it from the kernel’s list of active processes).
• Virtual machine based (installs a lightweight hypervisor beneath the running operating system and virtualises it) vs external (lives outside normal operation entirely, in BIOS, UEFI or system management mode, with direct hardware access).

On Linux, subverting system calls takes three forms: modify the system call table so selected entries point at the rootkit; modify the targets the table points at, leaving the table itself untouched; or redirect the table by pointing references at a new copy elsewhere in kernel memory.

The organising idea is the most transferable thing in the chapter: each generation installs one layer below the layer that detected the last one. Early rootkits modified user-mode utilities and libraries, and kernel code — one layer down — could see the discrepancy. So rootkits moved into the kernel, where the antivirus program is subject to the same modifications it is looking for. Then below the kernel, into a hypervisor. Then below that, into firmware.

The consequence for recovery is brutal and examinable: a kernel-mode or VM-based rootkit means a complete operating system reinstall, and a UEFI rootkit may mean replacing hardware. And it is why the only trustworthy inspection of a suspected rootkit is one performed from outside the running system.