# CyberGlossary
> Source: https://www.cyberglossary.org
---
# PE Executable Format
Source: https://www.cyberglossary.org/en/term/pe-executable-format
Published: 2026-10-06
PE is the binary format Windows uses for executables (.exe), libraries (.dll), drivers (.sys), and ActiveX (.ocx). Every file opens with the legacy MS-DOS stub — magic bytes `MZ` (0x5A4D) and the "This program cannot be run in DOS mode" message — whose `e_lfanew` field points to the real PE header: the signature `PE\0\0` (0x00004550), the COFF file header, and an optional header whose magic distinguishes PE32 (0x10B) from PE32+/64-bit (0x20B). The optional header carries `AddressOfEntryPoint`, `ImageBase`, and the data directories, followed by a section table mapping `.text`, `.rdata`, `.data`, `.rsrc`, and `.reloc`.
Loaders resolve the Import Address Table at load time and verify Authenticode signatures. Analysts weaponise the same structures defensively: Mandiant's **imphash** fingerprints a sample by its ordered import names to cluster related malware; abnormally high section entropy betrays UPX or custom packers; and the undocumented Rich header can tie a binary to a specific compiler toolchain. Attackers abuse PE features for DLL sideloading, process hollowing, and reflective loading. Microsoft publishes the authoritative PE/COFF specification; tools like pefile, PE-bear, and CFF Explorer parse these fields for triage.
```mermaid
flowchart TD
A["MS-DOS stub (MZ)"] --> B["e_lfanew offset"]
B --> C["PE signature (PE\0\0)"]
C --> D[COFF file header]
D --> E["Optional header (PE32 / PE32+)"]
E --> F[Data directories: imports, exports, reloc, security]
F --> G["Section table: .text .rdata .data .rsrc .reloc"]
G --> H[Loader maps sections + resolves IAT + checks Authenticode]
```
---
# Pharming
Source: https://www.cyberglossary.org/en/term/pharming
Published: 2026-10-06
Pharming subverts name resolution or routing so that users who correctly type a domain still land on an attacker-controlled clone. Unlike phishing it needs no lure click: techniques include poisoning DNS caches, compromising recursive resolvers, editing the local hosts file via malware, or changing a router's DNS settings. On the fraudulent site, credentials, payment data, and even MFA codes are harvested as if entered on the real one.
The best-documented case is the **DNSChanger** trojan run by Estonia's Rove Digital. Spread as a fake video codec, it rewrote victims' DNS to rogue servers and, at its peak, infected over four million machines across 100+ countries. The FBI's **Operation Ghost Click** (November 2011) seized the ~100-server infrastructure and charged seven suspects; court-ordered replacement resolvers kept victims online until July 2012. In 2018 Netlab 360 exposed **GhostDNS**, which brute-forced DNS on 100,000+ routers — about 87% in Brazil — to phish customers of Banco do Brasil and others. Symantec researchers earlier demonstrated "drive-by pharming," using CSRF against a router's default password to flip its DNS from a web page. Defences include DNSSEC, encrypted DNS (DoH/DoT), endpoint protection against hosts-file tampering, hardened router credentials, and strict TLS certificate checking.
```mermaid
flowchart LR
U[User types bank.example.com] --> R{Resolution path tampered?}
R -->|hosts file edited| M[Malware on endpoint]
R -->|router DNS changed| G[Rogue resolver e.g. GhostDNS]
R -->|cache poisoned| C[Compromised DNS cache]
M --> X[Attacker IP returned]
G --> X
C --> X
X --> P[Look-alike phishing site]
P --> H[Credentials / payment / MFA harvested]
```
---
# Scareware
Source: https://www.cyberglossary.org/en/term/scareware
Published: 2026-10-06
Scareware relies on social engineering rather than exploits: pop-ups, full-screen warnings, or fake "scans" claim the device is riddled with threats and pressure the user to act now. Clicking through installs rogue security software, buys a worthless "licence," or routes the victim to a tech-support call centre that then takes remote control. Some variants also drop real malware.
The archetypal operation was **WinFixer / WinAntivirus**, sold from roughly 2004 by Innovative Marketing and its payment arm ByteHosting. Fake online ads displayed a bogus system scan, then charged $40–60 to "fix" the invented infections, netting an estimated $60M+ from over a million victims. The FTC sued in 2008; in 2012 a federal court in Maryland entered a **$163 million** judgment against ringleader Kristy Ross, while co-founders Sam Jain and Daniel Sundin remained fugitives. Lock-screen variants later blurred into ransomware — the 2012 **Reveton** "police trojan" impersonated the FBI and demanded a MoneyPak "fine." Defences include ad and pop-up blockers, browser and SmartScreen warnings, application allow-listing, security-awareness training, and removing local administrator rights so users cannot silently install rogue payloads.
```mermaid
flowchart TD
A[Malvertising / pop-up / fake scan] --> B["Alarming claim: Your PC is infected!"]
B --> C{Victim reaction}
C -->|Downloads fix| D[Rogue AV / junk software installed]
C -->|Pays licence| E[Money to fraudster, no real protection]
C -->|Calls number| F[Tech-support scam, remote takeover]
D --> G[Possible real malware dropped]
E --> G
F --> G
```
---
# YARA Rule
Source: https://www.cyberglossary.org/en/term/yara-rule
Published: 2026-10-06
YARA is a pattern-matching language and tool created by Victor Manuel Alvarez at VirusTotal (now Google) to help researchers describe families of malware. A rule has three parts: a `meta` section (author, references, hashes), one or more `strings` definitions (plain text, hex with wildcards and jumps, or PCRE-style regex), and a boolean `condition` that combines those strings with counts, offsets, file size, and modules such as `pe`, `elf`, `math` (entropy), and `hash`. Conditions like `pe.imphash()` or `for any i in (0..#a): ($a[i] < 1024)` let a single rule express structural logic, not just string presence.
Analysts run YARA against disk, memory dumps, mail attachments, and sandboxes, and at scale through VirusTotal Livehunt/Retrohunt and EDR retro-hunt. Vendors ship rules with advisories: after the 2020 SolarWinds SUNBURST compromise, FireEye publicly released YARA (and Snort) detections on GitHub, and open rule sets like Florian Roth's `signature-base` are widely reused. In 2024 Alvarez announced **YARA-X**, a Rust rewrite whose 1.0.0 stable landed in 2025 and now powers VirusTotal in production; it removes the memory-safety bugs of the C engine and improves diagnostics. Because broad strings cause false positives, authors tune rules against known-good baselines.
```mermaid
flowchart LR
A[Sample / memory / file] --> B[YARA / YARA-X engine]
R[YARA rule:
meta + strings + condition] --> B
B --> C{Condition
satisfied?}
C -->|Yes| D[Match: family label + tags]
C -->|No| E[No detection]
D --> F[Triage, hunt, pivot on campaign]
```
---
# Credential Stealer
Source: https://www.cyberglossary.org/en/term/credential-stealer
Published: 2026-10-05
A credential stealer targets stored or in-memory secrets: Windows LSASS process credentials, browser password and cookie stores, DPAPI-protected blobs, SSH keys, Wi-Fi passwords, and cached domain credentials. Once extracted, those secrets fuel lateral movement, persistence, business email compromise, and credential-stuffing campaigns. Increasingly, stealers prize **session cookies and OAuth tokens**, because replaying a live session bypasses passwords and most MFA entirely.
```mermaid
flowchart LR
I[Infected host] --> L[Read LSASS memory
+ browser / DPAPI stores]
L --> E[Extract passwords,
hashes, cookies, tokens]
E --> X{{Exfiltrate to C2}}
X --> U[Lateral movement /
sold on stealer markets]
```
Mimikatz is the archetypal in-memory tool, reading credentials straight from LSASS — the technique catalogued as MITRE ATT&CK **T1003.001 (LSASS Memory)**. Commodity info-stealers such as RedLine (2020), META (2022), Raccoon, Vidar, and Lumma are sold as malware-as-a-service and have fed billions of stolen logins into underground markets. On 28 October 2024, Dutch police and the FBI ran **Operation Magnus**, seizing RedLine and META infrastructure and charging developer Maxim Rudometov. Defences include Windows Credential Guard, which virtualizes LSASS secrets inside a VBS trustlet, LSA protection (RunAsPPL), removing local-admin rights, FIDO2 passkeys instead of passwords, token-binding, and EDR detections for memory scraping and suspicious access to credential stores.
---
# Downloader
Source: https://www.cyberglossary.org/en/term/downloader-malware
Published: 2026-10-05
A downloader is a small first-stage program whose job is to fetch additional malware from attacker infrastructure once it runs. Unlike droppers, downloaders carry little or no embedded payload; they rely on outbound HTTP(S), DNS, or messaging-app channels to reach command-and-control and pull later stages. This separation keeps the initial file small and innocuous, lets operators swap payloads on demand, and frustrates static signatures because the dangerous code never ships in the lure.
```mermaid
flowchart LR
E[Phishing lure
LNK / ISO / macro] --> X[Downloader
executes]
X --> C2{{Contact C2
HTTPS / DNS}}
C2 --> F[Fetch next stage]
F --> R[Run payload:
ransomware / stealer / Cobalt Strike]
```
GuLoader, active since 2019, abuses NSIS installers and encrypted shellcode with heavy anti-analysis and often retrieves its payload from Google Drive or OneDrive. Bumblebee, first seen in March 2022, acts as an initial-access broker that delivers Cobalt Strike and ransomware; in May 2024 Europol's **Operation Endgame** disrupted it alongside IcedID, Pikabot, SmokeLoader, SystemBC, and TrickBot, though several resurfaced within months. Delivery typically uses phishing with LNK shortcuts, ISO/IMG containers, OneNote files, or VBA-macro documents chaining to PowerShell. Defences include outbound network and DNS filtering, sinkholing known C2, EDR rules for download-and-execute behaviour, mail and web isolation, Microsoft ASR rules, and disabling unused scripting hosts (WSH, macros, mshta).
---
# SHA-256
Source: https://www.cyberglossary.org/en/term/sha-256
Published: 2026-10-05
SHA-256 is a member of the SHA-2 family standardized by NIST in FIPS 180-4, producing a 256-bit (32-byte) digest from inputs of up to 2^64 bits. It operates on 32-bit words through a Merkle–Damgård construction: the message is padded, split into 512-bit blocks, and fed through a Davies–Meyer compression function of 64 rounds. The eight initial state words and 64 round constants are derived from the fractional parts of the square and cube roots of the first primes, a "nothing-up-my-sleeve" choice that rules out hidden backdoors.
```mermaid
flowchart LR
M[Message] --> P[Pad to multiple
of 512 bits]
P --> B[Split into
512-bit blocks]
B --> C[Compression
64 rounds]
IV[8 init words] --> C
C -->|chaining| C
C --> D[(256-bit digest)]
```
Unlike SHA-1 — broken by Google's 2017 *SHAttered* collision — SHA-256 has no practical collision or preimage attack beyond the generic 2^128 / 2^256 bounds. Its one structural caveat is length-extension: because the final state *is* the output, HMAC-SHA-256 or the truncated SHA-512/256 should be used where a keyed MAC is needed, and Bitcoin applies SHA-256 twice (SHA-256d) partly for this reason. Hardware acceleration via Intel SHA-NI and the ARMv8 cryptography extensions makes it extremely fast. Git is migrating its object model from SHA-1 to SHA-256. For password storage SHA-256 must still be wrapped in a slow KDF such as Argon2, scrypt, or PBKDF2.
---
# SSPM (SaaS Security Posture Management)
Source: https://www.cyberglossary.org/en/term/sspm
Published: 2026-10-05
SSPM platforms connect through APIs to SaaS apps such as Microsoft 365, Google Workspace, Salesforce, GitHub, Slack, Workday, ServiceNow, and Snowflake. They check tenant settings against best-practice baselines (admin MFA, external sharing, legacy authentication, data residency), inventory OAuth grants and third-party app integrations, and flag unusual administrative actions or privilege creep. Unlike CASB, which inspects user traffic in line, SSPM operates on the SaaS **control plane** itself via native APIs.
```mermaid
flowchart LR
S[SSPM] -->|API| A[SaaS tenants
M365 / Workspace / Salesforce]
A --> I[Inventory config,
identities, OAuth apps]
I --> B{Compare to
baseline}
B -->|drift / risky grant| AL[Alert & remediate]
B -->|compliant| OK[Record posture]
```
The category's relevance was underscored by the **Midnight Blizzard** (APT29) intrusion at Microsoft disclosed on 19 January 2024. The Russian state actor used a password-spray against a legacy, non-production test tenant with no MFA (from late November 2023), then abused a legacy test **OAuth application** that held elevated access to the corporate environment, created its own malicious OAuth apps, and granted itself the Exchange Online `full_access_as_app` role to read the mailboxes of senior leaders and security staff. Precisely the dormant test accounts, over-privileged OAuth grants, and missing admin MFA that SSPM is built to surface. As organizations run dozens to hundreds of SaaS apps, each with its own permission model and shadow-admin risk, SSPM provides continuous, app-aware posture visibility that generic CSPM and CASB tools miss.
---
# Coverage-Guided Fuzzing
Source: https://www.cyberglossary.org/en/term/coverage-guided-fuzzing
Published: 2026-10-04
Coverage-guided fuzzers instrument the target at compile time (AFL's `afl-cc`, LLVM's SanitizerCoverage) or via dynamic binary translation (QEMU mode), then run candidate inputs while recording which edges or basic blocks execute. Any input that reaches new coverage is added to an evolving corpus and further mutated, so over millions of executions the corpus drifts toward hard-to-reach code — the key insight that separates greybox fuzzing from blind random testing.
The approach was popularised by AFL (Michał Zalewski, 2013) and advanced by its community fork AFL++, by LLVM's in-process libFuzzer, and by Honggfuzz. Speed comes from fork servers and persistent mode (thousands of iterations per second), while **sanitizers act as oracles**: AddressSanitizer, UBSan and MemorySanitizer turn silent memory corruption into immediate, triageable crashes. Dictionaries and structure-aware mutators (libFuzzer with libprotobuf-mutator) help fuzzers past magic-byte and format checks.
Google's **OSS-Fuzz**, which runs these engines continuously against open-source code, has helped find over 13,000 vulnerabilities and more than 50,000 bugs across 1,000-plus projects. Defensive practice is to wire fuzzing into CI with a persistent seed corpus and regression tests, so every fix adds a crashing input that must never reappear.
```mermaid
flowchart LR
S[Seed corpus] --> M[Mutate input]
M --> R[Run instrumented target]
R --> C{New coverage?}
C -- Yes --> A[Add to corpus] --> M
C -- No --> D{Crash / sanitizer?}
D -- Yes --> T[Save and triage crash]
D -- No --> M
```
---
# Mean Time to Detect (MTTD)
Source: https://www.cyberglossary.org/en/term/mean-time-to-detect
Published: 2026-10-04
MTTD measures how quickly a security team becomes aware of malicious activity, typically from initial compromise to the first validated alert in the SIEM, SOAR or ticketing system. It is calculated as the sum of detection intervals across incidents divided by the number of incidents, and it is one of the core KPIs for SOC effectiveness — closely tied to telemetry coverage, detection engineering and analyst triage workflows.
MTTD is the defender-side mirror of **dwell time**, the attacker's window before discovery. Mandiant's *M-Trends 2024* reported a global median dwell time of 10 days for 2023 (down from 16 the prior year and from hundreds of days a decade earlier), driven largely by EDR telemetry and ransomware's self-announcing nature. Lower MTTD limits dwell time, shrinks blast radius and improves the odds of clean containment before encryption or exfiltration.
A single global number can mislead, so mature teams track MTTD per attack technique mapped to **MITRE ATT&CK**, exposing blind spots (for example, slow detection of credential dumping) that an aggregate figure hides. Beware perverse incentives: narrowing alert scope lowers MTTD on paper while leaving real intrusions undetected.
```mermaid
flowchart LR
A[Initial compromise] -->|dwell time| B[First validated alert]
B --> C[Response begins]
C --> D[Threat contained]
D --> E[Recovery]
A -. MTTD .-> B
B -. MTTR .-> C
```
---
# Windows Registry Analysis
Source: https://www.cyberglossary.org/en/term/registry-analysis
Published: 2026-10-04
The Windows Registry is a hierarchical database storing configuration for the OS, applications and user profiles. System hives (SYSTEM, SOFTWARE, SECURITY, SAM) live in `%SystemRoot%\System32\config`, while per-user hives are `NTUSER.DAT` and `UsrClass.dat` in each profile. Crucially, recent writes may sit only in the transaction logs (`.LOG1`/`.LOG2`); tools that replay these logs recover keys a naïve parser would miss.
Registry analysis extracts high-value evidence that often has no equivalent elsewhere on disk. Execution artifacts include **AppCompatCache (ShimCache)** and **Amcache.hve**, UserAssist (ROT13-encoded GUI launch counts), and BAM/DAM entries. Persistence shows up in Run/RunOnce keys, Services and Winlogon (MITRE ATT&CK **T1547.001**, with registry tampering covered by **T1112**). ShellBags reveal folder browsing, USBSTOR plus MountedDevices track removable media, and the SAM hive holds local password hashes.
Analysts parse live or imaged hives with Eric Zimmerman's Registry Explorer and RECmd, RegRipper, YARP or Autopsy, then fold the results into a super-timeline (e.g. Plaso) so registry keys are correlated with event logs and filesystem metadata. Because timestamps can be forged or keys wiped as anti-forensics, findings are cross-checked against independent sources.
```mermaid
flowchart TD
I[Disk image or live system] --> H[Acquire hives + .LOG transaction logs]
H --> P[Parse: Registry Explorer / RegRipper / RECmd]
P --> E[Extract artifacts]
E --> EX[Execution: ShimCache · Amcache · UserAssist]
E --> PE[Persistence: Run keys · Services]
E --> US[User activity: ShellBags · USBSTOR · RecentDocs]
EX --> T[Correlate in super-timeline]
PE --> T
US --> T
```
---
# Strategic Threat Intelligence
Source: https://www.cyberglossary.org/en/term/strategic-threat-intelligence
Published: 2026-10-04
Strategic threat intelligence sits at the top of the classic three-tier model — **strategic, operational and tactical** — translating complex threat dynamics into business-relevant insight for non-technical leadership. It covers adversary motives, geopolitics, sector-specific risk trends, regulatory shifts and the likely future evolution of threats, rather than the IOCs and TTPs that drive day-to-day detection.
It is produced through the **intelligence cycle** — direction, collection, processing, analysis, dissemination and feedback — fusing all-source material: OSINT, finished reporting from vendors and ISACs, government advisories (CISA, the UK NCSC, ENISA) and open geopolitical analysis. Outputs are narrative reports, dashboards and board briefings used to set security strategy, justify budget, define risk appetite and shape M&A or supply-chain decisions. A sanctions package or a new conflict, for instance, reliably reshapes the activity of state-aligned actors, and strategic CTI makes that link explicit *before* it reaches the SOC.
Unlike tactical feeds refreshed by the minute, strategic intelligence runs on weekly-to-quarterly cadences. It demands analysts who blend cybersecurity depth with structured analytic tradecraft, business fluency and geopolitical context — closer to an intelligence analyst than a SOC engineer.
```mermaid
flowchart TD
G[Geopolitics, OSINT, gov advisories] --> IC[Intelligence cycle]
TAC[Tactical: IOCs] --> IC
OPS[Operational: campaigns and TTPs] --> IC
IC --> STR[Strategic analysis]
STR --> BRF[Board briefings and reports]
BRF --> DEC[Strategy, budget, risk appetite]
```
---
# CAPEC
Source: https://www.cyberglossary.org/en/term/capec-attack-pattern-enumeration
Published: 2026-10-03
CAPEC (Common Attack Pattern Enumeration and Classification) is a MITRE-stewarded community resource, sponsored by CISA, that describes common patterns adversaries use to exploit software, hardware, and operational weaknesses. Each entry has a unique CAPEC-ID, a description, prerequisites, attack steps, severity/likelihood, related weaknesses (CWE), and mitigations. As of version 3.9 (released January 2023) the catalogue holds 559 attack patterns.
Patterns are organised by **Mechanisms of Attack** (e.g. Engage in Deceptive Interactions, Inject Unexpected Items, Manipulate Data Structures) and by **Domains of Attack** (Software, Hardware, Communications, Supply Chain, Social Engineering, Physical Security). Entries sit at an *abstraction* level — Meta, Standard, or Detailed — so CAPEC-66 (SQL Injection) refines the broader CAPEC-152 (Inject Unexpected Items).
```mermaid
flowchart TD
CAT[CAPEC catalogue] --> MECH[Mechanisms of Attack]
CAT --> DOM[Domains of Attack]
MECH --> META["Meta pattern
(abstract)"]
META --> STD["Standard pattern"]
STD --> DET["Detailed pattern
e.g. CAPEC-66 SQLi"]
DET -->|exploits| CWE[Related CWE weakness]
DET -->|realised by| ATTACK[ATT&CK technique]
```
CAPEC complements CWE (weaknesses), CVE (specific vulnerabilities), and ATT&CK (observed adversary techniques), which cross-reference each other. Threat modelers, secure-design reviewers, red teams, and pentest scopers use it to enumerate concrete attack scenarios and to justify the controls that counter each one.
---
# Honeytoken
Source: https://www.cyberglossary.org/en/term/honeytoken
Published: 2026-10-03
A honeytoken is a deception artifact embedded inside real systems so that any use of it is, by design, malicious or anomalous. The term was coined by Augusto Paes de Barros in a February 2003 mailing-list exchange with Lance Spitzner of the Honeynet Project, extending honeypot thinking from whole systems down to individual data items. Examples include planted user accounts, fake database rows, decoy cloud access keys, watermarked documents, and DNS records that beacon when resolved.
```mermaid
flowchart LR
P[Plant honeytoken
in repo / share / DB] --> W[Wait: no legit use]
W --> X((Attacker finds
& uses it))
X --> T[Use triggers
high-fidelity alert]
T --> IR[IR: identify source,
scope the breach]
```
Because honeytokens are inert and never touched by legitimate processes, they produce near-zero false positives and give high-fidelity, early signal of credential theft, data staging, or insider misuse. A practical pattern is the **AWS canary key**: a planted IAM key whose use is caught by CloudTrail — Thinkst Canarytokens popularised free, self-hosting versions (URL, document, and AWS-key tokens). Honeytokens extend visibility into places where logs are sparse — third-party SaaS, source-code repositories, and backups — and map to ATT&CK's *Decoy* defensive techniques. Caveats: a token must be plausible yet never reachable by normal workflows, and leaked-credential scanners or careless CI pipelines can trip it, so each alert still needs triage against its planted location.
---
# Replay Attack
Source: https://www.cyberglossary.org/en/term/replay-attack
Published: 2026-10-03
In a replay attack the adversary records a valid protocol exchange (for example a session cookie, a Kerberos ticket, a signed API request, or a wireless frame) and resubmits it to the server. If the protocol does not include freshness guarantees, the server cannot distinguish the replayed message from a fresh one. Replay is a building block of pass-the-hash, pass-the-ticket, transaction-tampering, and many IoT/automotive attacks.
```mermaid
flowchart LR
C[Client] -->|1. valid signed message| S[Server]
C -. intercepted .-> A[Attacker captures copy]
A -->|2. retransmit later| S
S -->|no freshness check:
accepts as genuine| G[Grants access]
```
Freshness primitives defeat replay. The Kerberos protocol (RFC 4120) mandates a **replay cache** plus authenticator timestamps within a clock-skew window; TOTP (RFC 6238) ties each code to a 30-second step. TLS 1.3 (RFC 8446) is anti-replay for normal data, but its **0-RTT early data** is explicitly replayable, so §8 requires server-side anti-replay or idempotent handling.
Real incidents show the range. In **KRACK** (Mathy Vanhoef, KU Leuven, 2017; CVE-2017-13077), replaying message 3 of the WPA2 four-way handshake forced the client to reinstall an in-use key, resetting the nonce/packet counter and breaking confidentiality. In hardware, Samy Kamkar's **RollJam** (DEF CON 2015, a ~$32 device) jammed and captured rolling-code keyfob frames, then replayed a withheld code to unlock cars and garages. Defences layer nonces, challenge–response, monotonic sequence numbers, short-lived channel-bound tokens, and mutual authentication.
---
# UEBA (User and Entity Behavior Analytics)
Source: https://www.cyberglossary.org/en/term/ueba
Published: 2026-10-03
User and Entity Behavior Analytics builds dynamic baselines for each identity (users, service accounts, hosts, IoT devices) and scores deviations using statistics, peer-group comparison, and machine learning. Gartner coined **UBA** in 2014 and renamed the category **UEBA** in its 2015 *Market Guide*, adding the "Entity" to capture non-human actors such as servers, applications, and devices. Unlike signature-based tooling, UEBA catches subtle misuse: logon-time anomalies, impossible travel, abnormal data access, lateral movement, or privilege abuse.
```mermaid
flowchart LR
L["Sources: SIEM, IdP,
EDR, cloud audit logs"] --> B[Build per-entity baseline]
B --> M[Score deviation
stats + ML + peer group]
M --> R{Risk score
over threshold?}
R -->|yes| A[Risk-scored alert → SOAR/analyst]
R -->|no| U[Update baseline]
```
Because a single odd event is weak evidence, UEBA accumulates **risk scores** across many signals before alerting, which cuts the false positives that overwhelm rule-based SIEM. The approach maps to MITRE ATT&CK techniques such as *Valid Accounts* (T1078) and *Exfiltration Over Web Service* (T1567), and it is central to insider-threat programs and zero-trust enforcement. Typical pitfalls are cold-start baselines that misread new joiners, seasonality (quarter-end finance spikes), and "alert laundering" where analysts trust the score without validating the underlying events. Mature deployments feed outcomes back to retrain models and tune peer groups.
---
# Business Impact Analysis (BIA)
Source: https://www.cyberglossary.org/en/term/business-impact-analysis
Published: 2026-10-02
A business impact analysis (BIA) determines how the loss of people, applications, facilities, or suppliers would affect an organization over time, so recovery can be prioritized by consequence rather than guesswork. Analysts inventory critical business processes, map their upstream and downstream dependencies, identify peak periods and manual workarounds, and quantify impact — lost revenue, contractual penalties, regulatory fines, safety, and reputational or customer-attrition costs — as a function of outage duration.
In NIST SP 800-34 Rev. 1 (*Contingency Planning Guide for Federal Information Systems*) the BIA is the second step of contingency planning and the basis for the core recovery metrics: Maximum Tolerable Downtime (MTD), the Recovery Time Objective (RTO), the Recovery Point Objective (RPO, how much data loss is acceptable), and Work Recovery Time (WRT = MTD − RTO). The guide stresses that the RTO must be set so the MTD is never exceeded. ISO 22301, the international business-continuity standard, likewise makes the BIA the foundation of the continuity program.
BIA outputs drive continuity and disaster-recovery design (e.g. active-active datacenters for a payments platform), incident-response planning, backup frequency, and cyber-insurance scoping. A BIA should be refreshed at least annually and after major business, supplier, or technology changes; a stale BIA that misses a single-source supplier or a new SaaS dependency can leave the most critical process without a recovery plan.
```mermaid
flowchart TD
A["Identify critical processes"] --> B["Map dependencies (apps, suppliers, people)"]
B --> C["Estimate impact vs outage duration"]
C --> D["Derive MTD / RTO / RPO"]
D --> E["Prioritize continuity & DR investments"]
E --> F["Feed incident-response & insurance planning"]
```
---
# Data Anonymization
Source: https://www.cyberglossary.org/en/term/data-anonymization
Published: 2026-10-02
Data anonymization irreversibly transforms personal data so that individuals can no longer be singled out, linked, or inferred — even by combining the release with outside information. Core techniques are suppression, generalization (e.g. coarsening a birth date to a year), aggregation, perturbation/noise, and randomization, usually evaluated against a formal model: k-anonymity, l-diversity, t-closeness, or differential privacy, which adds calibrated noise under a provable privacy budget (ε).
The bar is high because of a long record of re-identification. Latanya Sweeney famously estimated that 87% of Americans are unique on the combination of 5-digit ZIP, date of birth, and sex, and used public voter rolls to re-identify Massachusetts Governor William Weld's hospital records in "anonymized" state data — the result that motivated k-anonymity. In 2008 Narayanan and Shmatikov de-anonymized the Netflix Prize dataset (ratings of ~500,000 subscribers) by correlating sparse ratings with public IMDb profiles. The 2006 AOL search-log release was traced back to named individuals within days.
Under the GDPR, truly anonymized data falls outside the Regulation (Recital 26), but the Article 29 Working Party's Opinion 05/2014 and regulators such as the EDPB and CNIL require a documented re-identification risk assessment covering singling-out, linkability, and inference using means "reasonably likely to be used." Common pitfalls: relying on hashing or simple pseudonyms, releasing high-dimensional micro-data, or confusing pseudonymization with anonymization.
```mermaid
flowchart TD
R["Raw personal data"] --> D["Remove direct identifiers"]
D --> Q["Generalize / suppress quasi-identifiers"]
Q --> M["Apply privacy model (k-anonymity / differential privacy)"]
M --> T{"Re-identification risk acceptable?"}
T -->|"No"| Q
T -->|"Yes"| P["Publish / share anonymized dataset"]
```
---
# HTTP Request Smuggling
Source: https://www.cyberglossary.org/en/term/http-request-smuggling
Published: 2026-10-02
HTTP request smuggling abuses inconsistent parsing of the Content-Length (CL) and Transfer-Encoding (TE) headers between a front-end intermediary — load balancer, CDN, or reverse proxy — and the back-end origin. When the two tiers disagree on where a message ends, an attacker prepends a crafted prefix that the back end treats as the start of the *next* visitor's request. The three classic variants (CL.TE, TE.CL, and TE.TE header obfuscation) exist because RFC 7230 says a request carrying both headers must be rejected, yet many stacks silently prefer one.
The modern era began with James Kettle's 2019 Black Hat USA research "HTTP Desync Attacks: Smashing into the Cell Next Door," which weaponised the technique against real targets, including PayPal's login page. His follow-ups — "HTTP/2: The Sequel Is Always Worse" (2021) and "Browser-Powered Desync Attacks" (2022) — showed that HTTP/2-to-HTTP/1.1 downgrades and client-side desync keep the class alive even as individual servers get patched.
Impact includes web-cache poisoning served to every later visitor, credential and session-cookie capture over shared keep-alive connections, WAF and access-control bypass, and response-queue poisoning.
Defences: prefer HTTP/2 end-to-end (avoid downgrades), reject messages that contain both CL and TE or that are otherwise ambiguous, normalise requests at the edge, and keep front-end and back-end HTTP parsers version-aligned.
```mermaid
flowchart TD
A["Attacker"] -->|"CL.TE ambiguous request"| F["Front-end proxy / CDN"]
F -->|"forwards full body (keep-alive)"| B["Back-end origin"]
B -->|"splits on Transfer-Encoding"| S["Smuggled prefix left in buffer"]
V["Next visitor"] -->|"normal request"| F
F --> B
S -.->|"prepended to victim request"| P["Poisoned response / stolen data"]
```
---
# STIX
Source: https://www.cyberglossary.org/en/term/stix-format
Published: 2026-10-02
Structured Threat Information eXpression (STIX) is an open language, standardized by the OASIS Cyber Threat Intelligence Technical Committee, for representing cyber threat intelligence in a consistent, machine-readable form. The current version, STIX 2.1, became an OASIS Standard on 10 June 2021 and expresses intelligence as JSON. It defines three object families: 18 STIX Domain Objects (SDOs) such as indicator, malware, threat-actor, campaign, intrusion-set, attack-pattern, tool, and vulnerability; STIX Cyber-observable Objects (SCOs) for raw artefacts like files, IP addresses, and network traffic; and STIX Relationship Objects (SROs) that wire them into a graph (e.g. a threat-actor *uses* malware that *targets* an identity).
Because every concept has a stable schema and a globally unique ID, STIX lets producers share *context* — tactics, techniques, kill-chain phases, sightings, and confidence — rather than isolated indicators, and lets SIEMs, threat-intelligence platforms (TIPs), and SOAR tools ingest the same feed without bespoke parsers. STIX is normally transported by its companion protocol TAXII 2.1 (published the same day), a REST API offering collections and channels for pull/push sharing.
STIX underpins operational sharing across ISACs, national CERTs/CSIRTs, and commercial vendors, and pairs naturally with the Traffic Light Protocol for handling restrictions and with MITRE ATT&CK for technique references. STIX 2.1 supersedes the XML-based STIX 1.x and its older CybOX observable model.
```mermaid
flowchart LR
subgraph B["STIX 2.1 Bundle (JSON)"]
TA["Threat Actor (SDO)"] -->|"uses"| MW["Malware (SDO)"]
IND["Indicator (SDO)"] -->|"indicates"| MW
IND -->|"based-on"| OD["Observed Data + SCOs"]
end
B -->|"shared via TAXII 2.1"| C["SIEM / TIP / SOAR"]
```
---
# Passive DNS
Source: https://www.cyberglossary.org/en/term/passive-dns
Published: 2026-10-01
Passive DNS (pDNS) is built by sensors placed just above recursive resolvers that record the responses the resolver receives, without ever querying authoritative servers themselves. The technique was introduced by Florian Weimer in his 2005 paper *Passive DNS Replication*, presented at the FIRST conference; his system logged resolver answers and replicated them into a central, queryable database. Sensors typically capture only inter-server (cache-miss) traffic above the resolver, so they avoid recording the stub queries of individual end users.
Datasets from providers such as Farsight DNSDB (now part of DomainTools), VirusTotal, SecurityTrails, and CIRCL let defenders pivot from a domain to historical IPs, sibling domains, name servers, and first-seen/last-seen timestamps. Many expose records in the IETF Common Output Format (COF, `draft-dulaunoy-dnsop-passive-dns-cof`) so results are interchangeable across vendors. It is a core resource for threat hunting, malware infrastructure mapping, takedowns, and tracking fast-flux and domain-generation algorithms — for example, confirming that a phishing domain first resolved only hours before a campaign began. Because pDNS records only what was actually observed, it complements WHOIS, certificate transparency, and active scanning, and it is non-intrusive to the operators of the observed domains.
```mermaid
flowchart LR
C[Clients] --> R[Recursive resolver]
R -->|cache-miss queries| AUTH[Authoritative servers]
S[pDNS sensor] -. observes responses .-> R
S --> DB[(Passive DNS database)]
AN[Analyst] -->|pivot on domain / IP| DB
DB -->|historical resolutions| AN
```
---
# Site-to-Site VPN
Source: https://www.cyberglossary.org/en/term/site-to-site-vpn
Published: 2026-10-01
A site-to-site VPN connects two routed networks through gateways that build a cryptographic tunnel across an untrusted network, so endpoints behind them communicate as if directly linked. Implementations are most often IPsec in tunnel mode, sometimes complemented by GRE or modern alternatives like WireGuard.
The dominant stack is IPsec, defined by **RFC 4301** (Security Architecture for IP). Key exchange uses IKEv2 (**RFC 7296**), which negotiates an IKE SA and then one or more Child SAs; data is carried by the Encapsulating Security Payload, ESP (**RFC 4303**), which encrypts and authenticates each packet. Configuration means matching cryptographic suites on both peers, defining traffic selectors (which subnets are tunneled), and exchanging pre-shared keys or X.509 certificates, with Dead Peer Detection and rekey timers keeping the tunnel healthy.
A classic weakness is the legacy **IKEv1 aggressive mode with a pre-shared key**: the responder sends a hash of the PSK before the exchange is encrypted, letting an attacker who captures it run an offline dictionary attack (tools such as ike-scan and hashcat mode 5300 automate this). Certificate authentication or IKEv2 avoids that exposure. WireGuard offers a leaner alternative built on the Noise protocol framework and Curve25519, with a far smaller codebase. Site-to-site VPNs are heavily used for hybrid-cloud connectivity, branch-to-headquarters links, and disaster recovery, often paired with dynamic routing (BGP) for failover.
```mermaid
flowchart LR
subgraph SiteA[Site A 10.0.0.0/24]
HA[Internal host] --> GA[VPN Gateway A]
end
subgraph SiteB[Site B 10.1.0.0/24]
GB[VPN Gateway B] --> HB[Internal host]
end
GA -->|IKEv2 negotiation| GB
GA -->|ESP tunnel over Internet| GB
```
---
# Zero Trust Network
Source: https://www.cyberglossary.org/en/term/zero-trust-network
Published: 2026-10-01
A zero trust network discards the legacy assumption that the internal network is inherently trusted. Every connection — north-south or east-west — must be authenticated, authorized, and continuously evaluated based on identity, device posture, context, and risk before access to an application or service is granted.
The term was coined by John Kindervag at Forrester in his 2010 report *No More Chewy Centers: Introducing the Zero Trust Model of Information Security*, which attacked the "hard shell, soft centre" perimeter model. Google's BeyondCorp program (2014 onward) then proved the pattern at enterprise scale by moving access decisions off the VPN and onto per-request checks. In 2020 NIST codified it in **SP 800-207**, whose core abstraction is a Policy Decision Point (PDP) and Policy Enforcement Point (PEP): the PEP sits in the data path, and for every request it asks the PDP — fed by identity, device, and threat-intel signals — for an allow/deny verdict scoped to a single session.
In the U.S. federal sphere, Executive Order 14028 (May 2021) and OMB memo **M-22-09** (January 2022) mandated agencies move toward zero trust, with milestones due by the end of FY2024. Architecturally it combines strong identity (MFA, FIDO2), device attestation, encrypted transport (mTLS), microsegmentation, and least-privilege, just-in-time access — shrinking the blast radius of compromised credentials and treating "assume breach" as a design principle.
```mermaid
flowchart LR
U[User + Device] -->|request| PEP[Policy Enforcement Point]
PEP -->|query| PDP[Policy Decision Point]
ID[Identity / MFA] --> PDP
DEV[Device posture] --> PDP
CTX[Context + risk signals] --> PDP
PDP -->|allow / deny| PEP
PEP -->|least-privilege session| APP[Application / Resource]
```
---
# Hash Collision
Source: https://www.cyberglossary.org/en/term/hash-collision
Published: 2026-09-30
A hash collision is a pair of different inputs that map to identical hash outputs. Because hash functions compress arbitrary data to a fixed size, collisions exist mathematically, but a secure hash makes them computationally infeasible to find. The generic birthday bound means a brute-force collision needs only about 2^(n/2) work — 2^128 for SHA-256 — so a broken function is one where mathematical shortcuts drop that cost far lower.
Two collision classes matter. An **identical-prefix** collision appends crafted blocks to a shared prefix; the **chosen-prefix** collision, far more dangerous, lets an attacker start from two arbitrary, meaningful prefixes and still collide, which is what forges certificates and keys.
Real breaks: Wang et al. found practical MD5 collisions in 2004; in 2008 Sotirov, Stevens et al. minted a rogue CA certificate, and in 2012 the **Flame** espionage malware used a novel MD5 chosen-prefix collision to forge a Microsoft Terminal Server Licensing certificate and sign malware as Microsoft. SHA-1 fell to Google/CWI's **SHAttered** identical-prefix collision in 2017 (~2^63 work), then to Leurent and Peyrin's **SHA-1 is a Shambles** chosen-prefix collision in 2020, which forged a PGP key certification (GnuPG **CVE-2019-14855**, fixed in 2.2.18).
Defence: retire MD5 and SHA-1 for any security use and adopt SHA-256, SHA-3, or BLAKE2/BLAKE3, per NIST's deprecation of SHA-1.
```mermaid
flowchart TD
A[Attacker picks two prefixes P1 and P2] --> B[Collision search: compute near-collision blocks]
B --> C{H of P1 plus blocks equals H of P2 plus blocks?}
C -->|No| B
C -->|Yes| D[Benign document D1 and malicious document D2 share one hash]
D --> E[Victim signs or trusts D1]
E --> F[Signature or trust transfers to D2]
F --> G[Forged certificate, key, or binary accepted]
```
---
# One-Time Password (OTP)
Source: https://www.cyberglossary.org/en/term/one-time-password
Published: 2026-09-30
A One-Time Password (OTP) is a credential valid for a single use, so a captured code is worthless to an attacker after the moment it is spent. Modern OTPs are computed from a shared secret held by both an authenticator (app or hardware token) and the server. **HOTP** (RFC 4226) truncates an HMAC-SHA-1 of a monotonically increasing event counter into a 6–8 digit code; **TOTP** (RFC 6238) replaces the counter with Unix time divided by a step, defaulting to 30 seconds, which is why authenticator apps refresh on that cadence. **OCRA** (RFC 6287) binds the code to a server challenge or transaction data, and the older S/KEY/OTP scheme (RFC 1760/2289) hash-chained secrets for one-time use.
Delivery over SMS or email is common but weak: SS7 interception, SIM swapping, and mobile malware all expose the code, and NIST SP 800-63B has restricted SMS as an out-of-band channel since 2017.
The core limitation is that any OTP a human can read and retype can be relayed in real time. Adversary-in-the-middle phishing kits such as Evilginx and EvilProxy proxy the login, capture the OTP, and replay it within its validity window. For high-value accounts, prefer phishing-resistant, origin-bound factors — FIDO2/WebAuthn passkeys — which cannot be relayed this way.
```mermaid
flowchart TD
A[Shared secret provisioned to app and server] --> B{OTP type}
B -->|HOTP| C[Increment event counter]
B -->|TOTP| D[Read current time / 30s step]
C --> E[HMAC-SHA-1 of counter or timestep]
D --> E
E --> F[Truncate to 6-8 digit code]
F --> G[User submits code at login]
G --> H{Server recomputes and compares within window}
H -->|Match| I[Second factor accepted]
H -->|No match| J[Rejected]
```
---
# Sigma Rule
Source: https://www.cyberglossary.org/en/term/sigma-rule
Published: 2026-09-30
Sigma is an open detection-engineering format created by Florian Roth and Thomas Patzke that lets analysts describe a log-based detection once and translate it into many query dialects — Splunk SPL, Elastic ES|QL, Microsoft Sentinel KQL, Google Chronicle YARA-L, and more. It plays the role for generic log events that YARA plays for files and Snort/Suricata play for network traffic: a portable, shareable lingua franca so a detection published by one team runs on another's stack.
A rule is YAML with three key parts: **metadata** (a UUID `id`, a `level` from informational to critical, and `tags` mapping to MITRE ATT&CK techniques), a **logsource** (product, service, or category such as `process_creation`), and a **detection** block of named selectors combined by a `condition` expression. Field values support modifiers like `contains`, `startswith`, and `re` for regex.
Conversion moved from the legacy `sigmac` tool to the modular **pySigma** library and its `sigma` CLI, which apply per-backend pipelines that remap field names to each product's schema. The **SigmaHQ** GitHub repository curates thousands of community rules covering Windows Event Logs, Sysmon, Linux auditd, AWS CloudTrail, Okta, and Kubernetes. Sigma also added **correlation** rules for counting, thresholds, and temporal sequences across events.
```mermaid
flowchart LR
A[Analyst writes Sigma rule in YAML] --> B[logsource + detection + condition]
B --> C[pySigma converter + backend pipeline]
C --> D1[Splunk SPL]
C --> D2[Sentinel KQL]
C --> D3[Elastic ES-QL]
C --> D4[Chronicle YARA-L]
D1 --> E[Deployed as SIEM/EDR detection]
D2 --> E
D3 --> E
D4 --> E
E --> F[Alert on matching log events]
```
---
# WPS Attack
Source: https://www.cyberglossary.org/en/term/wps-attack
Published: 2026-09-30
Wi-Fi Protected Setup (WPS) was designed to simplify joining a home network using an eight-digit PIN. In December 2011 Stefan Viehböck — and independently Craig Heffner — disclosed a fatal design flaw, documented in **US-CERT VU#723755** and tracked as **CVE-2011-5053**. When the external-registrar method authenticates the PIN, the access point validates it in two halves and returns an EAP-NACK that reveals whether the *first* half was correct before the second is checked. Because the eighth digit is only a checksum of the first seven, the search space collapses from 10^8 (100 million) to 10^4 + 10^3 ≈ **11,000 attempts**.
Tools such as **Reaver** (Craig Heffner / Tactical Network Solutions) and **Bully** (Sofiane Talmat) exploit this against most consumer access points and recover the WPA/WPA2 pre-shared key in roughly 4–10 hours. The related **Pixie Dust** attack (Dominique Bongard, 2014) goes further, breaking WPS offline in seconds on routers with weak nonce randomness in the registration exchange.
Defence: disable WPS entirely, or restrict it to push-button (PBC) mode; vendors also added PIN-attempt rate limiting and lockouts after repeated failures. Many cheap routers still ship with the vulnerable external-registrar PIN method enabled by default.
```mermaid
flowchart TD
A[Attacker in radio range] --> B[Send WPS PIN guess to access point]
B --> C{First 4 digits correct?}
C -->|EAP-NACK early| D[Wrong first half: try next of 10^4]
C -->|Proceeds| E{Last 3 digits plus checksum correct?}
E -->|EAP-NACK| F[Wrong second half: try next of 10^3]
E -->|Success| G[AP returns WPA/WPA2 pre-shared key]
D --> B
F --> B
G --> H[Attacker joins the network]
```
---
# FIDO2
Source: https://www.cyberglossary.org/en/term/fido2
Published: 2026-09-29
FIDO2 is the umbrella term for two complementary specifications: **WebAuthn**, a W3C JavaScript API (Level 1 became a Recommendation in March 2019, Level 2 in April 2021) that lets relying parties create and verify public-key credentials, and the **Client to Authenticator Protocol (CTAP)**, which lets browsers talk to roaming authenticators over USB, NFC, or Bluetooth. CTAP2 is the FIDO2 protocol; the older CTAP1 is simply U2F, giving FIDO2 backward compatibility with existing security keys.
At registration the authenticator generates an ECDSA (ES256/P-256) or EdDSA key pair scoped to the relying-party origin and returns the public key plus an attestation statement. At authentication the server sends a random challenge; the private key — released only after user presence and verification (touch, biometric, or PIN) — signs the challenge together with the origin. Because signatures are bound to the true origin and never leave the device, FIDO2 structurally defeats phishing, credential replay, and credential stuffing; a monotonic signature counter also flags cloned authenticators. It supports both second-factor and fully passwordless flows and is the technical basis for **passkeys**, the synced/discoverable credentials that Apple, Google, and Microsoft began shipping in 2022.
```mermaid
flowchart LR
A[User visits site] --> B[Server sends random challenge and RP ID]
B --> C[Browser via WebAuthn calls authenticator]
C --> D[User verifies: touch, biometric, or PIN]
D --> E[Private key signs challenge plus origin]
E --> F[Server verifies signature with stored public key]
F --> G[Access granted]
```
---
# Harvest Now, Decrypt Later
Source: https://www.cyberglossary.org/en/term/harvest-now-decrypt-later
Published: 2026-09-29
Harvest now, decrypt later (HNDL), also called store-now-decrypt-later, describes adversaries who intercept and archive encrypted communications today, betting that a future cryptographically relevant quantum computer (CRQC) will break the underlying public-key schemes — RSA and elliptic-curve Diffie-Hellman — via **Shor's algorithm**. The data need not be readable now; it only has to still be valuable when decryption becomes feasible.
The threat is governed by **Mosca's inequality**: if the time data must stay secret (X) plus the time to migrate systems (Y) exceeds the time until a CRQC arrives (Z), you are already exposed. It is most acute for long-lived secrets — state intelligence, health and genomic records, intellectual property, and root or CA keys — whose value persists for decades.
Defences center on migrating to NIST's post-quantum standards, finalized on 13 August 2024: **FIPS 203 (ML-KEM)** for key encapsulation, **FIPS 204 (ML-DSA)** and **FIPS 205 (SLH-DSA)** for signatures. In practice, deployments favour *hybrid* key exchange such as **X25519MLKEM768**, already shipping in Chrome, Firefox and Cloudflare TLS, so a session stays safe if either component holds. The NSA's CNSA 2.0 suite sets a phased migration timeline. Shortening secret lifetimes and enforcing crypto agility let organizations swap algorithms without redesign.
```mermaid
flowchart LR
A[Attacker intercepts encrypted traffic today] --> B[Store ciphertext in long-term archive]
B --> C[Wait years for quantum computer]
C --> D[CRQC runs Shor's algorithm]
D --> E[Break RSA / ECDH key exchange]
E --> F[Decrypt archived sessions]
G[Defence: hybrid PQC key exchange now] -.blocks.-> F
```
---
# Identity and Access Management (IAM)
Source: https://www.cyberglossary.org/en/term/identity-and-access-management
Published: 2026-09-29
Identity and Access Management (IAM) is the framework of policies, processes and tooling that manages the lifecycle of human and machine identities and governs their access to applications, data and infrastructure. Core capabilities include provisioning and deprovisioning, authentication, authorization, single sign-on (SSO), multi-factor authentication, role and entitlement management, and audit logging. IAM is the backbone of zero-trust architectures, where every access decision depends on a verified identity and its attributes rather than network location.
IAM is built on open standards: **SAML 2.0** and **OpenID Connect** (layered on OAuth 2.0) for federated SSO, and **SCIM 2.0** (IETF RFCs 7642/7643/7644) for cross-domain user provisioning that automatically creates, updates and deactivates accounts across SaaS apps. Mature programs add adjacent disciplines — Identity Governance and Administration (IGA) for access certification, Privileged Access Management (PAM) for admin accounts, and CIEM for cloud entitlements.
Weak IAM is a leading breach cause: stolen or reused credentials are consistently among the top initial-access vectors in the Verizon DBIR, and orphaned accounts, standing privilege, and unmanaged service identities are routinely abused for lateral movement. Enforcing least privilege, just-in-time access, and prompt joiner-mover-leaver deprovisioning shrinks that attack surface.
```mermaid
flowchart LR
A[Identity source: HR, directory] --> B[Provisioning via SCIM]
B --> C[Identity store and IdP]
C --> D[Authentication: MFA, SSO]
D --> E[Authorization: RBAC/ABAC policy]
E --> F{Access decision}
F -->|Permit| G[Resource access + audit log]
F -->|Deny| H[Block and alert]
```
---
# SOAR
Source: https://www.cyberglossary.org/en/term/soar
Published: 2026-09-29
Gartner coined **Security Orchestration, Automation and Response (SOAR)** in 2017 to name a converging class of tools that merged security orchestration and automation, security incident-response platforms (SIRP), and threat-intelligence platforms (TIP). SOAR sits alongside the SIEM and EDR/XDR to operationalize response: it uses connectors and REST APIs to query threat intelligence, IAM, endpoint, network and ticketing systems, then runs codified **playbooks** that triage alerts, enrich indicators, contain hosts, disable accounts and document the case.
The value is measurable. By automating repeatable steps — sandbox detonation, reputation lookups, host isolation — SOAR slashes mean time to respond (MTTR) and enforces consistent process, while human approval gates guard high-risk actions such as account lockout or firewall changes. Well-designed playbooks are idempotent and log every step for audit. Common platforms include Splunk SOAR (formerly Phantom), Palo Alto Cortex XSOAR (formerly Demisto), Microsoft Sentinel automation rules, Swimlane and Tines. Since ~2024 Gartner has folded standalone SOAR into broader SecOps and "hyperautomation" categories, but the playbook-driven pattern remains the backbone of scalable detection-and-response programs.
```mermaid
flowchart TD
A[Alert from SIEM or EDR] --> B[SOAR ingests and dedupes]
B --> C[Playbook enriches: TI, WHOIS, sandbox]
C --> D{Malicious?}
D -->|No| E[Close as false positive]
D -->|Yes| F{High-risk action?}
F -->|No| G[Auto-contain: isolate host, block IOC]
F -->|Yes| H[Analyst approval gate]
H --> G
G --> I[Log case and update ticket]
```
---
# NTLM Authentication
Source: https://www.cyberglossary.org/en/term/ntlm-authentication
Published: 2026-09-28
NTLM (NT LAN Manager) is a family of Microsoft authentication protocols predating Kerberos in Windows networks. It uses a challenge-response handshake: the server sends a random nonce, and the client returns a response computed from the user's **NT hash**, so the password itself never crosses the wire. NTLMv1 relied on weak DES-based computation; **NTLMv2** uses an HMAC-MD5 response, but neither binds the exchange to the target service, which is the root of its danger.
## Attacks and deprecation
Because the response only proves knowledge of the hash, NTLM is exposed to **pass-the-hash** (replaying a stolen hash without cracking it), offline cracking of captured hashes, and above all **NTLM relay**: an attacker who coerces a victim to authenticate forwards that authentication to a third service. CVE-2019-1040 ("Drop the MIC") let attackers strip the Message Integrity Code and remove signing during relay. Coercion primitives such as **PetitPotam** (CVE-2021-36942, patched August 2021) trigger unauthenticated machine authentication that, when relayed to an AD CS web-enrollment endpoint (**ESC8**, advisory ADV210003), yields a certificate for a domain controller and **full domain takeover**.
Microsoft began formally deprecating NTLM in 2024, steering Windows 11 toward Kerberos with IAKerb and a local KDC. Defences: enforce SMB and LDAP signing, enable Extended Protection for Authentication (channel binding), restrict outbound NTLM via Group Policy, and prefer Kerberos-only configurations.
```mermaid
flowchart TD
C[Client] -->|1 NEGOTIATE| S[Server]
S -->|2 CHALLENGE nonce| C
C -->|3 RESPONSE from NT hash| S
S -->|4 forward to domain controller| DC[Domain controller]
DC -->|5 verify hash| S
S -->|6 access granted| C
```
---
# OAuth 2.0
Source: https://www.cyberglossary.org/en/term/oauth-2
Published: 2026-09-28
OAuth 2.0 (RFC 6749) separates four roles: the resource owner (user), the client (application), the authorization server that issues tokens, and the resource server that hosts the API. The client obtains an access token through a defined grant — **authorization code with PKCE** (RFC 7636) for interactive apps, **client credentials** for service-to-service calls, **device code** (RFC 8628) for input-constrained devices — then calls the API with that token as a bearer credential. Scopes and audiences constrain what the token can do.
## Security guidance and pitfalls
RFC 9700 (BCP 240, published January 2025) consolidates OAuth security practice: it **deprecates the implicit grant and the resource owner password credentials grant**, mandates PKCE for every authorization-code client, and requires exact redirect-URI matching to defeat code-interception and open-redirect attacks. Because access tokens are bearer credentials, sender-constraining them with DPoP or mutual-TLS limits replay after theft.
The dominant real-world abuse is **OAuth consent phishing** (illicit consent grant): rather than steal passwords, attackers register a malicious app and trick users into approving broad scopes. The May 2017 "Google Docs" worm spread this way in about an hour, and APT29/Nobelium repeatedly abused Microsoft 365 consent grants to persist through MFA. Defences include admin consent workflows, publisher verification, short-lived tokens, and revoking unused grants.
```mermaid
flowchart LR
U[Resource owner] -->|1 authorize + code_challenge| AS[Authorization server]
AS -->|2 auth code via redirect| C[Client app]
C -->|3 code + code_verifier| AS
AS -->|4 access token| C
C -->|5 bearer token| RS[Resource server / API]
RS -->|6 protected data| C
```
---
# SAML
Source: https://www.cyberglossary.org/en/term/saml
Published: 2026-09-28
SAML (Security Assertion Markup Language), standardised as OASIS SAML 2.0 in 2005, defines how a trusted **identity provider (IdP)** issues digitally signed XML assertions describing a user's identity and attributes to a **service provider (SP)**, enabling web single sign-on across security domains. SAML 2.0 supports HTTP-Redirect and HTTP-POST bindings; the SP must validate the assertion's XML signature, `Audience`, `NotOnOrAfter` time conditions and `InResponseTo` before creating a session.
## Attacks and weaknesses
Two failure classes dominate. **XML Signature Wrapping (XSW)** and comment-injection bugs let an attacker smuggle attacker-controlled data past signature verification. In February 2018 Duo Labs disclosed a broad class of these flaws across popular toolkits — CVE-2017-11427 (python-saml), CVE-2017-11428 (ruby-saml), CVE-2017-11429 (saml2-js) and CVE-2017-11430 (omniauth-saml) — where a `` comment inserted into the `NameID` truncated the parsed subject, letting an authenticated user log in as another. **Golden SAML**, described by CyberArk in 2017, is post-compromise: an attacker who steals an AD FS token-signing private key can forge arbitrary assertions that bypass passwords and MFA. APT29 used exactly this in the 2020 SolarWinds/SUNBURST campaign to mint federated tokens that appeared as normal sign-ins.
Defences: enforce signed responses *and* assertions, strict audience/recipient checks, hardware-protect (HSM) the token-signing key, rotate it, and monitor for anomalous federated logins. For new integrations OpenID Connect is often preferred.
```mermaid
flowchart LR
U[User browser] -->|1 access resource| SP[Service provider]
SP -->|2 AuthnRequest redirect| IdP[Identity provider]
IdP -->|3 authenticate user| IdP
IdP -->|4 signed SAML assertion| U
U -->|5 POST assertion| SP
SP -->|6 verify signature + conditions| SP
SP -->|7 session granted| U
```
---
# 5G Security
Source: https://www.cyberglossary.org/en/term/5g-security
Published: 2026-08-07
5G security, specified in 3GPP TS 33.501, builds on but significantly hardens the LTE model. Primary authentication uses 5G-AKA or EAP-AKA' with the home network's Authentication Server Function (AUSF) and Unified Data Management (UDM), achieving mutual authentication and a hierarchical key tree (KAUSF, KSEAF, KAMF, KgNB). To prevent IMSI catchers, the long-term identifier (SUPI) is never sent in the clear: instead, the UE encrypts it with the home operator's public key into a SUCI using ECIES (Curve25519 or P-256). User-plane traffic between UE and gNB can be ciphered and integrity-protected with NEA1/2/3 (SNOW 3G, AES-128, ZUC). Service-Based Architecture between network functions is protected by TLS 1.3 and OAuth 2.0 access tokens. Application-layer keys can be bootstrapped from the same 5G credentials via **AKMA** (TS 33.535), avoiding a separate secret for each service.
Residual weaknesses are well studied. The registration phase before security is established remains exposed to **false base stations** (fake gNBs); 3GPP's TR 33.809 study track works on FBS/MitM detection, and formal-analysis tools such as **5GReasoner** have surfaced protocol flaws in paging and registration. The core network is not immune either: Trend Micro's 2023 research showed that a malicious UE could reach the packet core and crash the User Plane Function (UPF) with malformed **GTP-U** packets, and demonstrated ASN.1 parsing bugs in open-source 5G cores — a reminder that the Service-Based Architecture widens the attack surface if the N3/N6 interfaces and roaming (SEPP) boundaries are not filtered. Defences include enforcing NEA/NIA integrity on signalling, roaming protection at the Security Edge Protection Proxy, and hardening the core against untrusted device traffic.
```mermaid
flowchart TD
UE[UE / SIM] -->|SUCI = ECIES-encrypted SUPI| SEAF[SEAF / AMF]
SEAF --> AUSF[AUSF home network]
AUSF --> UDM[UDM / ARPF
de-conceals SUPI]
UDM -->|5G-AKA vectors| AUSF
AUSF -->|KSEAF| SEAF
SEAF -->|KAMF then KgNB| GNB[gNB]
GNB -->|NEA/NIA ciphered + integrity
protected user plane| UE
UDM -.AKMA TS 33.535.-> APP[Application function]
```
---
# Adaptive Attack
Source: https://www.cyberglossary.org/en/term/adaptive-attack-ml
Published: 2026-08-07
An adaptive attack is constructed with full knowledge of the target defence and its assumptions, and its loss function or constraints are tailored to bypass that defence. The term was popularised by Carlini and Wagner, whose 2017 study *Adversarial Examples Are Not Easily Detected* broke ten proposed detection methods once the attack was retargeted against each detector's specific rule.
Two landmark evaluations cemented adaptive attacks as mandatory. Athalye, Carlini and Wagner's ICML 2018 paper *Obfuscated Gradients Give a False Sense of Security* found that 7 of 9 defences accepted at ICLR 2018 relied on **gradient masking** — they merely made gradients uninformative rather than the model truly robust — and circumvented 6 of them completely using techniques such as **BPDA** (Backward Pass Differentiable Approximation, to get past non-differentiable pre-processing) and **EOT** (Expectation over Transformation, to defeat randomised defences). In 2020, Tramèr, Carlini, Brendel and Madry's *On Adaptive Attacks to Adversarial Example Defenses* (NeurIPS) broke 13 defences from ICLR, ICML and NeurIPS, showing that even authors who *attempted* adaptive evaluations often built weak, non-tailored attacks.
The lesson: any defence for adversarial examples, watermarking, or AI-content detection must be evaluated against an adversary aware of the defence who adapts its objective, ideally releasing attack code. Skipping this step routinely produces overstated robustness claims that fall to simple, principled attacks.
```mermaid
flowchart TD
A[Proposed ML defence
claims robustness] --> B[Generic attack
e.g. standard PGD]
B -->|Attack fails| C[Apparent robustness]
C --> D{Adaptive evaluation?}
D -->|Skipped| E[Overstated claim
published]
D -->|Applied| F[Attacker studies defence
internals and assumptions]
F --> G[Tailor loss + BPDA / EOT
to the defence]
G --> H{Defence survives?}
H -->|No| I[Robustness refuted]
H -->|Yes| J[Evidence of genuine
robustness]
```
---
# Android Malware
Source: https://www.cyberglossary.org/en/term/android-malware
Published: 2026-08-07
Android malware ranges from advertising fraud and SMS premium-rate trojans to banking trojans, spyware, and remote-access tools. Well-documented families include Joker (premium-SMS fraud, repeatedly found on Google Play), Anubis and Cerberus (banking trojans abusing accessibility services to overlay phishing screens and steal SMS-based OTPs), BRATA (banking RAT that can factory-reset the device), and SharkBot (banking trojan using Automated Transfer Systems to initiate fraudulent transfers).
Two campaigns illustrate the scale. **FluBot**, a smishing worm first seen in December 2020, spread by texting fake package-delivery and voicemail links that installed an APK, then harvested contacts to text itself onward; a 2022 operation across 11 countries coordinated by Europol's EC3 dismantled its infrastructure. **GriftHorse**, documented by Zimperium zLabs in 2021, used roughly 200 innocuous-looking apps to subscribe an estimated 10 million-plus users across 70+ countries to premium services costing around EUR 30 a month.
The dominant delivery pattern today is a benign "dropper" that clears Google Play review, then side-loads the real payload and requests the **Accessibility Service** to read the screen, autofill fraudulent transfers, and dismiss its own uninstall dialogs. Families such as Anatsa (TeaBot) and Xenomorph refined this route.
Defences: stay on Google Play with Play Protect real-time scanning, use Android 13+ Restricted Settings (which block side-loaded apps from Accessibility and Notification-Listener access), keep the OS patched, and enforce EMM/MDM with Play Integrity attestation on enterprise devices.
```mermaid
flowchart TD
A[Dropper app passes
Google Play review] --> B[User installs
from Play or phishing SMS]
B --> C[App side-loads
real payload]
C --> D{User grants
Accessibility Service?}
D -->|No| E[Malware nags with
fake system prompts]
E --> D
D -->|Yes| F[Read screen, inject
overlays, autofill]
F --> G[Steal OTP / credentials
Automated Transfer System]
G --> H[Fraudulent transfer
or premium subscription]
```
---
# Assume Breach
Source: https://www.cyberglossary.org/en/term/assume-breach
Published: 2026-08-07
Assume Breach is a security operating philosophy popularized by Microsoft in the mid-2010s and now the default posture of mature programs and zero-trust architectures. Rather than treating prevention as the primary defense and detection as a backstop, an assume-breach program designs the environment as if the adversary has already gained a foothold and asks how detection, containment, recovery, and limiting blast-radius will hold up. Concretely this drives: network microsegmentation so lateral movement is constrained, identity-centric architecture (every request authenticated and authorized), endpoint detection and response everywhere, centralized logging with retention long enough for true-detection of slow campaigns, regular red-team and purple-team exercises against the live environment (not just labs), automated containment playbooks (isolate host, rotate keys, kill session), and recovery rehearsals (immutable backups, alternative paths to keep the business running). The 2020 SolarWinds/SUNBURST campaign (tracked as UNC2452) is the canonical argument for the posture: a trojanised software update gave the actor months of undetected access inside prevention-hardened networks, and the organisations that fared best were those already watching for anomalous identity and lateral-movement behaviour rather than trusting the perimeter. Mandiant's long-running M-Trends reports track global median dwell time — the interval between intrusion and detection — falling from over 400 days a decade ago to roughly 10 in recent years; assume-breach controls (EDR telemetry, behavioural detection, tight segmentation) are the main reason that number keeps dropping.
Assume Breach is a foundational principle of NIST SP 800-207 Zero Trust Architecture, the U.S. DoD Zero Trust Strategy, the U.K. NCSC Cyber Assessment Framework, and most modern security programs.
```mermaid
flowchart LR
A[Assume adversary
is already inside] --> B[Microsegment network
limit lateral movement]
A --> C[Authenticate + authorize
every request]
A --> D[EDR + centralized logging
everywhere]
D --> E[Detect anomalous
identity / movement]
E --> F[Automated containment
isolate, rotate keys, kill session]
F --> G[Recover from
immutable backups]
G --> H[Purple-team the live env
feed lessons back]
H --> A
```
---
# Ed25519
Source: https://www.cyberglossary.org/en/term/ed25519
Published: 2026-08-06
Ed25519 is the most widely deployed instance of the Edwards-curve Digital Signature Algorithm (EdDSA), specified in **RFC 8032**. It uses the twisted Edwards curve edwards25519 (birationally equivalent to Curve25519) over the prime field 2²⁵⁵ − 19, producing 32-byte public keys and 64-byte signatures with roughly 128 bits of security. Signing is deterministic: the per-signature nonce is derived from the private key and message via SHA-512, eliminating the catastrophic nonce-reuse failure that broke Sony's PlayStation 3 code-signing and the Android Bitcoin wallets that reused ECDSA `k` values.
In February 2023, NIST added EdDSA (Ed25519 and Ed448) to **FIPS 186-5**, ending a long period in which the scheme was ubiquitous in practice but not FIPS-approved — a gap that had kept it out of some regulated deployments. Ed25519 is now the default in OpenSSH, WireGuard, GnuPG, TLS 1.3, Signal, and modern code-signing systems.
A subtle pitfall is verification semantics. Because the curve has cofactor 8, implementations disagree on whether to accept small-order points and whether verification is cofactored — so a signature that one library accepts another may reject, and some allow malleable variants. The 2020 paper "Taming the Many EdDSA" (Chalkias, Garillot, Nikolaenko) catalogued these divergences, which matter for consensus systems like blockchains (Solana, Cardano) where every validator must agree bit-for-bit. RFC 8032 recommends the stricter checks; libraries such as libsodium enforce them by default.
```mermaid
flowchart TD
SK["Private seed"] -->|SHA-512| H["Hash h0..h63"]
H --> A["Scalar a, public key A = a*B"]
H --> PR["Prefix bytes"]
PR --> R["r = SHA-512(prefix, M)"]
R --> RP["R = r*B"]
RP --> S["S = r + SHA-512(R, A, M)*a"]
S --> SIG["Signature = R, S
64 bytes, deterministic"]
SIG --> V{"Verify:
8*S*B == 8*R + 8*h*A ?"}
A --> V
V -->|yes| OK["Valid"]
V -->|no| BAD["Reject"]
```
---
# Hacktivist
Source: https://www.cyberglossary.org/en/term/hacktivist
Published: 2026-08-06
Hacktivists publicise their grievances through defacements, leaks of sensitive documents ("hack and leak"), DDoS, doxxing, and disruption of services they consider unjust. Some are loosely organised online collectives such as Anonymous, LulzSec, GhostSec, or Anonymous Sudan; others align with geopolitical conflicts, such as the IT Army of Ukraine, Killnet, NoName057(16), and Cyber Av3ngers. Capabilities range from basic DDoS-as-a-service to credential leaks of millions of records.
Two shifts have made modern hacktivism more consequential than the defacement era. First, it now reaches **operational technology**: in November 2023 the Iran-aligned "Cyber Av3ngers" persona compromised internet-exposed Unitronics PLCs at the Municipal Water Authority of Aliquippa, Pennsylvania, by simply using the default password `1111`, forcing a booster station offline. CISA and the FBI issued joint advisory **AA23-335A** in response. Second, the line with statecraft has blurred — "Anonymous Sudan," presented as an ideological collective, was later assessed by researchers and named in a 2024 U.S. indictment as an operation run by Sudanese nationals wielding a rented DDoS botnet, illustrating how a hacktivist banner can mask criminal or state-aligned actors.
This deniability is the core policy problem: because hacktivism frequently overlaps with nation-state operations through proxies or shared ideology, defenders should treat a hacktivist claim as a starting hypothesis, not a conclusion, and prioritise the same hardening — no default credentials, no internet-exposed OT, DDoS mitigation — regardless of who is claiming the attack.
```mermaid
flowchart TD
M["Ideological / political grievance"] --> ACT{"Tactic"}
ACT --> D["Website defacement"]
ACT --> L["Hack-and-leak / doxxing"]
ACT --> DD["DDoS campaign"]
ACT --> OT["OT / ICS disruption"]
OT --> EX["Cyber Av3ngers vs
Unitronics PLC, default pw 1111"]
D --> PUB["Public attention / pressure"]
L --> PUB
DD --> PUB
EX --> PUB
PUB --> ATTR["Attribution challenge:
proxy for nation-state?"]
```
---
# Role-Based Access Control (RBAC)
Source: https://www.cyberglossary.org/en/term/role-based-access-control
Published: 2026-08-06
Role-Based Access Control assigns permissions to abstract roles (for example, "billing-admin" or "read-only auditor") and grants users access by adding them to those roles. This indirection simplifies administration, supports separation of duties, and makes audits straightforward because permissions are documented per role rather than per user. RBAC is the dominant model in enterprise IAM, cloud platforms (AWS IAM, Azure RBAC, Kubernetes RBAC), and ERP systems.
RBAC was formalised by David Ferraiolo and Rick Kuhn of NIST in their 1992 paper "Role-Based Access Controls," then unified with the Sandhu et al. framework and standardised as **ANSI/INCITS 359-2004** (revised as INCITS 359-2012). The standard defines four cumulative components: **core** RBAC (users–roles–permissions), **hierarchical** RBAC (roles inherit from senior roles), and two forms of **constrained** RBAC — Static and Dynamic Separation of Duty (SSD/DSD) — that block toxic permission combinations such as one user both creating and approving a payment.
Its main weakness is *role explosion*: in large organisations, encoding every fine-grained business need as a distinct role produces thousands of near-duplicate roles that become unmanageable. This pushes teams toward hybrid ABAC/RBAC designs, where roles set a coarse baseline and attributes (department, time, resource tag) refine each decision — the pattern behind AWS IAM condition keys and Kubernetes' RBAC-plus-admission-webhook model.
```mermaid
flowchart LR
U["User: Alice"] -->|assigned to| R1["Role: billing-admin"]
U -->|assigned to| R2["Role: auditor"]
R1 -->|inherits| R3["Role: billing-viewer"]
R1 -->|grants| P1["Perm: create invoice"]
R3 -->|grants| P2["Perm: read invoice"]
R2 -->|grants| P3["Perm: export logs"]
P1 --> RES[("Billing system")]
P2 --> RES
P3 --> RES
SSD["SSD constraint:
cannot hold approver + creator"] -. blocks .-> R1
```
---
# Return-Oriented Programming
Source: https://www.cyberglossary.org/en/term/rop-return-oriented-programming
Published: 2026-08-06
Hovav Shacham introduced ROP in his 2007 paper "The Geometry of Innocent Flesh on the Bone," proving that return-into-libc could be generalised into Turing-complete computation and thereby defeat DEP/W^X. The attacker corrupts the stack and writes a chain of addresses, each pointing to a short *gadget* — a handful of instructions ending in `RET`. After each gadget executes, `RET` pops the next address, so control flows through existing executable bytes (libc, the program, loaded libraries) with no injected code for DEP to catch.
Because every gadget address is absolute, ROP depends on knowing where code sits in memory, which is exactly what **ASLR** randomises; real exploits therefore pair ROP with an information leak. Variants generalise the primitive: **JOP** (jump-oriented) and **COP** (call-oriented) chain indirect jumps/calls instead of returns, and **SROP** (sigreturn-oriented) abuses the kernel's signal-frame restore to set every register at once. Blind ROP (Bittau et al., 2014) even builds a chain against a remote service with no binary, by observing crashes.
ROP is the principal reason a generation of mitigations exists. Defences attack one of three surfaces: gadget availability, control-flow integrity, or memory safety at the source. **Intel CET** (shipping since Tiger Lake, 2020) enforces a hardware **shadow stack** that detects mismatched return addresses and **Indirect Branch Tracking** (`endbr64`) against JOP/COP; ARM offers Pointer Authentication and BTI. Memory-safe languages such as Rust remove the corruption bug that starts the chain.
```mermaid
flowchart TD
A["Memory-corruption bug
stack overflow"] --> B["Overwrite saved return address"]
B --> C["Stack now holds
gadget address chain"]
C --> G1["Gadget 1: pop rdi, ret"]
G1 --> G2["Gadget 2: pop rsi, ret"]
G2 --> G3["Gadget 3: syscall, ret"]
G3 --> X["execve /bin/sh"]
D1["DEP: stack non-exec"] -. bypassed by reuse .-> C
D2["ASLR"] -. needs info leak .-> C
D3["Intel CET shadow stack"] -. blocks bad RET .-> G1
```
---
# IP Spoofing
Source: https://www.cyberglossary.org/en/term/ip-spoofing
Published: 2026-08-05
IP spoofing rewrites the 32-bit (IPv4) or 128-bit (IPv6) source-address field in a packet header so it appears to come from a different machine. Because the classic Internet forwards datagrams on destination alone and never verifies the source, a host can emit packets claiming almost any origin. Attackers exploit this to evade ACLs that trust specific addresses, hide the origin of scans, mount blind or off-path TCP attacks, and — most damagingly — power **reflection/amplification DDoS**: the attacker sends small queries to open reflectors (DNS, NTP, memcached, CLDAP) with the victim's IP as the forged source, so every large reply lands on the victim.
The technique underpins the biggest floods on record. The 1997 **Smurf attack** spoofed the victim's address into ICMP echo requests sent to broadcast, so whole subnets replied. In February 2018 **GitHub** was hit by a ~1.35 Tbps memcached amplification flood built entirely on spoofed UDP to port 11211, then a still-larger one struck a US provider days later.
The fix mostly lives with network operators, not the victim. **BCP 38 (RFC 2827)** and BCP 84 ingress filtering, unicast Reverse Path Forwarding (uRPF), and Source Address Validation (SAVI) drop forged packets at the edge before they leave. Authenticated transports (TLS, IPsec) and TCP's random sequence numbers defeat the impersonation downstream.
```mermaid
flowchart LR
A[Attacker] -->|src = Victim IP| R[Open reflector
DNS / NTP / memcached]
R -->|large reply to spoofed src| V[(Victim)]
subgraph Defence
E[Edge router: BCP 38 / uRPF]
end
A -.forged packet dropped.-> E
```
---
# JWT Vulnerabilities
Source: https://www.cyberglossary.org/en/term/jwt-vulnerabilities
Published: 2026-08-05
JSON Web Tokens carry authentication and authorization claims, but the flexibility of their header-declared signing algorithm has produced several recurring vulnerability classes. The **alg=none** bug, disclosed by Tim McLean in 2015, occurs when a verifier trusts the token's own `alg` header and dispatches to a "none" verifier that returns true for an empty signature — letting an attacker rewrite the payload and drop the signature. It was fixed in Node's `jsonwebtoken` before 4.2.2 (CVE-2015-9235).
**Key confusion** (CVE-2016-10555) is subtler: if a server accepts both RS256 and HS256, an attacker signs a token with HMAC using the server's *public* RSA key as the shared secret; a naive verifier feeds that public key into `HS256.verify()` and the forgery passes. Related issues include weak HS256 secrets crackable offline with hashcat, missing `exp`/`nbf` checks, and header-injection sinks — `kid` path traversal or SQL injection, and attacker-controlled `jwk`/`jku`/`x5u` fields that point verification at a key the attacker owns. In 2022, CVE-2022-23529 in `jsonwebtoken` raised RCE concerns via a crafted key object (later retracted after exploit prerequisites were disputed).
Defences: pin the accepted algorithm(s) server-side and never read `alg` from untrusted input, use strong asymmetric keys, validate `kid` against an allowlist, ignore embedded key URLs, enforce expiry, and treat every JWT field as hostile input.
```mermaid
flowchart TD
A[Attacker gets a valid JWT] --> B{Tamper header}
B -->|alg none, drop sig| C[Verifier skips check?]
B -->|RS256 to HS256| D[HMAC with public key]
B -->|jku / kid points to attacker key| E[Verify against rogue key]
C -->|Yes| F[Forged token accepted]
D -->|Yes| F
E -->|Yes| F
F --> G[Privilege escalation / auth bypass]
C -->|Pinned alg| H[Rejected]
D -->|Pinned alg| H
E -->|Allowlist kid| H
```
---
# OWASP ZAP
Source: https://www.cyberglossary.org/en/term/owasp-zap
Published: 2026-08-05
OWASP Zed Attack Proxy (ZAP) is an open-source dynamic application security testing (DAST) tool that acts as an intercepting proxy, automated scanner, and fuzzer for web applications and APIs. First released by Simon "psiinon" Bennetts in 2010 as a fork of the Paros Proxy, it grew into one of OWASP's flagship projects.
ZAP works by sitting between the tester's browser and the target: it **spiders** the app to enumerate URLs, replays each request through **passive scanning** (inspecting responses for issues like missing security headers or insecure cookie flags), then runs **active scanning** rules that inject payloads to probe for SQL injection, cross-site scripting, path traversal, and more. Findings map to CWE and WASC identifiers. Automation is exposed through the ZAP API, a scriptable engine (JavaScript, Python via Jython, Zest), and packaged Docker actions such as the *baseline* and *full-scan* jobs used in CI.
In September 2024 the three core maintainers (Bennetts, Ricardo Pereira, and Rick Mitchell) joined Checkmarx, which now employs them to work on the project, rebranded **ZAP by Checkmarx**. ZAP stays free and open source under the Apache License 2.0, controlled by the ZAP Core Team. Compared with Burp Suite, ZAP trades some polish for zero licensing cost and first-class scriptability, making it a common choice for pipeline DAST.
```mermaid
flowchart LR
T[Tester / CI job] --> P[ZAP proxy]
P --> S[Spider & AJAX crawl]
S --> PA[Passive scan
headers, cookies]
S --> AC[Active scan
inject payloads]
PA --> R[Alerts mapped to CWE]
AC --> R
P --> APP[(Target web app / API)]
APP --> P
```
---
# SAST (Static Application Security Testing)
Source: https://www.cyberglossary.org/en/term/sast
Published: 2026-08-05
SAST parses code into intermediate representations — an abstract syntax tree, control-flow graph, and data-flow graph — then applies pattern rules or **taint analysis** to detect insecure constructs mapped to CWE identifiers. Taint analysis is the core engine: it marks untrusted **sources** (an HTTP parameter, a file read), tracks how that data propagates through variables and function calls, and raises a finding when it reaches a dangerous **sink** (a SQL query, `exec`, an HTML response) without passing through a recognised **sanitiser**. Because nothing executes, SAST runs in IDEs, pre-commit hooks, and CI, and can scan code long before it ships.
Its blind spots are well documented. SAST is strong on deterministic bugs (SQL injection, XSS sinks, hard-coded secrets, weak crypto) but generates false positives on paths that are unreachable at runtime, and misses configuration, authentication-logic, and runtime-only flaws — so mature programs pair it with SCA and DAST. Tuning rulesets and triaging noise are the real operational costs. Standards such as **OWASP ASVS** and NIST SSDF reference static analysis as a verification control. Common engines include **Semgrep**, GitHub **CodeQL** (which queries code as a database), SonarQube, Checkmarx, Fortify, and Snyk Code.
```mermaid
flowchart LR
SRC[Source code / bytecode] --> P[Parse to AST + CFG + DFG]
P --> T[Taint analysis + rules]
SO[Untrusted source] -. tracked flow .-> T
T --> SK{Reaches sink
without sanitiser?}
SK -->|Yes| F[Finding mapped to CWE]
SK -->|No| OK[No alert]
F --> TR[Triage: fix or mark false positive]
```
---
# DES (Data Encryption Standard)
Source: https://www.cyberglossary.org/en/term/des
Published: 2026-08-04
DES is a symmetric block cipher built on a 16-round Feistel network operating on 64-bit blocks with a 56-bit effective key (the 64-bit key includes 8 parity bits). It grew out of IBM's Lucifer cipher and was standardized as **FIPS PUB 46** in 1977 by the National Bureau of Standards, becoming the workhorse of commercial cryptography for two decades. Its design notably strengthened the S-boxes against differential cryptanalysis — a technique the NSA and IBM knew about years before it was publicly rediscovered by Biham and Shamir in the late 1980s.
The fatal weakness is key length. A 56-bit space contains only ~7.2×10¹⁶ keys. In 1998 the EFF's purpose-built **Deep Crack** machine (cost ~$250,000) recovered a DES key in about 56 hours; in 1999 it teamed with distributed.net to do so in **22 hours**. Today a modest GPU or FPGA cluster, or a cloud rental, brute-forces DES in hours. Cryptanalytic shortcuts (differential and linear cryptanalysis) exist but remain slower than exhaustion in practice.
DES is therefore considered broken and is disallowed by NIST (SP 800-131A), PCI DSS, and virtually every modern standard. **Triple DES (3DES)** — applying DES three times for ~112-bit strength — served as a bridge but is itself vulnerable to the **Sweet32** birthday attack (**CVE-2016-2183**) on its 64-bit block, and NIST deprecated 3DES with a hard disallow after 2023. AES is the mandated replacement. DES survives only in legacy systems (early Kerberos v4, older payment hardware).
```mermaid
flowchart TD
P[64-bit plaintext block] --> IP[Initial permutation]
IP --> S[Split into L0 and R0]
S --> F[16 Feistel rounds
each: expansion, XOR subkey,
S-box substitution, permutation]
K[56-bit key] --> KS[Key schedule
16 round subkeys]
KS --> F
F --> FP[Final permutation]
FP --> C[64-bit ciphertext]
C -.->|56-bit key too short| B[Brute force
Deep Crack: ~56h 1998]
B --> R[Broken - replaced by AES;
3DES bridge deprecated 2023]
```
---
# Domain Generation Algorithm (DGA)
Source: https://www.cyberglossary.org/en/term/domain-generation-algorithm
Published: 2026-08-04
A Domain Generation Algorithm is code embedded in malware that produces hundreds or thousands of pseudo-random domain names per day from a shared seed — typically the current date, sometimes salted with an unpredictable value such as a Twitter trending topic or exchange rate to defeat pre-registration. The bot and the operator run the same algorithm, so both compute the same day's list; the attacker registers only a handful, while the bot walks the list until one resolves. This "rendezvous" model defeats static blocklists, because defenders cannot enumerate every future C2 domain in advance, and it makes takedowns hard: seizing today's domain does nothing about tomorrow's.
Real families illustrate the scale. **Conficker.C** generated 50,000 domains a day across many TLDs in 2008–2009, prompting an unprecedented industry coalition (the Conficker Working Group) to pre-register or block them. **Gameover Zeus** fell back to a DGA of ~1,000 domains/day when its peer-to-peer layer was disrupted; **CryptoLocker**, **Necurs**, and **Murofet/Licat** used date-seeded generators. The 2016 USENIX Security study by Plohmann et al. reverse-engineered dozens of DGA families, showing how varied the seeding and encoding schemes are.
Because DGA lookups create a distinctive burst of **NXDOMAIN** responses (most generated names are unregistered), defences center on DNS telemetry: statistical or machine-learning classifiers on domain character n-grams and entropy, passive-DNS correlation, sinkholing newly observed algorithmic names, and EDR rules that flag processes issuing high-volume failed resolutions.
```mermaid
flowchart TD
S[Shared seed
date + salt] --> A[DGA in malware]
S --> O[DGA run by operator]
A --> L[1000s of candidate
domains per day]
O --> R[Operator registers
a few domains]
L --> Q{DNS lookup}
Q -->|Most fail| N[NXDOMAIN burst]
Q -->|One resolves| C[Connect to C2 server]
N --> D[Detection: NXDOMAIN spike,
n-gram/entropy ML, passive DNS]
C --> E[Receive commands / exfiltrate]
D --> F[Sinkhole / block domain]
```
---
# Denial-of-Service (DoS) Attack
Source: https://www.cyberglossary.org/en/term/dos-attack
Published: 2026-08-04
A denial-of-service attack overwhelms a single target — a server, application, link, or device — from one or a few sources, with the goal of degrading or stopping its service. It differs from DDoS, which marshals many distributed hosts; a plain DoS relies on asymmetry, where a small amount of attacker effort forces a large amount of victim work.
Techniques span the stack. **Volumetric** floods saturate bandwidth. **Protocol abuse** exhausts finite state: a **SYN flood** fills the connection backlog with half-open handshakes, which is why **SYN cookies** were invented. **Slow attacks** exploit patience over volume — **Slowloris** (Robert Hansen, 2009) trickles partial HTTP headers to pin every worker thread on a threaded server like Apache, needing almost no bandwidth. **Application-layer resource exhaustion** turns one request into disproportionate cost: expensive database queries, decompression of a **zip/XML bomb**, or **ReDoS**, where a catastrophically backtracking regular expression on attacker-controlled input consumes CPU for seconds per request. **Algorithmic complexity attacks** such as the 2011 hash-flooding disclosure (28C3) forced worst-case O(n²) behavior in the hash tables of many web frameworks. Classic malformed-packet crashes — **Ping of Death**, **Teardrop**, **LAND** — and local **fork bombs** round out the family.
Defences layer together: rate limiting and connection timeouts, SYN cookies, request-size and time budgets, capacity planning and autoscaling, upstream/anycast filtering, WAF rules, randomized hash seeds, and hardening code against inputs that trigger super-linear work.
```mermaid
flowchart TD
A[Attacker: 1 or few hosts] --> B{Exhaust which resource?}
B -->|Bandwidth| C[Volumetric flood]
B -->|Connection state| D[SYN flood - half-open sockets]
B -->|Worker threads| E[Slowloris - slow partial requests]
B -->|CPU / memory| F[ReDoS, zip bomb,
hash-flooding, costly query]
B -->|Crash bug| G[Ping of Death / Teardrop / LAND]
C --> H[Service unavailable to
legitimate users]
D --> H
E --> H
F --> H
G --> H
H --> I[Defences: rate limiting, SYN cookies,
timeouts, WAF, autoscale, code hardening]
```
---
# Dragonblood
Source: https://www.cyberglossary.org/en/term/dragonblood
Published: 2026-08-04
Dragonblood was disclosed in April 2019 by Mathy Vanhoef (KU Leuven) and Eyal Ronen (Tel Aviv University / KU Leuven), the same researcher behind KRACK. It targets the Simultaneous Authentication of Equals (SAE) handshake — also called Dragonfly — used by WPA3-Personal, which was meant to make Wi-Fi passwords immune to offline dictionary attacks.
The core problem is the "hunt-and-peck" password-element (PWE) derivation. Its number of loop iterations and cache-access pattern depend on the password, so a nearby attacker who forces repeated handshakes can measure timing (**CVE-2019-9494**) or observe cache use (**CVE-2019-9495**) and leak enough information to run an offline password-partitioning attack that recovers the pre-shared key. Related flaws include a reflection/denial-of-service issue and missing state validation in the SAE confirm exchange (**CVE-2019-9496**). Separately, because most access points run **WPA3-Transition mode**, an attacker can spin up a rogue AP that only offers WPA2 and force a downgrade, then capture a classic PMKID for offline cracking — defeating WPA3 entirely.
The Wi-Fi Alliance and hostapd/wpa_supplicant maintainers responded by mandating the constant-time **Hash-to-Element (H2E)** method for PWE derivation, which removes the password-dependent branching. A follow-up study later showed even patched Brainpool-curve implementations could still leak timing, underscoring that side-channel-free crypto is hard. Defences: require H2E, disable transition mode where possible, patch client and AP firmware, and use long high-entropy passphrases.
```mermaid
flowchart TD
A[Attacker near WPA3 network] --> B{Attack path}
B -->|Side-channel| C[Force repeated SAE handshakes]
C --> D[Measure timing / cache of
hunt-and-peck PWE derivation]
D --> E[Offline password-partitioning]
B -->|Downgrade| F[Rogue AP offers WPA2 only]
F --> G[Client falls back
WPA3-Transition mode]
G --> H[Capture PMKID]
E --> I[Recover Wi-Fi passphrase]
H --> I
I --> J[Fix: Hash-to-Element H2E,
disable transition mode, patch firmware]
```
---
# Cellebrite UFED
Source: https://www.cyberglossary.org/en/term/cellebrite
Published: 2026-08-03
Cellebrite is an Israeli digital intelligence company best known for UFED (Universal Forensic Extraction Device) and the analysis suite Physical Analyzer / Inseyets. Its hardware and software let law-enforcement, intelligence services and corporate DFIR teams perform logical, file-system and physical extractions from iOS and Android phones, recover deleted records and parse hundreds of app formats including chat, calls, location and cloud artefacts. Cellebrite supports passcode-unlock workflows (Premium) and produces court-ready reports for chain-of-custody handling.
## How an extraction flows
```mermaid
flowchart LR
A[Seized device] --> B{Access method}
B -->|Logical| C[Backup / API pull]
B -->|File-system| D[Agent or exploit]
B -->|Physical| E[Bootloader / chip-off]
C --> F[UFED extraction]
D --> F
E --> F
F --> G[Physical Analyzer decode]
G --> H[Deleted-record carving]
G --> I[App DB parsing]
H --> J[Court-ready report]
I --> J
```
The tools have drawn scrutiny. In April 2021 Signal's Moxie Marlinspike published *"Exploiting vulnerabilities in Cellebrite,"* showing that UFED and Physical Analyzer had arbitrary-code-execution flaws: a specially crafted file placed on a scanned device could run code on the examiner's Windows machine, potentially tainting past and future evidence. He noted the suite bundled a 2012-era FFmpeg build carrying scores of unpatched vulnerabilities, and shipped Apple-signed DLLs without licence. Cellebrite has also been criticised for sales to authoritarian regimes. Defensively, examiners run extractions on isolated, validated workstations, hash images before analysis, and document tool versions to preserve admissibility.
---
# Censys
Source: https://www.cyberglossary.org/en/term/censys
Published: 2026-08-03
Censys grew out of academic research at the University of Michigan. It builds on **ZMap**, the modular scanner introduced by Zakir Durumeric and colleagues at USENIX Security 2013 that can sweep the entire public IPv4 space in under 45 minutes from a single machine. Censys itself was presented in the 2015 ACM CCS paper *"A Search Engine Backed by Internet-Wide Scanning"* (Durumeric, Adrian, Mirian, Bailey, Halderman). It runs continuous scans across IPv4, IPv6, and Certificate Transparency logs, exposing hosts and certificates as deeply parsed JSON indexed by service, software, JARM/JA3 fingerprints, ASN, and historical state.
## From raw scan to defender query
```mermaid
flowchart LR
A[ZMap probes IPv4/IPv6] --> B[Banner + TLS grab]
B --> C[Protocol parsers]
C --> D[Structured JSON host docs]
E[Certificate Transparency logs] --> D
D --> F[Search index]
F --> G[ASM: my exposed assets]
F --> H[Threat hunt: C2 fingerprints]
F --> I[IR: pivot on shared infra]
```
Defenders use Censys to discover exposed assets, watch for newly opened services, and hunt adversary infrastructure — for example clustering Cobalt Strike or malware C2 servers on shared TLS certificates, default HTTP bodies, or JARM hashes, then pivoting to related IPs. Because every observation is timestamped, incident responders can reconstruct when a service or certificate first appeared. Compared with Shodan, Censys emphasizes deep, schema-driven service parsing and certificate provenance, making it strong for external attack-surface management and infrastructure attribution. Attackers use the same data for reconnaissance, so reducing needless exposure is the core defence.
---
# Credential Access
Source: https://www.cyberglossary.org/en/term/credential-access
Published: 2026-08-03
Credential Access (MITRE ATT&CK tactic **TA0006**) groups techniques adversaries use to obtain credentials they can reuse to authenticate as legitimate users. Its anchor technique is **T1003 OS Credential Dumping**, whose sub-techniques map neatly to where secrets live: T1003.001 (LSASS memory), T1003.002 (SAM registry hive), T1003.003 (NTDS.dit on a domain controller), T1003.004 (LSA secrets), T1003.006 (DCSync via the directory-replication protocol), and T1003.008 (`/etc/shadow` on Linux). Adjacent techniques include kerberoasting and AS-REP roasting, NTLM capture with Responder, browser-credential and cloud-token theft, and MFA phishing or OAuth-consent abuse.
## Where credentials get stolen
```mermaid
flowchart TD
A[Adversary with local admin/SYSTEM] --> B[LSASS memory
T1003.001]
A --> C[SAM hive
T1003.002]
A --> D[NTDS.dit on DC
T1003.003]
A --> E[DCSync replication
T1003.006]
B --> F[Plaintext / NT hashes / tickets]
C --> F
D --> F
E --> F
F --> G[Lateral movement]
F --> H[Privilege escalation]
F --> I[Persistence]
```
Because these techniques abuse legitimate OS features rather than dropping malware, they frequently evade signature-based tools — the 2017 NotPetya and countless ransomware intrusions pivoted on LSASS-dumped credentials to spread. Defenders deploy Windows **Credential Guard** and LSA protection (RunAsPPL), enforce phishing-resistant MFA, adopt a tiered-admin model to stop domain-admin logons on workstations, vault and rotate privileged secrets, disable NTLM where possible, and alert on LSASS handle access, `ntdsutil` use, and anomalous replication (DCSync) requests.
---
# Cryptographic Agility
Source: https://www.cyberglossary.org/en/term/crypto-agility
Published: 2026-08-03
Cryptographic agility, or crypto agility, is the design discipline of building systems so algorithms, key sizes, certificate types, and protocols can be upgraded without rewriting application code or breaking interoperability. It is achieved through algorithm identifiers and negotiation (TLS cipher suites, JOSE `alg` parameters), abstraction layers like PKCS#11 and KMS interfaces, configurable libraries, automated certificate lifecycle (ACME), and a maintained inventory of where cryptography is used — a **cryptographic bill of materials (CBOM)**.
## The agile-swap loop
```mermaid
flowchart LR
A[Crypto inventory / CBOM] --> B[Algorithm behind an interface]
B --> C[Negotiation or config selects algo]
C --> D{Threat or standard change?}
D -->|SHA-1 broken, PQC mandate| E[Update config / rotate keys]
E --> C
D -->|Stable| F[Continue operating]
```
Agility became urgent as SHA-1 (practically broken by the 2017 SHAttered collision), RSA-1024, and 3DES were deprecated, and it is now the prerequisite for the post-quantum migration. In August 2024 NIST finalized **FIPS 203 (ML-KEM)** for key encapsulation, **FIPS 204 (ML-DSA)** and **FIPS 205 (SLH-DSA)** for signatures; the NSA's CNSA 2.0 suite sets timelines pushing many systems to adopt them well before 2035. Because "harvest-now, decrypt-later" adversaries record encrypted traffic today, agile systems roll out hybrid schemes (e.g. X25519 + ML-KEM) through configuration rather than code rewrites. Systems lacking agility — hard-coded algorithms, opaque firmware, expired protocol libraries — face multi-year, high-risk retrofits whenever a primitive falls.
---
# Chain of Custody
Source: https://www.cyberglossary.org/en/term/chain-of-custody
Published: 2026-08-02
Chain of custody (CoC) preserves the integrity and admissibility of digital and physical evidence. Every transfer is logged with timestamps, identifiers (case number, exhibit ID, hash values), and signatures, while items are stored in tamper-evident containers in access-controlled facilities. Best practice aligns with ISO/IEC 27037, NIST SP 800-86, and ACPO/SWGDE guidance: acquire with write blockers, calculate cryptographic hashes (SHA-256) before and after copying, and maintain duplicate working copies.
The discipline is codified in several standards. **RFC 3227** ("Guidelines for Evidence Collection and Archiving," 2002) established the *order of volatility* — capture RAM, caches, and network state before disk and archival media, since the most transient data is lost first. The ISO/IEC 27037/27041/27042/27043 series covers identification, collection, acquisition, preservation, and analysis, while NIST SP 800-86 details the collect-examine-analyze-report cycle. In U.S. courts, evidence must be *authenticated* under **Federal Rule of Evidence 901** and survive the *Daubert* reliability standard; a demonstrable, unbroken custody chain is how a party proves the exhibit shown to the jury is the same one seized and was not tampered with. A broken chain — missing entries, mismatched hashes, unsealed containers, or a gap where an item was unaccounted for — lets opposing counsel move to suppress, and can render otherwise decisive evidence inadmissible, collapsing litigation, insurance claims, or regulatory enquiries. Defences include dual-signed handoffs, hardware write blockers, contemporaneous hashing, and cryptographically time-stamped audit logs.
```mermaid
flowchart LR
A[Seizure / Identification] --> B[Acquisition
write blocker + hash]
B --> C{Hash matches?}
C -- No --> X[Integrity failure
evidence at risk]
C -- Yes --> D[Tamper-evident storage
access-controlled]
D --> E[Analysis on
working copy]
E --> F[Every transfer logged:
who / when / why / signature]
F --> G[Court production
FRE 901 authentication]
G --> H[Final disposition /
return or destruction]
```
---
# CISSP
Source: https://www.cyberglossary.org/en/term/cissp
Published: 2026-08-02
The Certified Information Systems Security Professional (CISSP) is issued by ISC2 and is widely regarded as the benchmark certification for experienced information security practitioners, managers, and architects. The exam covers eight Common Body of Knowledge (CBK) domains: Security and Risk Management, Asset Security, Security Architecture and Engineering, Communication and Network Security, Identity and Access Management, Security Assessment and Testing, Security Operations, and Software Development Security. Candidates take a Computerized Adaptive Test (CAT) of 100 to 150 questions over up to three hours.
The credential is accredited under ANSI/ISO/IEC 17024, and a passing result is a scaled score of **700 out of 1,000** — not a percentage of correct answers. CISSP requires five years of cumulative paid work experience across at least two CBK domains; one year can be waived with an approved four-year degree or credential. Passing candidates must be **endorsed within nine months** by an existing ISC2-certified professional (ISC2 itself can act as endorser). Those who pass but lack the experience become an **Associate of ISC2** while they earn it. The exam's domain weightings were last refreshed on **15 April 2024**. Holders can pursue the ISSAP, ISSEP, and ISSMP concentrations, and the certification satisfies U.S. DoD 8140/8570 baselines (IAT III, IAM II/III, IASAE I/II). Certification is maintained with 120 CPE credits per three-year cycle (minimum 40 per year) plus an annual maintenance fee.
```mermaid
flowchart TD
A[5 years experience
in 2+ CBK domains] --> B{Pass CAT exam
score >= 700/1000}
B -- No --> R[Retake after
waiting period]
B -- Yes, has experience --> C[Endorsement within
9 months by ISC2 member]
B -- Yes, lacks experience --> D[Associate of ISC2
earn experience, then endorse]
C --> E[CISSP granted]
D --> E
E --> F[Maintain: 120 CPE / 3 yrs
+ annual maintenance fee]
E --> G[Optional: ISSAP / ISSEP / ISSMP]
```
---
# Cloud Security
Source: https://www.cyberglossary.org/en/term/cloud-security
Published: 2026-08-02
Cloud security covers the practices used to secure workloads running on infrastructure that an organization does not fully own — typically AWS, Azure, GCP, or SaaS platforms. It spans identity and access management, network segmentation, encryption of data in transit and at rest, configuration hardening, workload protection, and continuous monitoring of cloud APIs and audit logs. Because the cloud is API-driven and elastic, traditional perimeter defences are insufficient; controls must follow the workload and integrate with the provider's native services (IAM, KMS, CloudTrail, Security Hub, Defender for Cloud).
The dividing line of accountability is the **shared responsibility model**: the provider secures the cloud (physical facilities, hypervisor, managed-service backplane) while the customer secures what runs *in* it (data, IAM policies, OS patching, and — crucially — configuration). Most publicized breaches trace to the customer's side. The **2019 Capital One breach** is the canonical example: a misconfigured ModSecurity WAF was abused via server-side request forgery (SSRF) to reach the EC2 instance metadata service at `169.254.169.254`, retrieving the temporary IAM credentials of an over-privileged role that could list and read S3 buckets — exposing roughly **106 million** applicant records. It drove wide adoption of **IMDSv2** (session-token-bound metadata requests), least-privilege IAM, and egress filtering. The **2023 Storm-0558** intrusion, in which a stolen Microsoft signing key let attackers forge tokens for Exchange Online, showed that even provider-side failures can cascade. Mature programs combine CSPM, CWPP, CIEM, and CNAPP tooling with CIS Benchmarks, guardrails as code, and strong governance under the shared responsibility model.
```mermaid
flowchart TD
subgraph P[Provider secures the cloud]
P1[Physical data centers]
P2[Hypervisor / host]
P3[Managed service backplane]
end
subgraph C[Customer secures in the cloud]
C1[Data & encryption keys]
C2[IAM policies & least privilege]
C3[Configuration / hardening]
C4[OS & app patching]
end
C3 -->|misconfig| M[SSRF -> IMDS creds
e.g. Capital One 2019]
M --> B[Data exfiltration]
C2 -->|least privilege + IMDSv2| D[Blast radius contained]
```
---
# Capture the Flag (CTF)
Source: https://www.cyberglossary.org/en/term/ctf-capture-the-flag
Published: 2026-08-02
Capture the Flag (CTF) is a cybersecurity competition format where participants find hidden strings — called flags, typically formatted like `flag{...}` or `CTF{...}` — by solving challenges in categories such as web exploitation, binary exploitation (pwn), reverse engineering, cryptography, forensics, and OSINT. Two main formats dominate: Jeopardy-style, where teams pick standalone tasks worth points, and attack-defense, where each team operates an identical vulnerable service and scores by exploiting opponents while patching their own.
The oldest and most prestigious event is **DEF CON CTF**, run at the Las Vegas conference since DEF CON 4 (1996); teams qualify through a gruelling online round, and the finals use a live attack-defense network where a scorebot plants and harvests flags each round. Organizing duty rotates — the **Order of the Overflow** ran it from 2018 to 2022 and the **Nautilus Institute** has run it since 2023. Global standings are aggregated by **CTFtime.org**, where academic powerhouses like Carnegie Mellon's **Plaid Parliament of Pwning (PPP)** consistently rank at the top. Jeopardy scoreboards often use *dynamic scoring*, where a challenge's point value decays as more teams solve it, rewarding rare breakthroughs. Educational ladders — **picoCTF** (Carnegie Mellon), HackTheBox, TryHackMe, and Google CTF — democratize entry from middle-school to professional level. Beyond sport, CTFs sharpen real skills in exploit development, incident triage, and secure coding, and are a staple of security recruiting pipelines and certification prep.
```mermaid
flowchart TD
A[CTF competition] --> B[Jeopardy-style]
A --> C[Attack-defense]
B --> B1[Web / Pwn / Crypto
Rev / Forensics / OSINT]
B1 --> B2[Solve challenge -> flag{...}]
B2 --> B3[Submit flag
dynamic scoring]
C --> C1[Run identical
vulnerable service]
C1 --> C2[Exploit opponents
+ patch your own]
C2 --> C3[Scorebot plants &
harvests flags per round]
B3 --> D[Ranking on CTFtime.org]
C3 --> D
```
---
# Dropper
Source: https://www.cyberglossary.org/en/term/dropper
Published: 2026-08-01
A dropper is a delivery component that carries one or more embedded payloads inside its own body and writes them to disk or memory once executed. Unlike a downloader, it does not need to contact the internet for the next stage — the malicious code travels with it. Droppers commonly bundle anti-analysis checks, decoy content, persistence setup, and process-injection routines before launching the final malware (info-stealer, ransomware, RAT).
Delivery formats track defender controls. When **Microsoft disabled Office macros by default** for internet-sourced files in 2022, Proofpoint measured VBA/XL4 macro use fall roughly 66%, and crews such as **Qakbot**, IcedID, and Bumblebee pivoted to **ISO/IMG containers and LNK shortcuts**. The trick is a Mark-of-the-Web (MOTW) bypass: the downloaded archive carries the MOTW tag, but files *extracted* from an ISO or IMG do not inherit it, so Windows treats the inner document or LNK as locally trusted. LNK-based campaigns rose over 1,600% after the change. Signed installers and trojanized utilities are also popular dropper vehicles.
```mermaid
flowchart LR
MAIL[Phishing email] --> CONT[ISO / IMG / signed installer]
CONT -->|MOTW bypass
inner file untagged| DROP[Dropper executes]
DROP --> AA[Anti-analysis + decoy]
DROP --> EMB[Embedded payload
written to disk/memory]
EMB --> INJ[Process injection]
INJ --> FINAL[Stealer / Ransomware / RAT]
DEF[Defence] -. sandbox, allow-listing, block ISO mount, EDR .-> DROP
```
Defences include email and web filtering, attachment sandboxing, application allow-listing, EDR with behaviour-based detection, blocking automatic ISO/IMG mounting, and disabling macro auto-execution.
---
# HIPAA
Source: https://www.cyberglossary.org/en/term/hipaa
Published: 2026-08-01
The Health Insurance Portability and Accountability Act of 1996 (HIPAA), implemented through the Privacy, Security, and Breach Notification Rules, sets U.S. national standards for protecting Protected Health Information (PHI). It applies to *covered entities* — health plans, healthcare providers conducting electronic transactions, and healthcare clearinghouses — and to their *business associates* handling PHI on their behalf. The **Security Rule** mandates administrative, physical, and technical safeguards (access controls, audit logs, transmission security, and risk analysis). The 2009 **HITECH Act** strengthened enforcement and, via the Breach Notification Rule, requires notifying affected individuals and HHS — within 60 days for large breaches (500+ individuals).
Enforcement is tangible. The HHS **Office for Civil Rights (OCR)** investigates and imposes tiered civil penalties, and for willful neglect, criminal referral. The record settlement followed the **2015 Anthem breach**: attackers entered through a spearphishing email and exfiltrated 78.8 million records, leading to a **$16 million** OCR settlement in 2018 — nearly triple the previous high of $5.55 million.
```mermaid
flowchart TD
PHI[Protected Health Information] --> CE[Covered entity
provider / plan / clearinghouse]
CE -->|BAA contract| BA[Business associate]
CE --> RULES{HIPAA Rules}
BA --> RULES
RULES --> PR[Privacy Rule]
RULES --> SR[Security Rule
admin/physical/technical safeguards]
RULES --> BN[Breach Notification
≤60 days if 500+]
RULES -->|violation| OCR[HHS OCR enforcement
tiered civil + criminal penalties]
```
Practical controls: encrypt PHI at rest and in transit, enforce least-privilege access with audit logging, run periodic risk analyses, and sign Business Associate Agreements before sharing PHI with vendors.
---
# Initial Access
Source: https://www.cyberglossary.org/en/term/initial-access
Published: 2026-08-01
Initial Access (MITRE ATT&CK tactic **TA0001**) groups the techniques adversaries use to gain their first entry point into a network or system. Its nine techniques include spearphishing attachments and links (T1566), exploitation of public-facing applications (T1190), valid accounts (T1078) purchased from initial access brokers, supply-chain compromise (T1195), drive-by downloads, and abuse of trusted relationships. Initial Access is a critical inflection point: it converts external pressure into in-network presence, after which adversaries pivot to execution, persistence, and discovery.
Real campaigns show how varied the entry can be. In the **MOVEit Transfer** campaign of May–June 2023, the Cl0p group exploited a public-facing web app via SQL injection (**CVE-2023-34362**), auto-scanning the internet and compromising 1,000+ organisations in days, then deploying the LEMURLOOT web shell. **Log4Shell** (CVE-2021-44228) similarly turned exposed services into footholds, while the 2015 **Anthem** breach began with a single spearphishing email to a subsidiary before lateral movement to 78.8 million records.
```mermaid
flowchart LR
ADV[Adversary] --> P[Spearphishing
T1566]
ADV --> E[Exploit public app
T1190]
ADV --> V[Valid accounts
T1078]
ADV --> S[Supply chain
T1195]
P --> FOOT[Foothold in network]
E --> FOOT
V --> FOOT
S --> FOOT
FOOT -->|TA0002+| NEXT[Execution → Persistence → Discovery]
DEF[Defenders] -. MFA, patching, email/web filtering, EDR .-> FOOT
```
Defenders prioritise phishing-resistant MFA, attack-surface reduction, email and web filtering, rapid patching of internet-facing services, and EDR coverage on first-touch endpoints to detect and block these techniques.
---
# Insecure Deserialization
Source: https://www.cyberglossary.org/en/term/insecure-deserialization
Published: 2026-08-01
When an application converts serialized data (Java/PHP/Python/.NET binary formats, YAML, or JSON with type metadata) back into objects, the deserialiser may invoke constructors, magic methods, or *gadget chains* — sequences of already-loaded methods that, strung together, reach a dangerous sink such as `Runtime.exec`. With untrusted input an attacker crafts a payload that triggers this behaviour during deserialisation, yielding remote code execution (RCE), authentication bypass, file write, or denial of service.
The canonical case is **CVE-2015-4852**: Oracle WebLogic unsafely deserialised unauthenticated Java objects sent over the T3 protocol to TCP 7001, and with Apache Commons Collections on the classpath the `ysoserial` tool produced a working RCE gadget. Oracle's first patch used a fragile deny-list of classes rather than blocking untrusted deserialisation outright. Similar flaws hit Apache Struts (CVE-2017-9805, via XStream) and countless PHP `unserialize()` object-injection bugs. In OWASP's list the category moved from A8:2017 into the broader **A08:2021 – Software and Data Integrity Failures**.
```mermaid
flowchart LR
A[Attacker] -->|crafted serialized blob
cookie / T3 / API body| APP[Application]
APP -->|deserialise untrusted bytes| DZ[Deserialiser]
DZ -->|instantiate objects
invoke magic methods| GC[Gadget chain
on classpath]
GC -->|reach dangerous sink| RCE[Runtime.exec / file write]
APP -. defence .-> SIG[Signed payload +
type allow-list]
SIG -.->|reject unknown types| DROP[Drop]
```
Defences: never deserialise untrusted data; prefer schema-bound formats (plain JSON, Protobuf) with no type recovery; sign or HMAC serialized payloads; enforce a strict allow-list of deserialisable types; and keep runtimes patched — modern .NET has obsoleted and removed `BinaryFormatter`.
---
# Cobalt Strike
Source: https://www.cyberglossary.org/en/term/cobalt-strike
Published: 2026-07-31
Cobalt Strike is a commercial threat-emulation tool originally written by Raphael Mudge and now sold by Fortra (formerly HelpSystems). It provides a team server, the Beacon implant, malleable C2 profiles, and tooling for phishing, lateral movement, pivoting, and privilege escalation, letting red teams credibly simulate sophisticated intrusions. Beacon supports asynchronous "sleep" check-ins with configurable jitter and can tunnel over HTTP(S), DNS, or SMB named pipes for peer-to-peer control, while malleable profiles reshape traffic to impersonate legitimate services.
Cracked and leaked copies have been heavily adopted by ransomware affiliates (Conti, LockBit, Ryuk) and nation-state actors; the SolarWinds SUNBURST intrusion (2020) staged a Cobalt Strike loader (Cobalt Strike's Beacon, via the TEARDROP/Raindrop loaders) for follow-on activity. To curb this abuse, Microsoft's DCU, Fortra, and Health-ISAC obtained a court order from the U.S. District Court for the Eastern District of New York on March 31, 2023, and sinkholed more than 200 malicious domains — an effort Fortra says cut unauthorized copies in the wild by roughly 80%. Defenders profile Beacon through EDR memory scanning (e.g. BeaconEye), default named pipes (`\\.\pipe\msagent_*`), JARM/JA3 TLS fingerprints, and YARA rules. Lawful use requires a paid license and engagement authorization.
```mermaid
flowchart LR
A[Operator] --> B[Team Server]
B -->|Malleable C2 profile| C[Beacon payload]
C -->|Phishing / exploit| D[Victim host]
D -->|Sleep + jitter check-in
HTTPS / DNS| B
D -->|SMB named pipe| E[Peer Beacon]
E --> F[Lateral movement
privilege escalation]
F --> G[Objectives:
ransomware / exfil]
```
---
# Metasploit
Source: https://www.cyberglossary.org/en/term/metasploit
Published: 2026-07-31
Metasploit is a modular offensive-security framework originally created by H.D. Moore in 2003 and acquired by Rapid7 in 2009, which now maintains it as an open-source project and a commercial product (Metasploit Pro). It provides a database of public exploits, payloads (including the in-memory Meterpreter agent), encoders, and auxiliary modules that operators chain to validate vulnerabilities, develop proof-of-concept exploits, and conduct authorized penetration tests. The `msfvenom` utility generates standalone payloads, while `msfconsole` drives module selection, option setting, and session handling.
Its module library tracks impactful CVEs quickly: `exploit/windows/smb/ms17_010_eternalblue` is a port of the Equation Group's ETERNALBLUE (MS17-010, CVE-2017-0144) — the SMBv1 flaw leaked by the Shadow Brokers and later weaponized by WannaCry and NotPetya — and the framework added a working module for BlueKeep (CVE-2019-0708) as well. Because Metasploit lowers the bar for weaponizing known vulnerabilities, defenders rely on it for control validation, detection engineering, and purple-team exercises. Blue teams fingerprint its default Meterpreter staging, characteristic TLS certificates, and process-injection behavior. Use without explicit written authorization is illegal in most jurisdictions.
```mermaid
flowchart LR
A[Recon / vuln scan] --> B[msfconsole: select exploit module]
B --> C[Set RHOSTS / options]
C --> D[Choose payload
e.g. Meterpreter]
D --> E[Run exploit]
E -->|Success| F[Session / Meterpreter shell]
F --> G[Post-exploitation modules
privesc, pivot, loot]
E -->|Fail| B
```
---
# Mimikatz
Source: https://www.cyberglossary.org/en/term/mimikatz
Published: 2026-07-31
Mimikatz is a credential-access tool created by Benjamin Delpy (gentilkiwi) to demonstrate fundamental Windows authentication weaknesses, particularly in LSASS memory and the SSPI providers (WDigest, Tspkg, Kerberos, MSV). Its most famous discovery was that the WDigest provider cached logon passwords in cleartext by default until Microsoft shipped KB2871997 and the `UseLogonCredential` registry hardening for Windows 8.1/Server 2012 R2. The `sekurlsa::logonpasswords` command reads secrets directly from LSASS; `lsadump::dcsync` abuses the MS-DRSR replication protocol (DRSUAPI) to pull any account's hash from a domain controller without running code on it (MITRE ATT&CK T1003.006), and `kerberos::golden` forges a krbtgt-signed TGT for near-permanent domain persistence.
Its techniques are woven into major incidents: the 2017 NotPetya wiper bundled a Mimikatz-derived credential harvester that piped stolen secrets to the worm over a named pipe, letting it move laterally to already-patched hosts alongside EternalBlue (CVE-2017-0144). Modern defenses — Credential Guard (VBS-isolated LSASS), LSA Protection (RunAsPPL), tiered administration, and EDR — significantly reduce its impact. Detection engineers watch for suspicious LSASS handle access (Sysmon Event ID 10, T1003.001).
```mermaid
flowchart LR
A[Compromised host
local admin] --> B[LSASS process memory]
B --> C{Mimikatz module}
C -->|sekurlsa::logonpasswords| D[Plaintext / NTLM hashes]
C -->|lsadump::dcsync| E[krbtgt hash via DRSUAPI]
C -->|kerberos::golden| F[Forged Golden Ticket]
D --> G[Pass-the-Hash / lateral movement]
E --> F
F --> H[Domain-wide persistence]
```
---
# WireGuard
Source: https://www.cyberglossary.org/en/term/wireguard
Published: 2026-07-31
WireGuard, created by Jason Donenfeld, is a VPN designed for simplicity and performance, with a codebase orders of magnitude smaller (~4,000 lines) than IPsec or OpenVPN — a small attack surface that makes it far easier to audit. It uses a fixed, non-negotiable cryptographic suite (Curve25519 for key exchange, ChaCha20-Poly1305 for authenticated encryption per RFC 8439, BLAKE2s for hashing, HKDF, and the Noise IK 1-RTT handshake), eliminating the cipher-downgrade and negotiation-complexity flaws that have plagued IPsec/IKE and TLS. Peers are identified by static public keys through a model Donenfeld calls "cryptokey routing," and the handshake provides perfect forward secrecy by rotating ephemeral keys.
The protocol's security was formally verified: Donenfeld and Kevin Milner modeled the handshake in the Tamarin prover, and later work produced a mechanized computational proof in CryptoVerif. WireGuard was mainlined into the Linux kernel in version 5.6 (2020), with userspace and `wireguard-go` ports for other systems. Running over UDP/51820, it stays silent to unsolicited packets, survives IP roaming seamlessly, and underpins mesh overlays such as Tailscale and Netmaker. A design trade-off is that WireGuard keeps peer state and last-known endpoints, so operators layer it with dynamic address management for large fleets.
```mermaid
flowchart LR
A[Peer A
static public key] -->|Noise IK handshake
1-RTT over UDP/51820| B[Peer B
static public key]
B -->|Ephemeral keys derived| C[Curve25519 shared secret]
C --> D[ChaCha20-Poly1305
encrypted tunnel]
D --> E{Cryptokey routing}
E -->|AllowedIPs match| F[Deliver to peer]
E -->|No match| G[Drop packet]
```
---
# Diamond Model of Intrusion Analysis
Source: https://www.cyberglossary.org/en/term/diamond-model
Published: 2026-07-30
The Diamond Model of Intrusion Analysis, introduced by Sergio Caltagirone, Andrew Pendergast, and Christopher Betz in a 2013 paper for the Center for Cyber Intelligence Analysis and Threat Research, represents each malicious event as a diamond connecting four core features: **Adversary**, **Capability** (tooling, malware, TTPs), **Infrastructure** (IPs, domains, C2), and **Victim**. Meta-features such as timestamp, phase, result, direction, methodology, and resources enrich each event.
## Pivoting and analytic use
The model's power is the **pivot**: any known vertex can be used to discover others. From a single malware hash (capability) an analyst can find every victim it touched; from one C2 domain (infrastructure), the registrant email that ties it to other domains; from victimology, the likely adversary intent. Chaining diamonds across the Cyber Kill Chain produces an **activity thread**, and grouping threads that share features yields an **activity group** — the discipline behind vendor clusters such as CrowdStrike's "BEAR"/"PANDA" naming or Microsoft's "typhoon" families.
Because it separates *who* (adversary) from *what* (capability) and *where* (infrastructure), the Diamond Model pairs naturally with **MITRE ATT&CK** (which enumerates the *how*) and structured formats like STIX, letting a SOC express a hypothesis as testable relationships rather than a flat list of IOCs. This is why it anchors pivoting workflows in threat-intelligence platforms and formal intrusion-analysis reports.
```mermaid
flowchart TD
A[Adversary] ---|develops| C[Capability]
A ---|controls| I[Infrastructure]
C ---|deployed via| I
C ---|used against| V[Victim]
I ---|connects to| V
A -.-|targets| V
subgraph Pivots
direction LR
P1[Hash to other victims]
P2[Domain to registrant to more domains]
P3[Victimology to adversary intent]
end
```
---
# Digital Forensics
Source: https://www.cyberglossary.org/en/term/digital-forensics
Published: 2026-07-30
Digital forensics applies investigative techniques to digital artefacts in support of incident response, litigation, internal investigations, and law-enforcement cases. Practitioners follow recognised process models such as **NIST SP 800-86** and **ISO/IEC 27037** to acquire data with integrity, maintain chain of custody, and reconstruct events through timeline and artefact analysis. Sub-disciplines cover disk, memory, network, mobile, and cloud forensics, each with specialised tools (Autopsy, EnCase, FTK, X-Ways, Volatility, Wireshark).
## Principles that make evidence hold up
Acquisition follows the **order of volatility** (RFC 3227): capture CPU registers, RAM, and network state before touching non-volatile disks, because volatile memory is lost at power-off yet often holds encryption keys, injected code, and live connections. Disk images are taken through **hardware write blockers** and verified by matching MD5/SHA-256 hashes of the source and copy — a mismatch means the evidence is tainted. The **ACPO / chain-of-custody** rule is that acquired data must not change; where change is unavoidable (live acquisition), the examiner must be competent and document every action.
Courtroom admissibility rests on reproducibility. The U.S. *Daubert* standard and the FBI-founded **SWGDE** guidelines require methods that other examiners can repeat and peer-review, which is why forensic tools are validated (e.g. NIST's Computer Forensic Tool Testing project) and why analysts log tool versions and hash values in their reports. The same rigour that satisfies a court also underpins sound containment decisions during an incident.
```mermaid
flowchart LR
A[Identify evidence sources] --> B[Preserve: isolate,
order of volatility]
B --> C[Acquire: write-blocker image
+ hash verification]
C --> D[Analyse: timeline,
artefacts, carving]
D --> E[Document: chain of custody,
tool versions, hashes]
E --> F[Report: reproducible,
court-defensible findings]
C -.maintain hash integrity.-> E
```
---
# DKIM
Source: https://www.cyberglossary.org/en/term/dkim
Published: 2026-07-30
DomainKeys Identified Mail (DKIM) is specified in RFC 6376. The sending Mail Transfer Agent computes a hash over selected headers (chosen with the `h=` tag — typically From, Subject, Date) and the body, signs it, and adds a `DKIM-Signature:` header naming the signing domain (`d=`) and selector (`s=`). Receivers fetch the public key from `._domainkey.` (a DNS TXT record) and verify the signature. Because it protects content rather than the transport path, DKIM survives most forwarding, and it provides the cryptographic identifier that DMARC aligns against.
## Real-world failures
Key length is not optional. In 2012 researcher Zachary Harris found Google signing with a factorable **512-bit** RSA key; he cracked it for roughly $75 of cloud compute and mailed a forgery to Larry Page "from" Sergey Brin. eBay, Yahoo, Twitter and Amazon shared the weakness, and Google upgraded to 2048-bit within days. **RFC 8463** (2018) added the compact, fast **Ed25519-SHA256** algorithm, but many mailbox providers still validate only RSA, so operators publish both under separate selectors.
A subtler abuse is the **DKIM replay attack**: because DKIM carries no delivery history, an attacker who obtains one validly signed message from a high-reputation domain can resend it to thousands of victims and the signature still verifies, borrowing the domain's reputation. Defences include oversigning critical headers, avoiding the body-length `l=` tag, setting an expiry with the `x=` tag, and rotating keys regularly (per M3AAWG guidance).
```mermaid
flowchart LR
A[Sender MTA] -->|hash headers+body,
sign with private key| B[Add DKIM-Signature header]
B --> C[Message in transit]
C --> D[Receiver MTA]
D -->|query selector._domainkey TXT| E[(DNS public key)]
E --> D
D -->|recompute hash,
verify signature| F{Valid & unaltered?}
F -->|Yes| G[Pass - feeds DMARC alignment]
F -->|No| H[Fail - DMARC decides fate]
```
---
# DMARC
Source: https://www.cyberglossary.org/en/term/dmarc
Published: 2026-07-30
Domain-based Message Authentication, Reporting and Conformance (DMARC), specified in RFC 7489, builds on SPF (RFC 7208) and DKIM (RFC 6376) by requiring **identifier alignment** between the visible `From:` domain and the domain authenticated by SPF or DKIM. This closes the gap those two protocols leave open: SPF and DKIM each validate a domain, but neither guarantees it is the one the recipient actually sees. Domain owners publish a TXT record at `_dmarc.` carrying a policy (`p=none`, `quarantine`, or `reject`), subdomain handling (`sp=`), alignment mode (`aspf`/`adkim`, relaxed or strict), a rollout percentage (`pct=`), and reporting URIs (`rua`, `ruf`).
## Deployment and enforcement
The safe rollout path is `p=none` first: aggregate XML reports (RFC 7489) reveal every legitimate sender — including forgotten marketing and ticketing platforms — so they can be authenticated before tightening to `quarantine` and then `reject`. Skipping this step blackholes real mail.
DMARC underpins **BIMI** (which shows a verified brand logo only at `p=quarantine`/`reject`) and became a practical mandate when **Google and Yahoo's bulk-sender rules took effect in February 2024**, requiring senders of ~5,000+ messages/day to Gmail to pass aligned SPF or DKIM, publish at least `p=none`, and offer one-click unsubscribe. The **DMARCbis** revision published in 2026 obsoletes RFC 7489, keeping `v=DMARC1` records working while replacing Public Suffix List lookups with a DNS "Tree Walk" to find the organisational domain.
```mermaid
flowchart TD
A[Inbound message] --> B{SPF pass?}
A --> C{DKIM pass?}
B --> D{From aligned
with SPF domain?}
C --> E{From aligned
with DKIM domain?}
D --> F{Either check
passes & aligns?}
E --> F
F -->|Yes| G[DMARC pass - deliver]
F -->|No| H[Apply p= policy]
H --> I[none: monitor]
H --> J[quarantine: spam folder]
H --> K[reject: bounce]
G & H --> L[Send rua aggregate report to domain owner]
```
---
# Hashcat
Source: https://www.cyberglossary.org/en/term/hashcat
Published: 2026-07-29
Hashcat is the most widely used password-recovery tool, written by Jens Steube (atom) and released as open source in 2015. It runs on CPUs and GPUs via OpenCL/CUDA/HIP, supports more than 300 hash modes (NTLM, bcrypt, scrypt, Kerberos AS-REP/TGS, WPA2, KeePass, etc.), and offers wordlist, rule-based, brute-force, mask, hybrid, and association attacks. Penetration testers and red teams use it to crack stolen hashes during engagements, while defenders use it to audit password strength and validate key-derivation-function (KDF) parameters.
The tool is the clearest practical demonstration of *why the choice of hash matters*. On a single RTX 4090, NTLM runs at roughly 288 billion guesses per second, so any 8-character password over that fast, unsalted hash falls almost instantly — the entire NTLM keyspace for short passwords is trivial. Feed the same GPU a bcrypt hash (mode 3200) and throughput collapses to a few thousand per second, dropping further as the cost factor rises (cost 12 is ~128× slower than the cost-5 benchmark). That five-to-six-order-of-magnitude gap is exactly the design goal of deliberately slow, salted KDFs like bcrypt, scrypt, and Argon2. Practical defences follow directly: store credentials with a modern memory-hard KDF and a high work factor, enforce long passphrases, and treat any dump of fast MD5/SHA-1/NTLM hashes as already compromised. Cracking hashes obtained without authorization may violate computer-misuse and privacy laws.
```mermaid
flowchart TD
A[Hash dump] --> B{Hash mode -m}
B --> C[Candidate generator]
C --> D[Wordlist + rules]
C --> E[Mask / brute-force]
C --> F[Hybrid / association]
D --> G[GPU hashing engine]
E --> G
F --> G
G --> H{Match?}
H -- yes --> I[Recovered password]
H -- no --> C
```
---
# Plaintext
Source: https://www.cyberglossary.org/en/term/plaintext
Published: 2026-07-29
Plaintext is the original, human- or machine-readable representation of information before encryption is applied or after it has been correctly decrypted. In cryptographic protocols the term distinguishes data inside the trust boundary from ciphertext that may safely traverse hostile channels. It is also the classic axis of cryptanalysis: a *known-plaintext attack* exploits matched plaintext/ciphertext pairs, while a *chosen-plaintext attack* lets the adversary encrypt inputs of their choosing — the very threat that IND-CPA security and randomized/AEAD modes are designed to defeat.
In applied security, "stored in plaintext" is shorthand for a serious failure. The 2012 LinkedIn breach exposed 6.5 million unsalted SHA-1 password hashes (later revealed to cover ~117 million accounts), and RockYou's 2009 breach leaked 32 million passwords in outright plaintext — both fed the wordlists still used to crack accounts today. Adobe's 2013 breach compounded the problem by encrypting 150+ million passwords with ECB-mode 3DES and a shared key, so identical passwords produced identical ciphertext. Defensive practices: never store credentials as plaintext or reversible ciphertext — use a salted, memory-hard KDF (Argon2, bcrypt, scrypt); encrypt data at rest with strong AEAD ciphers (AES-GCM, ChaCha20-Poly1305); enforce TLS in transit; and redact plaintext secrets from logs, error messages, URLs and referrer headers.
```mermaid
flowchart LR
A[Plaintext
inside trust boundary] -->|encrypt with key| B[Ciphertext]
B -->|hostile channel| C[Ciphertext]
C -->|decrypt with key| D[Plaintext recovered]
A -. leak: logs, plaintext store .-> E[Exposure]
B -. weak cipher / no salt .-> E
```
---
# Threat Intelligence
Source: https://www.cyberglossary.org/en/term/threat-intelligence
Published: 2026-07-29
Threat intelligence is the structured collection, processing, analysis and dissemination of information about adversaries, their motivations, capabilities and infrastructure. It transforms raw data (malware samples, IPs, domains, leaked credentials, dark-web chatter, vulnerability reports) into actionable intelligence by adding context, confidence and a relevant audience. Most programmes run some form of the *intelligence cycle* — direction, collection, processing, analysis, dissemination and feedback — so that output is tied to concrete decisions rather than raw feeds.
A useful prioritisation model is David Bianco's **Pyramid of Pain** (2013): indicators are ranked by how much it hurts an adversary to change them. Hash values and IP addresses sit at the bottom (trivially rotated), then domain names, host and network artifacts, tools, and finally TTPs at the apex — behaviours an actor cannot easily abandon. Detecting at the TTP level (mapped to MITRE ATT&CK) imposes far more cost than blocking a throwaway IP. Organizations exchange intelligence through structured formats and feeds — **STIX/TAXII**, MISP, vendor reporting and sector ISACs — to enrich SIEM and EDR detections, guide patching (e.g. correlating CISA KEV entries with exposed assets) and inform executive risk decisions. Intelligence is typically classified by audience and time horizon into strategic, operational and tactical levels; the discipline's value depends on relevance, timeliness and accuracy, not volume of indicators.
```mermaid
flowchart LR
A[Direction
intel requirements] --> B[Collection
feeds, OSINT, dark web]
B --> C[Processing
normalize, dedupe]
C --> D[Analysis
context, attribution, ATT&CK]
D --> E[Dissemination
STIX/TAXII, TIP, reports]
E --> F[Consumers
SIEM, EDR, IR, execs]
F --> A
```
---
# Wireshark
Source: https://www.cyberglossary.org/en/term/wireshark
Published: 2026-07-29
Wireshark is the leading open-source packet analyzer, originally written by Gerald Combs in 1998 as Ethereal and maintained by a global developer community under the Wireshark Foundation. It captures live traffic from wired, wireless, USB, and other interfaces and decodes thousands of protocols, from Ethernet and TCP/IP to industrial and crypto protocols. Network engineers, blue teamers, malware analysts, and threat hunters use it to diagnose performance issues, validate firewalls, reconstruct attack timelines, and extract files from packet captures (PCAPs).
Under the hood, Wireshark uses libpcap/Npcap to acquire frames and passes each one through a chain of protocol *dissectors*. Because those dissectors parse fully attacker-controlled input, they are a recurring source of vulnerabilities: 2024 alone brought CVE-2024-2955 (T.38 dissector crash, CVSS 7.5), CVE-2024-9780 (ITS dissector), and CVE-2024-9781 (AppleTalk/RELOAD framing), each allowing denial of service via a crafted capture file or injected packet. The practical lesson is to never open untrusted PCAPs on a production host — analyze them with `tshark` in a disposable VM, keep the tool patched, and avoid running as root (Wireshark isolates capture in a separate `dumpcap` process for exactly this reason). Display filters (`http.request`, `tcp.stream eq 3`, `ip.addr == …`) and *Follow TCP Stream* / *Export Objects* turn a raw capture into readable sessions and recovered files. Capturing traffic on networks you do not own or administer can violate wiretap and privacy laws, so authorization is essential.
```mermaid
flowchart LR
A[Network interface] --> B[libpcap / Npcap]
B --> C[dumpcap capture engine]
C --> D[Capture file / live buffer]
D --> E[Dissector chain
Ethernet - IP - TCP - app]
E --> F[Display filter]
F --> G[Packet list and detail view]
G --> H[Follow stream / export objects]
```
---
# Bearer Token
Source: https://www.cyberglossary.org/en/term/bearer-token
Published: 2026-07-28
A bearer token is a credential whose use is authenticated by possession alone: anyone who can present the token at the API gains the access it represents. It is most commonly carried in an HTTP `Authorization: Bearer` header and is defined by **RFC 6750** in the context of OAuth 2.0. Because there is no proof-of-possession, bearer tokens must be transported over TLS, stored carefully, scoped narrowly, and given short lifetimes. Leaked bearer tokens are immediately abusable until revoked or expired.
## Why possession-only credentials keep failing
Two landmark 2023 incidents show the risk. In the **Okta support-system breach** (initial access around 28 September 2023), attackers read customer-uploaded HTTP Archive (HAR) files that still contained live session cookies and tokens, then replayed them to pivot into customers such as **BeyondTrust** (2 October) and **Cloudflare** (18 October). Separately, the **Storm-0558** campaign forged Azure AD/MSA bearer tokens with a stolen Microsoft signing key, silently accessing Exchange Online mailboxes at roughly 25 organizations, including the U.S. State and Commerce Departments. In both cases the token *worked because it was valid* — the whole weakness of bearer semantics.
Stronger designs make a stolen token useless. **Sender-constrained** (proof-of-possession) tokens bind the credential to a key the client must prove it holds on every call: **DPoP (RFC 9449)** at the application layer via a signed JWT header, and **certificate-bound mTLS tokens (RFC 8705)** at the transport layer via `cnf.x5t#S256`. Both are mandated by the FAPI 2.0 profile. Complementary defences include short TTLs with refresh rotation, audience/scope restriction, token binding to device or IP context, and prompt revocation on anomaly.
```mermaid
flowchart TD
C[Client] -->|Authorization: Bearer token| API[Resource server]
API -->|token valid?| API
API -->|yes| G[Grant access]
L[Attacker steals token] -->|replays same token| API
API -.no possession proof.-> G
subgraph Mitigation
D["DPoP / mTLS binds token to client key"] --> R[Stolen token rejected]
end
```
---
# CIEM (Cloud Infrastructure Entitlement Management)
Source: https://www.cyberglossary.org/en/term/ciem
Published: 2026-07-28
Public clouds expose thousands of fine-grained permissions across IAM users, roles, service principals, federated identities, and workload identities. CIEM tools (a category named by Gartner) inventory every *effective* permission, map it against actual usage, and surface excessive entitlements — for example, an IAM role granted `s3:*` but only ever calling `GetObject`. They also detect privilege-escalation paths (`iam:PassRole`, `AssumeRole` chains, policy-version edits), unused identities, and risky cross-account trust relationships.
## Why entitlement sprawl is dangerous
The **Capital One breach (2019)** is the canonical case. Paige Thompson exploited a Server-Side Request Forgery flaw in a misconfigured ModSecurity WAF to reach the EC2 Instance Metadata Service and retrieve the temporary credentials of the WAF's IAM role. Because that role held far more S3 permissions than it needed, the stolen credentials could list and read roughly **106 million** customer records — a textbook failure of least privilege that led to an **$80M OCC fine** and a **$190M** class-action settlement. CIEM exists precisely to find and shrink that kind of over-broad role before an attacker does.
The effective-permission problem is genuinely hard: AWS alone defines thousands of actions, and a principal's real access is the intersection of identity policies, resource policies, permission boundaries, session policies, and SCPs. CIEM computes that graph, then feeds outcomes into automated remediation, scoped roles, just-in-time elevation, and drift alerting. It is a core pillar of **CNAPP**, and most valuable in multi-cloud estates where AWS, Azure, and GCP permission models diverge.
```mermaid
flowchart TD
A[Cloud identities: users, roles, service principals] --> B[CIEM ingests IAM policies + activity logs]
B --> C[Compute effective permissions graph]
C --> D{Excessive or risky?}
D -->|unused / over-broad| E[Right-size to least privilege]
D -->|escalation path| F[Alert: PassRole / AssumeRole chain]
D -->|in use, scoped| G[Keep]
E --> H[Just-in-time elevation]
```
---
# Cipher
Source: https://www.cyberglossary.org/en/term/cipher
Published: 2026-07-28
A cipher is the algorithm that performs encryption and decryption. Modern ciphers fall into symmetric (single shared key, e.g., AES, ChaCha20, 3DES) and asymmetric (public/private key pair, e.g., RSA, ECC) families, and into block ciphers (fixed-size blocks, e.g., AES-128) or stream ciphers (one bit/byte at a time, e.g., ChaCha20). A cipher is typically composed with a mode of operation (CBC, GCM, CTR) plus key-derivation, MAC, or AEAD construction to achieve confidentiality and integrity together.
## From classical to standardized ciphers
Ciphers predate computing — substitution (Caesar), polyalphabetic (Vigenere), and rotor machines (Enigma) were all eventually broken, which is why modern designs are public and peer-reviewed rather than secret (Kerckhoffs's principle). AES was standardized in **FIPS 197 (2001)** after an open NIST competition and remains the default symmetric cipher. Older algorithms have been formally retired: NIST **SP 800-131A Rev. 2** disallowed three-key 3DES for encryption after 31 December 2023, and RC4 was banned in TLS by **RFC 7465** once keystream biases enabled plaintext-recovery attacks. Choosing a strong cipher today means AEAD constructions such as AES-GCM, AES-GCM-SIV (**RFC 8452**), or ChaCha20-Poly1305 (**RFC 8439**) with correct IV/nonce handling — nonce reuse in GCM is catastrophic, leaking the authentication key and enabling forgery. Cipher agility (the ability to swap algorithms without re-architecting) is now a design requirement, driven by the migration toward post-quantum primitives such as ML-KEM.
```mermaid
flowchart LR
P[Plaintext] --> Enc["Cipher + mode (encrypt)"]
K1[Key] --> Enc
Enc --> C[Ciphertext]
C --> Dec["Cipher + mode (decrypt)"]
K2[Key] --> Dec
Dec --> P2[Plaintext]
C -. intercepted .-> A[Attacker sees only ciphertext]
```
---
# Loader
Source: https://www.cyberglossary.org/en/term/loader-malware
Published: 2026-07-28
A loader is a specialized first-stage component whose primary job is to fetch, decode, and execute additional malware in memory, typically through reflective DLL injection, process hollowing, or shellcode. It often profiles the host, disables defences, and establishes persistence before passing control to the next stage. Loaders are central to the modern **malware-as-a-service** economy, where access brokers sell installs to ransomware affiliates and info-stealer operators — the loader is the toll booth between initial access and monetization.
## Real loaders and their takedowns
**QakBot** (Qbot) was the archetype: a banking-trojan-turned-loader that seeded ransomware for Conti, REvil, ProLock, Egregor, and Black Basta. In **August 2023 the FBI-led Operation Duck Hunt** seized 52 servers, redirected the botnet through Bureau-controlled infrastructure, pushed an uninstaller to over **700,000** infected hosts, and tied the operation to roughly **$58M** in ransom fees. Europol's **Operation Endgame (May 2024)** then dismantled a wave of successor loaders — **IcedID, SmokeLoader, Pikabot, SystemBC**, and **Bumblebee** — the largest-ever action against the loader ecosystem. These campaigns confirm the pattern: disrupt the loader layer and you starve downstream ransomware.
Because loaders increasingly run **fileless** — decrypting payloads only in memory and abusing signed LOLBins (rundll32, regsvr32, mshta) — signature scanning alone misses them. Effective defences layer EDR/XDR with behavioural detection of injection (`CreateRemoteThread`, hollowed processes), AMSI-instrumented script inspection, PowerShell Constrained Language Mode, application allow-listing, macro and LNK/ISO delivery controls, and threat intelligence on active loader families.
```mermaid
flowchart LR
A[Initial access: phishing LNK / ISO / macro] --> B[Loader executes]
B --> C[Profile host and disable defences]
C --> D[Establish persistence]
D --> E[Fetch encrypted payload from C2]
E --> F[Decrypt and inject in memory]
F --> G{Next stage}
G --> H[Ransomware]
G --> I[Info-stealer]
G --> J[Cobalt Strike beacon]
```
---
# Dark Web
Source: https://www.cyberglossary.org/en/term/dark-web
Published: 2026-07-27
The Dark Web is the portion of the internet hosted on overlay networks (most prominently Tor's onion services and I2P's eepsites) that cannot be reached with a normal browser and standard DNS. Routing through layered, encrypted relays anonymises both visitors and operators, which is why it is used legitimately by journalists, dissidents, and whistleblowers, but also for cybercriminal marketplaces, ransomware leak sites, stolen-data brokers, and abuse-of-children material. Threat-intelligence teams monitor it to discover stolen credentials, exploit sales, and adversary infrastructure. Defences include continuous dark-web monitoring services, credential leak detection, takedown coordination, and blocking known Tor exit nodes from sensitive perimeters when appropriate.
## How anonymity works — and how it fails
A Tor onion service is reached through a `.onion` address derived from the server's public key; the client and server rendezvous at an introduction point without either side learning the other's IP. Traffic is wrapped in three layers of encryption and bounced through volunteer relays, so no single hop sees both origin and destination. This is genuinely strong — but the humans and software behind it are not. Law enforcement rarely breaks the crypto; instead it exploits operational-security mistakes, server misconfiguration, cryptocurrency tracing, and infiltration.
The takedown record shows the pattern. **Operation Bayonet** (July 2017) seized **AlphaBay** — then the largest darknet market with over 200,000 users — arresting founder Alexandre Cazes, while Dutch police secretly ran the rival market **Hansa** as a honeypot for weeks to deanonymise fleeing users. **Operation Cookie Monster** (April 2023) dismantled **Genesis Market**, which sold "bots" bundling stolen cookies, credentials and browser fingerprints for account takeover. **Operation Cronos** (February 2024) disrupted the **LockBit** ransomware gang, seizing 34 servers, source code and decryption keys across eight countries.
For defenders, the practical takeaway is exposure monitoring: watch leak sites and credential dumps for your organisation's data, enforce MFA and passkeys so stolen passwords are less useful, and feed observed adversary infrastructure into blocklists.
```mermaid
flowchart LR
U[User
Tor Browser] --> G[Guard relay]
G --> M[Middle relay]
M --> R[Rendezvous point]
R --> H[Hidden service
.onion leak site / market]
H -.->|OPSEC error
server misconfig
crypto tracing| LE[Law enforcement
takedown]
```
---
# DAST (Dynamic Application Security Testing)
Source: https://www.cyberglossary.org/en/term/dast
Published: 2026-07-27
DAST tools interact with a deployed application — usually via HTTP — without needing source code. They crawl endpoints, send crafted requests, and observe responses to detect issues such as SQL injection, XSS, SSRF, broken authentication, misconfigured CORS or insecure cookies. Because they see what an attacker would see, DAST complements SAST by catching runtime-only problems, including those arising from configuration, infrastructure or third-party services. DAST is typically run in staging or QA environments and integrated into CI/CD as a release gate. Common tools include OWASP ZAP, Burp Suite, Invicti, Acunetix and StackHawk.
## How it works
A DAST scan runs in two phases. First, a **crawler (spider)** maps the application's attack surface by following links, parsing JavaScript, and replaying recorded traffic to discover forms, parameters and API routes. Second, an **active scanner** mutates each input with attack payloads and infers vulnerabilities from response codes, timing, reflected content or error signatures — for example, a time-based blind SQL injection is confirmed when a `SLEEP()` payload measurably delays the response.
Modern DAST has shifted toward **API-first** and **authenticated** scanning: single-page apps and REST/GraphQL back-ends expose little to a naive crawler, so scanners consume OpenAPI/Swagger specs and use scripted login sequences to reach protected functionality. Coverage is commonly mapped against the OWASP Web Security Testing Guide (WSTG). DAST's limits matter just as much: it produces no line-of-code location, cannot see unreachable code paths, and risks false negatives on complex client-side state — which is why teams pair it with SAST and IAST rather than relying on it alone. To avoid scanning production and triggering real side effects (sending emails, placing orders), scans are gated to non-prod targets and given a defined scope and exclusion list.
```mermaid
flowchart LR
A[Running app
staging/QA] --> B[Crawler / spider
maps endpoints]
B --> C[Active scanner
injects payloads]
C --> D{Anomaly in
response?}
D -->|Yes| E[Report finding
SQLi / XSS / SSRF]
D -->|No| F[Mark endpoint clean]
E --> G[CI/CD gate
fail build / triage]
```
---
# Data Loss Prevention (DLP)
Source: https://www.cyberglossary.org/en/term/data-loss-prevention
Published: 2026-07-27
Data Loss Prevention (DLP) is a control category that inspects content in motion, at rest, and in use, then enforces policies to keep regulated or confidential data inside trusted boundaries. DLP engines combine pattern matching, lexical rules, exact data matching, machine learning, and document fingerprinting to recognize PII, payment data, source code, or intellectual property. Typical enforcement actions include blocking an outbound email, quarantining a file, requiring justification, or redacting content before it leaves the environment. Mature deployments link DLP to data classification, IAM, and SIEM/SOAR so that incidents are triaged, evidence is preserved, and policies are tuned to cut false positives while supporting GDPR, HIPAA, and PCI DSS obligations.
## Channels, detection, and the insider problem
DLP is usually deployed across three enforcement points: **endpoint** agents (blocking USB copy, print, clipboard and screenshot), **network/email** gateways (inspecting SMTP, web uploads and cloud sync), and **cloud/API** connectors that scan data at rest in SaaS and object storage. Detection quality hinges on identifying the right content: regex alone flags too much, so serious programs layer **exact data matching** (hashing rows of a real customer database), **document fingerprinting** for proprietary files, and dictionaries for regulated terms. PCI DSS Requirement 4 and GDPR Article 32 are common drivers, but the most valuable rule is often the least clever — alert when a single user exports thousands of records at once.
The hardest cases are insiders and endpoint egress rather than mass hacks. In 2022 Yahoo sued departing research scientist Qian Sang, alleging he downloaded roughly 570,000 files of the company's **AdLearn** intellectual property to personal devices minutes after receiving a competitor's job offer — exactly the "in-use" exfiltration DLP is meant to catch. Because motivated insiders can photograph a screen or use encrypted channels, DLP works best as one layer of a broader program: least-privilege access, user-activity monitoring (UEBA), and encryption, tuned continuously to keep false positives from training staff to ignore alerts.
```mermaid
flowchart TD
D[Sensitive data
PII / PCI / source code] --> C{DLP inspection}
C -->|Endpoint| E[USB / print / clipboard]
C -->|Network / email| N[SMTP / web upload]
C -->|Cloud / API| S[SaaS / object storage]
E --> P{Policy match?}
N --> P
S --> P
P -->|Yes| B[Block / quarantine / redact
+ alert to SIEM]
P -->|No| A[Allow]
```
---
# Demilitarized Zone (DMZ)
Source: https://www.cyberglossary.org/en/term/demilitarized-zone
Published: 2026-07-27
A DMZ is a perimeter subnet sandwiched between two firewalls (or a multi-legged firewall) where systems that must be reachable from the internet — web servers, mail relays, reverse proxies, VPN concentrators — are placed. The outer firewall lets defined inbound traffic reach the DMZ, while the inner firewall tightly restricts what the DMZ may initiate toward the internal network, ideally only specific application protocols to specific hosts. The architecture limits the blast radius of a compromise: even if an attacker takes over a DMZ host, they still face a strong policy boundary before reaching internal data. Modern designs add zero-trust controls, WAFs, and microsegmentation to harden this boundary further.
## Why the inner firewall matters
The whole value of a DMZ collapses if a perimeter host can freely reach internal systems. The 2017 Equifax breach illustrates the failure mode: attackers exploited an unpatched Apache Struts flaw (CVE-2017-5638) in the internet-facing online **dispute portal**, then moved to internal databases and exfiltrated data on ~147 million people between May and July 2017. A tightly egress-filtered DMZ — where the compromised web app could not open arbitrary connections inward — would have blunted that lateral movement.
Two design rules follow. First, treat the DMZ as **semi-trusted, never trusted**: inbound rules from the internet should be narrow, and *outbound* rules from the DMZ toward the LAN should be even narrower, allowing only the exact protocol, port and destination host each service needs (a web tier reaching one API endpoint, a mail relay reaching one SMTP host). Second, avoid **dual-homed hosts** that straddle both zones, since a single compromised NIC bypasses the firewalls entirely.
Cloud equivalents replace physical firewalls with subnets, security groups and NACLs — a public subnet fronted by a load balancer, a private subnet for application and data tiers — but the principle is identical: constrain what the exposed tier can talk to.
```mermaid
flowchart LR
I[Internet] -->|inbound 443| OF[Outer firewall]
OF --> DMZ[DMZ subnet
web / mail / reverse proxy]
DMZ -->|only defined app protocol| IF[Inner firewall]
IF --> LAN[Internal LAN
databases / AD / users]
DMZ -.->|blocked: arbitrary
inbound to LAN| LAN
```
---
# Browser Sandbox
Source: https://www.cyberglossary.org/en/term/browser-sandbox
Published: 2026-07-26
A browser sandbox is the set of operating-system mechanisms a browser uses to constrain less-trusted child processes — renderers, GPU process, network service — to a minimal set of capabilities. Chromium relies on Windows job objects and integrity levels, macOS Seatbelt, and Linux seccomp-bpf plus user namespaces; Firefox uses comparable primitives. Even if attacker JavaScript triggers memory corruption inside the renderer, the sandbox blocks arbitrary file access, process creation, and syscalls without a *second* bug — a sandbox escape.
This two-bug requirement is visible at Pwn2Own. At the March 2024 event, Manfred Paul's winning Chrome entry used **CVE-2024-2887**, a type-confusion flaw in the V8 WebAssembly engine, to get read/write in the renderer — but that alone stayed trapped inside the process. The same contest surfaced **CVE-2024-2886** (a use-after-free in WebCodecs) and **CVE-2024-3159** (out-of-bounds read in V8). Chrome layers further defence with **Site Isolation**, which puts each site in its own renderer to blunt Spectre-style speculative-execution leaks, and the V8 heap sandbox ("Ubercage") that contains corruption even before the OS sandbox applies.
Defences that strengthen the model: keeping browsers auto-updated, enabling Site Isolation and enhanced sandbox flags, disabling unneeded plugins, and using per-site process limits so a single renderer compromise cannot span origins.
```mermaid
flowchart TD
A[Malicious web page] --> B[Renderer process
untrusted, low privilege]
B --> C{Memory-corruption bug?
e.g. CVE-2024-2887}
C -->|No| D[Attack contained]
C -->|Yes| E[Arbitrary R/W in renderer]
E --> F{V8 heap sandbox
+ OS sandbox}
F -->|No escape bug| G[Still confined:
no files, no syscalls]
F -->|Sandbox-escape bug| H[Broker / kernel reached]
H --> I[Full host code execution]
```
---
# Canary Token
Source: https://www.cyberglossary.org/en/term/canary-token
Published: 2026-07-26
A canary token is a small, embeddable tripwire — a URL, document, DNS hostname, file, executable, or cloud credential — that calls back to a control server the moment it is opened, executed, or used. Because the token has no legitimate role, every callback is, by construction, a high-confidence signal of intrusion, insider activity, or data leakage. Security teams scatter canary tokens across file shares, source code, mailboxes, and SaaS apps to obtain early warning long before a breach reaches noisy detection layers.
The best-known implementation is Thinkst's free **Canarytokens** service (also self-hostable), which has minted tripwire URLs and documents for over a decade and added **AWS API-key tokens in 2017**. A crucial design detail is the *transport*: many tokens fire over **DNS**, so a decoy document opened deep inside a segmented network still alerts when its unique subdomain is resolved — even when the host has no direct HTTP egress. Each alert carries the source IP, user-agent, and timestamp. Operationally, the artifact matters: a decoy AWS key alerts the instant an attacker runs `sts get-caller-identity`, though defenders should know that Thinkst-hosted keys return a caller identity containing a beacon domain — a "tell" sophisticated adversaries may spot, which is one argument for self-hosting.
Deploy tokens uniquely per location so an alert pinpoints exactly which share, repo, or mailbox was touched, and treat any callback as an incident-response trigger.
```mermaid
flowchart LR
A[Defender mints token
URL / doc / AWS key / DNS] --> B[Plant in file share,
repo, mailbox, SaaS]
B --> C[Attacker opens,
runs, or resolves it]
C --> D{Transport}
D -->|HTTP| E[Callback to control server]
D -->|DNS| F[Unique subdomain resolved
works without HTTP egress]
E --> G[Alert: source IP, UA, timestamp]
F --> G
G --> H[High-confidence IoC →
incident response]
```
---
# CIS Controls
Source: https://www.cyberglossary.org/en/term/cis-controls
Published: 2026-07-26
The CIS Controls are a community-developed framework of prioritized cybersecurity safeguards published by the Center for Internet Security (CIS). The lineage runs back to the **SANS Top 20**, later the "Critical Security Controls," before CIS assumed stewardship. The current **version 8.1, released in June 2024**, defines **18 controls** and **153 safeguards**, and — reflecting a deliberate shift toward cloud, mobile, and outsourced environments — organizes them around *activities* rather than device types.
The signature feature is the three **Implementation Groups**. **IG1**, the "essential cyber hygiene" baseline every enterprise should meet, comprises **56 safeguards** drawn from 15 controls; IG2 and IG3 add safeguards for organizations with greater resources and risk. A small business can therefore start with a concrete, achievable IG1 subset instead of an abstract "do security" mandate. Version 8.1 also aligned with **NIST CSF 2.0**, adding coverage for the new **Govern** function and updated asset classes.
Although the CIS Controls carry no legal force, they are widely mapped to NIST CSF, ISO/IEC 27001, PCI DSS, and CMMC, so implementing them once satisfies many overlapping requirements. CIS publishes companion **Benchmarks** — hardening guides for specific operating systems and cloud services — that turn several safeguards into checkable configuration settings.
```mermaid
flowchart TD
A[CIS Controls v8.1
18 controls · 153 safeguards] --> B[IG1: essential cyber hygiene
56 safeguards — all enterprises]
A --> C[IG2: adds safeguards
for higher risk/resources]
A --> D[IG3: full set
mature, high-value targets]
B --> C --> D
A --> E[CIS Benchmarks
OS & cloud hardening]
A --> F[Mapped to NIST CSF 2.0,
ISO 27001, PCI DSS, CMMC]
```
---
# Cosign
Source: https://www.cyberglossary.org/en/term/cosign
Published: 2026-07-26
Cosign is the user-facing tool of the Sigstore stack, created to answer supply-chain attacks — from **SolarWinds** to hijacked npm packages — that target the build and distribution pipeline rather than running systems. It can sign container images, OCI artifacts, blobs, SBOMs, and in-toto attestations, storing signatures alongside the artifact in an OCI registry.
Its defining innovation is **keyless signing**. Instead of asking developers to guard a long-lived private key, Cosign requests a certificate from **Fulcio**, a certificate authority that verifies an **OIDC** identity (a GitHub Actions workflow, a Google or GitHub user) and issues a certificate valid for roughly **ten minutes**. Cosign signs within that window, then discards the ephemeral private key; because certificates are so short-lived, there is no need for revocation lists or OCSP. The signing event is recorded in **Rekor**, an append-only, tamper-evident transparency log, so anyone can later prove what was signed, by which identity, and when.
Verification policies can therefore demand *who* signed rather than *which key* signed — e.g. "only images built by our `release.yml` reusable workflow are admitted." Kubernetes admission controllers such as **Kyverno**, **Connaisseur**, and **OPA Gatekeeper** enforce these checks at deploy time, and Cosign-produced attestations underpin **SLSA** provenance, turning otherwise self-asserted build claims into cryptographically verifiable ones.
```mermaid
flowchart TD
A[CI job builds image] --> B[cosign sign --identity-token OIDC]
B --> C[Fulcio verifies OIDC identity
issues ~10-min certificate]
C --> D[Cosign signs, discards key]
D --> E[Signature + cert logged in Rekor
transparency log]
E --> F[Push image + signature to registry]
F --> G[Admission controller
Kyverno / Connaisseur]
G --> H{Signed by trusted
identity/workflow?}
H -->|Yes| I[Deploy allowed]
H -->|No| J[Blocked]
```
---
# BIMI
Source: https://www.cyberglossary.org/en/term/bimi
Published: 2026-07-25
Brand Indicators for Message Identification (BIMI), defined across IETF drafts (notably draft-ietf-dmarc-bimi) and the AuthIndicators Working Group specifications, allows a domain to publish a TXT record at `default._bimi.example.com` pointing to an **SVG Tiny Portable/Secure (P/S)** logo and, optionally, a certificate. Crucially, BIMI is not itself an authentication check — it is a *reward* layered on top of DMARC. A mailbox provider only renders the logo when the message passes DMARC with alignment **and** the domain enforces a policy of `p=quarantine` or `p=reject`, so BIMI gives organisations a visible incentive to finish DMARC enforcement rather than leaving it at `p=none`.
Two certificate types back the logo. A **Verified Mark Certificate (VMC)**, issued by DigiCert or Entrust, proves the logo is a registered trademark and is the only path that earns Gmail's blue verified checkmark. Gmail began showing BIMI avatars in 2021 (VMC only); the AuthIndicators group added the **Common Mark Certificate (CMC)** in late 2024, which Gmail supports to extend logos to organisations without a registered trademark — but without the checkmark. Apple Mail displays BIMI logos since iOS 16 / iPadOS 16 / macOS Ventura 13, accepting either VMC or CMC. Because a VMC anchors the logo to a trademark and DMARC enforcement, BIMI raises the cost of brand impersonation and business email compromise.
```mermaid
flowchart TD
M[Inbound message] --> A{SPF/DKIM pass and DMARC aligned?}
A -->|no| N[No logo shown]
A -->|yes| E{DMARC policy quarantine or reject?}
E -->|no| N
E -->|yes| B[Fetch BIMI record and SVG logo]
B --> C{VMC or CMC present and valid?}
C -->|VMC| V[Show logo + verified checkmark in Gmail]
C -->|CMC| L[Show logo, no checkmark]
C -->|none| L2[Some clients show logo, others require a cert]
```
---
# ChaCha20
Source: https://www.cyberglossary.org/en/term/chacha20
Published: 2026-07-25
ChaCha20 is a 20-round stream cipher designed by Daniel J. Bernstein in 2008 as a refinement of his Salsa20 design. It produces a keystream from a 256-bit key, a 96-bit nonce, and a 32-bit block counter using only add-rotate-xor (ARX) operations on 32-bit words — a "quarter-round" mixing four state words at a time. Because it needs no lookup tables, it is fast and naturally constant-time on CPUs without AES hardware, which is why Google first deployed it in 2014 to protect Android and Chrome traffic. Combined with the Poly1305 MAC, the AEAD scheme ChaCha20-Poly1305 is standardized in RFC 8439 (which obsoleted RFC 7539) and is one of the two mandatory cipher suites in TLS 1.3, alongside AES-GCM. It also underpins QUIC, WireGuard, OpenSSH, the Signal Protocol, and the Linux kernel RNG.
The critical operational pitfall is **nonce reuse**: encrypting two messages with the same key and nonce exposes the XOR of their plaintexts and reveals the one-time Poly1305 key, breaking both confidentiality and authenticity. The 96-bit nonce is comfortable for a per-connection counter but risky for random generation at scale, so **XChaCha20** (draft-irtf-cfrg-xchacha) extends the nonce to 192 bits via an HChaCha20 subkey derivation, making random nonces safe. After more than a decade of cryptanalysis, no attack breaks the full 20-round cipher.
```mermaid
flowchart LR
K[256-bit key] --> S[Initialize state: constants, key, counter, nonce]
N[96-bit nonce] --> S
CTR[Block counter] --> S
S --> R[20 rounds of ARX quarter-rounds]
R --> KS[Keystream block]
PT[Plaintext] --> X((XOR))
KS --> X
X --> CT[Ciphertext]
CT --> P[Poly1305 MAC]
P --> TAG[Authentication tag]
```
---
# Confidential Computing
Source: https://www.cyberglossary.org/en/term/confidential-computing
Published: 2026-07-25
Confidential computing closes the last gap in data protection: encryption in use. Workloads run inside a TEE — a CPU-enforced enclave whose memory is encrypted and integrity-checked, so neither the hypervisor, the host operating system, nor a privileged cloud administrator can read the plaintext. **Remote attestation** is the linchpin: before sending data or keys, a client verifies a hardware-signed quote describing the exact code measurement and microcode version running inside the enclave. The concept is governed by the **Confidential Computing Consortium**, formed under the Linux Foundation in 2019. Hardware backends include Intel SGX, Intel TDX, AMD SEV-SNP, Arm CCA, AWS Nitro Enclaves, Azure Confidential VMs, and Google Confidential Computing.
TEEs are not a silver bullet, and their history is a reminder that side channels bypass memory encryption. **Foreshadow / L1TF (CVE-2018-3615, 2018)** used speculative execution to read SGX enclave secrets from the L1 cache, defeating attestation until microcode and OS patches shipped. **Plundervolt (CVE-2019-11157, 2019)** did the complement: by dynamically undervolting the CPU it injected faults into SGX-protected computations, corrupting multiplications and RSA/AES operations to leak keys. Robust designs therefore combine confidential computing with least privilege, patched microcode, minimal enclave code, and short-lived attested keys.
```mermaid
flowchart TD
W[Workload deployed into TEE] --> M[CPU measures code and microcode]
M --> Q[Hardware signs attestation quote]
Q --> V{Client verifies quote}
V -->|trusted| REL[Release keys and data to enclave]
V -->|mismatch| DENY[Refuse to provision secrets]
REL --> ENC[Encrypted and integrity-checked enclave memory]
ENC --> P[Process plaintext, invisible to host and operator]
```
---
# CRYSTALS-Kyber
Source: https://www.cyberglossary.org/en/term/crystals-kyber
Published: 2026-07-25
CRYSTALS-Kyber is a key-encapsulation mechanism (KEM) whose security reduces to the Module Learning With Errors (MLWE) problem over structured lattices. NIST selected it as the primary PQC KEM in 2022 and finalized it as FIPS 203 (ML-KEM) in August 2024. The standard defines three parameter sets — ML-KEM-512, ML-KEM-768, and ML-KEM-1024 — targeting NIST security categories 1, 3, and 5, with public keys of roughly 800, 1184, and 1568 bytes and ciphertexts of comparable size.
Internally, an IND-CPA public-key scheme is hardened into an IND-CCA2 KEM using a Fujisaki–Okamoto transform: decapsulation re-encrypts the recovered message and rejects any mismatch, so a tampered ciphertext yields a pseudorandom "implicit reject" key rather than leaking secrets. Because a store-now-decrypt-later adversary could archive today's traffic for a future quantum computer, Kyber is deployed in *hybrid* mode (for example X25519MLKEM768), where an attacker must break both the classical and the post-quantum half.
Implementation security matters as much as the math. The **KyberSlash** disclosure (2024) showed that a secret-dependent integer division by the modulus q = 3329 was variable-time on many CPUs; timing decapsulation of forged ciphertexts could recover key bits. KyberSlash1 and KyberSlash2 were patched in the reference code (December 2023) by replacing divisions with multiplications, and fixes propagated to liboqs, PQClean, CIRCL, AWS-LC, and Botan.
```mermaid
flowchart LR
KG[KeyGen] --> PK[Public key pk]
KG --> SK[Secret key sk]
PK --> ENC[Encapsulate: pick m, derive K and ciphertext c]
ENC --> C[Ciphertext c]
ENC --> KS1[Shared secret K]
C --> DEC[Decapsulate with sk plus FO re-encrypt check]
SK --> DEC
DEC -->|match| KS2[Same shared secret K]
DEC -->|mismatch| REJ[Implicit reject: pseudorandom key]
```
---
# Cryptominer
Source: https://www.cyberglossary.org/en/term/cryptominer
Published: 2026-07-24
A cryptominer uses computing power to solve the proof-of-work puzzles that secure a cryptocurrency, earning block rewards. Legitimate miners are installed by the owner; malicious cryptominers are dropped by malware or injected into web pages and run hidden, stealing electricity and compute — abuse known as **cryptojacking**. Attackers overwhelmingly target **Monero (XMR)** using the open-source **XMRig** miner, because Monero's RandomX algorithm is CPU-friendly and its ring signatures frustrate payment tracing.
Real campaigns show the scale. In February 2018 **RedLock** found that intruders had reached **Tesla's** unauthenticated Kubernetes administration console, obtained AWS credentials, and quietly ran mining pods using evasion techniques — the pool hidden behind CloudFlare and CPU throttled to avoid detection. In October 2019 Palo Alto **Unit 42** documented **Graboid**, the first cryptojacking worm to spread through unsecured Docker daemons, infecting roughly 2,000 hosts and mining Monero in bursts. Families such as **Kinsing** and **WannaMine** (which reused the EternalBlue exploit) show how miners piggyback on exposed cloud services and unpatched hosts.
Indicators include sustained high CPU/GPU load, short-lived child processes, and outbound connections to Stratum mining pools. Because most endpoint tools do not inspect inside containers, cloud and Kubernetes workloads need dedicated monitoring. Defences: remove default-exposed admin consoles, block mining-pool domains and Stratum ports, application allow-listing, and cost/utilisation anomaly alerts that flag unexpected compute growth.
```mermaid
flowchart TD
A[Exposed Docker/K8s API or unpatched host] --> B[Attacker drops XMRig payload]
B --> C[Miner runs hidden with throttled CPU]
C --> D[Connects to Stratum mining pool]
D --> E[Monero XMR sent to attacker wallet]
C --> F[Worm scans for next victim]
F --> A
```
---
# Lucky 13
Source: https://www.cyberglossary.org/en/term/lucky-13
Published: 2026-07-24
Lucky 13 (**CVE-2013-0169**) was disclosed in February 2013 by Nadhem AlFardan and Kenny Paterson of the Information Security Group at Royal Holloway, University of London. It is a timing side-channel refinement of Serge Vaudenay's 2002 padding-oracle attack, targeting every CBC cipher suite in SSL 3.0 and TLS 1.0–1.2 (and DTLS), all of which use MAC-then-encrypt with HMAC.
The name refers to the 13 bytes of TLS header and sequence number that the MAC covers. Because HMAC-SHA1 processes data in 64-byte blocks, the number of compression-function calls — and therefore the verification time — depends on how many padding bytes the record contains. A man-in-the-middle who can inject forged ciphertexts measures these sub-microsecond differences across many trials to learn whether a guessed plaintext produced valid padding, reconstructing bytes one position at a time much like BEAST or POODLE. The original results recovered full plaintext against DTLS and partial bytes against TLS, demonstrated in practice against OpenSSL and GnuTLS.
Constant-time countermeasures — always computing a fixed number of HMAC blocks regardless of padding — shipped in OpenSSL 1.0.1d, GnuTLS, and NSS. The durable fix is to abandon CBC for AEAD suites such as AES-GCM and ChaCha20-Poly1305, which TLS 1.3 mandates exclusively.
```mermaid
flowchart TD
A[MITM injects forged TLS-CBC record] --> B[Server decrypts and strips padding]
B --> C{Padding length}
C -->|more padding| D[Fewer HMAC-SHA1 blocks - faster]
C -->|less padding| E[More HMAC blocks - slower]
D --> F[Attacker times MAC verification]
E --> F
F --> G[Statistics over millions of trials]
G --> H[Padding oracle recovers plaintext byte]
```
---
# Network Segmentation
Source: https://www.cyberglossary.org/en/term/network-segmentation
Published: 2026-07-24
Network segmentation partitions a flat enterprise network into smaller security zones — user, server, OT, payment (PCI-scope), and management VLANs — each with its own access policy enforced by a firewall, router ACL, or SDN/micro-segmentation controller. By limiting east-west traffic and forcing it through inspection points, segmentation contains lateral movement, shrinks the scope of compliance audits, and operationalises least privilege. Access between zones is granted explicitly rather than by default.
The canonical cautionary tale is the 2013 **Target** breach: attackers used credentials stolen from HVAC contractor **Fazio Mechanical Services** to reach an internet-facing vendor portal, then pivoted across a flat network to the point-of-sale environment and exfiltrated roughly 40 million payment-card records. No segmentation isolated the vendor portal from cardholder systems — the control that would have stopped the pivot. **PCI DSS Requirement 1** and its segmentation guidance now make isolation the standard way to keep systems out of audit scope.
In industrial settings the **Purdue Enterprise Reference Architecture** and **IEC 62443** zones-and-conduits model define segmentation between enterprise IT and OT. During the 2021 **Colonial Pipeline** ransomware incident the operator shut down OT as a precaution, unable to be certain the IT compromise had not crossed over. Defences: default-deny inter-zone rules, jump hosts with MFA, and per-zone continuous verification under zero trust (**NIST SP 800-207**).
```mermaid
flowchart LR
I[Internet] --> DMZ[DMZ / vendor portal]
DMZ -->|default-deny FW| U[User VLAN]
DMZ -->|default-deny FW| S[Server VLAN]
S -->|jump host + MFA| P[PCI cardholder zone]
S -->|one-way conduit| OT[OT / SCADA zone]
X[Compromised vendor account] -.blocked by segmentation.-> P
```
---
# Fault Injection
Source: https://www.cyberglossary.org/en/term/fault-injection
Published: 2026-07-23
Fault injection deliberately pushes a system outside its operating envelope — through voltage glitches, clock manipulation, electromagnetic pulses (EMFI), or a focused laser on a decapsulated die — so that a single instruction is skipped or a memory bit flips at a chosen moment. The attacker turns that controlled error into a security failure: bypassing a decision (skipping a PIN check or secure-boot signature verification) or corrupting a cryptographic computation. In **differential fault analysis**, first described by Boneh, DeMillo and Lipton in 1997 against RSA-CRT, comparing a correct signature with a faulted one reveals the private key; the same idea breaks AES in a handful of faulted encryptions.
Faulting is no longer purely physical. **CLKSCREW** (2017) and **VoltJockey** abused a CPU's own power-management registers to glitch ARM TrustZone from software, and Intel's **Plundervolt** (CVE-2019-11157, 2019) undervolted the core from ring 0 to corrupt SGX enclave computations until Intel disabled the interface via microcode. Hardware-wallet research at *wallet.fail* (35C3, 2018) glitched Trezor and Ledger devices to reach stored secrets. Rowhammer shows even ordinary memory access can induce faults.
Countermeasures include redundant or randomised computation, fault-detection sensors, voltage and clock monitors, error-correcting memory, and defensive code that double-checks every security branch.
```mermaid
flowchart TD
A[Attacker with device access] --> B{Fault vector}
B -->|Voltage / undervolt| C[VCC drop or spike]
B -->|Clock glitch| D[Overclock pulse]
B -->|EMFI / laser| E[Localized pulse on die]
C --> F[Instruction skip or bit flip]
D --> F
E --> F
F --> G{Exploited effect}
G -->|Skip check| H[Bypass PIN / secure boot]
G -->|Corrupt crypto| I[Fault analysis leaks key]
H --> J[System compromised]
I --> J
```
---
# Hardware Token
Source: https://www.cyberglossary.org/en/term/hardware-token
Published: 2026-07-23
A hardware token is a tamper-resistant physical device that generates or holds credentials used to prove identity. Examples include FIDO2 security keys (YubiKey, Google Titan, SoloKey), OATH TOTP/HOTP fobs, PIV/CAC smartcards, and chip-based EMV payment cards. They are stronger than passwords or app-based TOTP because the private key never leaves the secure element, and modern **FIDO2/WebAuthn** keys cryptographically bind each assertion to the site origin — so a credential phished on a look-alike domain is simply unusable, which is why FIDO2 is the reference for "phishing-resistant MFA."
Hardware does not make a token infallible. The 2011 breach of **RSA** exposed SecurID seed records, enabling downstream intrusions at defense contractors. The **ROCA** flaw (CVE-2017-15361) in Infineon's RSA key generation weakened keys on YubiKey 4 and many smartcards. Most recently, **EUCLEAK** (CVE-2024-45678, NinjaLab 2024) recovered ECDSA keys from YubiKey 5 devices with firmware below 5.7.0 via an electromagnetic side channel in the Infineon library — though the attack needs physical access and device disassembly. Practical risk is dominated by loss, theft and supply-chain tampering, so enrollment, attestation, inventory and prompt revocation matter as much as the cryptography.
```mermaid
flowchart TD
U[User at login] --> S[Server sends challenge]
S --> T[Hardware token]
T --> P{User presence + PIN/biometric}
P -->|verified| K[Sign challenge with origin-bound private key]
K --> V[Server verifies with public key]
V --> A[Access granted]
P -->|failed| D[Denied]
```
---
# Secure Software Development Lifecycle (SSDLC)
Source: https://www.cyberglossary.org/en/term/secure-sdlc
Published: 2026-07-23
An SSDLC formalizes *when* and *how* security work happens during software delivery rather than treating it as a one-off audit. Typical phases include security requirements, threat modeling, secure architecture review, secure-coding standards, code review, SAST, SCA, DAST/IAST, penetration testing, release gates and runtime monitoring. The economic case is well established: a defect caught in design costs a fraction of one found after release, so shifting security left reduces both risk and remediation cost, while compliance evidence is produced as a by-product of normal engineering.
The reference frameworks are **Microsoft SDL** (the original industrial model after the 2002 Trustworthy Computing memo), **OWASP SAMM** and **BSIMM** for maturity measurement, and **NIST SP 800-218**, the Secure Software Development Framework (SSDF v1.1, 2022). The SSDF matters beyond best practice: it was published in response to **Executive Order 14028** (May 2021), itself a reaction to the 2020 **SolarWinds** build-system compromise, in which attackers injected the SUNBURST backdoor into a signed Orion update. Under OMB M-22-18, vendors selling to US federal agencies must now attest that they follow SSDF practices — making a documented SSDLC a procurement requirement, not just a quality goal. Securing the build and release pipeline (provenance, signing, SBOMs) is now as important as securing the code itself.
```mermaid
flowchart LR
A[Requirements: security reqs] --> B[Design: threat modeling]
B --> C[Code: secure coding + SAST/SCA]
C --> D[Test: DAST/IAST + pentest]
D --> E[Release: gates + signing + SBOM]
E --> F[Operate: monitoring + patching]
F -->|Feedback / new risks| A
```
---
# Stealth Malware
Source: https://www.cyberglossary.org/en/term/stealth-malware
Published: 2026-07-23
Stealth malware bundles many evasion techniques so that it is invisible to users, security tools and forensic investigators at once: hooking system APIs to hide files and processes, intercepting integrity checks, sandbox and VM detection, anti-debugging, packing and obfuscation, living-off-the-land binaries, timestomping (MITRE ATT&CK T1070.006) and clearing logs after operation. The deeper the code sits, the harder it is to see. **TDL-4/TDSS** infected the Master Boot Record to load before Windows and hide its own files, while **LoJax** (ESET, 2018) — attributed to APT28/Sednit — was the first UEFI rootkit found in the wild, surviving OS reinstallation and even disk replacement by living in SPI flash. **Stuxnet** signed its kernel driver with stolen Realtek and JMicron certificates so it looked legitimate.
Because prevention is imperfect, detection assumes compromise. EDR with kernel-level and memory visibility, off-host tamper-evident logging, network traffic analysis, and threat hunting on TTPs (mapped to MITRE ATT&CK) surface behaviour that files alone hide. Hardening — UEFI Secure Boot, signed/HVCI-enforced drivers, least privilege, and reducing attacker dwell time through proactive hunting — shrinks where stealth malware can live.
```mermaid
flowchart TD
A[Malware executes] --> B{Environment check}
B -->|Sandbox / VM / debugger| C[Stay dormant or self-delete]
B -->|Real target| D[Establish persistence]
D --> E[Hide: API hooking, rootkit, UEFI/MBR]
E --> F[Evade: unhook EDR, obfuscate, LOLBins]
F --> G[Operate: C2, collection]
G --> H[Anti-forensics: timestomp, clear logs]
H --> I[Low-and-slow dwell]
```
---
# iframe sandbox
Source: https://www.cyberglossary.org/en/term/iframe-sandbox
Published: 2026-07-22
The `sandbox` attribute on an `