Technical Countermeasures to Social Engineering experimental

Technical Countermeasures to Social Engineering Bayesian filtering, email authentication, allowlisting, AI-based detection and the commercial anti-phishing stack. Prerequisite: MIRROR. Foundations of Technical Anti-Phishing: The Detection Problem. Frames technical countermeasures as a signal-detection problem with an irreducible false-positive and false-negative trade-off, setting the evaluation vocabulary (precision, recall, base rate) the rest of the course reuses.. Explain precision, recall and base rate in the context of phishing detection, and why a high base rate of legitimate mail makes even a low false-positive rate operationally significant.. Compute precision and recall for a given confusion matrix drawn from a simulated mail stream.. Detection as signal processing, not certainty, Base rate neglect and why 99 per cent accuracy can still fail operationally, The layered-defence principle, Where MIRROR ends and VECTOR begins Module 0: Foundations of Technical Anti-Phishing: The Detection Problem Learning outcomes By the end of this module you will be able to explain precision, recall and base rate in the context of phishing detection, and why a high base rate of legitimate mail makes even a low false-positive rate operationally significant. You will also be able to compute precision and recall for a given confusion matrix drawn from a simulated mail stream. 1. Detection as signal processing, not certainty Every technical countermeasure taught in this course, statistical, rule-based, or based on artificial intelligence (AI), makes a probabilistic determination, not a certain one. No filter achieves perfect separation between scam traffic and legitimate traffic, because the two categories are not cleanly separable in feature space: a legitimate but urgent internal email about a real wire transfer can resemble a business email compromise (BEC) pretext in every superficial respect, and a well-crafted scam email can resemble routine correspondence in every respect except intent, which no automated system can observe directly. This module's task is to give you the vocabulary to reason precisely about that trade-off rather than treating filter failures, in either direction, as simple bugs to be patched away. 2. Base rate neglect and why 99 per cent accuracy can still fail operationally Consider an organisation receiving one million legitimate emails and one thousand phishing emails per day, a realistic ratio for a mid-sized company. A filter with a 99 per cent true-negative rate, meaning it correctly lets through 99 per cent of legitimate mail, will still incorrectly flag roughly ten thousand legitimate messages as phishing every single day, an unusable volume of false alarms even though 99 per cent sounds, and is, mathematically excellent. This arithmetic, worked through fully in this module's lab, is a direct illustration of base rate neglect, the well documented cognitive tendency to ignore how the underlying frequency of a category affects the practical meaning of an accuracy figure, and it is the single most important reason this course insists on stating detection performance in terms of precision and recall rather than a single headline accuracy percentage. Precision is the proportion of flagged messages that are genuinely phishing; recall is the proportion of genuinely phishing messages that were successfully flagged. A filter can have very high recall (catching almost every real phishing email) while still having unacceptably low precision (also flagging a large number of legitimate emails), and the two figures must always be read together. 3. The layered-defence principle Because no single layer achieves both perfect precision and perfect recall, this course does not present Modules 1 through 5 as competing alternatives to be chosen between, but as complementary layers in a single defence-in-depth stack, following the same layering logic used throughout network security more broadly. Bayesian filtering (Module 1) catches content-based patterns; email authentication (Module 2) catches sender-identity spoofing that content analysis alone cannot see; RegEx and allowlist rules (Module 3) catch known structural patterns cheaply and transparently; AI-based classifiers (Module 4) catch novel patterns that rule-based systems miss; and the commercial platforms surveyed in Module 5 typically combine several of these layers already. A message that evades one layer is still exposed to the next. 4. Where MIRROR ends and VECTOR begins This course is the direct technical companion to MIRROR, Scams and Social Engineering. Each subsequent VECTOR module answers a specific MIRROR case study technically: Module 6 (voice-channel detection) answers MIRROR Module 9 (the 2026 voice channel); Module 7 (MFA fatigue and help-desk detection engineering) answers MIRROR Module 8 (the Uber and MGM Resorts incidents); and Module 8 (metrics and governance) answers MIRROR Module 10 and Module 11 (the analytical framework and board-facing training) by giving the board-level exposure statement a technical grounding. A learner who has completed MIRROR will recognise every case referenced in this course; a learner who has not is strongly encouraged to complete it first, per this course's prerequisite. Related CCI capabilities Cambridge Cyber International's Measurable Cyber Assurance concept, whose mantra is "computed, not opined," is the platform-level expression of this module's core argument: detection performance, like assurance more broadly, should be stated in defensible, repeatable metrics rather than a single unqualified accuracy claim (Cambridge Cyber International 2026). References Cambridge Cyber International (2026). Measurable Cyber Assurance. https://www.cambridgecyberinternational.com/en/platform/ Fawcett, T. (2006). An introduction to ROC analysis. Pattern Recognition Letters, 27(8), 861 to 874. https://doi.org/10.1016/j.patrec.2005.10.010 National Institute of Standards and Technology (2023). NIST Phish Scale User Guide, NIST Technical Note 2276. https://csrc.nist.gov/pubs/tn/2276/final Bayesian Filtering: From "A Plan for Spam" to Modern Classifiers. Teaches naive Bayesian text classification from first principles, using Paul Graham's foundational 2002 and 2003 essays as the historical and mathematical entry point, before showing how the same core idea generalises into modern statistical and neural classifiers.. Explain the naive Bayes assumption and how token-level spam probabilities combine into a message-level score.. Compute a message's spam probability by hand from a small supplied token-probability table.. Paul Graham's "A Plan for Spam" (2002), "Better Bayesian Filtering" (2003) and the refinements that followed, Worked arithmetic: from token probabilities to a message score, From Bayes to modern classifiers Module 1: Bayesian Filtering: From "A Plan for Spam" to Modern Classifiers Learning outcomes By the end of this module you will be able to explain the naive Bayes assumption and how token-level spam probabilities combine into a message-level score. You will also be able to compute a message's spam probability by hand from a small supplied token-probability table. 1. Paul Graham's "A Plan for Spam" (2002) In August 2002, the programmer and essayist Paul Graham published "A Plan for Spam," proposing that individual words, or tokens, could be scored by how strongly their prior appearance in a training corpus was associated with spam versus legitimate email, and that these per-token scores could be combined into a single message-level probability using Bayes' theorem (Graham 2002). This was, at the time, a significant departure from the rule-based filtering that dominated spam defence, because it required no hand-written rules at all, only a labelled corpus of prior messages the filter could learn from directly, an approach this course treats as the historical and conceptual foundation for every statistical and artificial intelligence (AI) based classifier covered later. 2. "Better Bayesian Filtering" (2003) and the refinements that followed Graham's 2003 follow-up essay, "Better Bayesian Filtering," refined the original proposal in two significant ways: it biased the combination formula to require stronger evidence before classifying a message as spam, explicitly trading some recall for improved precision on the reasoning that a legitimate email wrongly discarded is typically more costly to a user than a spam email that slips through, and it introduced scoring based on pairs of adjacent words rather than single words alone, capturing some of the context single-word scoring misses (Graham 2003). Open-source mail filtering projects operationalised these ideas at scale within a few years of publication, and the same false-positive-averse design philosophy remains standard practice in commercial filtering products today. 3. Worked arithmetic: from token probabilities to a message score Consider a simplified five-token message where each token has an independently computed spam probability from a training corpus: 0.9, 0.85, 0.95, 0.6, and 0.8. Under the naive independence assumption, these probabilities combine multiplicatively (in their odds form) rather than simply averaging, so that several moderately spam-associated tokens appearing together push the combined score toward certainty far faster than any single token would alone. This course's lab walks through the full combination arithmetic step by step using Graham's original formula, and the resulting message-level score, in this worked example, exceeds 0.99, illustrating exactly the phenomenon that makes Bayesian filtering effective: no single word needs to be damning on its own if enough moderately suspicious words appear together. 4. From Bayes to modern classifiers The naive Bayes classifier's core logic, learn per-feature associations from labelled training data, then combine them into a single prediction, is not superseded by modern machine learning so much as extended by it. Gradient-boosted decision trees relax the naive independence assumption by learning interactions between features directly. Transformer-based large language model (LLM) classifiers go further still, learning contextual representations of entire passages of text rather than scoring isolated tokens or token pairs. Module 4 of this course develops this lineage in full, but it is worth stating plainly here: a learner who genuinely understands the arithmetic in this module's lab has understood the conceptual core of every classifier discussed for the remainder of the course. Related CCI capabilities Cambridge Cyber International's GCIDB 1834 dataset supplies anonymised historical message corpora, spanning several distinct scam campaigns, that this module's lab uses to build its worked token-probability table from genuine rather than synthetic data (Cambridge Cyber International 2026). References Cambridge Cyber International (2026). GCIDB 1834: Cyber incidents did not start with the internet. https://www.cambridgecyberinternational.com/en/products/gcidb-1834/ Graham, P. (2002). A Plan for Spam. https://www.paulgraham.com/spam.html Graham, P. (2003). Better Bayesian Filtering. https://www.paulgraham.com/better.html Email Authentication: SPF, DKIM, DMARC and Why Spoofing Still Works. Teaches the three email authentication standards, Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting and Conformance (DMARC), and why look-alike domains and compromised legitimate accounts continue to defeat all three.. Explain what SPF, DKIM and DMARC each verify, and how DMARC uses SPF and DKIM results to set an enforcement policy.. Diagnose, from a supplied set of email headers, which of the three checks failed and why a message nonetheless reached an inbox.. SPF: authorising sending infrastructure, DKIM: cryptographically signing message content, DMARC: turning two checks into an enforceable policy, Why spoofing still works: look-alikes and compromised accounts Module 2: Email Authentication: SPF, DKIM, DMARC and Why Spoofing Still Works Learning outcomes By the end of this module you will be able to explain what SPF, DKIM and DMARC each verify, and how DMARC uses SPF and DKIM results to set an enforcement policy. You will also be able to diagnose, from a supplied set of email headers, which of the three checks failed and why a message nonetheless reached an inbox. 1. SPF: authorising sending infrastructure Sender Policy Framework (SPF), standardised in Internet Engineering Task Force (IETF) RFC 7208, lets a domain owner publish, as a Domain Name System (DNS) text record, the list of mail servers authorised to send email claiming to be from that domain (Internet Engineering Task Force 2014). A receiving mail server checks the connecting server's network address against this published list; a mismatch is an SPF failure. SPF is checked against the technical envelope sender, not necessarily the address a human reader sees, which is the first of several subtleties that make SPF alone insufficient. 2. DKIM: cryptographically signing message content DomainKeys Identified Mail (DKIM), standardised in RFC 6376, has the sending domain cryptographically sign selected message headers and, typically, the message body, using a private key, with the corresponding public key published in DNS for any receiver to verify (Internet Engineering Task Force 2011). A valid DKIM signature confirms both that the signing domain authorised the message and that the signed content was not altered after signing, providing an integrity guarantee SPF does not. 3. DMARC: turning two checks into an enforceable policy Domain-based Message Authentication, Reporting and Conformance (DMARC), standardised in RFC 7489, does not introduce a new verification mechanism; it requires that a message pass either SPF or DKIM and, critically, that the passing identifier be aligned with the domain visible in the message's From header, the address a human reader actually sees (Internet Engineering Task Force 2015). A domain owner publishes a DMARC policy instructing receivers what to do with messages that fail this alignment check, none (report only), quarantine (typically route to a spam folder), or reject (refuse delivery outright), and receives aggregate failure reports that make it possible to move from none toward reject with confidence rather than guesswork. 4. Why spoofing still works: look-alikes and compromised accounts None of these three standards addresses the two failure modes that dominate real-world spoofing losses. First, a look-alike domain, one character added, removed, or substituted with a visually similar character from a different alphabet, can publish entirely valid SPF, DKIM and DMARC records of its own; the standards check consistency within a claimed domain, not similarity to a different, legitimate domain, which is precisely why the business email compromise (BEC) cases examined in MIRROR Module 6 so often used look-alike supplier or executive domains rather than attempting to spoof the real domain directly. Second, a message sent from a genuinely compromised legitimate account, the attacker having obtained real credentials rather than forging anything, passes all three checks perfectly, because nothing about the message is technically inauthentic; only its content and intent are malicious, which authentication protocols, by design, do not evaluate at all. This is exactly the gap Modules 1, 3 and 4 exist to close. Related CCI capabilities Cambridge Cyber International's CySSURANCE Framework Modules, part of the CySSURANCE platform, include configuration and evidence templates for demonstrating email authentication controls to auditors and regulators, directly relevant to an organisation formalising the DMARC rollout this module describes (Cambridge Cyber International 2026). References Cambridge Cyber International (2026). CySSURANCE Framework Modules. https://www.cambridgecyberinternational.com/en/platform/ Internet Engineering Task Force (2011). RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. https://www.rfc-editor.org/rfc/rfc6376 Internet Engineering Task Force (2014). RFC 7208: Sender Policy Framework (SPF). https://datatracker.ietf.org/doc/html/rfc7208 Internet Engineering Task Force (2015). RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://datatracker.ietf.org/doc/html/rfc7489 Allowlisting, Denylisting and RegEx-Based Content Filtering. Teaches rule-based filtering, allowlists, denylists, and regular expression (RegEx) content matching, as the oldest and still most transparent layer of the anti-phishing stack, and is explicit about their brittleness against novel wording and encoding tricks.. Describe how allowlisting, denylisting and RegEx content rules each work, and identify a scenario where each is the appropriate tool.. Write a RegEx pattern to detect a specified look-alike domain pattern and test it against a supplied set of true and false examples.. Allowlisting: default deny for senders, Denylisting: blocking known-bad indicators, RegEx content filtering: pattern matching on structure, Brittleness: why rule-based filtering alone is not enough Module 3: Allowlisting, Denylisting and RegEx-Based Content Filtering Learning outcomes By the end of this module you will be able to describe how allowlisting, denylisting and regular expression (RegEx) content rules each work, and identify a scenario where each is the appropriate tool. You will also be able to write a RegEx pattern to detect a specified look-alike domain pattern and test it against a supplied set of true and false examples. 1. Allowlisting: default deny for senders An allowlist inverts the usual default for mail delivery: rather than accepting mail from anyone not already known to be malicious, it accepts mail only from senders or domains explicitly pre-approved. This is the most restrictive of the three approaches covered in this module, and it is appropriate exactly where that restriction is affordable: a dedicated inbox that only ever needs to receive payment instructions from a small, known set of business partners, for instance, the exact channel targeted in the business email compromise (BEC) cases examined in MIRROR Module 6. Allowlisting is unworkable for general-purpose corporate mail, where legitimate new correspondents arrive constantly and a default-deny posture would block ordinary business activity. 2. Denylisting: blocking known-bad indicators A denylist takes the opposite, and far more common, approach: mail is accepted by default, and specific senders, domains, or network addresses already associated with abuse are blocked. Denylisting is reactive by construction; a domain must be observed behaving maliciously, or reported as such by a threat intelligence feed, before it can be added, which means a denylist can never catch a genuinely first-seen attack using previously unused infrastructure. Its value lies in blocking repeat abuse cheaply and in benefiting from shared threat intelligence across many organisations simultaneously, since a domain denylisted after abusing one organisation is immediately blocked everywhere else the same denylist feed is consumed. 3. RegEx content filtering: pattern matching on structure A regular expression, or RegEx, is a formal pattern language for matching structure within text, not a full list of specific known-bad strings. A RegEx rule can match "a domain name resembling a known company name but with one character substituted" or "a message mentioning both a specific currency amount above a threshold and the phrase 'change of bank details'" without needing to have seen that exact domain or exact wording before, giving RegEx rules meaningfully more generalisation than a plain denylist while remaining fully human-readable and auditable, a property covered fully in Friedl's standard reference on the subject (Friedl 2006). 4. Brittleness: why rule-based filtering alone is not enough All three techniques in this module share a common weakness: they operate on the literal, surface form of a message, which makes them systematically vulnerable to attackers who deliberately alter that surface form while preserving intent. A homoglyph attack substitutes a visually near-identical character from a different alphabet, for example a Cyrillic character that renders identically to a Latin letter, defeating an exact-match RegEx pattern while looking unchanged to a human reader. A zero-width character, invisible when rendered, can be inserted inside a word to break a pattern match without changing what a human sees at all. Simple paraphrasing defeats phrase-based rules entirely, since a RegEx rule matching "change of bank details" will not match "please update our payment information," despite both meaning the same thing. This is precisely why the MITRE ATT&CK knowledge base treats phishing (technique T1566) as an evolving, actively evaded technique rather than a solved detection problem, and why this course, from Module 0 onward, insists that rule-based filtering is one layer among several rather than a complete solution on its own. Related CCI capabilities Cambridge Cyber International's NetDiagramer product, whose mantra is "documentation that is never out of date," is a useful adjacent capability for maintaining an accurate, current inventory of exactly which mail flows an allowlist policy needs to cover, since an allowlist that has drifted out of sync with an organisation's actual correspondents becomes either too restrictive or silently ineffective (Cambridge Cyber International 2026). References Cambridge Cyber International (2026). NetDiagramer. https://www.cambridgecyberinternational.com/en/products/netdiagramer/ Friedl, J.E.F. (2006). Mastering Regular Expressions, 3rd edition. O'Reilly Media. https://www.oreilly.com/library/view/mastering-regular-expressions/0596528124/ MITRE ATT&CK (2026). Phishing, Technique T1566. https://attack.mitre.org/techniques/T1566/ AI-Based Detection: Classifiers, Deepfake Voice Detection and Adversarial Evasion. Extends Module 1's Bayesian foundation into modern machine-learning and large language model (LLM) based text classifiers and audio-based deepfake voice detectors, and treats adversarial evasion as an expected, ongoing arms race rather than a solved problem.. Describe how a modern text classifier and an audio deepfake detector each make their determination, and name one documented evasion technique for each.. Evaluate a vendor's published detection accuracy claim for missing information (test set composition, base rate, adversarial robustness) and list what would be needed to assess it credibly.. From Bayes to gradient boosting to transformers, Deepfake voice detection, Adversarial evasion as an arms race, Reading a vendor accuracy claim critically Module 4: AI-Based Detection: Classifiers, Deepfake Voice Detection and Adversarial Evasion Learning outcomes By the end of this module you will be able to describe how a modern text classifier and an audio deepfake detector each make their determination, and name one documented evasion technique for each. You will also be able to evaluate a vendor's published detection accuracy claim for missing information and list what would be needed to assess it credibly. 1. From Bayes to gradient boosting to transformers Module 1 traced Bayesian filtering's core logic: learn feature-to-class associations from labelled data, then combine them into a prediction. Gradient-boosted decision tree classifiers extend this by learning non-linear interactions between features directly, rather than assuming, as naive Bayes does, that each feature contributes independently. Transformer-based large language model (LLM) classifiers extend it further still, learning contextual representations of entire passages of text, so that the same word can contribute differently to a classification depending on its surrounding context, a capability neither Bayesian nor gradient-boosted approaches have. All three, despite very different mathematics, share the same underlying supervised-learning logic: a labelled training corpus, a scoring function, and a decision threshold, which is why this course presents them as points on a single continuum rather than as unrelated techniques. 2. Deepfake voice detection Audio deepfake detection addresses a distinct problem from text classification: given a recorded or live voice sample, determine whether it was generated by a real human speaker or synthesised, or manipulated, by a voice-cloning system of the kind discussed in MIRROR Module 9. Rather than attempting to verify a speaker's identity directly, which would require a trusted enrolled voiceprint that is rarely available for an arbitrary incoming call, most deepfake detectors instead look for artefacts of the synthesis process itself: subtle spectral inconsistencies inaudible to most human listeners, unnaturally uniform prosody (the rhythm and intonation of speech), and the absence of the genuine background acoustic noise a real phone call or room recording would ordinarily contain. 3. Adversarial evasion as an arms race Ian Goodfellow, Jonathon Shlens, and Christian Szegedy's foundational 2015 paper on adversarial examples demonstrated that machine learning classifiers, across domains, can be fooled by inputs deliberately, and often only very slightly, perturbed to cross a decision boundary while remaining unchanged or nearly unchanged to a human observer (Goodfellow, Shlens and Szegedy 2015). Both text-based phishing classifiers and audio deepfake detectors face active adversarial evasion in exactly this sense: attackers test their scam content or synthesised voice against known or assumed detector behaviour and adjust it until it passes, a dynamic documented in the European Union Agency for Cybersecurity's threat landscape reporting as an ongoing, worsening trend rather than an occasional edge case (European Union Agency for Cybersecurity 2025). This module treats the arms race framing as permanent: any single detector's real-world accuracy should be expected to degrade over time as attackers adapt, which has direct operational implications for how often a deployed classifier needs to be retrained and re-evaluated. 4. Reading a vendor accuracy claim critically Given this arms race dynamic, this module's competency outcome asks you to interrogate, rather than accept at face value, any vendor's published detection accuracy figure. Three questions matter most. What was the test set's base rate, and does it match the real-world ratio of malicious to legitimate traffic the product will actually face, given Module 0's demonstration of how much base rate affects a headline figure's practical meaning? Was the test set adversarially perturbed, or does it consist only of previously seen, unmodified attack samples that a determined attacker would never actually submit unmodified? And is the figure independently reproducible, published in a peer-reviewed or third-party evaluated venue, rather than appearing only in the vendor's own marketing material? A vendor unable or unwilling to answer these three questions has not necessarily built a bad product, but has not yet given a technical buyer the information needed to assess it. Related CCI capabilities Cambridge Cyber International's VOLTAIC INTELLIGENCE dataset tracks documented adversarial evasion campaigns against detection systems, giving learners access to real, rather than hypothetical, examples of the arms race dynamic this module describes (Cambridge Cyber International 2026). References Cambridge Cyber International (2026). VOLTAIC INTELLIGENCE. https://www.cambridgecyberinternational.com/en/products/voltaic-intelligence/ European Union Agency for Cybersecurity (2025). ENISA Threat Landscape 2025: Social Engineering. https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025 Goodfellow, I., Shlens, J. and Szegedy, C. (2015). Explaining and Harnessing Adversarial Examples. International Conference on Learning Representations. https://arxiv.org/abs/1412.6572 Commercial Security Awareness and Filtering Platforms. Surveys the methodology, not merely the marketing, of commercial security awareness and email-filtering platforms including KnowBe4, Mailinblack and Proofpoint, comparing their published approaches on the same evaluation criteria introduced in Module 0.. Describe the core methodology (simulated phishing, content filtering, reporting workflow) each named platform publishes about its own approach.. Compare two platforms' published methodologies against the Module 0 evaluation vocabulary and identify at least one open question that would need direct vendor engagement to answer.. Security awareness training platforms: KnowBe4 as a category example, Managed email filtering: Mailinblack as a category example, Integrated threat protection: Proofpoint as a category example, Comparing methodologies without vendor benchmarking claims Module 5: Commercial Security Awareness and Filtering Platforms Learning outcomes By the end of this module you will be able to describe the core methodology each named platform publishes about its own approach: simulated phishing, content filtering, and reporting workflow. You will also be able to compare two platforms' published methodologies against the Module 0 evaluation vocabulary and identify at least one open question that would need direct vendor engagement to answer. 1. Security awareness training platforms: KnowBe4 as a category example KnowBe4 is one of the best known vendors in the simulated-phishing-plus-training category: employees across an organisation periodically receive realistic but harmless simulated phishing emails, and anyone who clicks a link or opens an attachment within the simulation is automatically routed to short, targeted training addressing the specific pretext they fell for, rather than a generic annual module (KnowBe4 2026). Organisation-wide metrics, click rate, reporting rate, and their trend over time, are tracked so a security team can demonstrate whether awareness is genuinely improving, directly operationalising the non-punitive metrics MIRROR Module 2 argues for, rather than a shaming leaderboard. 2. Managed email filtering: Mailinblack as a category example Mailinblack represents a different category: a managed email filtering service rather than a simulation-and-training product, in which inbound mail is screened using a combination of the technical layers this course covers individually in Modules 1 through 4, with a human-reviewed quarantine workflow for borderline messages and end-user reporting integration so that a flagged false positive can be released quickly (Mailinblack 2026). Being offered as a managed service rather than a self-hosted appliance shifts the operational burden of keeping detection rules current onto the vendor, a meaningful consideration for an organisation without dedicated detection-engineering staff of its own. 3. Integrated threat protection: Proofpoint as a category example Proofpoint and similarly positioned vendors offer integrated platforms combining inbound filtering, authentication policy enforcement of the kind taught in Module 2, and, distinctively, post-delivery threat detection: the capability to identify a message as malicious only after it has already been delivered to a user's inbox, typically because new threat intelligence became available after delivery, and automatically retract or quarantine it from within the mailbox. This capability addresses a real gap left by the pre-delivery layers covered in Modules 1 through 4, none of which can act on information that only becomes available after a message has already been let through. 4. Comparing methodologies without vendor benchmarking claims This module is deliberately structured to compare published architecture and methodology rather than to rank the three named platforms, or others, on head-to-head performance. Independently verified, apples-to-apples benchmark data across commercial anti-phishing vendors is rarely publicly available, and any benchmark a vendor publishes about its own product carries an inherent conflict of interest that this course is not in a position to resolve. What this module teaches instead is a set of questions worth raising directly with any vendor in this category, grounded in the evaluation vocabulary from Module 0: what test set and base rate underlie any published accuracy claim, how does the product's approach map onto the individual technical layers taught in this course, and what residual gaps does the vendor itself acknowledge. Related CCI capabilities Cambridge Cyber International's Multi-Framework Audit and Assessment service, whose mantra is "test once, satisfy many," is a relevant capability for an organisation that wants an independent assessment of how a chosen vendor platform's controls map onto multiple regulatory frameworks simultaneously, rather than evaluating the vendor's marketing claims unassisted (Cambridge Cyber International 2026). References Cambridge Cyber International (2026). Multi-Framework Audit and Assessment. https://www.cambridgecyberinternational.com/en/services/ KnowBe4 (2026). Security Awareness Training methodology overview. https://www.knowbe4.com/products/security-awareness-training Mailinblack (2026). Email security and phishing protection overview. https://www.mailinblack.com/en/ Detecting the Voice Channel: Robocall and Predictive-Dialer Signatures. Builds the technical detection counterpart to MIRROR Module 9, teaching call-pattern signatures (short-duration silent connects, high call volume from a single originating number in a short window, sequential number dialing) that distinguish predictive-dialer and AI cold-calling abuse from ordinary call traffic.. Describe at least three call-detail-record signatures associated with predictive dialer and AI cold-calling abuse.. Analyse a supplied call-detail-record sample and flag the calls most likely to originate from an abusive predictive dialer or AI cold-calling platform, with justification.. Call detail records as a data source, The silent-connect signature, Volume and sequential-dialing signatures, Limits of call-pattern detection against AI cold-calling Module 6: Detecting the Voice Channel: Robocall and Predictive-Dialer Signatures Learning outcomes By the end of this module you will be able to describe at least three call-detail-record signatures associated with predictive dialer and AI cold-calling abuse. You will also be able to analyse a supplied call-detail-record sample and flag the calls most likely to originate from an abusive predictive dialer or AI cold-calling platform, with justification. 1. Call detail records as a data source A call detail record (CDR) is the standard log entry a telecommunications carrier or an enterprise phone system generates for every call: the originating number, the destination number, the connection timestamp, the disconnection timestamp, and the resulting duration, among other fields. Unlike email, where content is directly available for the analysis techniques in Modules 1 through 4, voice-channel detection at scale typically relies heavily on metadata, the call detail record itself, rather than on transcribed or analysed audio content, because transcription and content analysis at telephone-network call volumes remains comparatively expensive and slower to act on than metadata pattern matching. 2. The silent-connect signature MIRROR Module 9 introduced the observation, drawn from Bitdefender's consumer security research, that a call which connects and then disconnects almost immediately, with no voice ever heard, is very often not a wrong number but a predictive dialer confirming that a line is live before deciding whether an agent is available to take it (Bitdefender 2026). This module formalises that observation into a detectable rule: a connection duration under roughly one to two seconds, with no subsequent callback within a short window, is a candidate signature for predictive dialer overflow, distinguishable in bulk call detail record analysis from the normal duration distribution of organic human calls, which rarely cluster so tightly near zero. 3. Volume and sequential-dialing signatures A second class of signature looks across calls rather than within a single call. Retell AI's explainer on predictive dialing describes the underlying mechanism: a predictive dialer places more outbound calls simultaneously than it has agents available, on a statistical expectation about answer rates, which necessarily produces a high volume of outbound calls from a single originating number within a short time window (Retell AI 2026). When the destination numbers dialed in such a burst are sequential or near-sequential, incrementing through a range rather than reflecting genuine, individually selected targets, this is a strong additional signature of automated, rather than organic human, dialing behaviour, since no legitimate individual caller places calls this way. 4. Limits of call-pattern detection against AI cold-calling The signatures above were developed against legacy predictive dialer behaviour and remain effective against it, but a well-configured, modern conversational artificial intelligence (AI) cold-calling platform of the kind Synthflow's 2026 overview describes can, in principle, be deliberately tuned to avoid both signatures, pacing its outbound calls to resemble an individual human agent's calling cadence rather than a bulk dialer's (Synthflow 2026). This module is explicit that call-pattern detection alone, exactly like every other layer in this course, is necessary but not sufficient, and that it must be paired with the caller-identity verification procedures MIRROR Module 8 and this course's Module 7 both design, so that even a call that evades pattern-based detection still faces a human process it cannot socially engineer past on the first attempt. Related CCI capabilities Cambridge Cyber International's VOLTAIC INTELLIGENCE dataset extends its adversary-infrastructure tracking to telephony abuse patterns, a natural data source for an organisation building the call-detail-record analysis this module teaches into an ongoing monitoring programme rather than a one-off exercise (Cambridge Cyber International 2026). References Bitdefender (2026). Got a Silent Call From an Unknown Number? It's Not Random, It's a Scam. Bitdefender Hot for Security blog. https://www.bitdefender.com/en-us/blog/hotforsecurity/silent-call-unknown-number-its-a-scam Cambridge Cyber International (2026). VOLTAIC INTELLIGENCE. https://www.cambridgecyberinternational.com/en/products/voltaic-intelligence/ Retell AI (2026). What Is Predictive Dialing and Does It Still Work in 2026? https://www.retellai.com/blog/what-is-predictive-dialing Synthflow (2026). AI Cold Calling: What It Is and How It Works in 2026. https://synthflow.ai/blog/ai-in-cold-calling Detection Engineering for MFA Fatigue and Help-Desk Vishing. Builds the technical detection counterpart to MIRROR Module 8, teaching push-notification rate limiting, number-matching multi-factor authentication (MFA), and help-desk reset-request anomaly detection.. Describe at least two technical controls that reduce MFA fatigue susceptibility and one anomaly-detection approach for help-desk reset requests.. Configure, in a simulated identity provider console, rate limiting and number-matching MFA settings that would have prevented the Module Uber-style scenario supplied in the lab.. Push-notification rate limiting, Number matching as an MFA hardening measure, Anomaly detection for help-desk reset requests, Where technical controls end and procedure must take over Module 7: Detection Engineering for MFA Fatigue and Help-Desk Vishing Learning outcomes By the end of this module you will be able to describe at least two technical controls that reduce multi-factor authentication (MFA) fatigue susceptibility and one anomaly-detection approach for help-desk reset requests. You will also be able to configure, in a simulated identity provider console, rate limiting and number-matching MFA settings that would have prevented the Uber-style scenario supplied in the lab. 1. Push-notification rate limiting Multi-factor authentication (MFA) fatigue, examined as a case study in MIRROR Module 8, exploits a simple property of push-based second-factor approval: an unlimited number of prompts can be sent, and each is a single tap to accept. The direct technical countermeasure is rate limiting: capping the number of push prompts a given account can receive within a defined window (for example five prompts within ten minutes) and, once that cap is reached, requiring an explicit cool-down period or forcing a fallback to a different, higher-friction verification method rather than continuing to allow pushes indefinitely. 2. Number matching as an MFA hardening measure A second, complementary control changes the approval action itself rather than its frequency. Number matching, now supported by major identity providers and documented in Microsoft's own guidance for Microsoft Authenticator, requires the user to read a number displayed on the login screen and type that same number into their authenticator application, rather than simply tapping an accept button (Microsoft 2025). This single change removes the exact failure mode that made the 2022 Uber breach possible: a fatigued or distracted user can no longer accidentally approve a login they did not initiate with a single reflexive tap, because approval now requires actively reading and transcribing a value that only the legitimate login attempt would display correctly. 3. Anomaly detection for help-desk reset requests Push-notification hardening addresses the multi-factor authentication (MFA) fatigue vector specifically, but the MGM Resorts and Caesars Entertainment cases from MIRROR Module 8 bypassed MFA fatigue entirely by going directly to a help-desk agent. The technical detection counterpart here is anomaly detection over reset-request metadata: flagging a request for a password or MFA reset that arrives outside standard working hours, that targets an account with elevated administrative privilege, or that follows in close succession after a failed login attempt or a burst of MFA push notifications, as a candidate for additional scrutiny before the reset is processed, rather than as a routine ticket to be closed as quickly as possible. 4. Where technical controls end and procedure must take over This module is explicit about a limit on what technical controls alone can achieve. Rate limiting and number matching reduce the multi-factor authentication (MFA) fatigue attack surface substantially, and anomaly detection surfaces suspicious reset requests for review, but none of these technical measures can, by itself, stop a sufficiently patient, well-prepared attacker from eventually reaching a human help-desk agent and presenting a convincing pretext, because a help desk exists precisely to grant legitimate exceptions to automated process when a human judges the request reasonable. This is exactly why MIRROR Module 8 designs a procedural control, manager attestation plus callback verification, as a companion to, not a replacement for, the technical controls in this module; the two courses are built to be deployed together rather than as alternatives. Related CCI capabilities Cambridge Cyber International's CySSURANCE platform, whose mantra is "model it, compute it, govern it," provides the natural home for codifying the rate-limiting, number-matching, and anomaly-detection thresholds this module teaches as governed, auditable configuration rather than settings that vary informally by administrator (Cambridge Cyber International 2026). References Bleeping Computer (2022). Uber links breach to Lapsus$ group, blames contractor for hack. https://www.bleepingcomputer.com/news/security/uber-links-breach-to-lapsus-group-blames-contractor-for-hack/ Cambridge Cyber International (2026). CySSURANCE. https://www.cambridgecyberinternational.com/en/platform/ Microsoft (2025). How number matching works for Microsoft Authenticator multifactor authentication notifications. https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match Metrics and Governance: Proving the Countermeasure Stack Works. Closes the technical arc by connecting Modules 1 through 7's individual controls to board-level governance, using Cambridge Cyber International's Cyber Value at Risk (cVaR) and DORA-MAST capabilities to state the countermeasure stack's effectiveness in terms a board and a regulator both accept.. Explain why per-layer detection metrics (precision, recall) are insufficient on their own for board reporting, and what additional framing is needed.. Draft a one-page governance brief translating this course's technical metrics into a cVaR-style exposure statement for a named organisation.. Why precision and recall do not speak to a board, From layer metrics to a single exposure statement, Regulatory framing: DORA-MAST and continuous assurance, Closing the loop back to MIRROR Module 8: Metrics and Governance: Proving the Countermeasure Stack Works Learning outcomes By the end of this module you will be able to explain why per-layer detection metrics such as precision and recall are insufficient on their own for board reporting, and what additional framing is needed. You will also be able to draft a one-page governance brief translating this course's technical metrics into a Cyber Value at Risk (cVaR) style exposure statement for a named organisation. 1. Why precision and recall do not speak to a board Modules 0 through 7 gave you a rich, technically precise vocabulary: precision, recall, base rate, alignment failure, adversarial evasion, call-detail-record signature. None of these terms, stated on their own, gives a board of directors or an audit committee a basis for a resourcing decision, not because boards are uninterested in technical detail, but because a board's decisions are denominated in currency, timeline, and regulatory obligation, not in classifier statistics. This module's task is translation: taking the genuine technical work of the preceding modules and restating its implications in the terms a board already uses for every other risk on its agenda. 2. From layer metrics to a single exposure statement The translation method taught here mirrors the outcome-quantification stage MIRROR Module 10 introduced for scam analysis generally: estimate the residual risk left uncovered after each technical layer (Modules 1 through 7) has done what it can, then combine these residual estimates into a single statement of remaining exposure, denominated in the same currency terms used throughout the two-course sequence. A residual exposure statement of this kind says, in effect, "even with our current detection stack in place, a scam of this type succeeding would plausibly cost this organisation this much," which is a fundamentally different, and fundamentally more actionable, statement than "our filter has 94 per cent precision." 3. Regulatory framing: DORA-MAST and continuous assurance For organisations in regulated sectors, particularly financial services falling under the European Union's Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, the translation task has an additional dimension: regulators increasingly expect continuous, evidence-based demonstration of operational resilience rather than a point-in-time attestation produced once a year (European Parliament and Council of the European Union 2022). Cambridge Cyber International's DORA-MAST product, whose mantra is "prove resilience, do not assert it," is built around exactly this continuous-evidence model, and this module shows concretely how the detection-layer metrics from Modules 1 through 7 can feed into that evidence base as ongoing operational data rather than a one-off compliance exercise. 4. Closing the loop back to MIRROR It would be a mistake to read this module as a final, bolted-on chapter about paperwork. Governance, properly understood, is the mechanism that keeps Modules 0 through 7 funded, staffed, and current in the first place; a detection-engineering programme that cannot demonstrate its value in terms a board accepts will not survive its next budget cycle regardless of its underlying technical quality. This closes the loop directly back to MIRROR Module 11's design of a CEO- and board-facing training session: the governance brief this module teaches you to write is precisely the artefact a security leader would bring into that session, giving the human-factors and technical halves of this two-course sequence a genuinely shared endpoint. Related CCI capabilities Cambridge Cyber International's Cyber Value at Risk (cVaR) and DORA-MAST products together supply the direct methodology and, for regulated entities, the direct regulatory framing this module's governance brief is built on, and are the recommended next stop for a learner responsible for taking this course's output into an actual board or regulatory conversation (Cambridge Cyber International 2026). References Cambridge Cyber International (2026). Cyber Value at Risk (cVaR). https://www.cambridgecyberinternational.com/en/products/cvar/ Cambridge Cyber International (2026). DORA-MAST. https://www.cambridgecyberinternational.com/en/products/dora-mast/ European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 (Digital Operational Resilience Act). https://eur-lex.europa.eu/eli/reg/2022/2554/oj Lab Capstone: Building a Layered Anti-Scam Detection Pipeline. Integrates Modules 0 through 8 into a single capstone design exercise: specify a layered detection pipeline, covering email and voice channels, for a named organisation profile, and defend the design's coverage and residual gaps.. Synthesise the individual layers taught in Modules 1 through 7 into one coherent, ordered pipeline design, explaining what each layer catches that the others do not.. Design a complete layered detection pipeline for a named organisation profile, including at least one email-channel and one voice-channel layer, and defend the design's residual gaps using Module 8's governance framing.. Why a capstone, not a ninth new technique, Ordering the pipeline: pre-delivery, in-transit and post-delivery, Documenting residual gaps honestly, From pipeline design to governance brief Module 9: Lab Capstone: Building a Layered Anti-Scam Detection Pipeline Learning outcomes By the end of this module you will be able to synthesise the individual layers taught in Modules 1 through 7 into one coherent, ordered pipeline design, explaining what each layer catches that the others do not. You will also be able to design a complete layered detection pipeline for a named organisation profile, including at least one email-channel and one voice-channel layer, and defend the design's residual gaps using Module 8's governance framing. 1. Why a capstone, not a ninth new technique Every module from 1 through 8 introduced something new: a technique, a standard, or a governance framing. This closing module deliberately introduces nothing new of that kind. Its purpose is integration, a distinct competency from understanding any single layer in isolation, because a working security programme is never one technique deployed alone; it is a specific, deliberately ordered combination of techniques, chosen and sequenced for a specific organisation's mail volume, risk tolerance, and regulatory obligations, and building that combination well is a skill this course has been building toward across every preceding module. 2. Ordering the pipeline: pre-delivery, in-transit and post-delivery This module supplies a worked reference pipeline as a starting point, not a mandatory template. Authentication checks (Module 2) run first, as a cheap, low-latency check that requires no content analysis at all. Content-based filtering, Bayesian scoring (Module 1), rule-based matching (Module 3), and artificial intelligence (AI) based classification (Module 4), runs next, in roughly that order of increasing computational cost, so that cheaper checks can resolve the easy cases before more expensive checks are invoked. Post-delivery detection, drawn from the integrated platforms surveyed in Module 5, runs continuously in the background, able to retract a message that later intelligence reveals to be malicious. The voice-channel layer (Module 6) and help-desk hardening (Module 7) run in parallel to this email-focused sequence, addressing an entirely separate channel with its own pipeline, rather than being inserted into the same linear order. 3. Documenting residual gaps honestly No combination of the layers taught in this course achieves complete coverage, and this module requires the capstone design to say so explicitly rather than imply otherwise. A concrete worked example: a well-resourced attacker who registers a freshly created look-alike domain, evading denylist and reputation-based checks that depend on prior observation, and who additionally uses a deliberately paced, human-cadence artificial intelligence (AI) cold-calling platform, evading the volume and sequential-dialing signatures taught in Module 6, could evade several layers of a well-built pipeline simultaneously. Naming this kind of gap explicitly, rather than presenting a pipeline diagram that implies invulnerability, is itself part of the competency this capstone assesses. 4. From pipeline design to governance brief The capstone closes, deliberately, by requiring its own documented residual gaps to be carried directly into a short governance statement using Module 8's Cyber Value at Risk (cVaR) style framing: what would this specific residual gap cost this specific organisation if exploited, stated in the same currency and regulatory terms a board already uses. This is where the two-course sequence, MIRROR and VECTOR together, actually ends: not with a claim of complete protection, but with a named, quantified, honestly reported set of gaps that becomes the starting point for the organisation's next resourcing conversation, precisely the conversation MIRROR Module 11 taught you how to have with a chief executive officer or a board in the first place. Related CCI capabilities Cambridge Cyber International's Cyber Value at Risk (cVaR) concept closes this course exactly as it closes MIRROR: as the shared vocabulary that lets a technical residual-gap analysis and a board-level resourcing conversation be conducted as a single, continuous discussion rather than two disconnected ones (Cambridge Cyber International 2026). References Cambridge Cyber International (2026). Cyber Value at Risk (cVaR). https://www.cambridgecyberinternational.com/en/products/cvar/ MITRE ATT&CK (2026). Phishing, Technique T1566. https://attack.mitre.org/techniques/T1566/ National Institute of Standards and Technology (2023). NIST Phish Scale User Guide, NIST Technical Note 2276. https://csrc.nist.gov/pubs/tn/2276/final