Common Attacks & the Cyber Kill Chain

Malware Taxonomy

Malware is a catch-all term, and using it precisely matters more than most people assume. Calling every malicious binary "a virus" is like calling every vehicle "a car." The distinctions describe different behaviors, different propagation methods, and different defensive priorities.

Getting the terminology right is often the fastest way to signal to a colleague or an interviewer that you actually understand how these things work, rather than just having memorized the word.

Self-Replicating: Virus vs Worm

A virus is malicious code that attaches itself to a legitimate file or program and requires that host to execute. It cannot run on its own, and it typically needs some form of user action, opening an infected document or running an infected executable, to activate. Once running, a virus replicates by inserting copies of itself into other files on the system.

A worm, by contrast, is self-replicating and self-propagating. It does not need a host file or user action to spread. It exploits a vulnerability or a network service to copy itself directly to other machines, which is why worms like WannaCry were able to spread across entire networks in minutes without anyone clicking anything.

Deception and Extortion: Trojan vs Ransomware

A trojan disguises itself as legitimate software to trick a user into installing it. The name comes from the wooden horse for a reason: the payload is hidden inside something that looks harmless or even desirable, a cracked software installer, a fake invoice attachment, a bogus system utility. Trojans do not self-replicate. Their defining trait is deception, not propagation.

Ransomware is malware that encrypts a victim's files, or in more advanced cases exfiltrates them first, and demands payment for the decryption key or for withholding the stolen data from public release. Modern ransomware operations are frequently double-extortion: encrypt and steal, then threaten both denial of access and public leak.

Post-Compromise Tools: RAT vs Rootkit

A Remote Access Trojan, or RAT, is a specific trojan subtype built to give an attacker persistent, interactive remote control over an infected machine: keystroke logging, screen capture, file transfer, webcam access, and arbitrary command execution. RATs are the workhorse of many post-compromise operations because they turn a single foothold into an ongoing presence.

A rootkit is different in kind rather than degree. It is designed to operate at a privileged level, often kernel mode, specifically to hide its own presence and the presence of other malicious activity from the operating system and from security tools. A rootkit does not necessarily do anything malicious on its own; its job is concealment, which is what makes it so dangerous when paired with something else.

Phishing and Social Engineering Tradecraft

Social engineering is the manipulation of people rather than systems, and it remains the single most common initial access vector across nearly every breach report published every year. It is almost always cheaper and more reliable to trick a human than to find and exploit a technical vulnerability.

Three Escalating Levels of Targeting

• Phishing. Mass-distributed fraudulent messages, usually email, designed to trick recipients into clicking a malicious link, opening a malicious attachment, or handing over credentials. Volume is the strategy: send enough messages and a percentage will land.
• Spear phishing. A message researched and tailored to a specific individual or small group, referencing their real job title, a real colleague's name, or a real ongoing project. The personalization dramatically increases the click-through rate because the message no longer trips the mental alarm bells that generic phishing does.
• Whaling. A further narrowing: spear phishing aimed specifically at executives or other high-value targets, where the payoff for a successful compromise, or a successful impersonation of that executive, is proportionally larger.

Business Email Compromise

Business Email Compromise, or BEC, is where social engineering stops being about malware delivery entirely and becomes pure fraud. An adversary compromises or spoofs an executive's or vendor's email account and uses that trusted position to instruct someone in finance to wire funds, change payroll banking details, or release sensitive data.

There is often no malicious link and no attachment at all, which is exactly why BEC is so hard for traditional email security controls to catch. It reads as a well-written email from what looks like a legitimate, trusted sender, asking for something that seems like a normal business request.

Pretexting and the Levers It Pulls

Pretexting is the broader technique underneath most of this: inventing a fabricated scenario, a pretext, to justify why the target should share information or take an action they otherwise would not. A caller claiming to be from IT support asking for a password reset confirmation is pretexting. So is an attacker posing as a new vendor requesting an update to banking details on file.

Social engineering works because it exploits three consistent human tendencies:

• Deference to authority. People comply faster with requests that appear to come from a boss or an official source.
• Manufactured urgency. A ticking clock short-circuits careful verification.
• Default trust. Most people extend good faith to messages that look like they come from a known and legitimate source.

Effective defenses target these three levers directly rather than trying to teach people to spot every possible technical tell.

Common Web and Network Attack Patterns

Beyond malware and social engineering, a handful of technical attack patterns show up constantly enough that every security practitioner needs at least a working understanding of the mechanism, even without going near exploit development.

SQL Injection

SQL injection is the oldest and still one of the most damaging. It happens when an application builds a database query by directly concatenating user-supplied input into the query string instead of treating that input as data.

If a login form takes a username and drops it straight into a SQL statement, an attacker can supply input that alters the structure of the query itself, for example closing out the intended string early and appending their own logic, tricking the database into returning data it should never have exposed or bypassing authentication entirely. The fundamental problem is a failure to separate code from data.

Cross-Site Scripting (XSS)

Cross-site scripting, or XSS, is the web equivalent of the same underlying idea applied to the browser instead of the database. It occurs when an application takes untrusted input and renders it back into a page without properly sanitizing or encoding it, allowing an attacker to inject their own script into that page.

When another user's browser loads the page, the attacker's script runs in the context of that user's session, which can mean stealing session cookies, redirecting the user, or performing actions on their behalf without their knowledge. Stored XSS persists the malicious script somewhere the application saves and later serves to other users, a comment field is the classic example. Reflected XSS instead relies on tricking a victim into clicking a crafted link where the malicious payload is part of the request itself and gets echoed straight back in the response.

Man-in-the-Middle

A man-in-the-middle attack works on an entirely different layer: instead of exploiting a flaw in application logic, the attacker positions themselves between two parties who believe they are communicating directly with each other, intercepting, and potentially altering, the traffic that passes between them.

This can happen on a compromised or spoofed Wi-Fi network, through ARP spoofing on a local network, or through a fraudulent certificate that lets an attacker decrypt traffic a victim believes is securely encrypted. The core mechanism is always the same: break the assumption of a direct, private channel between two endpoints, and everything that flows through that channel is now visible, and potentially modifiable, to a third party.

These three patterns are worth learning together because they illustrate three distinct trust failures that recur constantly in security work. Recognizing which trust boundary failed is often more useful for a working analyst than memorizing exploit syntax, because it tells you where the actual fix belongs.

The Cyber Kill Chain

In 2011, Lockheed Martin published the Cyber Kill Chain, a model borrowed from military targeting doctrine and adapted to describe the stages an adversary moves through to execute a successful intrusion.

Its core insight, and the reason it remains useful more than a decade later, is that defenders do not need to stop every stage. Breaking the chain at any single stage stops the entire attack. That reframes defense from an all-or-nothing problem into a layered one: even if reconnaissance and delivery both succeed, a detection at exploitation or command and control still wins.

1. Reconnaissance. The adversary researches the target before any contact is made: harvesting employee names and email addresses from LinkedIn, enumerating internet-facing infrastructure, or identifying which software versions a target organization runs.
2. Weaponization. The adversary couples a deliverable exploit with a payload, for example embedding a malicious macro inside a Word document crafted to look like a legitimate invoice.
3. Delivery. The weaponized payload is transmitted to the target, most commonly a phishing email attachment, but also a malicious USB drop or a compromised website waiting for a visitor.
4. Exploitation. The weaponized payload actually triggers: the user opens the document and enables macros, or a vulnerable service processes a malicious request and executes attacker code.
5. Installation. The adversary establishes persistence on the compromised system, often a backdoor or RAT configured to survive a reboot.
6. Command and Control (C2). The adversary establishes a communication channel back out to infrastructure they control, a beacon that checks in periodically for further instructions, which is what turns a single infected machine into something the attacker can actively operate.
7. Actions on Objectives. The point of the whole operation: the adversary exfiltrates sensitive data, deploys ransomware across the environment, or pivots to additional systems to expand their foothold.

Everything before the final stage was setup. Everything at that stage is the actual damage. This is also why detection earlier in the chain is worth so much more than detection here: catching an intrusion at delivery or exploitation costs an incident report, while catching it at actions on objectives costs a breach.

Quick reference for the same seven stages:

MITRE ATT&CK as the Modern Complement

MITRE ATT&CK is a globally maintained knowledge base of adversary tactics and techniques built from observed, real-world intrusions.

Tactics, Techniques, and IDs

Where the Kill Chain gives you seven broad, linear stages, ATT&CK gives you a matrix: tactics across the top, representing the adversary's goal at a given moment, such as Initial Access or Persistence, and dozens of specific techniques underneath each tactic describing exactly how that goal can be achieved. Each technique carries a unique identifier, T1566 for phishing, T1059 for command and scripting interpreter abuse, which gives analysts a precise, shared label instead of a prose description that varies from person to person.

Why ATT&CK Is Non-Linear

The key structural difference from the Kill Chain is that ATT&CK is not linear. A real intrusion does not march through tactics in a fixed order the way the Kill Chain's seven stages imply. An adversary might establish Persistence, then pivot back to Discovery, then attempt Privilege Escalation, then return to Persistence again with a second, more resilient backdoor.

ATT&CK's matrix structure reflects that reality: tactics can be revisited, skipped, or interleaved depending on what the adversary encounters in the environment. That flexibility is precisely why ATT&CK has become the preferred framework for detection engineering. A detection team does not build one rule for "the exploitation stage." They build a rule mapped to a specific technique, and they can track exactly which techniques they have coverage for and which they do not.

Three Tactics to Know

Three tactics are worth knowing as concrete anchors before the rest of this platform goes deeper into ATT&CK:

• Initial Access. The techniques an adversary uses to get an initial foothold in the environment: phishing, exploiting a public-facing application, or valid account abuse.
• Execution. The techniques used to run attacker-controlled code once inside: PowerShell abuse, scheduled task creation, or exploiting a scripting interpreter.
• Persistence. The techniques used to maintain that foothold across reboots and credential rotations: registry run keys, scheduled tasks configured to recur, or new account creation.

These three alone map cleanly onto the Kill Chain's Delivery-through-Installation stages, but with far more granularity about the actual mechanism used.

Kill Chain vs ATT&CK

The two frameworks are not competitors. Most mature SOCs use both: the Kill Chain to frame the narrative of what happened, ATT&CK to specify precisely how.

Why This Vocabulary Matters for Detection

None of this is trivia. A SOC analyst who can say "this alert represents Initial Access via T1566.001, spear phishing attachment, and the process tree afterward looks like Execution via T1059.001, PowerShell" has communicated, in one sentence, exactly what happened, exactly how far the adversary got, and exactly what the next likely stage is. Compare that to "someone opened a bad email and now there's weird PowerShell running," which conveys roughly the same facts but gives a colleague, a manager, or an automated system nothing precise to act on.

Precision as Communication

This shared vocabulary is what lets a SOC function as a team rather than a collection of individuals improvising their own descriptions. When an analyst hands off an incident at shift change, when a detection engineer writes a rule, when a threat hunter documents a hypothesis, when an incident responder writes the final report, all of them are describing the same underlying reality using the same named stages and the same technique IDs.

That precision is what turns "something bad happened" into "here is exactly what stage this intrusion reached, and here is exactly what stage we need to prevent it from reaching next time."

Precision as Prioritization

It also directly drives prioritization. Knowing that an alert sits at Command and Control rather than Reconnaissance tells you the urgency instantly: C2 means an adversary already has a live, interactive presence in the environment, while reconnaissance activity, though worth logging, does not yet mean anyone is inside. The kill chain stage or ATT&CK tactic an alert maps to is often the single fastest way to triage severity before a full investigation has even started.

This vocabulary is not specific to this chapter. Every other module on this platform, threat hunting, threat intelligence, cloud security, LOLBAS, assumes you already have this frame in your head. When a later chapter references "an actor at the Persistence stage" or cites a specific technique ID, it is building directly on what you learned here.

Getting comfortable with these terms now, to the point where you can use them correctly in a sentence without pausing to look them up, is one of the highest-leverage things you can do early in a security career.