Learn Ethical Hacking Series):npm ls --all | wc -l # 847 total packages
npm ls --depth=0 | wc -l # 23 direct dependencies
npm audit
The important detail here is the **depth**. 23 direct dependencies sounds manageable -- but 847 total packages means each direct dependency pulls in roughly 36 transitive dependencies you never asked for. The critical vulnerability in `xml2js` is three levels deep in the tree. You didn't install it, you didn't ask for it, you probably didn't know it existed -- and it's running in your production application with your application's permissions. That's the supply chain problem in a nutshell.
**Exercise 2:** XZ Utils backdoor analysis.
```text
Social engineering timeline:
2021: "Jia Tan" submits small, useful patches to xz-utils
2022: Builds reputation, becomes co-maintainer
2023: Takes over release management, including tarball generation
Feb 2024: Inserts obfuscated test files (.xz binaries) into repo
Mar 2024: Modified build system extracts backdoor from test files
during "make" and links it into liblzma
Technical mechanism:
Backdoor was NOT in the git source code. It was in pre-built
test fixture files (bad-3-corrupt_lzma2.xz) that the build
system extracted and compiled. Source code review would not
find it -- only the release tarball contained the trigger.
The backdoor hooked into RSA_public_decrypt in OpenSSH's
authentication path via liblzma, allowing RCE with a specific
key before normal authentication.
Discovery: Andres Freund noticed 500ms SSH latency increase.
Profiled sshd, found CPU time in liblzma (should not be called
during SSH auth). Traced to the backdoor.
Defenses that would have caught it:
- Reproducible builds (tarball != git source = red flag)
- Automated diffing between git and release artifacts
- Multiple maintainer sign-off for releases
- Build process auditing (SLSA Level 3+)
The scariest part of this case isn't the technical sophistication (which was considerable). It's the patience. Two years of building trust. Two years of being helpful. Two years of showing up, writing patches, fixing bugs -- real work, real value. And then one poisoned release. The entire open source trust model assumes that contributors who provide sustained value are trustworthy. Jia Tan proved that assumption wrong.
Exercise 3: Dependency confusion lab.
# Created private package: mycompany-testpkg-a7x9 (version 1.0.0)
# Local directory index configured in pip.conf
# Published same name on TestPyPI: version 99.0.0
# Result with --extra-index-url: pip installed version 99.0.0
# from TestPyPI (higher version wins across all indexes)
# Fix: use --index-url (single index, no fallback) for internal
# packages, or use namespaced packages that cannot exist publicly
The critical takeaway from this lab: --extra-index-url is dangerous because pip treats all indexes as equivalent and picks the highest version from any of them. The --index-url flag (without "extra") replaces the default index entirely rather than adding to it. For internal packages, you want --index-url pointing to your private registry with NO fallback to PyPI. Or better yet: vendor your dependencies and install from a local directory with --no-index --find-links=./vendor/.
Episode 45 covered supply chain attacks -- the class of attack that weaponizes trust in software dependencies. We went through dependency confusion (Alex Birsan's technique that hit Apple, Microsoft, PayPal, and 35+ others by registering internal package names on public registries), typosquatting (malicious packages with names one keystroke away from the real thing), build system poisoning (the SolarWinds SUNBURST backdoor that spent 9 months inside 18,000 organizations before FireEye found it by accident), the XZ Utils backdoor (two years of patient social engineering to compromise a solo maintainer of critical infrastructure), SBOMs and dependency auditing tools (Syft, Grype, npm audit, pip-audit), and the SLSA framework for build provenance. The core lesson: modern software is built on layers of trust -- in registries, in maintainers, in build systems, in update channels -- and each layer of trust is an attack surface.
For 45 episodes we attacked software, networks, and infrastructure. We exploited buffer overflows, SQL injection, misconfigured cloud services, Active Directory delegation paths, and supply chain trust relationships. Every single attack targeted something technical -- a bug, a configuration mistake, a protocol flaw, a poisoned dependency. Something that, in principle, a patch or a better design or a more careful process could fix.
Now we enter Arc 4: Social, Organizational, and Human Attacks. The targets here are not machines. They are people. And people cannot be patched.
Here we go.
The security industry spends billions on security awareness training every year. Annual compliance modules with click-through slides. Mandatory phishing simulations that send fake emails and count who clicks. "Think Before You Click" posters in the breakroom. Lunch-and-learn sessions about password hygiene. And the click rates barely budge.
Why? Because security awareness training treats a psychological problem as an information problem. The assumption is: if people KNOW about phishing, they will not click. This is like saying: if people KNOW about calories, they will not eat junk food. Knowledge does not change behavior. Habits change behavior. Environment changes behavior. Incentives change behavior. A 45-minute PowerPoint presentation does none of those things.
The data backs this up consistently:
Typical phishing simulation results across industries:
- Before training: 20-30% click rate
- Immediately after training: 5-10% click rate
- 6 months later: 15-25% click rate (regression to baseline)
- 12 months later: back to 20-30%
The training creates temporary awareness, not behavioral change.
The moment the training fades from memory, the old habits return.
Verizon 2024 Data Breach Investigations Report (DBIR):
- 68% of breaches involved a human element
(social engineering, errors, misuse of credentials)
- Median time-to-click on a phishing email: 21 seconds
- That's 21 seconds between receiving the email and clicking
the link. No amount of training changes a 21-second reaction.
Proofpoint State of the Phish 2024:
- 71% of organizations experienced at least one successful
phishing attack
- 96% of those organizations already had security awareness
training programs in place
- Training does not prevent phishing. It creates the illusion
of prevention.
The industry keeps doing it because compliance frameworks (SOC 2, ISO 27001, PCI-DSS, HIPAA) require "security awareness training." The training exists to satisfy auditors, not to change behavior. And so the cycle continues: train, simulate, measure, report, repeat -- while the click rates stay the same and the breaches keep happening.
Social engineering works because it exploits how human brains are wired. These are not weaknesses you can train away -- they are features of human cognition that evolved over hundreds of thousands of years. An attacker who understands these biases can manipulate nearly anyone, regardless of their technical sophisticaton or security training.
Robert Cialdini's six principles of influence (from his 1984 book Influence) remain the definitive framework for understanding social engineering:
People comply with requests from perceived authority figures without questioning. This is deep -- experiments by Stanley Milgram in the 1960s showed that ordinary people would administer what they believed were lethal electric shocks to another person simply because an authority figure told them to.
Pretext: "This is James from the IT Security team. We've detected
unusual activity on your account. I need you to verify your
credentials immediately by logging in at this link."
Why it works: the caller claims authority (IT Security), creates
urgency (unusual activity, immediately), and provides a plausible
reason. The target's brain processes the authority claim BEFORE
the skepticism kicks in. By the time critical thinking activates,
the emotional response (fear, compliance) has already primed the
target to act.
Real case: A red team operator called a company's finance
department, introduced himself as the new CFO's assistant, and
requested an urgent wire transfer. Used LinkedIn to get the CFO's
name, assistant's typical communication style, and recent company
news for context. Transfer was approved within 20 minutes.
The finance employee had completed security awareness training
three weeks earlier.
Time pressure short-circuits critical thinking. The prefrontal cortex (rational analysis, risk assessment, skepticism) needs time to process information. The amygdala (fight-or-flight, emotional reaction) responds instantly. Urgency forces the brain to defer to the amygdala:
Email: "Your account will be permanently deleted in 2 hours
unless you verify your identity. Click here to confirm."
Phone: "This is the IRS. There is a warrant for your arrest for
tax fraud. You must pay the outstanding balance immediately to
avoid arrest. I need your credit card number right now."
Slack DM: "Hey, CEO here. I'm in a meeting and my laptop died.
I need you to buy 5 gift cards at $200 each and send me the
codes ASAP. Will explain later. Don't tell anyone -- it's for
a surprise for the team."
Why it works: every scenario creates a tight deadline that
prevents the target from pausing, consulting a colleague, or
verifying the request through a separate channel. The emotional
pressure to ACT overwhelms the rational impulse to VERIFY.
People follow what others appear to be doing. If everyone else is doing it, it must be safe:
"Your colleagues John, Sarah, and Mike have already updated their
security credentials. You're the last person in your department
who hasn't completed this mandatory requirement."
Why it works: humans are social animals. If others have done it,
it must be safe and legitimate. The attacker names real colleagues
(found on LinkedIn or the company website) to make the social
proof concrete and verifiable. The target thinks: "If John did
it, it must be fine." They don't think: "How do I know John
actually did it?"
People feel obligated to return favors. This one is subtle and extremely effective because the target doesn't even realize they're being manipulated:
Pretext: The attacker first HELPS the target.
"Hey, I noticed your printer wasn't working earlier -- I fixed
the driver for you. By the way, I left my badge at home today,
could you let me into the server room? I just need to check the
UPS status real quick."
Why it works: the target feels indebted because the attacker
provided unsolicited help first. Refusing the follow-up request
feels socially inappropriate -- rude, even -- after receiving a
favor. The social contract of reciprocity overrides the security
policy of "don't let unbadged people into the server room."
Two more Cialdini principles that attackers chain together. Liking: people comply more readily with requests from people they find pleasant, attractive, or similar to themselves. Consistency: once someone commits to a small action, they're more likely to comply with a larger request that aligns with that initial commitment.
Liking attack:
The attacker builds rapport before asking for anything.
Compliments the target's work ("I saw your presentation last
week -- really impressive data on Q3 projections"). Finds
common ground ("You went to Michigan State? My sister went
there!"). Mirrors body language, speech patterns, enthusiasm.
By the time the actual request comes, the target WANTS to help.
Consistency (foot-in-the-door):
Day 1: "Could you forward me the meeting notes from Tuesday?
I missed the call." (small, harmless request)
Day 3: "Thanks for those notes! Quick question -- do you have
the login for the analytics dashboard? I need to pull
some numbers for my report." (escalation)
Day 5: "Hey, one more thing -- I need access to the shared
drive with the financial projections. Can you share
your credentials or add me?" (the real target)
Each compliance makes the next one easier. Saying "no" after
saying "yes" twice feels inconsistent. The target's brain
resolves the dissonance by continuing to comply.
Pretexting goes beyond a simple phishing email. The attacker constructs a complete fictional identity -- a character with a backstory, motivation, vocabulary, and relationship to the target organization. A good pretext is indistinguishable from reality because it IS a reality, carefully built from OSINT:
Pretext construction checklist:
1. WHO are you? (IT contractor, new employee, vendor rep,
auditor, delivery person, fellow conference attendee)
2. WHY are you contacting them? (scheduled maintenance, audit,
onboarding, emergency, project collaboration)
3. WHAT do you need? (credentials, access, information, a door
opened, a USB plugged in, an email forwarded)
4. WHAT do you already know? (names, projects, office layout,
recent events, org chart -- all from OSINT)
5. WHAT is your cover for being questioned? (work order number,
manager's name, reference to a real project, badge number)
Pretext research sources:
- LinkedIn: org chart, job titles, employee names, recent hires
- Company website: office locations, department names, leadership
- Job postings: internal tools, tech stack, team structures
- Glassdoor: office layout descriptions, culture, dress code
- Social media: employee photos (office backgrounds reveal
badge systems, door types, security cameras)
- Public filings: contracts, vendor relationships, partner orgs
- Conference talks: project names, architecture decisions
The deeper the pretext, the more convincing the attack. A good
pretext takes hours or days to develop and minutes to execute.
The difference between "phishing" and "pretexting" is like the difference between throwing a rock and building a siege engine. Phishing is a volume play -- send 10,000 emails, get 200 clicks. Pretexting is targeted, researched, and devastating. A well-constructed pretext against a specific individual has success rates north of 80% in red team engagements. That person received the same security awareness training as everyone else. It did not help.
Vishing (voice phishing) bypasses every email security control that organizations have spent millions deploying. No spam filters. No URL scanning. No sandbox analysis. No DMARC/DKIM/SPF. No "suspicious email" banner. Just a phone call:
Typical vishing script for credential harvesting:
"Good morning, this is David from ServiceDesk, employee ID 4472.
We're doing a system migration this weekend and I'm calling
everyone in the finance department to verify their access before
the cutover. Can I confirm -- you're using the new portal at
portal.company.com for your daily work?
[Target confirms]
Great. During the migration, your current password will need to
be re-synced. I can do that for you right now so you're not
locked out Monday morning. What's your current password?"
Enhancements that increase success rate:
- Caller ID spoofing to show the company's internal number
(VoIP services like SIPVicious, spoofcard make this trivial)
- Background office noise played through speakers (YouTube has
"office ambience" recordings specifically for this)
- Calling during lunch hour when people are distracted
- Having a "supervisor" ready to take over if the target
pushes back ("Let me transfer you to my manager")
- Referencing a real ongoing project or system change (from
LinkedIn posts by IT staff or company blog announcements)
Vishing success rates in red team engagements typically run between 50-70%. More than half of the people called will provide their password, approve an MFA prompt, or perform the requested action. This is NOT because these people are stupid -- it's because the psychological triggers (authority, helpfulness, urgency, social proof) operate below the level of conscious decision-making. Training tells people "don't give your password to strangers on the phone." The vishing call makes the caller not feel like a stranger -- they know your name, your department, your manager's name, the project you're working on, and the system migration that's actually happening next weekend.
Why vishing is particularly dangerous:
1. No digital evidence trail (no email to report or forward)
2. Real-time interaction -- attacker adjusts to responses
3. Emotional pressure is immediate and personal
4. Caller ID spoofing is trivial and undetectable
5. Voice conveys authority and urgency better than text
6. MFA bypass: "I just sent a verification code to your phone,
can you read it back to me?" (real-time phishing relay)
That last point -- real-time MFA bypass -- deserves emphasis. The attacker calls the target, gets their password, simultaneously logs in to the real service (which sends an MFA push or SMS code to the target's phone), and asks the target to read back the code or approve the push. The target does it because they're "helping IT verify their access." The entire MFA flow is relayed in real time through the phone call. This defeats SMS-based MFA and app-based push MFA. Only phishing-resistant MFA (FIDO2/WebAuthn hardware keys) survives this attack, because the cryptographic challenge is bound to the legitimate domain and cannot be relayed.
Digital attacks get all the attention, but physical access remains one of the most reliable attack vectors. Getting inside a building is often easier than getting into a network ;-)
Scenarios that work consistently in red team engagements:
1. The delivery person
Walk up to the door carrying a large box labeled with the
company logo (printed at a copy shop for $3). Someone WILL
hold the door for you. Nobody questions a delivery. Wear a
uniform (polo shirt with any logo, brown pants) for extra
credibility. Bonus: the box can contain your attack hardware
(a Raspberry Pi drop box, a rogue access point, a USB
Rubber Ducky).
2. The new employee
"Hi, I'm starting in engineering next week -- HR said I should
come by today to pick up my badge and laptop. Could you let
me in? I'll find the HR office from here." Carry a folder
with printed papers (looks like onboarding documents). Nobody
wants to be rude to the new person on their first day.
3. The smoking buddy
Stand outside the building near the smoking area. Chat with
smokers for 10 minutes. Talk about the weather, complain about
the parking. Walk back in with them. No badge needed -- you're
"with them" now. Social bonds formed through shared experience
(even a 10-minute cigarette break) create implicit trust.
4. The IT emergency
Carry a laptop bag and look slightly stressed. "Hey, server
room emergency -- the monitoring is going crazy and I need
to check the UPS. Can you badge me in? My badge is in my
other jacket." Nobody wants to be the person who delayed a
fix during an outage.
5. The conference room squatter
Enter during a large meeting or event when the lobby is busy
and reception is overwhelmed. Walk with purpose toward the
conference rooms. Sit down, open your laptop, look busy.
You are now an employee. Stay for hours. Access the internal
network from any ethernet port or wifi (which is often open
on the internal VLAN in conference rooms).
Physical attack payloads (what you do once inside):
1. USB drop attack
Leave USB drives labeled "Quarterly Financials 2026" or
"Executive Bonus Structure" in common areas (kitchen,
parking lot, lobby). Human curiosity guarantees someone
will plug one in. The USB contains an autorun payload or
a Rubber Ducky script that executes in seconds.
2. Rogue device deployment
Plug a tiny device (Raspberry Pi Zero, LAN Turtle, WiFi
Pineapple) into an unused network port behind a printer or
under a desk. Configure it to call home over cellular or
tunnel through the corporate network. You now have
persistent remote access to the internal network.
3. Credential harvesting via shoulder surfing
Position yourself behind someone logging in at their desk
or a shared kiosk. Most people don't shield their keyboards.
In open office layouts, a "delivery person" walking through
has a clear line of sight to dozens of screens.
4. Badge cloning
RFID/NFC badges (HID ProxCard, iCLASS) can be read from
up to 3 feet away with a Proxmark3 or long-range reader
hidden in a bag. Clone the badge, return next day with full
access. Works against every RFID system that doesn't use
cryptographic challenge-response (which is most of them).
If traditional security awareness training does not change behavior (and the data is clear that it does not), what actually reduces the human attack surface? The answer is a combination of technical controls that remove the human from the decision and environmental changes that make the secure behavior the default behavior.
Technical control > human behavior. Always.
FIDO2/WebAuthn hardware keys (YubiKey, SoloKey, Google Titan)
cannot be phished. The authentication protocol binds the
cryptographic challenge to the legitimate domain. The hardware
key refuses to authenticate if the domain is wrong -- even if
the user willingly typed their password on a fake site.
This removes the human from the equation entirely. You cannot
trick a hardware key with urgency. You cannot social-engineer
a hardware key with authority. You cannot vish a hardware key
over the phone.
Google's internal data (published 2019): after deploying FIDO2
keys to all 85,000+ employees, they experienced ZERO successful
phishing attacks. Zero. Not "reduced by 90%" -- zero.
Comparison of MFA types against real-time phishing relay:
SMS codes: DEFEATED (attacker relays code via phone)
TOTP app codes: DEFEATED (attacker relays code via phone)
Push notification: DEFEATED (attacker asks target to approve)
FIDO2 hardware: IMMUNE (domain binding prevents relay)
The single highest-impact security investment any organization
can make is deploying phishing-resistant MFA to all employees.
Not training. Hardware keys.
Instead of annual 45-minute compliance modules that everyone
forgets within a week, deliver 30-second lessons at the exact
moment they're relevant:
- User clicks a simulated phish -> immediately shown what they
missed (the specific indicators in THAT email, not a generic
"phishing 101" slide deck)
- User attempts to send sensitive data externally -> popup
explaining the risk BEFORE the action completes, with an
"are you sure?" confirmation
- User plugs in an unknown USB -> brief notification explaining
the risk (not a punitive block that teaches them to use a
different port next time)
- User reuses a password -> notification at password creation
time explaining the specific risk of credential stuffing
The principle: teach at the moment of relevance, not months
before it. Humans learn from immediate feedback, not from
abstract warnings about hypothetical future events.
KnowBe4 data: just-in-time training following a simulated
phish click reduces repeat click rates by 75% -- compared to
40% reduction from annual training alone. And the effect
persists longer (6+ months vs 3 months).
Embed security-minded individuals in every team. Not security
professionals -- regular developers, accountants, marketers,
and operations people who receive extra training and act as the
team's security conscience.
They are peers, not auditors. They answer questions without
judgment. They review PRs for security issues. They report
suspicious emails on behalf of hesitant colleagues. They
translate security policy into team-specific language.
This scales security culture horizontally instead of relying on
a central security team that cannot be everywhere. In a company
with 2,000 employees and a 5-person security team, the ratio is
1:400. With a security champion in every team (say 50 champions),
the ratio drops to 1:40. That's a 10x improvement in security
coverage with minimal additional headcount.
The key insight: people listen to peers more than to authority
figures. A colleague saying "hey, that email looks weird" is
more persuasive than a training video saying "be cautious of
unexpected emails." Same message, different source, dramatically
different compliance rate.
The most effective defense against BEC (Business Email Compromise)
is not training. It's a rule:
"Any wire transfer over $5,000 requires verbal confirmation via a
phone call to a KNOWN number (not the number in the email)."
This process control costs nothing to implement. It defeats
100% of email-based wire fraud. No training needed -- just a
rule that the finance team follows regardless of who asks.
Other process controls that eliminate human judgment:
- Password managers with autofill (only fills on the correct
domain -- phishing sites get nothing)
- URL rewriting and time-of-click analysis (email security
gateway rewrites links and checks them when clicked, not
just when delivered)
- Separation of duties (the person who requests a transfer
cannot also approve it)
- Out-of-band verification for all sensitive requests (if
the CEO emails asking for a transfer, call the CEO on a
known number and verify)
Process > Training > Hope
The pattern: don't ask humans to be vigilant. Design systems
where the secure outcome happens by default, and the insecure
outcome requires deliberate effort to achieve.
Security architecture principles borrowed from behavioral
economics ("nudge theory" -- Thaler & Sunstein, 2008):
1. Default to secure
- Pre-enroll all employees in MFA (opt-out instead of opt-in)
- Set password manager as default (pre-installed, pre-configured)
- Auto-lock screens after 5 minutes (not "please remember
to lock your screen")
2. Make the secure path the easy path
- SSO for all applications (one login, not 47 passwords)
- VPN auto-connects when leaving the corporate network
- Encrypted messaging is the default channel, not email
3. Remove friction from reporting
- One-click "Report Phishing" button in the email client
- No blame, no investigation, no "why did you click?" --
just "thanks for reporting"
- Publicly celebrate reports ("Sarah in accounting spotted
a sophisticated phishing attempt this week!")
4. Make the insecure path hard
- Block USB mass storage by default (whitelist specific devices)
- Disable macros in Office documents by default
- Require MFA step-up for sensitive operations (even if
already authenticated)
AI is making social engineering dramatically more effective. AI-generated phishing emails have perfect grammar, personalised content (scraped from LinkedIn, company websites, and social media profiles), and contextually appropriate urgency. The traditional advice -- "look for spelling errors and generic greetings" -- is completely obsolete.
Pre-AI phishing (obvious, low effort):
Subject: Urgent! Your acount has been comprimised
From: security@g00gle-verify.com
Body: "Dear Valued Customer, Please click below link to
verify your account immediatly or your account will be
locked permanantly."
AI-generated phishing (2024+):
Subject: Re: Q3 Revenue Projections - Updated Spreadsheet
From: (spoofed) m.chen@company.com
Body: "Hi Sarah,
Following up on our discussion in yesterday's standup -- I've
updated the Q3 revenue projections with the revised APAC
numbers that David's team sent over. The delta is significant
enough that we should probably loop in finance before the
board meeting next Thursday.
Updated spreadsheet is here: [link to credential harvester]
Let me know if the EMEA numbers look right to you -- I wasn't
sure about the FX adjustment methodology.
Best,
Michael"
The AI version references real projects, real colleagues, real
events (all scraped from LinkedIn, Slack messages, and company
blog posts). It reads like an actual internal email. No spelling
errors to spot. No generic greeting. No urgency that feels
manufactured. Just a colleague sharing a spreadsheet.
AI voice cloning can replicate a CEO's voice from a 30-second public recording (an earnings call, a conference talk, a YouTube interview). AI can generate deepfake video for video calls -- real-time face swapping that is good enough to fool colleagues who interact with the person regularly. The trust anchors humans rely on -- "I recognize the voice," "I see their face," "the email reads naturally" -- are being systematically undermined by the same technology that makes our lives more convenient.
The irony: organizations deploy AI-powered security awareness training platforms that teach employees to spot attacks that no longer look the way the training describes. The training is fighting the last war. AI-generated phishing doesn't have spelling errors. AI-cloned voices don't sound robotic. AI-generated pretexts don't have logical gaps. The training material is optimized for threats that are rapidly becoming extinct while the new threats operate at a level of sophistication the training doesn't acknowledge.
We've now covered the foundational psychology of why humans are vulnerable and why traditional defenses against human exploitation consistenly fail. The cognitive biases, the social engineering principles, the gap between knowing and doing -- these are the constants that every attack in this arc builds on.
The next phase goes deeper into specific attack methodologies that exploit these human vulnerabilities at an organizational level. We will examine the physical dimension of security -- how attackers combine OSINT with physical access to compromise targets that believe they're protected because their firewalls are configured correctly. And we will look at what happens when the attacker isn't an outsider at all -- when the threat comes from someone who already has a badge, a VPN connection, and a good reason to access the data they're stealing. Those scenarios require a completely different defensive model than anything we've discussed so far, because the attacker has already bypassed every perimeter control by definition.
Exercise 1: Design a vishing pretext for an authorized red team engagement. Your target: an employee in the HR department. Your goal: obtain their current password over the phone. Document: (a) the character you will portray (name, employee ID, department, role), (b) the full phone script with branching dialogue for different responses (target is cooperative, target is suspicious, target asks for verification), (c) the OSINT you would gather beforehand (LinkedIn profiles, company website, recent news, org chart), (d) how you would handle pushback ("I need to verify who you are" -- what's your response?). Do NOT execute this -- design only. Save to ~/lab-notes/vishing-pretext-design.md.
Exercise 2: Analyze 3 real Business Email Compromise cases from FBI IC3 reports or news articles. For each case, document: (a) the pretext used by the attacker, (b) the amount stolen, (c) which Cialdini principle was the primary lever (authority, urgency, social proof, reciprocity, scarcity, liking), (d) what single process control would have prevented the loss (e.g., out-of-band verbal confirmation, dual approval, etc.). Compile your analysis in ~/lab-notes/bec-case-studies.md.
Exercise 3: Evaluate your own organization's (or a hypothetical mid-size company's) security posture against this episode's framework. Score it on four dimensions: (a) training frequency and format (annual click-through module = 1, monthly micro-training with just-in-time feedback = 5), (b) MFA type deployed (SMS = 1, app-based TOTP = 3, hardware FIDO2 key = 5), (c) process controls for financial transactions (none = 1, email-only approval = 2, verbal verification required on known number = 5), (d) security champions program (none = 1, informal volunteers = 3, structured program with training budget = 5). Total score out of 20 and identify the single highest-impact improvement. Write your assessment to ~/lab-notes/security-posture-assessment.md.
@scipio