Social Engineering and Phishing

Why people are targeted

Social engineering is the manipulation of people into doing something that helps an attacker: revealing a password, opening a file, transferring money or holding a door open. It targets human nature instead of software, which makes it effective against even well-patched organizations: one convincing email can bypass millions of euros' worth of technology.

Social engineering works because it abuses traits that are normally good — helpfulness, respect for colleagues, the wish to do your job quickly. The same psychological levers appear again and again:

(CFO: chief financial officer.) Many attacks combine several levers: an "urgent" request from the "director" about a "confidential" acquisition. Recognizing the lever is often easier than recognizing the technical trick — if a message pushes you to act fast and skip the normal process, slow down.

Phishing and its variants

Phishing is a social engineering attack in which the attacker sends a fraudulent message, pretending to be a trustworthy party, to make the recipient click a link, open an attachment, enter credentials or transfer money. It is one of the most common ways attacks start. The name is a play on "fishing": cast out bait and see who bites.

(HR: human resources; CEO: chief executive officer; QR: quick response.)

Spear phishing and whaling

Spear phishing is phishing aimed at a specific person, group or organization, using details about them — names, roles, projects, suppliers — to make the message believable. Attackers collect those details from company websites, social media and earlier breaches. Whaling is spear phishing aimed at senior executives ("big fish"), whose authority and access make them especially valuable. The defense is the same as for all phishing, but awareness that "this message knows a lot about me" does not make it genuine.

Vishing, smishing and QR codes

Vishing (voice phishing) uses phone calls or voicemail. Caller ID can be faked, so a call that appears to come from your bank or your own help desk proves nothing. Voice cloning with AI now makes it possible to imitate a known voice from a short recording, which is another reason to verify requests through a separate channel rather than by recognizing a voice.

Smishing (SMS phishing) uses text messages and chat apps. Phones show little of a link's address, and people read messages quickly between other things. A familiar example is the "Hi Mum" scam: a "child" writes from a new number and soon needs an urgent payment.

QR codes hide the address entirely until you scan them, and they move the attack from a protected work computer to a personal phone outside the company's email filters. Treat a QR code like a link: check the address the camera shows before opening it.

Business email compromise

Business email compromise (BEC) is fraud in which an attacker uses a hijacked or convincingly faked business email account to trick an organization into paying money or sending sensitive data. Typical forms are CEO fraud (the "director" orders an urgent, confidential transfer) and invoice fraud (a "supplier" announces new bank details). BEC often contains no link or attachment at all, so technical filters miss it — and because the mailbox may be a real, compromised one, the sender address can be perfectly correct.

The defense is process, not technology: changes to bank details and unusual payments are always verified by calling the supplier or manager on a phone number you already have (from the contract or directory, never from the email), and large payments need approval from a second person.

Pretexting

Pretexting is creating an invented scenario — a pretext — that gives the attacker a believable reason to ask for information or action: a new colleague who is locked out, an auditor who needs a list of accounts, a technician who must "check the network cabinet". The story is often built over several contacts, each collecting a small, harmless-looking detail that makes the next request more convincing.

Red flags

No single sign proves a message is phishing, and a skilled attacker avoids most of them. Use these as reasons to stop and verify:

• Sender address versus display name. The display name says "IT Service Desk", the actual address is servicedesk@example-support.net. Mail apps often show only the name — tap or hover to see the address. Note that a correct address is no proof: it may be spoofed or a real, compromised account.
• Mismatched links. Hover over a link on a computer (or long-press on a phone) and read where it really goes before clicking. The visible text can say anything.
• Urgency and pressure. Deadlines, threats, "do not tell anyone", "I'm in a meeting, just do it".
• Unusual requests. Gift cards, changed bank details, password or MFA codes, a payment outside the normal process, a request to install remote-support software.
• Unexpected attachments. Especially archives, documents that ask you to "enable content" or "enable editing", and files with double extensions like invoice.pdf.exe.
• Login pages reached from a message. A legitimate service rarely needs you to log in through an email link. Go to the site through your own bookmark instead.
• Something feels slightly off. An unusual tone, a greeting the person never uses, a request at an odd time. Trust that feeling enough to check.

Reading a link

The part of an address that tells you who you are really dealing with is the registered domain. Take the host name (between :// and the next /), then read it from right to left: the top-level domain plus the name just before it (example.net) is the registered domain. Everything to the left of the registered domain can be chosen freely by whoever owns it.

The program below applies these checks to a few made-up links, all on reserved example domains. For each one it compares the text a reader would see with where the link really goes, using urllib.parse from the standard library. It is a teaching aid, not a filter: real email security products do much more, and use the Public Suffix List to find the registered domain correctly for names like example.co.uk.

from ipaddress import ip_address
from urllib.parse import urlsplit

# (text the reader sees, where the link really goes) - all made up
links = [
    ("www.example.com/account", "https://www.example.com/account"),
    ("www.example.com", "https://www.example.com.example.net/login"),
    ("www.example.com", "https://www.example.com@192.0.2.10/login"),
    ("www.example.com", "https://www.еxample.com/"),  # Cyrillic "е"
    ("Verify your account", "https://example.org/verify"),
]


def registered_domain(host):
    """Last two labels: good enough for this demo, wrong for e.g. .co.uk."""
    return ".".join(host.split(".")[-2:])


def findings(text, href):
    parts = urlsplit(href)
    host = parts.hostname or ""
    notes = []
    if parts.username:
        notes.append(f"'@' in address: browser goes to {host}")
    try:
        ip_address(host)
        notes.append("destination is a bare IP address")
    except ValueError:
        pass
    if not host.isascii():
        notes.append("non-ASCII letters in the name (look-alike?)")
    shown = urlsplit("https://" + text).hostname if "." in text and " " not in text else None
    if shown is None:
        notes.append(f"text is not an address; real destination {host}")
    elif registered_domain(shown) != registered_domain(host) and not notes:
        notes.append(f"shows {registered_domain(shown)}, goes to {registered_domain(host)}")
    return notes or ["text and destination agree"]


for number, (text, href) in enumerate(links, start=1):
    print(f"{number}. {text!r}")
    for note in findings(text, href):
        print(f"   - {note}")

1. 'www.example.com/account'
   - text and destination agree
2. 'www.example.com'
   - shows example.com, goes to example.net
3. 'www.example.com'
   - '@' in address: browser goes to 192.0.2.10
   - destination is a bare IP address
4. 'www.example.com'
   - non-ASCII letters in the name (look-alike?)
5. 'Verify your account'
   - text is not an address; real destination example.org

What each finding means:

1. Text and destination agree.
2. The address starts with www.example.com, but the registered domain is example.net.
3. In a web address, everything before an @ is treated as a user name, so the browser goes to the IP address behind it. Legitimate links almost never look like this.
4. The name contains a Cyrillic letter "е" (е) that looks identical to the Latin "e". Browsers show such names as xn-- (Punycode) in some situations precisely to expose this.
5. The text is not an address at all, which is normal — but only hovering tells you where it goes.

MFA fatigue and help desk attacks

Multi-factor authentication (MFA, see Remote Access) stops most attacks with stolen passwords, so attackers target the second factor too — again through people.

MFA fatigue (push bombing)

An attacker who has someone's password tries to log in again and again, so the victim's phone shows approval prompt after prompt, sometimes late at night. The attacker hopes the victim approves one by accident, to make it stop, or after a phone call from "IT" saying "just approve it, we are fixing your account".

• For users: never approve a prompt you did not start. An unexpected prompt almost certainly means someone else has your password — deny it, report it and change your password.
• For administrators: enable number matching (the user types the number shown on the sign-in screen into the authenticator app; it stops blind approvals, but not a real-time relay phishing site, which shows the number too), show the location and application in the prompt, limit the number of prompts, and move toward phishing-resistant methods such as passkeys and hardware security keys (see Passwords and Authentication).

Phishing-resistant methods matter for another reason too: some phishing sites relay the login to the real service in real time and capture the resulting session, which defeats one-time codes and push approvals. Passkeys and security keys are bound to the real web address, so they do not work on a lookalike site.

Help desk social engineering: verifying callers

A help desk exists to help people regain access, which makes it a prime target: an attacker who talks an agent into resetting a password or registering a new MFA device takes over the account without any technical attack. Several widely reported incidents in recent years started exactly like this, with a convincing phone call to an IT help desk.

Practical rules for help desk staff:

• Verify identity with something the caller cannot easily look up. Name, employee number and manager's name can be found on social media or in earlier leaks. Verify identity as strongly as practical — a callback to a number on file plus a manager's confirmation, or in-person ID; treat a video call alone as insufficient, since faces and voices can be faked.
• Call back, do not call through. Hang up and call the person on a number you look up yourself — never one the caller gives you.
• Be extra careful with high-impact requests: MFA resets or new devices, password resets for administrators or executives, and requests to remove security controls. These deserve a stricter procedure, ideally with a second approver.
• Never ask for or accept passwords or MFA codes. Legitimate IT staff do not need them, and saying so out loud teaches users the same rule.
• Pressure is a signal. An angry "executive" who is "about to board a plane" is exactly the situation the procedure is for. Following it is never wrong; your manager should back you.
• Log and report. Record every reset in the ticket, and report suspicious calls to the security team even if you refused — the same attacker may call a colleague next.

What to do: report, verify, recover

Reporting is the single most useful thing anyone can do. One report lets the security team remove the same message from every mailbox, block the sender and the link, and warn others — often within minutes.

• Use the report button (often a "Report phishing" button in the mail app) or forward the message as instructed by your security team. Do not forward it to colleagues to ask their opinion.
• Never "just check" a link or attachment. Opening a suspicious link to see what happens is exactly what the attacker wants; visiting can be enough to reveal that your address is active, and some pages try to exploit the browser. Analysis is the security team's job, in a safe environment.
• Verify through a second channel. Call the colleague, supplier or bank on a number you already know. Do not reply to the message itself.

If you clicked

Everyone can be fooled once; what matters is what happens next. Speed beats embarrassment.

1. Report it immediately to the help desk or security team, and say exactly what you did: clicked, entered a password, approved a prompt, opened a file, made a payment.
2. If you entered a password: change it at once from a device you trust, and anywhere else you used the same password. The security team may also end all active sessions for the account.
3. If you opened a file or installed something: follow your organization's instructions. Often that means disconnecting the device from the network (unplug the cable, switch off Wi-Fi) but leaving it switched on, so that evidence is preserved — unless you are told otherwise.
4. If money was transferred: contact your bank straight away; a recall is sometimes possible when the bank acts within hours.
5. Keep the message; do not delete it. It is evidence and helps find other recipients.

What happens afterward is covered in Incident Response.

Awareness training and simulations

Technical controls catch most phishing before it arrives: spam and malware filters, link rewriting, a banner on external mail, and email authentication — Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting and Conformance (DMARC) — which make it harder to send mail in your domain's name — they do not stop lookalike domains. What gets through meets people, and people learn best by practice.

Security awareness training teaches staff to recognize and report social engineering. It works best when it is short, regular and specific to people's work: finance staff learn about invoice fraud, help desk staff about caller verification.

Phishing simulations send realistic but harmless test emails and show a short explanation to those who click. Done well, they build a reporting habit; done badly, they destroy trust. Ethical simulations:

• Are approved and announced in general terms ("we run simulations throughout the year"), with clear rules about what is measured.
• Teach, never punish or publicly name people who clicked.
• Avoid cruel lures — fake bonuses, layoffs, health scares — that damage trust in the employer more than they teach.
• Measure the reporting rate and the time to first report, not only the click rate: a high number of quick reports means the organization would catch a real attack early.
• Respect privacy: individual results are personal data. Involve the privacy officer and, where required, employee representatives such as a works council (in the Netherlands the ondernemingsraad) before monitoring individual behavior.