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, by phone, and by text message, against 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 obtains an action that the system would otherwise refuse.

Social engineering manipulates a person into revealing information or performing 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. The habits of human judgment that these attacks use cannot be patched. 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. A request that seems odd gets done 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 the tone of colleagues. 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, a person follows links and supplies information that 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 as photos before the resume that 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 begins with survey questions about which operating system the person runs can end with an offer 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). The combination leaves the reader with 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 a package was expected. Constant security prompts also produce security fatigue: when every website, application, and document displays a warning, a genuine warning is dismissed 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 any malware, or it can supply a link or attachment that begins a malware chain. The delivery channel may be email, a text message, a workplace chat, or a 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 is easier to place in a normal workflow than an unrelated generic demand. The information can come from public sources, earlier stolen correspondence, or a compromised account.

Spear phishing used to be limited by labor. Collecting enough information about one person to write a convincing message, and then writing it, took an attacker time for each target. It was therefore used 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 its 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 a pretext of this kind. 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 the requested action as well as 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 is useful because it tests the claim through a channel the suspicious message did not supply.

Spear Phishing Against Hotels

A campaign reported by Microsoft combined the techniques above: targeting by industry, a pretext drawn from the 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 contained a link that led 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 credentials for the reservation service 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 page it opens is under the attacker’s control. A hotel employee can instead open the service’s booking-management site through a bookmark or a known address and check the reported review or inquiry there, which tests the claim through a channel the message did not supply.

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 mistake. A user who types an address can hit an adjacent key, skip a letter, or double one. A user who reads an address can mistake one character for another or not know which of two plausible names is the real one. 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 characters from more than one alphabet are mixed, so that a Cyrillic а is not 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 a developer types a package name into a build file. In July 2017, a publisher uploaded about forty packages to npm, the package registry for JavaScript, 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. The program built from it carries that code to everyone who runs it. 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 is not offered, the domain deserves a check before the password is entered 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 while posing as the help desk, 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, using checks such as a certificate installed on the device. 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 phishing attack that runs in real time. 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 a second factor that the user never types. 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 it a random challenge together with the domain of the page, and the key signs both. A lookalike page gets a signature over its own domain, which the real site rejects, so there is nothing for the relay to pass along. CISA calls this phishing-resistant authentication. The industry standard behind it is called FIDO, and the credentials are known to consumers as passkeys.

Technical Defenses against Social Engineering

A user’s decision to run a program does not have to give it every permission the user holds. 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.