CEH M09-03 | Vishing, Smishing, and Impersonation
Module 09: Social Engineering | Beginner lesson | About 12–15 minutes
The central idea of this lesson: attackers do not always need to break into your computer. If they make you believe they are someone trustworthy, they may persuade you to carry out an unsafe action yourself.
Also, receiving two messages that appear to confirm each other does not establish two independent, trustworthy sources.
Using the fictional Northstar Learning Center, we will work through these questions:
- 1. How do attackers combine text messages, phone calls, and false identities?
- 2. Why can a genuine login code become useful to an attacker?
- 3. Why is independent verification more reliable than trying to recognize a fake voice?
- 4. How can security staff connect concepts from other CEH units to analyze, prevent, and investigate the attack?
1. Start with the whole picture: four different dimensions of phishing
The previous unit, M09-02, introduced phishing, spear phishing, and whaling.
This lesson adds three terms:
- Smishing: phishing that uses SMS text messages to manipulate the recipient.
- Vishing: phishing that uses telephone or other voice communication to manipulate the recipient.
- Impersonation: causing a person to mistake an attacker for another person or organization.
These are not mutually exclusive attack categories. They answer different questions.
A mechanism diagram is not incident evidence
Northstar and Lin are part of a synthetic teaching scenario. A diagram shows how a mechanism could operate; it does not establish that a real incident occurred.
- Fact：A limited observation directly supported by evidence, such as receiving a text. A call record does not establish what was said.
- Risk：Possible harm that warrants protection. Reported code disclosure needs timely action, but does not prove a successful login.
- Hypothesis：An explanation to test, such as one party arranging the text and call. A diagram may stipulate it; a real case still needs evidence.
- Unknown：Insufficient evidence for a conclusion, such as unauthorized login, exfiltration or the extent of impact.
Concept｜Classification describes one event; it does not require choosing only one attack label.
A teaching framework: target, channel, claimed identity and requested action can coexist.
The whole diagram scales proportionally to this column. Small screens also shrink its text; open the original SVG to zoom, or read the explanation below.
- Who is targeted?
- Lin, an ordinary employee. Is there evidence of content tailored to him?
- Which channel?
- SMS and voice. One attack may use more than one channel.
- Who is impersonated?
- The caller claims to be the IT help desk, borrowing trust in that role.
- What is requested?
- Disclose a login code or approve a login the employee did not initiate.
Read the diagram｜Use the event as the shared reference for target, channel, claimed identity and requested action. Connections show relationships, not time or causation.
Example｜Lin is the target, text and voice are channels, the help desk is the claimed identity, and the code is what is requested.
Technical mechanism｜The same evidence can support several labels. Tailored targeting and a high-value target each require supporting evidence.
Limits｜Separate facts from hypotheses: knowing a name does not automatically establish tailoring; impersonating an executive does not by itself establish whaling.
For example, an attacker might gather background information about Lin, design a text specifically for him, then call while pretending to be company support and ask for a verification code.
If there is actual evidence that the approach was tailored to him, we can describe it as:
Spear phishing (target) + smishing and vishing (channels) + impersonation (technique) + obtaining a verification code (objective).
A common exam mistake: an attacker claiming to be a chairperson does not automatically make the incident whaling. Whaling primarily concerns targeting senior or high-value people, not impersonating a senior person.
The Canadian Centre for Cyber Security also places smishing and vishing among related forms of social engineering and phishing. Canadian Centre for Cyber Security: Social engineering; Vishing; Smishing
2. Vishing and smishing: two channels may have one attacker behind them
Imagine that you are Lin at Northstar Learning Center.
At 10 a.m., you receive a text:
[Northstar IT Help Desk] An unusual login has been detected on your course-materials account. Contact support promptly to avoid account suspension.
Two minutes later, your phone rings.
The caller says, “Hello, Lin. This is the IT help desk. There is an issue with the account for the course-materials project you are managing. We should have just sent you a text.”
Lin thinks, “They know my name, my work, and even that I just received a text.”
But this is what might actually be happening:
Concept｜Different channels do not necessarily mean independent sources.
One attacker arranges both the text and the call, making them appear to corroborate each other.
The whole diagram scales proportionally to this column. Small screens also shrink its text; open the original SVG to zoom, or read the explanation below.
- One attacker
- The same source controls both the SMS and the voice contact.
- SMS
- The attacker sends an account-alert text to draw Lin into a fabricated incident.
- Voice call
- The same party claims to be IT support and refers to the earlier text.
- Lin receives both
- Matching claims may share one source; they do not independently verify support.
Read the diagram｜Trace the SMS and voice paths backward from Lin. If both reach the same controller, they add no independent identity proof. This is a control boundary, not a telecom-network boundary.
Example｜The caller may know the earlier text simply because the same party arranged it.
Technical mechanism｜Arrows show who arranges or communicates a message, not verified identity or control of the entire phone network.
Limits｜Common control is a stipulated hypothesis in this synthetic scenario. Two matching messages alone leave their control and true sender unverified in a real case.
This approach exploits an intuitive response: when consistent information appears in different places, we tend to treat it as more credible.
From a security perspective, however, the important question is whether the evidence is genuinely independent.
Three technical ideas to distinguish
- 1. Caller ID spoofing
The name or number displayed for an incoming call can be falsified.
It is like writing “sent by a bank” on an envelope: that label does not establish that the bank really sent it.
The FTC warns against relying on caller ID alone to establish who is calling. Federal Trade Commission: Scammers can fake caller ID info
- 2. AI voice cloning
Attackers may also use AI to imitate the voice of a manager, family member, friend, or support worker. FTC: AI voice-cloning scams
Keep these distinctions in mind:
- Sounding human does not prove that the voice is a live human voice.
- Sounding like a particular person does not prove that the speaker is that person.
- Distorted audio does not by itself prove that AI was used.
The real defensive strategy is therefore not to develop perfect hearing for every AI-generated voice. It is to establish identity-verification procedures that do not depend on the voice alone.
- 3. Reconnaissance and footprinting
This connects to concepts in CEH M02.
An attacker who knows Lin's name, department, and project may previously have collected that information from a company website, social posts, event lists, or similar sources.
If specific account, group, or shared-resource information was obtained by querying system services, the activity may also connect to enumeration in M04.
But keep a firm distinction:
Knowing someone's background does not prove that their account has been compromised. Knowing an internal project name also does not directly establish that information was leaked.
3. How can a genuine OTP help a fake support worker?
This is the technical mechanism most worth understanding in the lesson.
An OTP, or one-time password/verification code, is intended as a security measure.
This lesson uses OTP informally for the one-time login code in the example. Under NIST's formal classification, a code that a platform sends to a phone by SMS belongs to out-of-band authentication, which differs from an OTP generated by an authenticator. If people must manually enter either kind of output, they may still be deceived into relaying it. NIST SP 800-63B-4: Authenticators and phishing resistance
Suppose you are logging into the course-materials system:
- 1. You enter your account name and password.
- 2. The system requires a second authentication factor.
- 3. The platform sends a one-time verification code to your phone.
- 4. You enter the code in the login process you initiated. Only after verification succeeds may the platform permit the login.
Under normal conditions, the OTP helps reduce the risk of account misuse.
An attacker can nevertheless use social engineering to try to persuade you to give them the code.
Concept｜A genuine code does not authenticate the person asking for it.
Synthetic scenario: the code is real, but the person requesting it may be an impostor. Platform rules differ.
The whole diagram scales proportionally to this column. Small screens also shrink its text; open the original SVG to zoom, or read the explanation below.
- Attacker starts a request
- Attempts login or account recovery; the platform still requires its other conditions.
- Real platform sends the OTP
- The platform sends a code for that operation to Lin's phone.
- Lin receives a real code and a fake call
- A genuine OTP arrives while an impostor claiming to be support asks Lin to read it out.
- Lin discloses the code to the impostor
- The account holder relays the code to the attacker instead of using a trusted entry point.
- Attacker attempts to submit the code
- The code is sent to the real platform. Success depends on other conditions and the actual records.
Read the diagram｜Keep three roles distinct: the attacker attempts to initiate a platform request; the platform sends a code to Lin’s phone, Lin discloses it to the impostor, and the attacker attempts to submit it to the platform. Read each arrow as who sends what to whom.
Example｜Lin did not initiate a login but reads out a newly received code. Exposure risk arises when it crosses to an untrusted party.
Technical mechanism｜The platform still checks validity, the relevant operation and other conditions. The endpoint is an attempt, not guaranteed success. NIST classifies this SMS code as out-of-band authentication.
Limits｜Disclosure supports exposure risk. Acceptance, the login operator and subsequent actions remain unknown without platform and activity records.
Why can the platform not identify the person from the OTP alone?
In plain language:
The platform checks whether the code is correct, valid, and consistent with its verification rules. That does not necessarily reveal whether the person entering it is the actual holder of the phone.
Suppose that:
- The attacker already has Lin's account name and password.
- The platform also requires an SMS verification code.
- Lin reads the code to the fake support worker.
- The attacker submits it to the genuine platform while it is still valid.
If the other authentication conditions are also satisfied, the attacker may successfully log in.
This corrects a common misconception: knowing an OTP does not always guarantee a successful login. Some systems impose device restrictions, additional verification, or risk checks. Different codes may also authorize only particular operations.
Next, understand MFA and phishing-resistant authentication
MFA, or multi-factor authentication, requires different types of authentication factors.
For example:
| Authentication factor | Everyday example |
|---|---|
| Something you know | A password you know |
| Something you have | A phone or security key you possess |
| Something you are | A biometric characteristic, such as your fingerprint |
The key is not the number of steps, but whether different types of factors are used. Entering two passwords does not automatically make the process MFA.
NIST SP 800-63B-4 states that OTP and out-of-band authentication involving manual entry of an authenticator output are not phishing-resistant. Manual entry does not bind the output to the specific session being authenticated—a particular authentication interaction—so an attacker may relay it. NIST SP 800-63B-4: Phishing resistance
Compare the two approaches:
Concept｜Adding a step and preventing an impostor site from exploiting an authentication output are different properties.
Compare whether the authentication output can be relayed and whether it is bound to the intended verifier.
The whole diagram scales proportionally to this column. Small screens also shrink its text; open the original SVG to zoom, or read the explanation below.
- Traditional OTP
- The SMS code in this example expires and can be used only once, but it may still be relayed to an attacker in real time.
- Phishing-resistant authentication
- Correctly implemented FIDO2/WebAuthn authentication, for example, uses cryptographic mechanisms to bind authentication to the intended verifier.
Read the diagram｜The code-side arrow carries a short-lived output a person can relay. The resistant-side arrow represents proof for the intended service, not delivery of a private key to that service or a caller.
Example｜Reading an SMS code aloud may enable immediate relay; correctly implemented WebAuthn includes the intended verifier in its mechanism.
Technical mechanism｜This is not a magic arrow: the browser checks whether the calling origin may use the requested service identifier (RP ID); the authenticator scopes credentials by RP ID. The server separately checks the response’s clientDataJSON origin and current challenge, authenticator-data rpIdHash, signature and other conditions. W3C: client; server verification
Limits｜An authentication response does not transmit the private key; this does not mean every passkey remains on one device forever. Syncable credentials can use protected synchronization. The figure also cannot establish payment authority or sound recovery, fallback and device security. NIST: syncable authenticators
A passkey is a cryptographic sign-in credential based on FIDO standards, commonly used through WebAuthn. The protection of the complete service still depends on its implementation, account-recovery procedures, and usage context. Phishing-resistant authentication primarily prevents fake sites from exploiting login credentials; it does not automatically stop every fraudulent payment or improper authorization to release information. FIDO Alliance: Passkeys
Connect this to authentication and authorization
This is a fundamental distinction in security engineering:
- Authentication: Who are you? Can you demonstrate control of this account?
- Authorization: Once authenticated, what are you permitted to do?
It is like using a staff badge to enter an office: getting through the entrance does not mean you can open every manager's office or every records cabinet.
A successful login therefore does not authorize every operation. An attacker obtaining a verification code also does not establish that all information has been read.
4. Independent verification means leaving the suspicious source's control
Return to Lin's situation.
The fake support worker says, “If you do not believe me, call the support number in the text you just received.”
Lin does so. The person answering says, “Yes, there was an unusual-login support ticket.”
Has this verified the request?
No. The support number and the ticket information may all have come from the attacker.
Concept｜Verification must leave the suspicious party’s source, not merely change tools.
Changing apps or asking again is not enough if the suspicious source supplies every contact detail.
The whole diagram scales proportionally to this column. Small screens also shrink its text; open the original SVG to zoom, or read the explanation below.
- Path A | Still inside the same source
- Suspicious SMS → support link in that SMS → phone number supplied by that contact → a claim of confirmation. There is still no independent proof.
- Path B | Return to an established process
- Suspicious SMS → pause and hang up → independently open the established help desk → verify the ticket, identity and authority. Perform only needed, authorized actions.
Read the diagram｜Path A follows that party’s links and numbers within the same control scope. Path B pauses the interaction, then starts a new check through a previously verified entry point.
Example｜Independently opening an existing official app differs from following an “official app” link in the suspicious text.
Technical mechanism｜A trusted source supplies a starting point for checks. Verify identity, the incident or request, and authority separately. Route arrows are checking steps, not automatic increases in trust.
Limits｜If the suspicious party supplies the new entry point, the boundary has not been crossed. Confirmed employment does not authorize every request.
Suppose someone calls while impersonating your bank's support staff. A safer response is to end the suspicious call, then open the bank's official app that you already had installed, or use an official contact method you previously verified.
In Taiwan, people can also independently dial the 165 anti-fraud consultation hotline for help with suspected scams. It is an official consultation channel provided by the Criminal Investigation Bureau. Criminal Investigation Bureau: 165 anti-fraud consultation hotline
Remember one further distinction: even confirming that the caller really works for the company does not authorize every request they make.
For example, if a genuine IT employee asks you to send all employee records, you must still check the work purpose, permissions, and formal approval process.
Separate three questions: Is the identity genuine? Is the request genuine? Is the operation authorized?
5. Incident reasoning: sharing a code does not prove completed compromise
This connects directly to incident response in M01-07.
Suppose Lin tells security staff, “I received a call from fake support, and I think I read them my verification code.”
A security engineer cannot immediately write:
“The attacker has compromised the company, and all course materials have been disclosed.”
The current evidence supports a more limited conclusion.
Concept｜Incident analysis does not automatically join five cards into a successful-compromise story.
These are evidence questions, not an inevitable attack sequence. Events may overlap, be absent or remain unconfirmed.
The whole diagram scales proportionally to this column. Small screens also shrink its text; open the original SVG to zoom, or read the explanation below.
- Contact
- Texts and call records show signs of contact, not necessarily the caller's true identity.
- Credential exposure
- An employee reports sharing an OTP. This creates exposure risk requiring timely protective action.
- Successful authentication
- Platform records still need checks of the operator and authorization; success alone does not identify an attacker.
- Unauthorized action
- Verify the operator, purpose, permissions and actual activity using access or change records.
- Data exfiltration
- Verified transfer evidence must establish content, recipient and scope. A download alert alone is insufficient.
Read the diagram｜Link each claim to its supporting material and preserve unconfirmed states. Contact, exposure, login, actions and exfiltration are not one inevitable route.
Example｜With only a text, call records and an employee account, contact has evidence and reported disclosure creates risk. Attacker login and exfiltration remain unconfirmed.
Technical mechanism｜A successful-login record still needs operator and authorization checks. A download alert still needs data, recipient and transfer evidence before an exfiltration conclusion.
Limits｜Reporting, preservation and containment can precede certainty. The need to act is not proof of harm, and failing to find a log is not proof of safety.
Now reason from the available evidence:
| Available information | Reasonable conclusion |
|---|---|
| A text-message screenshot and call record | There are signs of a message and call; the source's identity is not yet established |
| Lin reports having read out the OTP | Authentication information may have been exposed, requiring prompt action |
| The platform shows a successful login | A successful-login event exists; determine whether it was unauthorized |
| Unusual device access or download records | Access activity warrants investigation; identify the operator and purpose |
| Verified evidence of data transmission | This can further support a finding of data exfiltration and help establish its scope |
Risk reduction can begin before an investigation is complete, but final conclusions must not exceed the evidence.
If Lin really shared the code with a stranger, he should report promptly through the official help desk. Depending on the system, authorized staff can examine login records, terminate suspicious sessions, update necessary credentials, and preserve logs.
Absence of an observed login record does not guarantee safety: records may be incomplete, or investigators may not yet have located the relevant source.
This is the principle described in M01-07: first limit potential harm, then investigate, recover, and improve.
6. Connect this lesson to the broader CEH knowledge map
The priority is not memorizing more abbreviations. It is understanding how the related concepts work together.
Concept｜A knowledge map indexes analytical tools; it is not a fixed attack script.
Concept relationships, not a fixed attack sequence. Authorization and rules of engagement govern testing and investigation.
The whole diagram scales proportionally to this column. Small screens also shrink its text; open the original SVG to zoom, or read the explanation below.
- M09 | Social engineering
- Recognize phishing, impersonation and cross-channel trust.
- M02/M04 | Reconnaissance and enumeration
- Gather target and environment clues; clues do not prove compromise.
- M01-04/05 | Attack analysis
- Analyze vectors and observed behavior. An ATT&CK classification is not proof of success.
- M01-01/02 | Security and risk
- CIA, assets, threats, vulnerabilities and consequences.
- M01-06 | Defensive controls
- Authentication, least privilege and defense in depth.
- M01-07 | Incident response
- Detect, contain, investigate, recover and improve.
- M01-03 | Authorization and ROE
- Testing and investigation must stay within explicit permission and scope.
Read the diagram｜Relationship lines connect social engineering with reconnaissance, behavior classification, defenses, risk and response. The authorization and ROE boundary governs the scope of testing and investigation.
Example｜For an impostor-support call, use M09 to examine persuasion, M01-05 to describe behavior and M01-07 to plan evidence collection and response without assuming every module occurred in sequence.
Technical mechanism｜ATT&CK mapping describes observed behavior. Least privilege, authentication and response reduce risk at different points, rather than forming mandatory consecutive stages.
Limits｜A connection proves neither attack success nor completion of a course unit. A teaching example does not authorize testing real accounts.
Explore the two most important connections
First: MITRE ATT&CK in M01-05.
M01-05 explains that MITRE ATT&CK is not merely a way to divide attacks into stages. It describes attacks through tactics—the objectives—and techniques—the behaviors used.
Using voice communication to persuade a target to provide access can correspond to ATT&CK's T1566.004 — Spearphishing Voice. This technique belongs to the Initial Access tactic.
A fake-support call alone, however, does not prove that the attacker successfully obtained initial access. An ATT&CK technique classification describes behavior; the outcome of an incident still requires evidence.
Second: defense in depth in M01-06.
To prevent this type of incident, Northstar cannot rely only on telling employees, “Do not trust calls from strangers.”
It should arrange controls at multiple layers:
| Defensive layer | Example measures |
|---|---|
| People and process | Established verification channels, suspicious-request reporting, review of sensitive actions |
| Accounts and authentication | Appropriate phishing-resistant MFA, monitoring for unusual logins |
| Permission management | Least privilege and separate approval for major changes |
| Device protection | Formal authorization for remote-support tools |
| Detection and response | Logs, unusual-activity alerts, session revocation, and incident investigation |
That is the value of defense in depth: even if Lin makes a poor decision in the moment, other controls can reduce the likelihood of attack success and wider harm.
Viewed through M01-01's CIA triad, unauthorized reading of course materials may harm confidentiality; improper alteration of course grades may harm integrity; and an account lockout that interrupts work may harm availability.
7. A two-minute exercise: identify a trustworthy source
You do not need to install Kali Linux, run commands, or send real text messages.
Suppose a caller claims to be bank support and asks for a login code received on your phone. How should you verify the request?
A. Call the support number provided in the caller's text
B. Independently open the official banking app you previously verified and use its established entry point
C. Ask the caller to repeat their employee number
Choose an answer and explain your reasoning before opening the reference explanation. This is a tabletop exercise: it does not submit an answer or establish verified understanding.
Reference explanation: 1. Two-minute exercise: which verification method is more reliable?
The suggested answer is B: independently open the official banking app you previously verified and use its established entry point. The key is not that an app is always safer than a phone call. It is that the suspicious caller or text did not supply this entry point for the current interaction.
A still uses a number provided by the suspicious source. Even if the person answering says, “Yes, that was us,” it may simply be another part of the same party's arrangement, not independent evidence.
C asks the caller to repeat an employee number but remains inside the caller's information source. Knowing a number does not establish that a trusted system confirms the person, support ticket, or request.
In practice, do not provide the login code. End the suspicious call, then use an established trusted contact method to verify the identity, request, and authority. Even verifying a bank employee's identity does not remove the normal procedures for sensitive operations. Canadian Centre for Cyber Security: Avoiding vishing
8. After-lesson understanding check
These three questions cover attack classification, authentication mechanisms, and incident response. Think through each in your own words; a short answer is enough.
Question 1 | Attack classification
An attacker targets a company's finance manager, first sending a phishing text and then calling while impersonating bank support. Which phishing concepts might apply at the same time, and why?
Question 2 | Technical mechanism
Why can an OTP generated by the genuine platform still help an attacker log in? Why does this not mean that MFA is completely useless?
Question 3 | Incident handling
An employee definitely read out an OTP, but only call records are currently available; login and access logs have not yet been obtained. What can you establish? What can you not establish? What should be done first?
Answer the three questions in your own words, then compare each with its reference explanation. The explanations are teaching material, not records of a learner's submitted answers or verified understanding.
Reference explanation: 2. After-lesson question 1: which classifications may apply?
These concepts can coexist: the SMS channel is smishing, deceptive inducement through the voice call is vishing, and pretending to be bank support is impersonation. They describe channels and a technique rather than mutually exclusive options. The overall activity remains within phishing.
From the target perspective, the question explicitly targets a company's finance manager, so spear phishing is an appropriate description. If that manager holds a senior position, substantial payment authority, or other high-value privileges, whaling may be a more specific classification. Do not infer an unstated rank or set of permissions solely from the word “manager.”
Distinguish whom the attacker targets from whom the attacker impersonates. The target is the finance manager; the claimed identity is bank support. An important-sounding assumed identity does not itself make an incident whaling. In a real investigation, examine the target, content, and behavior before applying the classifications supported by evidence. Canadian Centre for Cyber Security: Social engineering
Reference explanation: 3. After-lesson question 2: how can a genuine OTP help an attacker?
A genuine code establishes only that it came from the real platform or satisfies its verification rules. It does not authenticate the person asking for it. If the attacker has the other required conditions and persuades the user to disclose a still-valid code, the attacker may submit it to the genuine platform and complete that authentication transaction.
Obtaining the code does not guarantee a successful login. The outcome depends on the operation associated with the code, whether it expired or was already used, and whether device restrictions, additional verification, and other conditions are satisfied. Confirm the outcome from actual records rather than inferring success from the mechanism alone.
This does not make MFA useless. Different factors add protection: for example, if only a password is exposed, an additional factor may prevent login. The limitation is that authentication methods differ in phishing resistance. Manually entered OTP or SMS out-of-band outputs can be relayed through deception and should not be treated as phishing-resistant. Correctly implemented FIDO2/WebAuthn instead uses cryptography to bind authentication to the intended verifier. NIST SP 800-63B-4: Phishing resistance
Finally, keep login and authorization separate. Stronger authentication does not automatically establish that every payment or information disclosure is appropriate. Independent approval, least privilege, and other controls are still needed.
Reference explanation: 4. After-lesson question 3: what can be concluded, and what comes first?
Under the question's stated premise, the employee read out the OTP, creating an authentication-information exposure risk. Call records support the occurrence of corresponding call activity. In a real investigation, call records do not necessarily establish what was said; separate the user's account, corroborating evidence, and verified facts.
You cannot yet conclude that unauthorized login succeeded, the account was fully controlled, or course materials were disclosed. Investigate the operation associated with the code, its validity, authentication and login results, whether the operator was authorized, and the scope of subsequent access, downloads, or transmissions.
Do not wait for every fact before taking protective action. Stop the suspicious interaction, provide no further codes or approvals, and report immediately through the established official help desk. Authorized responders can protect the account according to risk, inspect or revoke suspicious sessions, address necessary credentials, and preserve messages, timestamps, and logs. Do not erase records yourself or repeat suspicious actions as a test.
Then correlate login, device, permission-change, support-ticket, and data-activity records. A lack of observed anomalies does not guarantee safety because records may be incomplete. In short: address risk promptly, but establish successful compromise and data disclosure with their own evidence. Canadian Centre for Cyber Security: Responding to social engineering
Visual reasoning check | Trace sources, transfers and evidence limits
Use only these known details: Lin receives an alert text and a follow-up call; the platform sends a login code; Lin reports reading it to the caller. No platform login, activity or transfer records are available. Figures 2 and 3 illustrate possible mechanisms, not a fully established investigation.
- 1. Using Figures 2 and 5, where does a “verification number” supplied in the text belong? Which part of the route must change before an independent check can begin?
- 2. Using Figure 3, identify who sends the genuine code to whom, who discloses it to whom, and the final arrow that can only be labeled an attempt. Why can it not simply become “successful login”?
- 3. Using Figure 6, separate supported facts and risk from hypotheses or unknown outcomes. If a successful-login record is later found, does it establish exfiltration? What evidence is still missing?
Explain your reasoning using arrows, components and evidence before opening the reference answer. This teaching check does not submit a response or record confirmed understanding.
Reference answer | Visual reasoning
1. The number remains within the suspicious source’s control scope. Switching to voice does not create an independent source. Break the dependency from text-supplied contact details to callback verification: end the interaction, then independently open a previously verified official app or help desk. Still verify identity, the request and authority. Common control is a plausible hypothesis to investigate, not a conclusion established by matching content alone.
2. Genuine code: real platform → Lin’s phone. Disclosure: Lin → impostor caller. The final arrow is the attacker’s attempted submission → real platform. The diagram supplies a possible mechanism, but this scenario has no submission or login records. Code validity, the relevant operation, other authentication conditions and the actual result do not follow automatically from disclosure.
3. Supported facts include receipt of a text and platform code, the occurrence of a call, and the existence of an employee disclosure report. A call record alone does not establish the spoken content. The report creates exposure risk requiring official reporting and appropriate protective action. Common control, attacker login, unauthorized actions and exfiltration still need investigation. A successful-login record establishes a login event, but operator, timing and authority need checks. Exfiltration additionally requires verified content, recipient, transfer and scope evidence. Missing logs do not establish safety; a need to respond does not establish a breach.
Finally, bring M09-03 together into one complete reasoning approach:
Identify the channel through which the person approached you, the identity they claim, and the access or authority they seek. Then independently verify outside the suspicious source's control. If an unsafe action has already occurred, control the risk first and use evidence to establish the actual impact.
This approach applies not only to fake-support calls, but also to impersonated police or prosecutors, fake managers, account-recovery scams, and future AI voice-impersonation attempts.
The next unit, M09-04, covers pretexting, baiting, and tailgating. It explains how attackers construct a plausible situation that encourages someone to help them cross an existing security boundary.
Related reading and diagram files
M09-01 · M09-02 · M01-01 · M01-02 · M01-03 · M01-04 · M01-05 · M01-06 · M01-07
M02 reconnaissance and footprinting · M04 enumeration
Editorial clarifications: SMS out-of-band verification is distinguished from the formal OTP-authenticator category; expiration is scoped to this example; a passkey is described as a FIDO cryptographic credential. Imported source cards and submit-button text are replaced by direct references and reading guidance, not an answer-submission feature.
v1.2.0 visual additions preserve the full primary manuscript and original reference answers, adding role and trust boundaries, arrow-reading guidance, failure and unknown outcomes, and a visual reasoning check. These simplified models do not substitute for incident evidence.
W3C WebAuthn Level 3 — Client origin/RP ID checks · W3C WebAuthn Level 3 — Verifying an Authentication Assertion · NIST SP 800-63B-4 — Syncable Authenticators · NIST SP 800-63B-4 — Phishing Resistance · FIDO Alliance — Passkeys
Download all seven diagrams in Chinese and English (SVG ZIP)
Concept Q&A
Pending: related questions will be edited into anonymous teaching notes when available.