Malware that has arrived, delivered its payload, and arranged to run again still has to decide when to act, and most of it has to reach its operator. A network connection lets the program retrieve instructions or transfer stolen data, and the operator needs that connection to survive the blocking of a server or a domain.

We finish the malware lifecycle with triggers, the conditions under which a payload activates; communication with an operator, including the ways malware hides its traffic and finds its controller again; the payloads themselves; and propagation. We end with detection, the defender’s view of every stage, and a conclusion that looks back over all four parts.

Triggers

A payload that acts at the wrong moment can expose the malware before it reaches its target, so many programs wait. A trigger is the condition under which the payload activates: a date, a count of executions, a user action, or the presence of a particular target.

A logic bomb is code that performs a destructive action when a specified condition occurs. It is usually planted by someone who already has access rather than delivered by an attack, and it may sit inside an otherwise legitimate program. On March 4, 2002, a logic bomb planted by a systems administrator who had resigned two weeks earlier from UBS PaineWebber, a brokerage, began deleting files on about 1,000 of the firm’s computers in branch offices across the country. Repairs cost more than $3 million, and he was sentenced to 97 months in prison in December 2006. Logic bomb is the narrower term: a trigger is any condition a payload waits for, and a logic bomb is a destructive payload together with its trigger.

Not every payload waits for a condition. A credential thief that runs immediately may not have any trigger beyond its own startup, and a worm’s replication can itself consume enough resources to create harm.

Code intended for a particular industrial controller may inspect the attached equipment before changing its behavior. Stuxnet, for example, activated its physical payload only when it found the specific controller configuration it targeted, so a machine could be infected without meeting the conditions that activated that payload.

Communicating with an Operator

Malware may need to retrieve instructions, download a later payload, or transfer stolen information. These activities can share a channel, but they need not use the same protocol or destination.

Command and control (C2, also written C&C) is the exchange through which an operator directs compromised systems and receives status or results. Exfiltration is the unauthorized transfer of collected information out of the environment. Hiding C2 traffic, downloads, and exfiltration can rely on ordinary encrypted connections, on infrastructure the network already permits, or on data embedded inside another protocol. When continued contact is necessary, the program also needs ways to find its operator again after a server or domain is blocked.

The clearest case is a botnet, a collection of compromised machines, called bots or zombies, that a single operator controls. Each bot checks in with a control server or with other bots, reports that it is alive, and waits for a command: send spam, flood a target with traffic, install another program, or collect and upload data. The operator addresses all of them at once, so one person can direct thousands or millions of machines, and the same botnet can be rented out for different jobs. The Emotet and QakBot botnets, whose takedowns we describe later in this section, were rented this way to deliver other groups’ malware to the machines they controlled.

Fully autonomous malware can operate without C2. A worm can replicate according to embedded instructions, and ransomware can encrypt with an embedded public key.

Concealing Traffic in Web and Cloud Services

An infected machine can initiate an outbound HTTPS connection and receive commands in the response. Blocking unsolicited inbound connections does not prevent this exchange if outbound web traffic remains permitted.

Transport Layer Security (TLS) encrypts the connection between the client and server. It thus protects an attacker’s requests and responses from an ordinary network observer just as it protects legitimate web traffic. Commands can be embedded in request bodies or responses, while stolen information can be sent as an ordinary-looking upload.

Cloud hosting and content delivery networks, the shared servers that host many sites’ content, provide destinations shared with legitimate services. Blocking an entire provider can interrupt unrelated business traffic, while permitting all of it can leave malicious accounts and domains reachable.

Tunneling Data through DNS

The Domain Name System (DNS) translates names such as www.rutgers.edu into addresses and retrieves other records associated with a name. Nearly every network permits it, since a machine that cannot look up names cannot do much else. A machine with no other route to the Internet can usually still send a query to its resolver, the DNS service that performs lookups for it, and receive a reply. A lookup can therefore transport attacker-selected information if the queried name contains that information and the attacker controls the responding domain.

DNS tunneling embeds commands or other data inside DNS queries and replies. A typical exchange has the following steps:

1. Malware encodes a request or a fragment of stolen data into a queried name, such as <encoded-data>.<message-id>.control.example.

2. The machine sends the query to its recursive resolver. If the answer is not cached, that resolver forwards the question to the authoritative server, the server responsible for that domain, which the attacker operates for control.example.

3. The server reads the information in the name and returns a response. A TXT record, a DNS record containing text strings, can contain an encoded command or reply.

4. Malware extracts the response data and interprets it according to its own protocol. Repeated exchanges can transfer a larger message in fragments.

For example, a toy protocol could use ready.17.control.example to announce that infected machine 17 is waiting for work, and a TXT reply containing wait=60 could instruct the malware to contact the server again after 60 seconds. The DNS software merely handles names and text records, while the malware interprets those strings as messages. A real protocol would disguise the domain names and TXT replies to avoid suspicion. In either case, the queried names move information outward and the reply records move information inward. The organization’s own resolver relays both through normal DNS processing.

Encoding makes the data fit DNS fields, but it does not provide confidentiality, so the attacker may encrypt the content before encoding it. DNS message sizes, caching, and the overhead of repeated lookups can limit throughput.

Finding Replacement Control Servers

A single embedded controller address stops working when it is blocked or seized. Malware can contain several addresses and attempt another if one fails, and later configuration updates can replace the list while a working contact remains.

A dead-drop resolver is a public page or account that publishes the current controller address. Malware reads the page and contacts the indicated server, so updating the page changes the destination without redistributing the installed program. A defender cannot block the platform, since employees use it for its intended purpose, so blocking the channel means finding the one account the malware reads.

A domain generation algorithm (DGA) lets malware and its operator generate a sequence of candidate domain names from shared inputs, such as a date. The operator registers some of those names and points them at control servers, and infected machines try the generated names until they reach a server. Researchers who recover the algorithm can also predict candidates and coordinate their registration or blocking.

Relaying Control through Peers

A central controller gives defenders a single target for disruption. Peer-to-peer control distributes communication among infected machines, which can relay instructions or help other infected machines find contacts. Removing one server may leave other paths operational, although finding peers, authenticating messages, and maintaining the network add complexity and observable traffic.

Detecting and Disrupting Hidden Traffic

Encryption hides the content of a connection but not its existence, so timing, volume, and destination remain visible. Resolver logs can expose queried names even when the final web exchange is encrypted, and monitoring on the endpoint, the user’s own machine, can identify which process initiated the traffic. A document editor that contacts a new destination immediately after opening a downloaded file provides more context than a report stating that it used HTTPS.

Beaconing is repeated communication that announces availability or requests work. Regular intervals can expose an automated check-in, although updates and monitoring tools also communicate periodically. Malware can vary the intervals or reduce their frequency, trading responsiveness for less obvious timing.

DNS tunnels can produce long encoded names, many unique subdomains, unusual TXT-query volume, or repeated queries with little cache reuse. Each also has legitimate causes, so defenders combine those observations with the queried domain, originating process, and surrounding activity. Requiring managed resolvers and recording their queries improves visibility into this route.

Investigators can seize servers, suspend discovery accounts, or redirect domains. Sinkholing redirects traffic intended for malicious infrastructure to a defender-controlled destination. It can interrupt communication and identify affected networks. But receiving a check-in does not remove the malware or invalidate stolen credentials, and malware that authenticates commands with cryptographic keys will reject instructions from the replacement server.

Payloads

A payload uses the available permissions to pursue the attacker’s objective. One program may combine theft, remote control, and encryption, or select different actions through configuration.

Stealing Credentials and Documents

An infostealer collects information that can be sold or used to access other systems, such as browser passwords, session tokens, cryptocurrency wallet secrets, and private documents.

A session token, usually stored by the browser as a cookie, lets a server recognize a previously authenticated session. Most session tokens are bearer tokens, which can be used by whoever possesses them, so copying a usable token can let an attacker reuse the session without repeating the password or second-factor challenge. The token must still be valid, and the server may impose additional restrictions, such as requiring evidence that the request came from the original device, but multifactor authentication at login does not automatically protect a token after login.

The browser itself has to read stored passwords and tokens to use them. Malware running with the same user’s permissions can therefore often call the same interfaces or read the data after the browser decrypts it, although operating system and browser protections can restrict access from other processes. Removing an infostealer does not invalidate secrets already copied elsewhere, so recovery includes revoking affected sessions and replacing exposed credentials.

Extorting Victims and Destroying Data

Ransomware creates a denial of access that the attacker claims to be able to reverse. A common design encrypts files with symmetric keys and protects those keys using an attacker-controlled public key, while the corresponding private key remains with the attacker, so the key needed to decrypt the files never exists on the victim’s machine. Encryption can proceed without a live connection to the operator when the necessary public key is already available.

An attacker can also copy documents before encryption and demand payment to avoid publication, a practice called double extortion. Restoring a backup repairs availability but does not recall the stolen copies.

A wiper can overwrite data, destroy metadata, or encrypt information while discarding what recovery would require. It does not have to preserve a usable decryption key, even if it displays a ransom demand.

Maintaining Remote Control

A backdoor lets an operator issue later instructions. A remote access trojan can provide file transfer, command execution, screen viewing, or additional software installation, and access can also be sold to another operator who chooses a later payload.

An authorized support tool can provide similar operations, so investigators need to verify who installed it, which account controls it, and whether its use was approved.

Consuming Processor and Network Resources

Cryptocurrency mining consumes computation and electricity. Spam distribution uses a machine’s outgoing mail capacity and can exploit its history as a legitimate sender. A botnet can direct many devices to flood a target in a distributed denial-of-service (DDoS) attack.

Sabotaging Software and Physical Equipment

A payload can alter files, application state, or industrial control software. A controller’s legitimate operations include changing motor speeds, opening valves, and adjusting temperatures, and malicious code can misuse those operations while presenting misleading readings to the people running the equipment.

Propagation

A worm searches for reachable systems and attempts to make them execute a copy of itself. Replication can support a later payload or consume enough resources to disrupt service on its own: SQL Slammer produced widespread network congestion through rapid scanning without a separate payload to destroy files or disable a service.

Propagation is the stage that most often breaks the sequence. Code Red and SQL Slammer spread before doing anything else, and their scanning was itself the damage. A worm also carries the earlier stages with it, since each copy performs its own infection and delivery on the next machine. Blocking propagation, therefore, protects machines that are not yet infected while leaving the payload active on those that are, as WannaCry showed.

Defending Systems through Malware Detection

A scanner may recognize a known malicious executable before it runs. A script that uses a signed interpreter to steal browser data requires different evidence, because the interpreter’s file is genuine even though the script’s actions are unauthorized. Practical security products combine inspection before execution with monitoring during execution.

Detecting Known Code and Suspicious Structure

Known malicious programs often contain recognizable structures or instruction sequences, and matching those structures can provide a quick decision before the program runs.

A malware signature is a pattern used to recognize malicious content or a known class of malware. It can be a file hash, a byte sequence, or a more flexible rule: a cryptographic hash identifies one exact file, while a structural rule may recognize several related variants. This use of “signature” differs from a digital signature that authenticates a publisher.

Signature matching is fast and useful against known samples and recognizable relatives, but it depends on the content being available and the signature accurately describing it. Changing one byte can defeat an exact file-hash match but may leave a larger structural match intact.

Static analysis examines a program without executing it, using information such as strings, imported functions, file structure, and instructions. A static heuristic uses features that suggest suspicious construction or capability instead of requiring one exact known signature, allowing a detector to identify unfamiliar malware that resembles known malicious code.

Evading Static Detection with Packing and Mutation

Packing, which Part 3 described as a delivery technique, compresses or encrypts an executable and attaches a small program that restores the original when the file runs. A packed file on disk holds only the unpacking code and the transformed data, so a scanner looking for the payload’s instructions does not find them until the program runs. A detector can still recognize a known packer, inspect memory after the program has unpacked itself, or observe the resulting behavior.

Polymorphic and metamorphic malware go beyond packing by making every copy of the malware different. They differ in what remains the same.

Polymorphic malware keeps a single body of code and encrypts it with a different key in each copy, varying the small decryption routine as well, so no two copies share a recognizable byte sequence. The mechanism is the same as an encrypting packer. The difference is that a packer is applied once and every copy is identical, while polymorphic code re-encrypts itself with a new key and a new decryption routine each time it replicates. Once a copy runs and decrypts itself, however, the body in memory is identical every time, and a memory scanner can match it.

Metamorphic malware rewrites the code itself for each copy. It substitutes equivalent instructions, reorders independent instructions, and inserts instructions that do nothing, so even the running program has no fixed body to match. Detection then has to rely on what the code does. Vendor usage of the two terms varies.

Detecting Malicious Behavior

A program can disguise what it is, but not what it does. Once it runs, the files it reads, the processes it starts, and the connections it opens are all visible, as are how those actions relate to where the program came from and what started it.

Behavioral detection evaluates actions performed during execution. A security product can observe file access, process creation, memory changes, configuration modifications, and network communication. Dynamic analysis examines a running program, often in a controlled environment, while live-system monitoring observes activity during ordinary use.

A dynamic heuristic evaluates combinations or sequences of runtime events. A document application that starts an unusual interpreter, followed by browser data access and an external upload, provides more context than any event alone. A backup program may also read many files, but its source, expected schedule, destination, and resource access differ.

An endpoint detection and response (EDR) system records and correlates events on computers so defenders can investigate and respond to suspected compromise. The records preserve the relationship between an initial process and later activity even after the original process exits. Investigators can then trace a script’s download, the process that ran it, and a later network connection. Missing events, deleted records, or a compromised monitoring component can leave that reconstruction incomplete.

Behavioral rules also make mistakes. A false positive identifies legitimate activity as malicious, and a false negative misses malicious activity. Strict rules can impede legitimate administration, while permissive rules can enable unauthorized use of the same tools, so the detector’s policy needs context on which actions are expected and authorized.

Defending with Analysis Sandboxes

A defender can run a suspicious program in an isolated environment and observe its behavior. Containment limits the consequences while monitoring records the program’s actions.

An analysis sandbox combines a controlled execution environment with observation, using a virtual machine, operating system isolation, or another arrangement. Isolation alone does not classify malware: a well-contained program can still be malicious, and a clean observation may only show that the program did not do anything malicious during that run.

Analysis sandboxes are tools for security vendors and an organization’s security team, rather than for ordinary users. A vendor runs newly seen samples to produce detection rules, and an organization’s mail gateway or endpoint product can send a suspicious attachment to a sandbox, often in the vendor’s cloud, before the user opens it.

Evading Sandbox Analysis

Malware can look for evidence that it is being analyzed and withhold its payload. It may inspect the environment, check for user activity, or delay execution beyond the observation period, so a program that waits for mouse activity or a particular target configuration may remain inactive in a sandbox that does not reproduce those conditions.

A run can also show nothing for reasons unrelated to evasion: a payload server may be offline, the required document or target configuration may be missing, or the program may be waiting for a later command. Extending observation and reproducing realistic conditions can expose more behavior, but a short run cannot show everything the program might do later.

Detecting Memory-resident Malware and Rootkits

Code that executes only in memory does not leave a conventional payload file for a scanner to inspect. A detector can still examine the script supplied to an interpreter, instructions in executable memory, the process that started the code, or its network activity.

The Antimalware Scan Interface (AMSI) lets supported Windows applications submit content to security software for scanning. PowerShell, for example, submits each script block after decoding it, so the scanner inspects the instructions that will actually execute even when the downloaded text was encoded.

A kernel rootkit can alter the kernel’s reports or disable the monitoring component, making local detection incomplete or misleading. An independent network record can show that a connection occurred even if the local process list conceals its source, but it cannot necessarily identify the encrypted content or prove which local code sent it.

Detecting Malware with Reputation and Telemetry

A newly seen executable contacting infrastructure associated with known theft can warrant inspection even without an exact signature match.

Reputation-based detection uses evidence about a file, publisher, address, or domain from prior observations. Telemetry is recorded operational data used for analysis, and combining telemetry from many machines can expose rare process relationships or coordinated infrastructure that are difficult to recognize from a single machine.

A newly released legitimate program may have few prior observations, while malicious activity can use a common signed tool. A rare file needs investigation rather than automatic classification as malware, and a familiar publisher does not authorize every use of its programs.

Protecting the Detector

Security software often has broad privileges to inspect processes and files, and its parsers consume deliberately hostile input.

The detector belongs to the trusted computing base, the components whose correct operation is needed to enforce security. A parser vulnerability or compromised monitoring driver can expose the machine and corrupt the evidence supplied to administrators.

Conclusion

Each defense described in these four parts changed the attacker’s route rather than ending the attacks. Removing AutoRun left parser flaws and drop attacks. Blocking macros from the Internet in 2022 sent the same lures into other file types and onto fake verification pages. Signatures led to packers and polymorphic code, which led to behavioral detection, which led to sandbox evasion. Secure Boot led to attacks with signed boot loaders that were merely old, which led to revocation. Each defense closed a route that took the attacker little effort and forced a move to one that took more, was easier to observe, or depended on a user’s decision.

What did not change was how malware is defined, where the last control has to sit, and where detection has to look:

1. Malware was defined throughout by what the people responsible for the system had authorized, never by the operations a program performed.

2. The controls that held were the ones that applied after a user’s decision to run something: application control, the Principle of Least Privilege, sandboxes, and a firmware policy that does not consult the user at all.

3. Every reliable detection came from a vantage point the attacker had not changed: trusted recovery media, a hardware record of the boot, a network log, or a comparison between two views of the same system.

Attackers increasingly use programs that are already installed and signed, arrive through channels the victim trusts, and buy access and tools from one another rather than building everything themselves. Large language models have made targeted social engineering cheap. Defenders record more, with endpoint detection and attestation. They deny by default, with application control and blocked macros. And they move analysis off the endpoint into vendor clouds. A new technique can be examined with the same questions we asked at each stage here: how it gets execution, how it survives, how it finds its operator, and from which vantage point it can still be seen.