Every course in this subject so far has assumed the problem in front of you is real — a disk genuinely failing, a service genuinely slow, a connection genuinely broken. This course covers a different category entirely: situations where the "problem" itself is a deliberate attempt to manipulate you, the support technician, into doing something you shouldn't. Attackers know that a busy person trying to be helpful is often an easier target than the system they're actually trying to reach.

What Every Prior Chapter in This Subject Quietly Assumed

Each Technical Support course so far has treated one specific thing as a given. This course exists because none of those things can always be assumed:

This course is specifically about the situations where that last assumption breaks down — where the "user" isn't who they claim to be, or the urgent request is deliberately shaped to make you skip a step you'd normally take.

Not the Same Ground as This Site's Security Courses

This site already has a Security subject — but its courses assume a very different reader, sitting in a very different seat:

None of that requires writing or reading a line of code the way those courses do — and this course doesn't ask you to either. The skill here is entirely judgment, exercised in real time, usually over a phone call, a chat window, or a ticket queue, with someone on the other end actively trying to move faster than your judgment can keep up.

What This Course Actually Covers

Four areas, built out across the next eight chapters:

• Recognizing manipulation aimed at you (Chapters 2–3) — phishing across email, SMS, and voice, and social engineering tactics that don't involve a suspicious link at all
• Verifying identity and handling resets safely (Chapters 4–5) — confirming who you're really talking to before acting, and the specific, high-risk case of a password reset request
• Recognizing a real incident and handling it without destroying evidence (Chapters 6–7) — the moment a "routine" ticket turns out not to be routine, and what to do (and not do) in the minutes right after
• Confidentiality and session hygiene (Chapters 8–9) — protecting the sensitive data that passes through support work every day, and locking down your own workstation and sessions

A Request That Isn't Resolved Yet

A message lands in the support queue midafternoon: "This is urgent — I'm locked out of my account and about to walk into a board meeting in five minutes. I can't verify by phone right now. Please just reset it and send the new password to this email."

Nothing about that message is resolved in this chapter — it's deliberately left open. Chapter 5 comes back to this exact request directly, once the identity-verification and password-reset material it depends on has actually been covered.

Hands-On Exercises

Phishing is the most common way an attacker reaches a support technician directly, and it now comes through three genuinely different channels — email, text message, and phone calls — each with its own specific tells. This chapter builds the concrete pattern-recognition Chapter 1's tip-box promised: manufactured urgency is the constant across all three, but the surface details differ enough that each channel deserves its own look.

Email Phishing

The classic channel, and still the most common. The red flags rarely show up one at a time — a genuine phishing email usually stacks several at once:

• Sender domain mismatch — a display name that looks legitimate ("IT Support Desk") hiding a domain that isn't
• Urgency and consequence — "within 24 hours," "your account will be suspended," "immediate action required"
• A generic greeting — "Dear User" instead of an actual name, since bulk phishing rarely has one
• A link whose visible text doesn't match its real destination — the single most reliable technical tell, and the easiest to check

The display text of that link reads exactly like the real password-reset page — that's deliberate. The actual destination, visible by hovering over the link (or reading its raw HTML source, as above) rather than clicking it, is a completely different domain. This gap between what a link says and where it actually goes is worth checking on every single link in a message that asks you to log in or reset anything.

SMS Phishing ("Smishing")

The same manipulation, compressed into a text message. Smishing relies on the format itself working in the attacker's favor — a text message has no visible "From" domain to inspect, sender IDs are trivially spoofed, and shortened links (bit.ly/..., t.co/...) hide their real destination by design, not just by accident.

• "Your package couldn't be delivered — confirm your address: [link]"
• "Unusual sign-in detected. Verify your identity now or your account will be locked: [link]"
• A sender ID that looks like a short internal extension or an official-looking company name, spoofable with no special tools

Voice Phishing ("Vishing")

The channel most likely to reach a support technician directly, and the hardest to fake-detect on instinct alone, because caller ID can be spoofed just as easily as an email's display name. A vishing call typically impersonates IT, a vendor, or an executive, and leans even harder on urgency than email or SMS, since a live conversation gives the caller room to keep pushing past hesitation in real time.

The specific attack worth knowing by name is the one-time-code relay: the caller triggers a genuine password reset or MFA challenge on the real account first, then calls claiming to be verifying your identity, and asks you to "read back the code we just sent you to confirm it's really you."

Red Flags That Appear Across All Three Channels

That last row connects directly back to Chapter 1's own framing: the request that asks you to skip verification "just this once, because it's urgent" isn't an edge case this course has to imagine — it's the single most common shape a real attack actually takes.

Hands-On Exercises

Chapter 2 covered phishing's three channels — but every one of them relied on a message: an email, a text, a call. This chapter covers the tactics that don't need a message at all — a fabricated backstory, a face pretending to be someone it isn't, or a lure left somewhere it's likely to be found. None of these show up in a typical "spot the phishing email" training, which is exactly why they're worth their own chapter.

Pretexting: The Fabricated Backstory

Pretexting is an invented scenario, built specifically to make a request feel routine and legitimate before the actual ask arrives. The backstory does the persuading; the request itself is often small enough to seem reasonable on its own.

Example: a caller identifies themselves as the manager of a new hire starting Monday, explains the new hire's laptop hasn't arrived yet, and asks for "just a temporary login" so the new hire can start onboarding paperwork from a personal device today. Every individual detail — a manager, a new hire, a shipping delay — is plausible in isolation. The backstory's job is to make the actual request (creating access outside the normal process) feel like a minor administrative favor rather than what it actually is.

Impersonation: Claiming to Be Someone Specific

Where pretexting invents a scenario, impersonation claims a specific identity — a named coworker, a known vendor contact, an executive, or even IT itself calling about IT's own systems. The more specific and verifiable-sounding the claimed identity, the more it discourages a target from questioning it.

• Executive impersonation — a request that name-drops urgency and authority together ("this is [CFO name], I need this handled before my flight")
• Vendor impersonation — someone claiming to represent a company you already do business with, asking for account details "to process a routine update"
• IT impersonation — perhaps the most direct threat to a support technician specifically, since it targets the exact trust relationship coworkers have with the support desk itself
• Physical impersonation (tailgating) — wearing a delivery uniform, a contractor badge, or simply carrying a box and walking confidently through a badge-locked door behind someone who holds it open

That last one is a preview of Chapter 9's own physical-security material — worth flagging here because it's a form of impersonation, not a separate category of threat.

Baiting: The Enticing Lure

Baiting offers something the target wants — curiosity, a free item, an exclusive download — with a malicious payload attached to the offer. The classic version is physical: a USB drive labeled Payroll_2026_Confidential.xlsx left in a car park, breakroom, or elevator, counting on someone's curiosity to plug it into a work machine. The digital version is the same idea online — a "free" tool, plugin, or download that quietly installs something unwanted alongside it.

Quid Pro Quo: Something for Something

A close cousin of baiting, framed as an even trade rather than a free gift. An attacker calls around an organization claiming to be IT support offering a "free security upgrade," and asks whoever picks up to run a specific command or temporarily disable a specific protection in exchange. Most employees who answer won't take the offer — but the attacker only needs one who does.

Comparing the Four Tactics

A Request That's Left Open Again

A call comes in: "This is Facilities — we've got a delivery emergency and need the loading dock badge reader temporarily disabled for the next twenty minutes." It's a blend of pretexting (the delivery-emergency backstory) and impersonation (claiming to be Facilities). Whether it's legitimate or not can't be determined from the call alone — and that's exactly the point.

Hands-On Exercises

Chapter 3 established the principle: a claim can only be verified through a channel the claimant doesn't control. This chapter turns that principle into a practical, repeatable process — and, just as important, one that scales with how risky the request actually is. Not every request needs the same amount of scrutiny, and treating a low-stakes question with the same suspicion as a password reset just trains people to route around your process rather than follow it.

Match Verification Effort to Risk, Not to Suspicion

Verification isn't a single on/off switch — it scales with what's actually being asked for:

The Chapter 1 reset request and Chapter 3's badge-reader call both sit firmly in the high tier — which is exactly why neither could be resolved on the spot in the chapters that introduced them.

Callback Verification, Done Properly

Chapter 3 established the core rule; here's what it looks like in practice. Never call back a number the requester provided — not the number they're calling from, not a number they read out over chat. Instead:

1. End or pause the current contact
2. Independently look up the person or department's number — an internal directory, an intranet page, a previously saved contact — never anything supplied in this specific conversation
3. Call that number and confirm the request directly

Applied to Chapter 3's badge-reader call: rather than acting on the caller's claim, or even calling back whatever number showed on caller ID, the technician looks up Facilities' own listed extension and calls that instead. If the person who actually answers has no idea what "delivery emergency" is being referred to, the original call is confirmed as fabricated — without ever having disabled anything.

Out-of-Band Confirmation

A close relative of callback verification, used when a phone call isn't the channel in question. If a request arrives over chat, confirm it through a different channel entirely — a known email address, an in-person check, or a separate messaging platform the requester doesn't control the identity behind. The principle is the same: never confirm a claim using only the same channel the claim arrived on, since that channel may itself be compromised or spoofed.

Why "Security Questions" Are Weaker Than They Feel

Knowledge-based checks like these are fine as one layer among several for medium-risk requests — they should never be the only check standing in front of a high-risk one.

Worked Example: Applying the Tiers

A chat message arrives: "Hey, it's Dana from Accounting, can you tell me what my temp password is? I'm locked out and have a deadline in ten minutes." This is a high-risk request (a credential) wearing a low-risk tone (a casual, friendly chat message). The risk tier is set by what's being asked for, not by how the request is phrased — so it gets high-tier verification regardless of how routine or friendly it sounds: an out-of-band callback to a number looked up independently, not a reply in the same chat thread.

Hands-On Exercises

A password reset is the single most common high-risk request a support desk handles, and the single most valuable one to an attacker — it grants direct account access, and because technicians handle dozens of legitimate resets every week, a malicious one is designed to look exactly like all the rest. This chapter applies Chapter 4's risk-tiered verification specifically to resets, and finally resolves the request left open since Chapter 1.

Why Resets Sit at the Top of the Risk Tier

Chapter 4's table placed password resets firmly in the high-risk tier alongside access grants and disabling security controls. A reset deserves that placement for a specific reason beyond "it's sensitive": once completed, it hands over full account access immediately, with no further step required — unlike, say, a leaked employee ID, which still needs to be combined with something else to be useful. A successful reset is the entire attack, done in one step.

The Safe Reset Procedure

1. Verify first, every time — full high-tier verification per Chapter 4, with no exception for urgency. Stated urgency is not a reason to skip a step; per Chapter 1, it's very often the reason the request exists at all.
2. Prefer self-service recovery over technician-mediated resets — a self-service flow tied to a previously registered device or authenticator app verifies identity through something the account owner already possesses, which no attacker on a cold call has access to.
3. Never transmit a new password in plaintext — not by email, not by chat, not read aloud over the phone. Use a forced reset-on-next-login instead, so no actual password value is ever something a technician hands over at all.
4. Never send the new credential through the same channel the request arrived on — the same out-of-band principle from Chapter 4, applied specifically to the response, not just the verification.
5. Document who requested it, when, and how it was verified — this record is exactly the evidence Chapter 7 needs if a reset later turns out to have been part of a real incident.

Resolving Chapter 1's Request

"This is urgent — I'm locked out and about to walk into a board meeting in five minutes. I can't verify by phone right now. Please just reset it and send the new password to this email."

Run through the procedure above: this is unambiguously high-risk (a reset), which means full verification, with no exception carved out for urgency. The stated inability to verify isn't a reason to bypass verification — following the reasoning from Chapters 1 through 4, it's the exact shape a real attack takes. The correct response isn't a flat refusal, though — it's holding the verification requirement while offering a path that doesn't require abandoning it: point the requester to the self-service recovery flow, which takes seconds and needs no phone call at all, or offer to verify with their manager directly while they're in transit. A genuine employee in a genuine hurry can complete either path in under a minute. A request that suddenly goes quiet once a real verification path is offered has told you everything you need to know.

MFA & Account Recovery Deserve the Same Treatment

Requests to reset, remove, or "temporarily disable" multi-factor authentication are at least as high-risk as a password reset — arguably higher, since MFA exists specifically to catch an account compromise even after a password has already been stolen. Removing it doesn't just grant access; it removes the safeguard that would have caught the very attack in progress.

Unsafe vs. Safe, Side by Side

Hands-On Exercises

Chapters 2 through 5 were about stopping an attack before it succeeds. This chapter is about what happens after one already might have — recognizing the moment an ordinary-looking ticket is actually an early sign that something has already gone wrong, not a normal request to work through as usual.

Where This Sits Relative to `incident1`

This site's own Incident Response & Ticketing Workflows course teaches classification, severity, and escalation — but all of that starts from a ticket already recognized as a security-relevant incident. This chapter covers the step before that: noticing that a given ticket even belongs in that category in the first place. `incident1`'s own material picks up exactly where this chapter leaves off.

Symptoms Worth a Second Look

• "I'm getting weird emails from myself" — a classic sign of a spoofed or compromised mailbox, not a glitch worth dismissing
• Unexpected password-reset emails the user didn't request — someone else may already be attempting to take over the account
• An unfamiliar sign-in notification — "new device" or "new location" alerts the user doesn't recognize
• Several users reporting similar odd behavior around the same time — a pattern, not an isolated glitch, and worth treating differently from a single one-off report
• An unfamiliar file, process, or browser extension the user didn't install — a possible sign of malware, especially following Chapter 3's baiting material
• Unusual slowness paired with unusual network activity — often has a perfectly mundane explanation per `perfdiag1`/`netdiag1`, but worth asking the question rather than assuming the boring explanation automatically

The One Question That Actually Matters

Not every odd symptom is an attack — most aren't. But a genuine security lens means actually asking, for each one: could this innocuous-looking symptom also be an early sign of compromise? — rather than reaching for the most boring available explanation by reflex, every single time.

The Same Symptom, Read Two Ways

Both Failure Modes Have a Real Cost

Treating every odd symptom as a full security incident produces the same problem Chapter 4 warned against for over-verification: alert fatigue, wasted investigation time, and a support process people learn to route around. But never asking the question at all means genuine early warning signs quietly pass by unnoticed until the damage is much larger. The goal isn't maximum suspicion — it's asking the one question above, consistently, and only escalating when the answer to it is genuinely "yes, this could be."

Worked Example: The Sync Bug That Wasn't

A user reports their email "isn't syncing right on their phone" — missing some messages, sent items appearing they don't remember sending. The routine read is a sync glitch, worth a quick app restart. Reading it through the lens above instead, a check of the account's own mail rules turns up a forwarding rule the user never created, quietly copying every incoming message to an external address. This is a well-known pattern in real account-compromise cases: once an attacker gains access, a forwarding rule lets them keep reading the mailbox even after the original login is noticed and the password changed.

Hands-On Exercises

Chapter 6 ended with a warning: don't quietly fix a suspicious finding the moment you spot it. This chapter covers exactly what to do instead — the same "evidence over guesswork" discipline `log1` built this entire subject around, and the same "capture before mitigate" sequencing `incident1`'s own Chapter 6 taught, both applied here to the specific moment a support technician finds a possible compromise.

Evidence First Isn't Optional — It's the Whole Point

Per `log1`'s own foundational argument, real evidence beats guesswork every time. Applied here: the very first thing that happens after a suspicious discovery determines whether anyone investigating it later has anything real to work from, or only someone's memory of what they think they saw.

The Capture-vs-Mitigate Tension, Resolved

`incident1`'s own Chapter 6 named this tension directly for general incidents: fixing something immediately can destroy the exact evidence needed to understand it, but leaving something broken indefinitely just to preserve evidence isn't right either, especially when it's actively causing harm. A live forwarding rule quietly leaking mail is exactly this case — every minute it stays in place is another minute of exposure.

What Not to Do

Worked Example: Resolving Chapter 6's Forwarding Rule

Returning to the ticket from Chapter 6 — the mail-forwarding rule quietly copying every message to an external address. Applying the sequence above: the technician screenshots the rule's exact configuration and creation timestamp, notes exactly when and how it was found, then disables the rule within minutes to stop the ongoing leak, and immediately escalates the documented finding through the organization's incident process rather than continuing to investigate alone.

Hands-On Exercises

Chapters 6 and 7 covered what to do once something is actually wrong. This chapter is about something quieter and far more constant — the sensitive data support work touches on every single ticket, incident or not. A support technician routinely sees more personal and account data than almost any other role in an organization, simply as a byproduct of doing the job well.

Least Exposure, Not Least Effort

`remote1`'s own Chapter 6 established least privilege for access — only reaching for the permissions a task actually needs. The same principle applies to data: only look at, record, or copy what's actually needed to resolve the ticket in front of you. During a remote session, that means resisting the pull to browse unrelated files or folders "just because you can see them" — the fact that access is technically available doesn't make looking at it appropriate.

Ticket Notes: Write What's Needed, Not What's Available

Ticket systems are often readable by a wider audience than the sensitive data pasted into them warrants — other technicians, reporting tools, sometimes exported logs. Never paste a password, a full card number, or an identification number into a ticket note, even "just temporarily" to reference later.

The safe version records exactly what a later reader needs — that verification happened, and how — without also recording the sensitive material itself.

Screen Sharing: What You See Isn't Yours to Keep

`remote1`'s own Chapter 5 covered the trust model behind screen sharing; this chapter covers what happens when that shared screen shows something unrelated and sensitive — another open tab with a coworker's HR record, a personal message, anything outside the scope of the actual ticket. Don't linger on it, don't comment on it, and don't note it anywhere unless it's genuinely relevant to a real security concern. Seeing something incidentally isn't a license to act on it or discuss it.

Data Minimization When Pulling Records

When troubleshooting requires querying or exporting data, pull only what the specific ticket needs — a single account's records, not a full table export, even if a broader export would be more convenient to work from. This is the same underlying principle `dbsec1` teaches from the database-administration side, applied here to the everyday habits of support work rather than to system design.

Sending Sensitive Data Safely

Chapter 5 already established never sending a password in plaintext. The same rule extends to any sensitive data: never over an unencrypted channel, and never to a personal email address, no matter how much faster it would be for the person asking. If a legitimate business reason exists to transfer sensitive data, it should go through a channel your organization has actually approved for that purpose — not whatever's most convenient in the moment.

Hands-On Exercises

Every chapter so far has focused on requests, tickets, and data flowing through a support technician. This chapter turns to something more basic and easy to overlook: the technician's own workstation. It's not just one more employee's device — it's typically a hub with a reach far wider than any single account, and that reach is exactly why it deserves its own chapter.

Why This Workstation Specifically Matters More

A compromised regular employee workstation typically exposes that one person's own accounts and data. A compromised support workstation is different in kind: it often has active sessions into ticketing systems, remote-access tools (`remote1`'s own territory), and sometimes elevated or admin-capable credentials — reaching many other accounts and systems at once. Compromising it doesn't just expose one identity; it hands an attacker the exact tools this course has spent eight chapters teaching how to recognize being misused against someone else.

The Habit That Matters Most: Locking the Screen, Every Time

Chapter 3 covered physical impersonation — someone walking through a badge-locked door by looking like they belong. An unlocked, already-authenticated support workstation removes the need for any of that effort at all; the badge-locked door and the fake delivery uniform become irrelevant if the workstation itself is simply sitting open. Lock the screen every time you step away, including "just a minute" — that's precisely the length of time an opportunistic attempt actually needs.

Session Hygiene

• Close sessions when finished — per `remote1`'s own "clean disconnection" standard, don't leave remote-access sessions or admin panels open indefinitely once a ticket is resolved
• Short auto-lock timeouts — a workstation that locks itself after a brief idle period limits the damage of a forgotten manual lock
• Separate everyday and elevated accounts — per `remote1`'s own least-privilege material, don't stay logged into an admin-capable account as your default; switch into it only for the specific task that needs it

Physical Security Basics

• Use a cable lock or equivalent for a laptop in any semi-public space
• Never leave a workstation unattended in a public or semi-public area, even briefly
• Use a privacy screen if your desk has visual exposure to sensitive ticket or account data from a walkway or shared space
• Store any physical security tokens or hardware keys securely, separate from the device they unlock — the same reasoning as never leaving a house key in the lock

Credential Hygiene for Your Own Accounts

Everything Chapter 5 assumed on the end user's side applies just as directly to a support technician's own accounts: a unique, strong password per account, MFA enabled everywhere it's offered, and a password manager rather than reused or written-down credentials. A technician who skips this for their own accounts while enforcing it strictly for everyone else is protecting the wrong side of the relationship.

Hands-On Exercises

Nine chapters built the toolkit — recognizing phishing and social engineering, verifying identity, resetting credentials safely, spotting a routine ticket that isn't, handling a finding without destroying evidence, protecting data, and securing your own workstation. This capstone runs three fresh tickets through that toolkit end to end, matching the three-scenario shape most of this subject's own courses use.

Ticket 1: A Phishing Report That Wasn't Caught in Time

A user forwards a suspicious email to the support desk: "Is this legit? It's asking me to verify my account."

Ticket 2: An Unfamiliar App With Account Access

A user mentions, almost in passing, that they've been seeing occasional strange sign-in notifications lately — nothing that seemed urgent enough to report on its own.

Ticket 3: An Urgent Reset Request, In Person

Someone walks up to the support desk directly: "Hi, I'm starting today, my manager said to come find you — I need my account unlocked right now, I've got a meeting in ten minutes and no one told me my temporary password."

Chapter Attribution

Honest Scope Note

Hands-On Exercises