Adversarial Risk Group
GlossarySocial Engineering and Phishing9 min read

What is smishing?

Smishing is a phishing attack delivered via SMS in which an attacker uses a text message to drive the target toward a credential prompt or workflow action.

Key takeaways

  • Smishing uses a higher-trust channel than email and faces almost no enterprise filtering.
  • The dominant payload is a link to a credential-harvest page or a workflow request (gift card, wire confirmation, password reset).
  • BYOD and field workforces are disproportionately exposed because their corporate mobile usage is informal.
  • Mobile carriers and MDM tools provide limited protection; workflow controls and adaptive simulation matter more.
  • For mid-market manufacturers, smishing is rising fastest against plant managers, drivers, and field-service staff whose mobile devices are central to their job.

How does a smishing attack work?

A smishing attack has three stages.

1. Source the number. Mobile numbers are collected from public sources (LinkedIn, vendor portals, conference badge scans) and from data brokers that aggregate consumer data. Personal numbers are usually easier to find than work numbers; the attacker exploits that overlap.

2. Send the message. Infrastructure varies. Mass campaigns go out through SMS gateways and rotating short codes. Targeted campaigns use disposable numbers, lookalike short codes resembling known senders (banks, carriers, HR platforms), or international gateways that bypass US 10DLC registration. The message is short by necessity: a pretext line and a link, or a pretext line and a phone callback request.

3. Drive the action. The link goes to a credential-harvest page tuned to mobile rendering. The page imitates Microsoft 365, Google, Okta, an HR portal, or a payroll provider. Credentials and MFA codes are forwarded to the attacker's automation in real time, often allowing immediate login with the captured code. Alternatively, the request is workflow-only (a gift card, a wire, a phone callback) and the channel switch from SMS to voice or email follows quickly.

The attack is fast: from receipt to compromise is usually under five minutes for credential-harvest variants. There is no equivalent of the email sandbox; the target's phone renders the link without delay or warning.

Why SMS is a higher-trust channel than email for attackers

Three structural properties make smishing land harder than equivalent email content.

  1. Less filtering. Email systems run dense spam, anti-phishing, link-rewriting, sandboxing, and DMARC enforcement. SMS systems run almost none of this for inbound messages. The message arrives unmediated.
  2. Higher inferred trust. SMS in the consumer mental model is "people I know and the systems they use". A text message is less suspicious by default than an email, especially a text that appears to come from a known short code.
  3. Smaller screens, less context. Mobile rendering hides full URLs, sender identity, and historical context. A user who would notice an off-by-one domain on a desktop email client may miss the same signal on a phone screen.

The combined effect is that smishing converts at materially higher rates than equivalent-quality email content. Industry data from 2023 to 2025 consistently shows mobile-delivered phishing landing pages converting at two to three times the rate of email-delivered equivalents.

Common smishing scenarios targeting employees

In a workforce context, four scenarios dominate:

HR or payroll pretext. "Update your direct deposit at the new portal" or "Your W-2 is ready". Link to a forged login page that captures Microsoft 365 or payroll-provider credentials. High click-through because the action is plausible at payroll cycles.

IT help desk pretext. "We need to verify your MFA" or "Your account is locked, click to recover". Targets often include the MFA reset code in the response, allowing the attacker to log in. See What is MFA fatigue (push bombing)?.

Executive-impersonation request. "Hi, this is Sarah, can you help me with something quick?" The follow-up asks for gift cards, a wire confirmation, or a number transfer. Targets are usually finance or executive assistants. The pretext exploits direct CEO-to-employee interaction patterns.

Vendor or contractor pretext. "Your delivery is rescheduled, please confirm at this link" or "Your invoice could not be processed, please update your information". Targets are AP, procurement, and shipping coordinators. The link captures credentials or drives a vendor-information change.

Each scenario fits an internal workflow, which is what makes the success rate high.

Examples of smishing in BYOD and field-employee environments

Mid-market manufacturers have several workforce segments where mobile is central to the job. These segments are disproportionately exposed.

  • Plant managers and shift supervisors. Receive operational alerts on personal phones; corporate communications often blend with personal traffic. A smishing pretext claiming to be from corporate IT during a known outage period has a high success rate.
  • Drivers and logistics coordinators. Phone-first workflow with delivery apps, route updates, and signature confirmations. A pretext referencing a real delivery (often harvested from public shipping data) leads to a credential prompt or a workflow change.
  • Field-service technicians. Move between customer sites, often with the corporate-credential mobile app installed personally. A vendor-impersonation pretext or a "ticket update" with a link reaches the target before the IT team is aware.
  • Maintenance and trade staff with limited email use. Often communicate primarily via SMS with managers. A smishing pretext from a "manager" with a request for a quick action (a code, a confirmation, a number transfer) hits a trust pattern that has no email equivalent for these users.
  • C-suite on the road. Executives traveling for industry events are visible (LinkedIn check-ins, conference programs). A smishing pretext written for the moment ("I am in your hotel lobby, can you confirm this for me") is more believable than the same pretext in email.

The pattern across these segments: mobile use is operationally central, formal IT touch is light, and the smishing pretext arrives in a context where verification feels inconvenient.

How to recognize a smishing message

For an individual reader who suspects a message might be smishing, five checks are reliable:

  1. Does the sender match the claimed identity? Banks, payroll providers, and IT departments use short codes or registered numbers; an unfamiliar mobile number claiming to be one of these is suspect.
  2. Does the link domain match the legitimate domain exactly? Mobile clients truncate URLs. Long-pressing the link to preview the full domain matters; lookalike domains and free TLDs are common.
  3. Is the action high-impact? A request to update payment information, enter credentials, transfer money, or share an MFA code is exactly what a real attacker is asking for. The action is the signal.
  4. Is there time pressure? "In the next ten minutes", "before the end of the day", "your account will be locked". Real corporate workflow does not depend on text-message immediacy.
  5. Is the conversation switching channels? "Reply to this on WhatsApp" or "call me at this number" moves the conversation off any logged or filtered channel. Channel switching is a near-universal attacker signal.

For an organization, the same caveat applies as with vishing: individual recognition is useful but not a defense by itself. The program is what matters.

Best practices for defending against smishing

  1. Phishing-resistant authentication everywhere. A captured MFA code is the dominant smishing payload. FIDO2 and passkeys eliminate the value of the captured code. See What is phishing-resistant MFA?.
  2. Workflow controls that do not depend on mobile channel. Direct deposit changes, vendor-information changes, and wire transfers should require an action in the system of record (HRIS, ERP) plus an out-of-band confirmation; an SMS-initiated change should not be possible.
  3. Help desk verification protocols that survive mobile. MFA reset requested via SMS or phone must require callback to a directory-sourced number and (where available) verification through corporate ID or video.
  4. Personal mobile number governance. Reduce the public availability of executive and finance-team mobile numbers. They are routinely harvested for smishing pretexts; the friction of obtaining them is low but measurable.
  5. Continuous, adaptive smishing simulation. Send realistic smishing pretexts to in-scope employees as part of the program. Outcomes feed the same backlog as email and voice simulations. Adaptive simulation avoids the failure mode of training on a small set of memorized lures.
  6. Brief field workforces explicitly. Drivers, technicians, and field-service staff often receive less security training than office staff. A short, role-specific brief on smishing patterns (and the right escalation path) addresses the gap.
  7. Incident response for mobile compromise. If a smishing attempt succeeds against a personal device with corporate access, the response (revoke tokens, rotate credentials, kill sessions) needs to be fast and documented. See What is an incident response plan (IRP)?.

Smishing FAQs

How is smishing different from regular text scams?

Mass text scams target broad consumer audiences with low-effort pretexts (package delivery, tax authority, bank fraud alerts). Smishing aimed at a workforce is more targeted: the attacker pretends to be HR, IT, an executive, or a vendor, and the message references workflow or context specific to the recipient.

Can mobile carriers block smishing?

Carriers block some bulk patterns, but smishing infrastructure rotates faster than carrier filters update. Industry mechanisms like 10DLC registration in the US improve sender-side accountability but do not stop targeted smishing from disposable numbers or international gateways.

Do MDM tools stop smishing?

Mobile device management does not block SMS at the carrier level. MDM can enforce browser configuration, restrict app installs, and surface anomalous behavior after the fact, but the smishing message itself reaches the device. Defense relies on workflow controls and continuous simulation, not on filtering the channel.

What is the most common smishing lure in 2026?

In the workforce context, the most successful lures are HR or payroll updates with a link to a forged Microsoft 365 login page, IT help desk MFA-reset prompts, and executive-impersonation texts asking for a quick favor (a gift card, a wire confirmation, a number transfer). Each one exploits the lower scrutiny that SMS attracts compared to email.

How ARG includes smishing in continuous simulation

Smishing is a standard channel in ARG's continuous adversarial simulation. It runs alongside email phishing, vishing, OAuth-grant testing, and (during on-site engagement years) physical pretext entries. Pretext, sender number, lure family, and target rotate per round so the workforce experiences a realistic, moving threat surface rather than a memorized template library.

The simulation is operated by James Wall on infrastructure ARG controls. For each client, in-scope targets typically include high-volume mobile users (finance, AP, HR, executives, plant managers, field-service technicians). Pretexts are calibrated to the target's role and current visible business context: a payroll-update lure during a payroll cycle, an executive-impersonation request during a known travel window, a vendor-confirmation lure during a known delivery period.

Each test logs delivery, recipient action, link interaction, credential submission, and (where applicable) the path the captured credential would have taken inside the environment. The packet shows trend over time: who is improving, where pretexts still land, what controls demonstrably blocked the action. The same backlog drives remediation as for the other channels: workflow change first, training where it produces measurable behavior change, simulation re-test to confirm the change held.

For founding clients, smishing simulation is part of the monthly retainer alongside email, voice, and (during physical engagement weeks) on-site social engineering.

Apply as a founding client or see how the engagement works for the full delivery cycle.

Find what gets through.

ARG runs continuous AI-driven adversarial simulation and on-site physical audits for mid-market manufacturers. Two founding-client spots remain.

Author: James WallUpdated 2026-05-18Adversarial Risk Group