pk.org: Computer Security/Lecture Notes

Malware

Part 1 - What Malware Is and How It Gets In

Paul Krzyzanowski – 2026-11-03

In an April 2025 campaign, a compromised website displayed a fake “I’m not a robot” checkbox. Clicking it copied a command to the clipboard, and the page then instructed visitors to paste that command into the Windows Run dialog and run it. Doing so started a chain of scripts that delivered Lumma Stealer, malicious software that collected browser passwords, session cookies, and cryptocurrency wallet data. The fake checkbox is an instance of a technique called ClickFix, first seen in 2023. A page presents a verification step or an error message and tells the visitor to fix it by running a command. The same lure has delivered many kinds of malware since.

The browser’s restrictions prevented the page from running that command directly, but persuading the visitor to run it gave the attacker code execution with the user’s permissions.

We begin with the terms used to describe malware, separating how a program spreads from what it does, and then lay out the lifecycle of a malware infection: infection, delivery, persistence, trigger, communication, payload, and propagation. This part covers the first stage, infection: the routes by which malware reaches execution, including exploits, removable media, malicious documents, and compromised update channels. Social engineering, the route that targets people rather than software, is the subject of Part 2. Part 3 covers delivery, persistence, and concealment with rootkits, and Part 4 covers triggers, communication with an operator, payloads, propagation, and detection.

What Malware Is

A backup program and ransomware both read and rewrite files. A remote administration program and a malicious remote control program both accept instructions from another machine. The operations alone do not identify which program is malicious.

Malware, short for malicious software, is software deliberately deployed to violate the security interests or policies of the people responsible for a system.

A user’s decision to run a program does not authorize every action the program might take. An employee may be allowed to install software on a company computer, but clicking an installer does not give it permission to steal company documents. An administrator can authorize a remote-support tool to control the same computer for an approved support task.

A bug can also delete files or expose a password. The difference is intent: an accidental cleanup error belongs in a reliability investigation, while code written to erase a competitor’s records belongs in a malware investigation, even if the resulting file operations look identical.

Malware does not always need administrator privileges to cause substantial damage. An ordinary user’s process can already read that user’s documents, browser data, and accessible network shares. In a company, the employee may have access to company-sensitive content. Encrypting those documents requires only the write permission the user already has. Exfiltrating them requires only a network connection. An intrusion can achieve its objective without ever controlling the kernel.

Malware Labels Describe Different Properties

A malware report may describe how a program spreads, how it deceives a user, what it does, or how it hides. These properties are independent of one another, so several labels can apply to a single program.

Propagation labels, such as virus and worm, describe how a program spreads. Payload labels, such as ransomware and infostealer, describe what it does after it executes. Other labels, including trojan and __rootkit, describe deception or concealment.

Vendor names add another source of variation. Two security companies may assign different family names to closely related samples. A detection name can include the platform, a suspected family, and the behavior that triggered the detector.

Viruses

A virus replicates by inserting its code into a host, which can be an executable program, a document containing macros (programs stored in the document), or a disk’s boot sector. The boot sector is the block of code that a computer first loads from a disk during startup. The infected host activates the virus when the associated program, document, or boot code is executed, allowing the virus to infect additional hosts.

The host is part of the definition. An executable file that merely contains a malicious program is not necessarily a virus. It becomes one when its replication mechanism infects other hosts. A downloaded credential stealer that never inserts itself into another program is malware, not a virus.

The terminology dates back to experiments that Fred Cohen conducted as a graduate student at the University of Southern California in 1983. Cohen inserted experimental code into a Unix utility called vd, which displayed file structures graphically, and the modified utility ran the inserted code before its intended work.

People ran a useful program, and Cohen’s inserted code ran with their permissions. The operating system authenticated the user’s account, but it did not verify that every instruction in the utility served the account holder’s purpose. The same applies to libraries: loading an untrusted library gives its code the same access as the application that loads it.

Worms

A worm is a self-replicating program that spreads between systems without inserting its replication code into a separate host program or document. Many worms exploit network services and do not require any user action on each newly infected machine. Others use credentials or social engineering. A virus’s need for a host is the defining difference between the two, while the absence of human involvement is a common difference rather than a rule.

The Morris worm, released on November 2, 1988, spread among Unix-based systems through several access paths. Its repeated infections on the same systems consumed resources and made machines unusable, and the Federal Bureau of Investigation’s account documents the incident and the subsequent investigation. A worm can disrupt availability simply through replication, even when its author has not included a separate destructive payload.

Propagation and persistence are independent. A worm can run in memory and spread rapidly without arranging to restart after a reboot, while a nonreplicating backdoor can remain on one machine for years.

Deception, Access, and Payloads

Several other labels describe how a program disguises itself or hides, how it gains access, or what it does:

A trojanized utility can install an infostealer and a backdoor, and a rootkit can hide all three. Ransomware may steal documents before encrypting them, taking on the the function of an infostealer.

A remote access trojan (RAT) is a trojan that contains a backdoor: it gives an unauthorized operator remote control of a machine. A legitimate remote-support product provides many of the same operations, and an attacker may deploy the legitimate product itself. In that case, the malicious activity is the unauthorized installation and use, while the file remains an authentic vendor release.

Backdoors in Legitimate Code

Not every backdoor is a separately installed program. A deliberately altered authentication routine can accept a password known only to the attacker, and a hidden account or an added key for SSH, the remote-login service, can preserve access through mechanisms the system already provides. Searching only for suspicious executables will miss all of these.

A backdoor can also be a feature its developer put there on purpose. The sendmail mail server of the 1980s had a debugging mode that any remote sender could switch on with the DEBUG command. Once it was on, a message could name a program instead of a mailbox as its recipient. The server would then run that program with the body of the message as its input. The mode went far beyond anything the mail protocol was designed to do. It was enabled by default in the BSD and Sun releases of the time, so anyone who could connect to a mail server and knew about this undocumented feature could run commands on it. The Morris worm used it as one of its four ways in.

An attacker can also plant a backdoor in software that other people will install. This becomes a supply chain attack. In 2021, a contributor using the name Jia Tan began sending useful patches to XZ Utils, a compression library included in nearly every Linux distribution and maintained by one volunteer. Over the next year, accounts that appeared nowhere else online pressed the maintainer to share the work. By the end of 2022, Jia Tan had commit access and was preparing releases. In February 2024, the releases contained a backdoor. The malicious code was hidden in binary test files. A build script that existed only in the release archive, not in the public source repository, extracted it and compiled it into the library during the build.

The target was OpenSSH, the software that handles remote logins. On Debian and Fedora, two popular Linux distributions, the OpenSSH server loads the library indirectly through the system’s service manager. The backdoor thus ended up inside the program that accepts remote logins. It intercepted public-key authentication. A sender holding the right private key could then run commands without logging in. Andres Freund, a Microsoft engineer, found it in March 2024 because remote logins on his test system had started taking half a second longer and using more processor time than they should. The backdoor had reached only development versions of the distributions. Had the discovery come a few weeks later, it would have made it to production servers worldwide.

The XZ Utils backdoor illustrates a lesson that Ken Thompson described in 1984: the source code that people review is not necessarily the code that runs.

Several Labels on One Incident

On June 27, 2017, malware later named NotPetya spread from Ukraine to companies around the world within hours. It stopped container shipping at Maersk, drug production at Merck, and package delivery at FedEx’s TNT subsidiary. The White House attributed it to the Russian military in February 2018 and called it “the most destructive and costly cyber-attack in history.” Total losses have been estimated at more than $10 billion.

NotPetya combined a compromised software update with automated movement from machine to machine inside networks. Microsoft’s initial technical analysis traced the delivery through the Ukrainian M.E.Doc accounting application and documented both the movement using stolen credentials and the exploitation of Windows vulnerabilities. The update channel explained the first execution, and the worm behavior explained the subsequent spread.

NotPetya displayed a ransom demand, but its destructive behavior led researchers to classify it as a wiper. The same incident therefore involved a supply chain compromise, credential theft, worm propagation, and a destructive payload. Blocking the compromised update could have prevented initial execution, while restricting movement between machines could have limited the subsequent spread.

Lumma also fits several labels, but none of them describes propagation. Its credential collection makes it an infostealer, a fake utility used to deliver it is a trojan, and the script that fetches it is a downloader, a component we describe in Part 3. It is not a virus or a worm, because it does not replicate. When Microsoft and the US Justice Department disrupted its infrastructure in May 2025, Microsoft counted roughly 394,000 infected Windows machines over the preceding two months, reached by repeatedly delivering the same malware rather than by replication.

Potentially Unwanted Programs

The definition of malware is based on what the people responsible for a system authorized. With advertising software (adware), browser toolbars, and bundled utilities, poor disclosure can make it hard to tell what the user agreed to.

A potentially unwanted program (PUP) is software whose behavior or installation practices may conflict with the user’s expectations or interests. The label often applies to intrusive advertising, unwanted browser changes, or bundled installations with inadequate disclosure.

Agreeing to install a weather utility is not consent to continuous collection of browsing history. A checkbox hidden on an unrelated installation screen is weaker evidence of consent than a clear explanation of the data collected and the available controls.

A toolbar may use standard browser extension interfaces to change the default search engine or collect browsing history. Using those interfaces does not show that the user authorized those actions. Whether the toolbar is unwanted or malicious depends on what the installer disclosed, what the user agreed to, and whether the user can undo the changes or remove the toolbar.


The Malware Lifecycle

A classic description of a self-contained virus separates three functions:

  1. The infection mechanism finds another host and inserts the code needed to replicate.

  2. The trigger determines when a particular action occurs, such as on a date, after a count, or when a target configuration is present.

  3. The payload performs the action beyond replication, such as displaying a message, collecting information, or damaging files.

The three functions are independent: a virus can replicate on every execution and activate its destructive action only when a condition becomes true. They also need not occupy separate files or even distinct routines.

Modern malware is rarely a single self-contained program, so the description has grown into a longer list of activities.

The classic infection mechanism, finding and infecting the next host, appears in this list as propagation, and infection now means how the malware first arrives and executes. The list is a teaching order rather than a sequence that every program follows, because malware can omit, repeat, or combine these activities:

  1. Infection is how the malware arrives and first executes: through a vulnerability, a deceived user, or a device someone plugs in.

  2. Delivery is the work of a dropper or loader that deploys the actual payload, often in several stages.

  3. Persistence arranges for the malware to survive logouts and reboots.

  4. Trigger is the condition under which the payload activates.

  5. Communication is the contact with an operator, the person or group running the malware, to receive instructions and return results.

  6. Payload is what the malware does: steal, encrypt, control, or sabotage.

  7. Propagation is spreading to other systems, for malware built to do so.

An infostealer may run its payload at startup with neither a trigger nor persistence; a worm propagates before doing anything else; and fully autonomous malware never contacts an operator.

Concealment runs alongside the stages rather than being one of them: a rootkit hides whatever the earlier stages installed, so we cover it after persistence. Detection, the defender’s view of every stage, comes last.


Infection: How Malware Gets In

Malware gets into a computer in a few ways:

  1. By exploiting a vulnerability in software the computer already runs: a network service, a document viewer, a browser, or the code that handles removable media.

  2. By convincing an unsuspecting user to install software, run a command, open an attachment, or click on a link.

  3. By physical access to the machine, such as a removable drive carried into an isolated network.

The following sections cover the first and third routes. The second route, social engineering, does not need a flaw in any software. We cover it on its own in Part 2. These three are not mutually exclusive. The Lumma page relied only on a user’s decision, and the worms described below relied only on a vulnerability, but many intrusions combine routes.

They are also not the only ways in. An attacker with stolen administrative credentials can log in and use ordinary deployment tools, and a compromised update service can distribute malicious code through an approved installation process. Neither requires a new exploit or a new mistake by the final user. The final section of this part covers both.

Initial access is the first foothold in the target environment, and execution is the running of attacker-chosen instructions. The two can occur together, but a stolen account may provide initial access before any malware runs, and an uploaded file may reach the machine without ever gaining execution.

Privilege escalation gives the attacker greater authority on the compromised machine (e.g., gaining root access), and lateral movement uses access to one machine or account to reach others. These actions cross additional boundaries after initial access.

Lumma distributors used several routes. ESET, a Slovak security company, documented cracked software, fake code repositories, phishing (deceptive messages, which we cover in Part 2), and delivery by other malware in May 2025. Microsoft’s delivery analysis also documented malvertising, malicious advertising that directed software searches toward fake download sites. A familiar utility’s name in a search advertisement did not identify the organization supplying the installer.

Exploiting a Running Program

A program already processes data from files, messages, and network connections, and a flaw in that processing can turn input into an instruction.

An exploit uses a vulnerability to make a system perform an unintended operation. A memory-corruption exploit can overwrite control information and redirect execution, while a command-injection exploit can place attacker-supplied instructions in text that a shell interprets.

The attacker initially has only the privileges of the compromised process. Exploiting a document renderer does not automatically give control over the kernel. If the renderer is confined to a sandbox, the attacker may need a second vulnerability to escape it. The chain then includes remote code execution and a separate increase in authority.

The exploit gives the attacker a way to run code, and the malware payload uses that execution to steal information, install a backdoor, or damage the system. Repairing the exploited vulnerability prevents that entry path from working again, but it does not remove a payload that has already installed itself.

A zero-day vulnerability is a flaw for which no protective patch is available, and a zero-day attack exploits such a flaw. The name refers to developers having “zero days” of advance warning to prepare a fix: attackers may exploit the flaw before the developer even knows it exists.

The term does not describe the exploitation technique or whether user interaction is required. Many attacks exploit older flaws on machines that have not received an available patch. Code Red and Slammer, discussed below, both spread this way.

An N-day vulnerability is one that has been public for N days, and an N-day exploit targets it. A patch is usually what makes the flaw public. Attackers compare the patched code with the previous version to find what changed, work out the flaw the change repairs, and build an exploit for it. Organizations take days or months to test and install patches, and some systems never receive them. The attacker therefore has a window between the release of a patch and its installation on a given machine. The window closes as N grows and more systems are patched, which is why exploits often appear within days of a patch. A zero-day exploit is expensive, because it requires finding a flaw that nobody else has. An N-day exploit starts from a flaw the vendor has already pointed out.

Automated Network Propagation

An exposed service can become both the entry point and the source of attacks on other machines. Each newly infected host contributes another scanner, so the number of infections grows exponentially at first.

On July 19, 2001, a variant of Code Red infected more than 359,000 machines in fourteen hours. It attacked Microsoft’s Internet Information Services web server through a buffer overflow, and the Center for Applied Internet Data Analysis, an Internet measurement research group, measured the spread. Each vulnerable server was reachable through the interface it already provided to web clients.

On January 25, 2003, SQL Slammer used a buffer overflow in Microsoft SQL Server and the related Microsoft SQL Server Desktop Engine. The worm fit in a single 376-byte UDP packet, a message sent without first setting up a connection. Researchers measured it infecting more than 90 percent of vulnerable hosts within ten minutes. A patch had been available before the outbreak. A payload that small allowed replication to proceed faster than an organization could investigate an alert and manually patch its machines.

Defenders were limited by response time. A defense that starts after the first infection must compete with automated replication, so restricting access to an unnecessary network service and patching it before exposure remove the opportunity before the first infection.

Removable Media and Air-Gapped Systems

A file can cross a network boundary without using a network connection. A removable drive moves data between machines, and those machines may interpret some of that data as executable instructions.

An air gap separates a system or network from direct connections to other networks. It does not eliminate transfers through removable storage, maintenance laptops, or imported project files, so those transfers become the entry points. An isolated machine can also write stolen data to removable storage for pickup later, without a live network connection to a remote operator.

Before network downloads became routine, programs moved between PCs on floppy disks and CD-ROMs. A file-infecting virus could modify executables or document macros on a writable floppy, and sharing the disk distributed the infected copies. An infected boot sector provided another activation route, since the machine executed it during boot. Flash drives replaced those media, hold far more data, and move between machines more often. They can carry infected executables, malicious documents, or shortcuts that reach a vulnerable parser.

Stuxnet, discovered in 2010, targeted the control systems for the uranium enrichment centrifuges at Iran’s Natanz plant. That network was air-gapped, so the attackers’ first problem was not exploiting a software vulnerability but reaching the machines. No network path existed for an exploit to travel over, so the malware had to arrive on something carried in. Stuxnet was built to spread through removable drives. Symantec, a security company, documented two methods: exploiting a flaw in how Windows handled shortcut files, and an older method based on AutoRun, a Windows feature described below. How the first copy entered the plant is not publicly established, but removable media is the leading explanation.

A drive on its own does not execute code; it is a storage device. Execution requires a mechanism, such as a user launching a file, a startup feature interpreting a configuration file, or a vulnerability in the software that displays the drive’s contents.

AutoRun and Parser Flaws

AutoRun was a Windows feature that read an autorun.inf file from newly inserted media and ran the program it named. It was meant to start an installer from a CD, and malware on a flash drive used it the same way: inserting the drive was enough to run the code. Microsoft removed it for USB drives in Windows 7 in 2009, and later for earlier Windows versions by update; CDs and DVDs kept it.

A parser vulnerability is a separate route, as the Stuxnet shortcut flaw was: it could trigger when a user merely viewed the folder containing the shortcut, so opening an executable was unnecessary. Removing AutoRun closed the route that ran a named program on insertion while leaving the flaw in the code that displayed a directory.

USB Drop Attacks

A USB drop attack leaves a flash drive where a target is likely to find it and relies on the finder to plug it in and open what it holds. The drive carries one of the routes above: a program the finder runs, a document with a malicious macro, or a file that reaches a parser flaw. The attacker supplies only the lure, and the finder supplies the execution step that the attacker could not perform from outside.

In April 2015, researchers at the University of Illinois Urbana-Champaign, the University of Michigan, and Google dropped 297 flash drives at thirty locations on the Illinois campus: parking lots, hallways, academic buildings, and common areas. They didn’t contain malicious softare but each drive contained files that reported back to the researchers when opened. The first drive was connected within six minutes, 98 percent of the drives were picked up, and 45 percent had a file opened.

The finders were not careless people looking for free storage. In a follow-up survey, most said they opened the drive to find its owner, and nearly half opened a file labeled as photos before the resume that would have held contact information. That is why training alone is a weak defense here: a person who intends to return a drive still runs whatever it carries. The controls below limit what an unknown drive may do once connected and do not depend on the finder’s judgment.

Impersonating USB Devices with BadUSB

When connected, a USB device reports its interfaces and capabilities to the operating system, which uses that information to determine how to interact with it. A device that looks like a flash drive can, with the modified firmware, report a keyboard interface, a network interface, storage, or multiple interfaces.

BadUSB refers to attacks that alter or abuse USB-device firmware, the software stored inside the device that controls it, so that the device performs an unexpected function. SRLabs, a German security research company, demonstrated firmware reprogramming in 2014. A reprogrammed device could impersonate a keyboard to generate keystrokes, or a network adapter to modify network configuration, although susceptibility depends on the controller and its firmware protections.

Keyboard impersonation sends input through the operating system’s normal keyboard interface. If the active session permits it, generated keystrokes can start an application or enter commands with that session’s privileges, but the device does not automatically acquire administrator rights or defeat a locked login screen.

Scanning files on a flash drive does not (and cannot) inspect its controller firmware, and reformatting its storage also leaves that firmware unchanged. A policy that blocks removable storage may still accept the same physical device if it presents a permitted keyboard interface.

Defending against Malicious Media

The defenses depend on how the malicious media causes code to execute:

  1. Automatic execution on insertion. Windows blocks the traditional AutoRun mechanism on ordinary USB flash drives. AutoRun should be disabled on systems and media that still support it, including optical discs.

  2. Files the user runs. Application control restricts which executable programs may run. Scripts need restrictions enforced by their interpreters, and separate macro settings disable document macros or permit only approved ones, as the Australian Cyber Security Centre’s guidance describes. These policies apply to files on removable media as well as downloaded files.

  3. Infected boot sectors. A firmware setting that disables booting from external media prevents the computer from executing the drive’s boot code during startup.

  4. Parser flaws. The operating system and the applications that read the drive’s contents have to be kept patched. A malicious file can exploit a flaw in that software even if the user never runs the file as a program.

A device impersonating a keyboard requires additional controls. It sends keystrokes rather than providing a file to run, so disabling AutoRun or external boot does not block its input. Application control can still restrict programs that the injected keystrokes attempt to launch.

Device-control policy can require approval before a new USB device or one of its functions, such as keyboard input, becomes usable. Linux provides authorization controls for whole devices and individual interfaces. However, a device reports its own manufacturer and product IDs. A reprogrammed device can copy an approved device’s IDs, so an allowlist based on those IDs does not reliably identify the physical device. Keeping ports and approved peripherals under physical control reduces opportunities to attach or substitute a hostile device.

An unattended workstation should be locked, so that injected keystrokes reach only the lock screen. Where removable data transfer is necessary, a dedicated transfer system can inspect files and allow only approved file types before copying them to the destination system.

Documents That Execute Code

A file format can contain instructions as well as displayed content. An Office document, for example, may include a script that automates editing, calculations, or reporting, and the application runs that script when the document opens or when the user acts on it.

A macro is a program stored in a document and run by the application that opens it. A malicious macro can use the application’s permitted operations to modify files or start another program. This route depends on macro execution being enabled, or permitted by a trusted configuration, and it does not require a vulnerability in the application.

Microsoft Office macros are the dominant example. Most companies use the software, so there there are many targets and documents are shared as part of normal business operations.

Office has had a built-in programming language since the early 1990s, and since Office 97, every Office application has used Visual Basic for Applications (VBA). VBA is a complete programming language rather than a list of editing commands: a macro can read and write any file the user can reach, call the Windows API, download from the Internet, start other programs, and send mail through Outlook. A macro has all the permissions the user running Word has.

That power made macro viruses the most common malware of the late 1990s. The first widespread one, Concept, appeared in 1995 and did nothing beyond spreading, but it showed that a document could carry a program that infected Word’s default template. From there, every document the user saved afterward.

On March 26, 1999, the Melissa virus began spreading as an infected Word document. Its macro used Outlook to send messages to the first fifty addresses in a user’s address book, and the FBI’s account of Melissa describes the resulting mail disruption. The document was the replication host, while the mail client supplied distribution. Messages appearing to come from acquaintances helped the next recipient trust the attachment.

Macro documents remained the most common type of malicious attachment throughout the 2010s. Office 2000 added a warning before running macros. From Office 2010 onward, a downloaded file opened in a read-only view with a bar that had two buttons, one to enable editing and then one to enable content.

The attacker’s problem became persuading the user to click both. The document itself supplied the reason to click: a notice on its first page said that the file was protected, or that it was made in a different version of Office, or that content had to be enabled before the text would appear. Emotet, a network of infected machines that was rented out to deliver other groups’ malware until Europol dismantled it in January 2021, delivered its loader mostly through Word documents of this kind.

In 2022, Microsoft changed the default so that Office blocks macros in files that came from the Internet, and the bar no longer offers a button to enable them; trusted locations and organizational policy can still allow them. Within months, attackers had moved their lures into other file types, and macro documents dropped out of the leading delivery routes.

A different document attack exploits a parsing flaw. The application intends to interpret the file only as data, but malformed contents corrupt memory or reach an unsafe interpreter, a program that executes commands or scripts given to it as text. The two attacks need different defenses: blocking macros does not repair a flaw in an image decoder or document parser, and fixing parser bugs does not prevent a user from authorizing a malicious macro.

Macros are not the only executable content a document can carry. The PDF format supports embedded JavaScript, which the viewer runs when the document opens or when the reader fills in a form. Many of the exploits against Adobe Reader in the late 2000s used that JavaScript to set up memory corruption in the viewer.

A document also does not have to execute anything to begin an attack. A PDF or Office file can contain a link or a QR code that leads to a phishing page or a download. A user who has already decided the document is legitimate may follow it with less suspicion than a link in an email. Mail filters that examine links in a message body may not examine links inside an attachment.

The security boundary belongs between untrusted document content and general system authority. A report that needs formatting or a spreadsheet that needs viewing should not automatically receive permission to launch a command interpreter. The application should enforce that distinction even when the file itself claims the action is necessary.

Drive-by Downloads and Zero-click Attacks

Some entry routes remove the explicit decision to run a newly received program, because a browser or messaging application already processes the attacker’s content as part of its normal operation.

A drive-by download delivers unwanted software through a web page the user visits, often by exploiting a browser or related component. In the exploit-based case, visiting the page provides the input needed to run attacker-controlled code. Downloading a file and executing it are separate events, so a page that merely offers a malicious installer still needs the user to run it.

The term is also used loosely to refer to any automatic downloads and to compromised pages that display further lures. The Lumma page relied on a visitor to run a command. Visiting the page started the chain, but the browser did not execute that command on its own.

A zero-click attack does not require any interaction between the target and the attack content. A parser in the messaging application may run when a message arrives or when the application generates a preview, so the user need not open the message or select an attachment.

In 2021, an exploit delivered Pegasus, spyware sold to governments by NSO Group, an Israeli company, through iMessage, the messaging app on iPhones. Google’s Project Zero, a vulnerability research team, analyzed the attack. The attachment was named as a GIF, but iMessage identified it by its contents and handed it to the PDF code, so the name gave no indication of which parser would run. That code reached the decoder for JBIG2, an image compression format used mostly in scanned PDFs. In that decoder, an integer overflow caused an undersized allocation and an out-of-bounds write. The exploit then used the resulting memory corruption to gain code execution.

The automatic processing was what made the attack zero-click. The integer overflow was the vulnerability. The crafted attachment was the exploit, carrying both the input that triggered the overflow and the code that ran afterward. Pegasus was the spyware delivered through the chain.

Zero-click describes only the user interaction an attack requires. It says nothing about the flaw itself. A zero-click attack can exploit an old, long-patched flaw on a device that was never updated.

Entry Through Trusted Channels

The routes we discussed involve a new file, a deceived user, or a flaw. Two others involve neither: the malicious code arrives through a channel the victim already trusts, either an approved update or a legitimate account.

In a supply chain compromise, the malicious code arrives through a channel the victim trusts, and nothing the victim can see distinguishes the compromised release from an authentic one. It takes two common forms:

  1. A compromised update delivers the code through an approved update procedure, as the M.E.Doc update did for NotPetya.

  2. A malicious dependency delivers it inside a library that a legitimate program loads. The XZ Utils backdoor described earlier reached the OpenSSH server this way.

Code signing identifies a signing authority and protects signed content from later changes. It cannot exclude a compromise that happened before the signature was applied: a compromised build or signing process can produce correctly signed malicious code.

A counterfeit utility downloaded from an attacker-controlled site is a different case. The cracked software and fake utilities that distribute Lumma arrive through a channel the attacker controls, not one the publisher does, so nothing in the publisher’s chain was compromised. The failed control was the user’s judgment of the source.

The same distinction applies to credentials. A stolen administrator account can install software through a legitimate remote-management service, and the service may operate exactly as designed. The authentication failure occurred when the attacker obtained or reused the account’s authority, not in the later installation mechanism.