Phishing & Social Engineering.

A convincing message can cross a trust boundary.

In Lesson 01, you learned to separate assets, weaknesses, threat events and risk. In Lesson 02, you learned that identity verification and authorization are different controls. An attacker may try to bypass both by persuading a real employee to perform an action voluntarily.

This lesson covers common communication-based attacks from the defender's perspective. It does not teach how to target real users, operate phishing kits, or click dangerous links. Every example uses fictional names and inert test-domain addresses.

Social engineering targets decisions, not just computers.

Start by identifying what action the sender wants and why the request might be unsafe.

Social engineering is an attempt to influence people into making decisions that benefit an attacker. A malicious actor might impersonate a coworker, vendor or technical support, and ask someone to disclose information, open an attachment, approve a sign-in or transfer money. The underlying weakness is often a trust assumption or a workflow with insufficient verification—not necessarily a missing software update.

A suspicious request is not automatically proof of compromise. Treat the message as an observable artifact, and distinguish what it says from what can be independently established. The defender's job is to slow down the unsafe decision, preserve useful evidence and route the issue through approved channels.

Phishing is a message-based social engineering attack.

Recognize the goal, not just whether the message looks sloppy.

Phishing uses deceptive messages to prompt a recipient to reveal information, visit an attacker-controlled page, open harmful content, approve an authentication request or carry out an unauthorized business action. Email phishing is common, but similar lures arrive through texts, phone calls, collaboration apps and QR codes.

Attackers may use polished writing, familiar branding, real names and references to genuine projects. Misspellings can be a clue, but the absence of errors is not evidence that a message is genuine. A legitimate-looking email can also be sent from a real account that an attacker has taken over. Ask what the recipient is being pressured to do.

Urgency and authority are tactics—not verification.

A rushed decision can bypass a normal control that would otherwise work.

A message may claim the CEO needs a wire transfer before a meeting, that an account will expire in ten minutes, or that the security team must receive an MFA code immediately. Other lures use curiosity, fear, sympathy or rewards. These emotional hooks encourage the recipient to act before checking the request.

Urgency alone is not evidence of fraud: real emergencies exist. Compare the request with the organization's established workflows. A business-critical change should still have a verifiable owner and approved exception process. The more consequential the action, the more valuable it is to confirm through a separate, known channel.

Display names, email addresses and domains answer different questions.

Treat the sender line as one clue in a broader investigation.

An email display name is free-form text visible in many mail clients. It can say 'Northstar Security' even when the actual sender address is unrelated. The domain is the part of an email address after @; northstar.example.test and northstar-support.example.test are different names, even if both look plausible. In a URL, the registered domain must be identified carefully; a trusted brand appearing earlier in a hostname does not make the final domain trustworthy.

Replies can be redirected to a different Reply-To address, and attackers may use lookalike domains or compromised legitimate accounts. Even a matching domain does not prove the request is authorized. The evidence may show where a message came from; it usually cannot prove who at the organization intended the action.

A link can be misleading even when its visible text is familiar.

Learn what can and cannot be concluded from URL components.

An HTTPS URL has a scheme such as https://, a hostname, and a path. HTTPS indicates transport encryption when correctly configured; it does not guarantee that the operator or page is trustworthy. A hostname such as payroll.northstar.example.test.evil.example.test is under evil.example.test, not northstar.example.test. Query parameters and redirects can further obscure the final destination.

When a message is suspicious, do not test the destination by opening it in your normal browser or scanning an unknown QR code with your personal phone. A mail security team may examine URLs with approved tooling and isolation. For this course, displayed addresses are inert examples, not clickable links.

Attachments, QR codes and conversations can all carry the lure.

Never treat an unfamiliar file or QR destination as safe because it looks routine.

A document attachment may request macros or other active content; an archive may hide a program; a QR code may steer a phone to a fake sign-in page. A collaboration chat might present a file-share link as if it came from a coworker. The exact harmful behavior depends on the content and endpoint protections, so do not label every attachment as malware without examination.

Use the organization's approved reporting and analysis process. Preserve the original suspicious item, avoid forwarding dangerous links or files broadly, and do not enable macros or execute files to 'see what happens.' For this lesson, no suspicious content is ever opened or executed.

Email authentication can strengthen origin evidence—but not prove intent.

Treat SPF, DKIM and DMARC as signals, not guaranteed verdicts.

SPF (Sender Policy Framework) helps a receiving service check whether an IP was permitted by the envelope sender's domain. DKIM (DomainKeys Identified Mail) provides a signature that can support integrity and domain responsibility for signed message parts. DMARC (Domain-based Message Authentication, Reporting, and Conformance) connects selected checks to the visible From domain through alignment and domain policy.

A 'pass' means a relevant technical authentication check succeeded according to the service's evaluation. It does not mean the message is benign: a malicious sender can authenticate their own domain, and a compromised legitimate account may send authenticated mail. Header results need to be correlated with sender context and the requested action. This course introduces these terms; configuring records belongs in a later defensive module.

Business email compromise attacks business processes.

Not every harmful message asks for a password.

Business email compromise (BEC) describes fraud in which attackers impersonate or use trusted business identities to induce unauthorized actions, often changing payment details or requesting transfers or sensitive information. A compromised vendor mailbox can be more convincing than a crude lookalike address, so simple sender-domain checking cannot replace business verification.

Many organizations require independent confirmation for new bank instructions, changed payees, high-value payments or unusual requests for customer data. A technician investigating the email should preserve the request and notify the right team instead of personally approving the transfer or declaring the sender trustworthy based on technical email checks.

Credentials and MFA approvals are separate attack targets.

A request for your sign-in factor is a warning even when the message mentions security.

Credential phishing tries to collect passwords or sign-in information through an impersonated portal or conversation. An adversary may also trigger repeated MFA prompts and pressure someone to approve them, or ask for a one-time code. Users should not approve unexpected prompts or share codes; they should report the event and follow their organization's account-protection procedure.

A malicious website may appear indistinguishable from the real one, and a successful sign-in method does not make every session theft impossible. Phishing-resistant authenticators can reduce certain impersonation paths, but an investigation still needs session, sign-in and account evidence before claiming an account was compromised.

Investigate signals together and separate fact from inference.

A risk indicator asks for investigation; it rarely proves a whole incident by itself.

Start with observable facts: the complete sender address, Reply-To, message timestamps, the stated request, displayed destination, actual hostname as available through approved tools, and whether recipients interacted. Additional sources may include mail gateway disposition, delivery logs, user reports and sign-in alerts. Record the origin of each observation and any uncertainty.

A suspicious domain is an indicator, not automatic proof of credential theft. Conversely, a domain that passes SPF and DKIM is not evidence that a payment change was authorized. Different explanations may fit the same artifact. State the narrowest conclusion supported by available evidence and identify the next verification step.

Report safely and verify through an independent channel.

Your first response should not create another incident.

If you receive a suspicious message, avoid its links, attachments, QR codes and callback information. Use your organization's reporting control or service desk/security channel, preserving the original artifact as policy directs. For an unexpected vendor change, initiate verification using previously trusted contact details rather than replying to the message.

If someone has already submitted credentials, approved an unexpected MFA prompt, opened active content or sent money, the action is no longer 'just a suspicious message.' Escalate promptly and provide a factual timeline of what was done. Do not delete potential evidence, run unapproved forensic tools or publicly distribute the sample. Exact containment steps belong to the responsible security and incident-response teams.

Analyze a complete message before deciding what it proves.

Practice documenting the message, the pressure, the indicator and the safest next verification.

The Message Investigation Workbench below presents fictional messages with inert addresses and sample authentication observations. Your goal is to identify defensible indicators, choose a safe next action and distinguish a plausible concern from a confirmed incident. You are not being asked to click suspicious links or execute attachments.

The workbench intentionally includes an authentic vendor message that is still unsafe to approve without process verification and a plausible legitimate message that should be verified rather than automatically labeled an attack. A good defender does not assume every unexpected email is malicious or every passing technical authentication check is benign.

What do you know—and what is only suspected?

An email apparently from a vendor requests a payment change, passes SPF/DKIM/DMARC and includes a new callback number. We know an unusual change was requested and domain checks passed. We do not know that the change is authorized, the account is safe, or that it has been compromised. The defensible action is to hold processing and verify through previously known contacts.

The next cybersecurity modules will explore malware, credential attacks and how defenders correlate evidence across systems. This lesson prepares you to recognize the initial lure without treating every suspicion as a confirmed incident.

Know where the recommendations come from.

All information required for Practice is in this lesson. These official references provide additional context for safely recognizing, reporting and responding to phishing.