Lesson 1: Social Engineering, Attacks, and Vulnerabilities

A finance employee receives an urgent message that appears to come from an executive.

It asks for a payment-account change and says the request must be completed immediately.

What do we know?

We know a message arrived.

We know the display name looks familiar.

We know the request creates financial risk and uses urgency.

We do not yet know that the executive actually sent it.

That gap between appearance and verified identity is where social engineering lives.

Social engineering attacks the decision process

Social engineering tries to make a person perform an action the attacker wants by exploiting trust, urgency, fear, authority, curiosity, or habit.

The defensive skill is not becoming suspicious of every human interaction.

It is knowing which claims deserve independent verification before a high-impact action.

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

The phishing family changes the delivery path, not the core idea

Phishing

Broad deceptive email or web messaging intended to influence many recipients.

Spear phishing

Targeted phishing aimed at a specific person or group.

Whaling

Targeted social engineering aimed at high-value executives or decision-makers.

Smishing

Deceptive SMS or text messaging.

Vishing

Voice-based deception.

QR phishing

A QR code sends the user toward a deceptive or unsafe destination.

The QR code does not make the request trustworthy. It only hides the destination from casual inspection until the code is scanned.

A safe response is to verify through a known channel rather than interacting with the suspicious path.

Business email compromise attacks the business process

Business email compromise, or BEC, often uses impersonation or compromised communication to manipulate payment, account, payroll, or sensitive-information workflows.

The important control is not simply "train users not to click links."

Financial and account changes should have approval and verification processes strong enough that one convincing message cannot override them.

Security is architecture around human decisions too.

Physical information leakage does not require malware

Shoulder surfing

Someone observes sensitive information directly from a screen, keyboard, badge, or document.

Tailgating

Someone follows an authorized person through a controlled entrance without completing the required access process.

Impersonation

Someone pretends to be a trusted person, vendor, technician, or authority.

Dumpster diving

Someone recovers useful information from improperly discarded material.

These threats explain why privacy screens, access procedures, secure disposal, and identity verification matter even when the endpoint is perfectly patched.

Availability attacks are different from account compromise

A denial-of-service attack attempts to make a system or service unavailable.

A distributed denial-of-service attack uses many sources or systems to create that disruption.

The user-visible result may be a slow or unavailable service.

That symptom alone does not prove DDoS. Provider failure, application overload, routing problems, or legitimate traffic spikes can look similar.

Scope and upstream evidence matter.

An evil twin attacks wireless trust

An evil twin is a deceptive wireless network made to resemble a legitimate one.

The defensive lesson is not to practice creating one.

It is to understand that SSID names are labels, not identity proof.

Approved enterprise authentication, certificates, managed profiles, and user verification can provide stronger evidence about the real network.

Spoofing means some identity characteristic is falsified

Spoofing can involve an apparent sender, source address, caller identity, or another system characteristic.

A displayed identity can be useful context.

It is not always cryptographic proof of origin.

When the action is high impact, use an independent verification method.

On-path threats exploit position between communicating systems

An on-path attacker attempts to observe or alter communication between parties.

The defensive implications include protected protocols, certificate validation, trusted network configuration, and avoiding casual bypass of trust warnings.

If a browser suddenly reports a certificate-name or trust problem on a familiar service, clicking through it throws away exactly the evidence the browser is giving you.

Brute force and dictionary attacks target authentication

A brute-force approach repeatedly guesses possible credentials.

A dictionary approach uses likely password candidates or word-based lists.

You do not need to perform either technique to understand the controls that reduce risk:

• strong unique passwords;
• MFA;
• failed-attempt lockout;
• rate limiting and monitoring;
• password managers;
• disabling unnecessary exposed authentication services.

Insider threat starts with legitimate access

An insider threat involves risk originating from someone who already has some legitimate access or relationship with the organization.

That makes least privilege, logging, separation of duties, DLP, and access lifecycle important.

Authentication alone cannot solve misuse by a valid identity.

Zero-day describes the fix gap

A zero-day vulnerability or exploit condition exists before a normal known-fix cycle has fully addressed the issue.

That is why security cannot depend only on patching.

Other layers such as least privilege, application control, segmentation, endpoint detection, backup, and response still matter.

Application vulnerabilities are recognition boundaries for technicians

SQL injection

Improperly handled application input can alter database-query behavior.

The technician-level defensive response is recognition, patching, safe configuration, and escalation to the application or security owner.

Cross-site scripting

Improperly handled web content can allow untrusted script content to execute in a user's browser context.

Again, the support role is recognition and defensive response, not reproducing the attack.

Supply-chain risk arrives through something you trusted

A supply-chain or pipeline compromise can enter through software suppliers, dependencies, updates, build systems, or vendors.

That creates an uncomfortable but important rule:

A familiar source is useful evidence. It is not absolute proof that the artifact is safe.

Organizations use trusted repositories, integrity/signature checks, staged deployment, monitoring, and vendor response because trusted paths can still fail.

Vulnerability is often a system state, not an attack

A system can become vulnerable because it is:

• non-compliant;
• unpatched;
• unprotected;
• end-of-life;
• unmanaged BYOD outside required policy.

No attacker needs to be present for the risk to exist.

A working unsupported laptop can still be an unacceptable endpoint.

Worked case: urgent payment change

Evidence:

message: unexpected
request: financial account change
urgency: high
sender display name: familiar
independent verification: not yet performed

The correct first response is not to reply to the message asking whether it is real.

Use the organization's known approval and contact process.

Why?

Because replying stays inside the same unverified communication channel.

Worked case: unexpected QR login request

Evidence:

message: unexpected
QR code: requests account verification
user has not scanned it
sender resembles known vendor

Safe response:

• do not scan the code;
• use the known legitimate service path independently;
• report the suspicious artifact under policy.

The goal is to verify without entering the attacker's chosen path.

Build a threat-recognition matrix

For supplied fictional cases, document:

observable indicator
threat / vulnerability category
asset at risk
non-malicious alternative where plausible
what is NOT proven
safe immediate response
verification or escalation path
control that would reduce recurrence

Include phishing, spear phishing, whaling, vishing, smishing, QR phishing, shoulder surfing, tailgating, impersonation, dumpster diving, DoS/DDoS, evil twin, zero-day, spoofing, on-path, brute force, dictionary, insider threat, BEC, supply-chain risk, SQL injection/XSS recognition, and vulnerable endpoint states.

Before you move on

Threat recognition should make your next action safer.

If recognizing the threat makes you want to click the suspicious link, scan the QR code, or "test" the live system, you moved in the wrong direction.

Next we deal with malware, where symptoms overlap even more and containment matters before certainty.