Cyber Security Attack Types – Active and Passive Attacks

Published: March 6, 2021. Updated: August 2026. Reviewed by Encryption Consulting’s Cryptography advisory team.

Every cyber security attack falls into one of two categories based on what the attacker does to the data in transit: a passive attack observes or copies it without changing anything, and an active attack modifies, injects, replays, or blocks it. NIST’s Computer Security Resource Center defines an active attack as one where “the attacker transmits data” to alter system resources or affect their operation, and a passive attack as “an attack that does not alter systems or data.” That single distinction, whether the attacker touches the data path or only watches it, drives almost every decision about which control stops which attack.

What Are Active Attacks in Cyber Security?

An active attack is any exploit where the attacker injects, modifies, replays, or blocks traffic rather than simply observing it. Because active attacks change system state, resource availability, or message content, victims usually notice something is wrong, an outage, a corrupted transaction, an unexpected session, even if they cannot immediately identify the cause. Active attacks are also harder to execute than passive ones, and attackers frequently run a passive reconnaissance phase first to learn the network layout before launching the active phase.

The most common active attack categories are:

• Man-in-the-middle (MITM): the attacker positions itself between two communicating parties, intercepting, and often altering, traffic while both sides believe they are talking directly to each other. NIST’s glossary lists MITM alongside impersonation and session hijacking as active attacks on a secure communication protocol.
• Replay attack: the attacker captures a valid message, such as an authentication handshake or a financial transaction, and resends it later to impersonate the original sender or repeat the transaction. NIST SP 800-63 defines it as replaying “previously captured messages between a legitimate claimant and a verifier to masquerade as that claimant.”
• Session hijacking: a specialized, high-impact form of active attack where the attacker steals or predicts a valid session token (often a cookie) to take over an authenticated session in progress. Because this deserves its own depth of coverage, see Encryption Consulting’s dedicated guide, What Is Session Hijacking?, for detection and mitigation detail.
• Denial-of-service (DoS) and distributed denial-of-service (DDoS): the attacker floods a device, application, or network with traffic or malformed requests until it becomes unresponsive to legitimate users. NIST defines DoS as “the prevention of authorized access to resources or the delaying of time-critical operations.” Common mechanics include SYN floods (exhausting server connection tables with incomplete TCP handshakes), ICMP/ping floods, and buffer-overflow floods that exceed a service’s request-handling capacity.
• Message modification and injection: the attacker alters message content in transit, injects malicious payloads, or, in a cut-and-paste variant, splices fragments of different encrypted messages together to extract or manipulate data.

Older, still-relevant active-attack techniques worth naming explicitly include backdoor Trojans, malware that grants an unauthorized attacker ongoing access to a system once a user is tricked into installing it, and rootkits, which hide privileged access so the attacker can modify settings, read files, or monitor activity without detection. Flame, identified in 2012, is a documented example of rootkit-class malware that recorded audio, captured screenshots, and monitored network traffic on infected Windows systems.

What Are Passive Attacks in Cyber Security?

A passive attack monitors, collects, or copies data without altering the system or the data itself, which is exactly why it is so hard to catch. There is no crash, no corrupted record, and no failed login for a monitoring team to notice. The attacker’s goal is almost always reconnaissance: mapping open ports, identifying vulnerable services, or harvesting confidential content for later use.

• Eavesdropping (sniffing): the attacker inserts a packet sniffer into the network path between two endpoints to capture traffic as it passes. The more network hops and the longer the path, the easier it becomes for an attacker to plant a sniffer somewhere along it undetected.
• Traffic analysis: even when message content is encrypted, an attacker can still observe traffic volume, timing, and endpoints to infer who is communicating with whom and when, a limitation worth flagging even for otherwise well-encrypted channels (see Limitations below).
• Release of message contents: malware installed on a device (a virus or spyware) quietly monitors messages, emails, or transferred files containing personal or confidential information for the attacker to harvest later.

Passive reconnaissance increasingly extends to IoT and protocol-specific attack surfaces as well. In IoT-based smart-home systems, for example, RPL (Routing Protocol for Low-Power and Lossy Networks) is widely used because it fits resource-constrained devices that cannot run traditional routing protocols, and its lightweight design has been a documented target for traffic-analysis and topology-mapping research.

Why Does the Active vs. Passive Distinction Matter Operationally?

The distinction is not academic, it determines which control category to invest in first. Passive attacks threaten confidentiality and are frequently undetectable in real time, so the practical defense is preventive: encrypt the data so that intercepted traffic is worthless to the attacker. Active attacks threaten integrity and availability and are usually detectable after the fact, so the defense mix adds authentication, integrity checks, and redundancy on top of encryption. A mature security program treats these as complementary layers rather than substitutes for one another: encryption alone stops eavesdropping but does nothing to stop a replay attack, and authentication alone stops impersonation but does nothing to stop traffic analysis.

Which Defense Stops Each Attack Type?

Use this table as a starting checklist, not a complete architecture. Real deployments combine several rows at once.

Attack Type	Category	Primary Defense / Protocol	Key-Management Dependency
Eavesdropping / sniffing	Passive	TLS 1.2+/TLS 1.3 encryption in transit, IPsec VPN tunneling	Valid, non-expired TLS certificates; strong cipher suite configuration
Traffic analysis	Passive	Traffic padding, VPN/tunneling to obscure endpoints and timing	Consistent key rotation so long-lived sessions do not expose patterns
Man-in-the-middle (MITM)	Active	Mutual TLS (mTLS) with certificate-based authentication, certificate pinning	Both parties need a trusted, unexpired certificate issued by a governed CA; private key protection is essential
Replay attack	Active	Sequence numbers, timestamps, and cryptographic nonces bound to each message	Session and token secrets must be rotated and never reused across sessions
Session hijacking	Active	Short-lived, high-entropy session tokens; Secure/HttpOnly cookies; step-up mutual TLS (see the dedicated Session Hijacking guide)	Token-signing keys must be protected and rotated on a defined schedule
Message modification / injection	Active	Message authentication codes (HMAC), digital signatures	Signing keys must be generated, stored, and rotated under a governed key-management process
Denial-of-service / DDoS	Active	Rate limiting, network redundancy, DDoS scrubbing services, anomaly-based monitoring	Not primarily key-dependent, but availability of certificate infrastructure (OCSP/CRL responders) must itself be resilient to DoS

How Do You Build Layered Defenses Against Both Attack Categories?

No single protocol defeats every attack in the table above. Building resilience against both categories is a sequence, not a single purchase:

1. Model the threat first. Identify which assets and channels an attacker would eavesdrop on (passive) versus which they would try to alter, replay, or flood (active). The controls differ, so the assessment has to come before the architecture.
2. Encrypt everything in transit and at rest. TLS 1.2 or, preferably, TLS 1.3 for network traffic closes off the easiest eavesdropping and sniffing paths. This is the baseline passive-attack control.
3. Require mutual, certificate-based authentication. One-way TLS proves the server’s identity to the client; mutual TLS (mTLS) proves both directions, which is what actually closes the door on man-in-the-middle attacks. This step depends entirely on healthy key management: certificates must be issued from a governed CA, private keys must never leave protected storage, and expired or revoked certificates must be rejected automatically, not manually.
4. Add message-level integrity controls. Sequence numbers, timestamps, nonces, and message authentication codes stop replay and tampering attacks even if an attacker somehow gets a copy of the encrypted traffic.
5. Harden for availability. Rate limiting, connection-table protections against SYN floods, load balancing, and, where warranted, a dedicated DDoS-scrubbing provider address the active attacks that target uptime rather than confidentiality.
6. Monitor and log continuously. Active attacks are usually detectable if someone is watching; instrument authentication failures, unusual session behavior, and traffic spikes so the “usually detectable” property of active attacks actually translates into a fast response.
7. Govern the keys and certificates that make every prior step work. Encryption, mutual TLS, and message signing are only as strong as the key-management program behind them, rotation schedules, revocation processes, and secure storage (HSM-backed where possible) all need to be owned by a defined process, not left to ad hoc renewal.

Limitations

These controls reduce risk; they do not eliminate it, and each comes with a real trade-off worth planning for:

• Encryption stops an attacker from reading message content, but traffic analysis can still reveal who is communicating, how often, and roughly how much data is moving, even over a fully encrypted channel.
• Mutual TLS and certificate-based authentication only work as well as the certificate lifecycle behind them. An expired certificate, an unrevoked compromised key, or a private key stored insecurely undermines the entire control, regardless of protocol strength.
• Rate limiting and redundancy reduce the impact of smaller denial-of-service attempts, but a sufficiently large, distributed volumetric attack can still overwhelm on-premises capacity without a specialized scrubbing provider in front of it.
• Sequence numbers and nonces prevent replay within the systems that implement them correctly; legacy protocols and poorly configured APIs that skip this step remain exposed regardless of how strong the surrounding encryption is.
• Detection-based controls (anomaly monitoring, intrusion detection) help with active attacks but are inherently reactive; a well-executed passive attack may never generate an alert at all.

What Would Encryption Consulting Recommend?

Treat active and passive attack resistance as two halves of one program, not two separate projects. Start with encryption in transit as the non-negotiable baseline against passive attacks, then layer mutual, certificate-based authentication to close the man-in-the-middle gap that one-way TLS leaves open. Because nearly every control in this post, mTLS, message signing, session-token protection, ultimately depends on how well keys and certificates are generated, stored, and rotated, we typically recommend an encryption and PKI advisory engagement before adding more point solutions: fix the key-management foundation first, and the defenses layered on top of it hold up under real attack conditions rather than failing at renewal time. For organizations building out certificate-based mutual authentication specifically, our work on private PKI for Zero Trust networks covers the architecture in more depth, and where credential-based active attacks (not just network-level MITM) are the concern, pairing this with centralized multi-factor authentication closes the gap that a stolen or replayed password alone would otherwise leave open.

Conclusion

Cyber security attacks split into two operationally distinct categories: passive attacks that quietly observe or copy data, and active attacks that modify, replay, hijack, or disrupt it. Advanced Persistent Threats typically run a passive reconnaissance phase to map an organization’s infrastructure before launching a targeted active attack, which is why treating the two categories as connected stages of the same campaign, rather than unrelated risks, produces a stronger defense. Encrypting data in transit, requiring mutual certificate-based authentication, adding message-level integrity checks, and hardening for availability together close the gaps that any single control leaves open, provided the key management underneath all of it is actively governed rather than left to expire.

FAQ

What is the main difference between an active and a passive attack? A passive attack observes or copies data without altering the system, while an active attack modifies, injects, replays, or blocks it. NIST’s glossary defines a passive attack as one that “does not alter systems or data,” and an active attack as one where the attacker transmits data to affect system resources or operation.

Is a man-in-the-middle attack active or passive? Active. A MITM attacker inserts itself into the communication path and can intercept, alter, or inject traffic, which is why NIST classifies it alongside impersonation and session hijacking as an active attack on a secure communication protocol.

How does TLS protect against eavesdropping and MITM attacks? Standard (one-way) TLS encrypts data in transit, which defeats simple eavesdropping and sniffing. It only authenticates the server, however, so it does not by itself stop a MITM attacker who can present a fraudulent certificate to a poorly validating client. Mutual TLS, where both client and server present certificates, closes that remaining gap.

Can passive attacks be detected? Rarely in real time. Because a passive attack does not alter data or system behavior, there is typically no error, crash, or failed request for monitoring tools to flag. Detection usually happens only afterward, through evidence such as leaked data appearing elsewhere or through forensic analysis of network logs.

What is a replay attack and how is it prevented? A replay attack captures a previously valid message, such as a login handshake, and resends it later to impersonate the original sender. NIST SP 800-63 defines it as replaying “previously captured messages between a legitimate claimant and a verifier to masquerade as that claimant.” It is prevented with sequence numbers, timestamps, and single-use cryptographic nonces bound to each message so a captured message cannot be reused.

References

• NIST CSRC Glossary, “Active Attack”: https://csrc.nist.gov/glossary/term/active_attack
• NIST CSRC Glossary, “Passive Attack”: https://csrc.nist.gov/glossary/term/passive_attack
• NIST CSRC Glossary, “Man-in-the-Middle Attack (MitM)”: https://csrc.nist.gov/glossary/term/man_in_the_middle_attack
• NIST CSRC Glossary, “Replay Attack”: https://csrc.nist.gov/glossary/term/replay_attack
• NIST CSRC Glossary, “Denial of Service (DoS)”: https://csrc.nist.gov/glossary/term/denial_of_service
• NIST Special Publication 800-63B, Digital Identity Guidelines, Authentication and Lifecycle Management: https://pages.nist.gov/800-63-3/sp800-63b.html
• IETF RFC 4949, Internet Security Glossary, Version 2: https://www.rfc-editor.org/rfc/rfc4949