The fake verification page that delivered Lumma Stealer exploited nothing in the browser. It presented a dangerous command as a routine step and relied on the visitor to run it, the technique Part 1 introduced as ClickFix. The same approach works by email, phone, and text message, targeting people who would never open a suspicious attachment.

Social engineering is the one infection route that targets people rather than software. We begin with why people comply, then cover phishing and its targeted forms, lookalike domain names, attacks by phone and text message, and the technical controls that limit what a deceived person can do.

How Social Engineering Works

A request can gain cooperation by appearing to belong to an existing job, relationship, or security procedure. The attacker gets the system to perform an action it would otherwise refuse.

Social engineering manipulates someone into revealing information or taking an action that weakens security. The requested action might be opening a document, approving a login, installing software, or changing an account’s recovery information. The technique targets the decision that grants authority rather than the mechanism that enforces it.

Social engineering needs no vulnerability. The software does exactly what it was designed to do, with the permissions of a user who chose to act. That makes it cheap, since there is no flaw to find and no exploit to write. It also makes every person with access a possible entry point. A software flaw can be repaired on millions of machines with one patch. You can’t patch the habits of human judgment these attacks exploit. Training lowers the rate of mistakes but does not eliminate them. An attacker needs only one.

Why People Comply

Robert Cialdini, a psychologist at Arizona State University, described in his 1984 book Influence a small set of principles that salespeople and fundraisers use to gain compliance. Attackers use those principles and a few others. The ones that appear most often in attacks are the following:

• Authority. People tend to follow instructions from someone who appears to be in charge. Stanley Milgram’s experiments at Yale in the early 1960s showed that ordinary people would follow an authority figure’s instructions even after they believed they were harming someone. An attacker claims to be the IT department, a security team, an executive, a bank, or a government agency. People follow an odd request anyway because questioning the chief financial officer feels riskier than following an unusual instruction.

• Urgency and scarcity. Time pressure removes the verification steps a person would otherwise take. An account that will be closed in 24 hours, a password that expires in an hour, or an offer that ends at midnight all push for action before thought. Legitimate organizations rarely create this kind of pressure for routine matters.

• Trust and familiarity. A familiar name, logo, or writing style lowers suspicion. Attackers copy the look of well-known services and colleagues’ tone. A message sent from a colleague’s compromised account comes from a trusted source in every technical sense. Social proof, the tendency to do what others appear to be doing, works the same way: download counts, reviews, and testimonials can all be invented.

• Fear. A warning that the computer is infected, that an account has been compromised, or that legal action is imminent produces an immediate reaction rather than a considered one. Under stress, people follow links and provide information they would otherwise refuse.

• Curiosity. A subject line such as “photo from last night” or an attachment named Salary_Adjustments_Q4.xlsx invites a click to find out. In the USB drop study in Part 1, finders who meant to return a drive still opened a file labeled “photos” before the resume, which would have named the owner.

• Reward. A gift card, a tax refund, or free access to a paid service motivates people to overlook risk, especially when the offer is plausible and arrives at a plausible time, such as a refund notice during tax season.

• Helpfulness and reciprocity. Most people want to help a colleague who is locked out or a new employee who cannot print. An attacker can also do a small favor first, since people feel obliged to return one.

• Consistency and commitment. A person who has agreed to a small request tends to agree to a larger one that follows from it. A caller who starts with survey questions about which operating system the person runs can end by offering to install a missing security update. The “update” is the malware.

The strongest lures combine several principles. A message that appears to come from the recipient’s bank (trust) warns of suspicious activity (fear), demands action within the hour (urgency), and comes from the fraud department (authority). Together, these elements give the reader a plausible reason to act and no time to check.

Two further factors work in the attacker’s favor. People make many decisions a day and cannot examine each one. They judge a message by a few quick cues: the logo looks right, the formatting is professional, and they expected a package. Constant security prompts also create security fatigue: when every website, application, and document displays a warning, people dismiss genuine warnings along with the rest.

Phishing

Phishing uses a deceptive message or site to impersonate a trusted source and induce an action that weakens security. A message can request credentials without installing malware, or it can provide a link or attachment that starts a malware chain. The delivery channel may be email, text message, workplace chat, or social-media message.

Spear phishing targets a particular person or organization with information selected to make the request plausible. A message about an actual supplier or project fits more easily into a normal workflow than an unrelated, generic request. Attackers can get this information from public sources, previously stolen correspondence, or a compromised account.

Spear phishing used to be limited by the labor required. Collecting enough information about one person to write a convincing message, and then writing it, took an attacker time for each target. Attackers therefore used it against a small number of valuable targets, while mass phishing sent one generic message to everyone.

Large language models have removed that limit. A model can search the web for a target’s employer, projects, and recent activity, write a message that refers to them, and repeat the process for thousands of people. In a 2024 study, researchers at the Harvard Kennedy School had an AI agent run that whole process against 101 participants. Of the people who received an AI-generated spear-phishing message, 54 percent clicked the link. That matched the rate for messages written by human experts and was more than four times the rate for generic spam, at a cost of a few cents per message. The per-target effort that once protected most people from this kind of attack, because it was too slow to do for everyone, is now automated.

Pretexting presents an invented situation to justify the requested action. A supposed support technician claims that a security check failed, or a supposed colleague needs an urgent invoice reviewed. The pretext converts an unusual action into an apparent prerequisite for completing a legitimate task.

The Lumma verification page used this kind of pretext. The visitor wanted access to the page. The attacker claimed that proving humanity required a system command, so the interface presented the dangerous operation as a routine obstacle to the desired result. That boundary crossing did not require an attachment or a browser vulnerability.

Trust Signals and Their Limits

A reader judges a message by its trust signals. Attackers can supply every one of them: a recognizable logo, a deadline that discourages independent verification, and personal details that make the sender appear informed. A compromised account can supply a real conversation history and an authentic-looking sender address.

HTTPS, the encrypted form of the web protocol, protects the connection to the domain named in the address, but it does not show that the domain belongs to the organization pictured on the page. A correctly spelled company name in a page heading also does not identify the party controlling the server.

Recognizing an attack depends on examining both the requested action and the message’s appearance. Several mismatches deserve scrutiny:

• A browser-verification page instructs the visitor to run a command in an operating system utility, as in the ClickFix lure.

• A document claims that its contents require disabling a security control.

• A message directs a payment, password change, or software installation outside the organization’s usual process.

• A familiar sender requests secrecy or urgency that prevents verification through a separate channel.

• A displayed link, sender name, or reply address differs from the destination or account actually involved.

None of these observations proves that a message without them is safe. A lookalike domain, such as rutgers-helpdesk.com, shows the same address in the displayed link and in the destination. Independent verification helps because it tests the claim through a channel the suspicious message didn’t provide.

Spear Phishing Against Hotels

A campaign Microsoft reported combined the techniques above: industry targeting, a pretext drawn from recipients’ own work, and the same kind of fake verification page the Lumma campaign used.

Microsoft reported on March 13, 2025, that a campaign active since December 2024 impersonated Booking.com, an online travel reservation service. Messages sent to hospitality organizations referred to a negative guest review, an inquiry from a prospective guest, a promotion opportunity, or a request to verify the hotel’s account. Each included a link to a fake verification page. The page told the employee to open the Windows Run dialog with a keyboard shortcut, paste a command that the page had already placed on the clipboard, and run it. The command downloaded and ran malware, including Lumma and several remote access trojans, which Microsoft reports were used to steal credentials and payment data.

An attacker who obtains a hotel’s reservation-service credentials can also read its bookings. Guest names, dates, and correspondence would make a later message to a guest appear credible, since a targeted message can contain correct facts without coming from an authorized sender.

The link in the message leads wherever the sender chooses, so the attacker controls the page it opens. A hotel employee can instead open the service’s booking-management site through a bookmark or known address and check the reported review or inquiry there, testing the claim through a channel the message didn’t provide.

Lookalike Domain Names

A phishing link has to lead somewhere. The address it leads to is one of the few things the attacker cannot copy exactly. The attacker’s substitute has to look right to a reader who glances at it.

Typosquatting

Typosquatting registers a domain name that differs from a legitimate one by the kind of error a person makes while typing or reading. The name catches two kinds of mistakes. A user who types an address can hit an adjacent key, skip a letter, or double one. A user reading an address can mistake one character for another or not know which of two plausible names is correct. Common forms include the following:

• A substituted character: paypa1.com, with a digit one for the letter l, or micros0ft.com.

• An omitted character: gogle.com or amazn.com.

• An added character: gooogle.com or payppal.com.

• An adjacent key: goohle.com, since h sits next to g.

• A different top-level domain: google.net or microsoft.org.

• A lookalike character from another alphabet. Browsers now display such names in an encoded form when they mix characters from more than one alphabet, so a Cyrillic а isn’t shown as a Latin a.

A typosquatted domain can host a copy of the real site’s login page and collect the credentials of anyone who arrives by mistake, then forward the visitor to the real site so nothing seems wrong. It can host a fake download page for software the visitor was searching for. It can carry advertisements and earn money from the traffic. It can also serve as the sender’s domain in a phishing message, where security@paypal-verify.com reads more plausibly than an unrelated address.

Software package registries have the same problem as domain names, since developers type a package name into a build file. In July 2017, a publisher uploaded about forty packages to npm, the JavaScript package registry, with names close to popular ones. One, crossenv, imitated the widely used cross-env package and sent the environment variables of any machine that installed it to a server the publisher controlled. Those variables often hold credentials. The packages were live for about two weeks before a user noticed and reported them. A build that installs a mistyped name has installed attacker code with the developer’s permissions.

Two defenses do different jobs: checking a package’s exact name and source helps prevent selecting an impostor in the first place, and enforcing a lockfile keeps later installations on the recorded versions. A lockfile can also preserve a malicious package selected by mistake.

Combosquatting

Combosquatting combines a correctly spelled brand or organization name with additional words in a domain registered by an attacker. For example, rutgers-helpdesk.com looks like the name of a university support service. But it is a separate domain from rutgers.edu; including rutgers in the name does not show that Rutgers owns it. The deception works even when the reader does not make a typing mistake.

A company can register common misspellings and other likely lookalike domains before attackers do, a practice called defensive registration. It protects those particular names, but combosquatting creates many more possibilities by adding words such as support, security, login, or verify. Registering a few likely combinations leaves many others available.

The voice-phishing campaign described below used the same technique: some domain names added support before the targeted company’s name or okta after it. Okta is an identity provider many organizations use for employee logins.

A 2017 study analyzed almost six years of DNS records and found increasing combosquatting activity over that period. Nearly 60 percent of the abusive domains identified in the study were observed over periods longer than 1,000 days. This measures their presence in DNS records, not continuous malicious activity throughout those periods.

Defending against Lookalike Domains

The following controls reduce typing errors and help detect or block lookalike domains:

• Verified bookmarks. A bookmark for a confirmed address avoids retyping it on later visits. Searching for the organization’s name is less dependable, because search results can include advertisements that link to impersonation sites.

• A password manager’s address matching. Password managers normally offer saved credentials only when the website’s address matches the saved login. If an expected login isn’t offered, the domain deserves a check before you enter the password by hand. A failure to autofill is a warning sign, although it can also have other causes.

• Domain filtering and monitoring. An organization can configure its DNS resolver, the service that looks up names for its machines, to block known or suspected lookalike domains instead of returning their addresses. It can also monitor new domain registrations for names resembling its own name or its vendors’ names and investigate suspicious ones.

The 2020 joint vishing advisory from the FBI and CISA, the U.S. Cybersecurity and Infrastructure Security Agency, specifically recommended bookmarking the correct address of the corporate VPN, the service through which employees reach the company network from outside, and refusing to visit an alternative address solely because an incoming caller supplied it.

Attacks by Phone and Text Message

Email is filtered, archived, and examined. A phone call or a text message reaches the person directly, on a small screen or in real time, with fewer defenses in between.

Vishing

Vishing, or voice phishing, uses phone calls to obtain sensitive information, payments, or access. A live caller can respond to objections and pressure the recipient to act immediately. Caller ID can be spoofed, making the call appear to come from an employer or bank.

A common pretext is technical support: the caller claims to have detected malware and persuades the recipient to install a legitimate remote-support tool, giving the attacker control of the computer. Other callers impersonate bank employees or government officials and demand account information or urgent payment.

In August 2020, the FBI and CISA described a campaign targeting employees working from home. Attackers collected personal and job details from public sources, registered combosquatted domains, and built copies of company VPN login pages. They then called employees, posing as the help desk and using the collected details and spoofed company phone numbers to appear credible.

The caller directed the employee to a supposed new VPN login page. Attackers captured the password and one-time code and used them immediately. Some employees also approved authentication prompts because they believed these were part of the support process. The advisory recommended restricting VPN access to company-managed devices and using checks such as a device certificate. Captured passwords and one-time codes would then be insufficient to connect from an attacker’s computer.

Smishing

Smishing, or SMS phishing, uses mobile text messages. Attackers imitate familiar notifications, such as delivery problems, bank alerts, and unpaid bills, to persuade recipients to follow a link. Shortened links can conceal the destination.

In April 2024, the FBI warned about texts impersonating state toll services. The messages claimed an unpaid toll and threatened a late fee unless the recipient paid through a link to a lookalike domain. The FBI advised recipients to check their accounts through the toll service’s legitimate website or an independently obtained customer-service number.

Defeating One-Time Codes

A second authentication factor delivered by text message does not stop a real-time phishing attack. The attack takes the following steps:

1. The victim enters a username and password on the attacker’s copy of the login page.

2. The attacker immediately enters them on the real site.

3. The real site sends a one-time code to the victim’s phone.

4. The attacker’s page asks the victim for the code. The victim types it in.

5. The attacker enters the code on the real site and is logged in.

The whole exchange fits within the minute or so for which the code is valid. From the victim’s side, the login looked normal: enter a password, get a text message, and enter the code from the message.

CISA’s guidance on phishing-resistant authentication lists three further attacks on codes and prompts:

1. Repeated push notifications until a tired user approves one.

2. A SIM swap, in which the attacker persuades the carrier to move the victim’s phone number to the attacker’s phone.

3. Interception in the telephone signaling network.

An authenticator app that generates time-based codes from a secret shared with the server is a better second factor than a text message. There is no message to intercept and no phone number to swap. It still does not stop the relay, because the code depends only on the secret and the time, not on which site is asking for it. The user types a valid code into the attacker’s page.

The fix is authentication that is cryptographically bound to the legitimate site. A hardware security key, or the equivalent built into a phone or laptop, holds a private key for each site. At login, the browser sends the key a random challenge and the page’s domain, and the key signs both. A lookalike page signs over its own domain, which the real site rejects, so the relay has nothing to pass along. CISA calls this phishing-resistant authentication. The industry standard behind it is FIDO, and consumers know the credentials as passkeys.

Technical Defenses against Social Engineering

A user’s decision to run a program doesn’t have to grant it every permission the user has. A sandbox can restrict the files and services available to the program, applying the Principle of Least Privilege. Application control can block unapproved programs and interpreters, while document settings can prevent unapproved macros from running.

The fake verification page illustrates why the delivery route determines which controls help. There was no attachment to avoid: the visitor was instructed to paste and run a command. Blocking unnecessary scripting utilities can prevent that execution path. Monitoring unexpected interpreter launches can help detect an attack and trigger a response.

Technical controls can also limit what stolen credentials provide. A VPN can require a credential stored on an approved company device in addition to the employee’s password. Passkeys are tied to a site’s domain, so a lookalike domain cannot use a passkey registered for the legitimate site.

Next: Part 3: Delivery and Persistence

Lecture 9: Part 1 | Part 2 | Part 3 | Part 4
Lecture 9 Study Guide | List of terms