The first smishing case I ever triaged was a fake parcel notification. Someone on the finance team clicked a "missed delivery" link, entered card details, and we spent twenty minutes confirming it was personal fraud with no corporate exposure.
Closed it as out of scope; that was five years ago, and that's still what most people picture when they hear smishing: prize texts, toll scams, fake USPS notifications hitting personal phones. In 2026, smishing increasingly starts enterprise intrusions through channels most SOC tooling cannot see.
Consumer scams still arrive. The SMS (Short Message Service) attacks I work in 2026 are multi-stage credential harvesting campaigns. An attacker texts an employee posing as IT, walks them to a victim-branded single sign-on (SSO) page, captures the credentials and the multi-factor authentication (MFA) code, and registers their own device before the analyst on shift has any signal at all.
The text message is the first move in an enterprise intrusion, and the channel it rides on produces no telemetry in the stack we built to catch phishing.
In Brief:
Smishing is a phishing sub-type delivered over mobile messaging channels: SMS, MMS, Rich Communication Services (RCS), and OTT apps. The 2026 version centers on IT helpdesk impersonation and MFA code interception feeding straight into SaaS and identity compromise.
Voice phishing climbed to 11% of all intrusions in 2025 while email phishing dropped to 6%. In cloud-specific compromises, the voice phishing share hit 23%, driven by ShinyHunters and Scattered Spider. The attack moved to a channel most controls don't cover.
iOS 26.5 added cross-platform RCS encryption between iPhone and Android in May 2026. That removed the last carrier-side content filter for that message path. The Groupe Speciale Mobile Association (GSMA) specification that introduced end-to-end encryption (E2EE) shifts spam handling to client-side detection, because network-side content inspection no longer applies once a message is encrypted.
The SMS channel is invisible to the standard security operations center (SOC) stack. Nothing about it reaches security information and event management (SIEM), endpoint detection and response (EDR), or email gateway logs. Detection is entirely downstream in identity and mobile threat defense (MTD) telemetry, and most SOCs don't own enough of it to reliably tell a social-engineered helpdesk reset from a legitimate one.
What smishing means and what it's become
Smishing is a phishing sub-type delivered via mobile messaging channels rather than email or voice, where attackers impersonate trusted entities and use urgency to get targets to reveal credentials, click malicious links, or hand over MFA codes. The FCC describes it as a mashup of SMS and phishing. For SOC purposes, the channel's telemetry gap matters more than the dictionary definition.
For SOC teams, smishing exploits the absence of enterprise-grade inspection on the mobile message layer. Unlike email phishing, it generates no logs in your standard stack: no SIEM log source, no EDR agent on the message layer, no email gateway in the transport path.
The MITRE technique exists, T1660 (Phishing, Mobile), but the related T1566 and T1566.003 techniques rely on downstream signals like anomalous authentication from a new device, so the initial access event itself is never directly observed.
Smishing moved from consumer fraud to enterprise attack vector
Voice phishing climbed to 11% of all intrusions in 2025, the second most common initial vector, while email phishing fell to 6% from 14% the year before. In cloud-specific compromises, the voice phishing share hit 23%, driven by ShinyHunters and Scattered Spider. These are live, human-driven campaigns rather than mass email, so the detection stack built for email phishing never sees them. That is part of why email phishing keeps sliding as voice phishing climbs: the email controls work, so attackers moved to the phone.
Mandiant's M-Trends 2026 describes it plainly: financially motivated groups phone IT help desks, pose as employees to get past MFA, and gain initial access to SaaS. From there they harvest long-lived OAuth tokens and session cookies, and by compromising third-party SaaS vendors they take hard-coded keys and access tokens to pivot into downstream customer environments. The call reaches your identity provider without exploiting a single vulnerability.
Four delivery and targeting patterns dominating 2026
Four patterns account for most of what I see hit the queue. They overlap, chain together, and all start outside SIEM visibility.
IT helpdesk impersonation and MFA code interception
In January 2026, UNC6661 / ShinyHunters impersonated IT staff, called employees claiming the company was updating MFA settings, directed them to victim-branded credential harvesting sites to capture SSO credentials and MFA codes, then registered their own device for MFA.
Domains followed the format <companyname>sso.com or <companyname>internal.com, registered via NICENIC. In confirmed cases they reached Okta customer accounts and used PowerShell to download sensitive data from SharePoint and OneDrive.
Mandiant's M-Trends 2026 put the median hand-off in 2025 intrusions at 22 seconds, the gap between initial access and the point where an access broker hands the environment to a secondary group. CrowdStrike's 2025 Threat Hunting Report documented Scattered Spider moving from account takeover to ransomware in under 24 hours.
I rebuilt a team's incident response plan once around the assumption that an analyst would have an hour to validate a suspicious reset before it mattered; that assumption no longer holds. The window for a human in the loop is now measured in seconds, and the only place you'll see the attack is in the identity logs after credentials are already gone.
RCS delivery and carrier filter bypass
RCS broke the one detection layer that used to work against this vector. Carrier SMS filters were built for the SS7 signaling network and don't extend to IP-based RCS.
When E2EE is on for a conversation, the GSMA's own specification moves spam handling to client-side detection, since the content can no longer be inspected in transit. Content-based filtering, the primary mechanism for smishing detection at the network level, is effectively blocked when encryption is active.
iOS 26.5 added cross-platform RCS encryption between iPhone and Android in May 2026, removing the last carrier-side content inspection for that message path. The GSMA's answer to the gap is on-device detection and user-submitted spam reports as the primary intelligence source when content is encrypted. In 2026, carrier-side defense depends on users reporting messages that have already been delivered and acted on.
Toll fraud networks and Smishing Triad campaigns
Smishing Triad, a PRC-based operation, runs a phishing-as-a-service business, selling kits from roughly $200 a month to operators who need no technical skill of their own. Its enterprise relevance comes from that kit ecosystem and its 2025 move toward banks and financial institutions, which Silent Push first flagged in March 2025 alongside the bank-focused Lighthouse kit.
Researchers at Palo Alto Networks' Unit 42 had linked the operation to approximately 200,000 malicious domains as of October 2025, with USPS the most impersonated service. Delivery has included iMessage from compromised iCloud accounts, RCS, and traditional SMS gateways using leased routes and local phone numbers.
Two things make this enterprise-relevant in 2026: the March 2025 pivot toward banks and financial institutions signals expansion beyond consumer fraud, and the PhaaS kit ecosystem (Lighthouse, Lucid, Darcula) has dropped the skill floor significantly.
By the end of 2025, phishing-as-a-service kits accounted for 90% of high-volume phishing campaigns, up from 60-70% earlier in the year, with kits like Lighthouse supporting 2FA credential theft through customizable templates at low weekly rates. An operationally sophisticated smishing-to-adversary-in-the-middle (AiTM) chain can now be rented rather than built.
SIM swapping enabled by smishing as the initial vector
SIM swapping gives attackers control of the phone number used for recovery or MFA. The chain runs: attacker gains control of the number, finds accounts using it for recovery or MFA, intercepts OTPs or triggers account recovery, registers a new MFA device, then removes the legitimate user's recovery options.
CISA's advisory documents Scattered Spider using SIM swaps alongside push bombing and smishing to bypass MFA. Microsoft has described Octo Tempest as among the most sophisticated financially motivated actors for exactly this combination of advanced social engineering, SIM swapping, and identity compromise.
Watch the denominator carefully. Microsoft's Digital Defense Report data shows SIM swapping, MFA fatigue, and AiTM attacks together make up less than 1% of all identity attacks, because the vast majority are password-based.
That low number misleads on targeted enterprise intrusions, where SIM swapping plays an outsized role. FS-ISAC has stated directly: confirm there is no SMS-based MFA in any application. If a phone number is a recovery factor, smishing is your attack surface.
Most SOC tooling wasn't built for a channel that generates no email telemetry
Practitioners get this wrong when they treat smishing as a tuning problem. The detection gap is structural: the SMS and RCS channel doesn't feed a SIEM, carries no EDR telemetry on the message layer, and never transits an email gateway, so there's no event to write a rule against.
Most SOCs have no visibility into mobile endpoints at all, and most of those endpoints are personal phones outside management scope entirely. You can tune detection content for a year and not improve coverage on the initial vector.
The channel economics explain why attackers moved here. Smishing carries a 25.7% click rate, often bypassing corporate defenses entirely because SMS lands on personal devices outside the email security perimeter. Smishing now accounts for roughly 70% of mobile-targeted phishing, and because it lives outside the email channel, traditional filtering tools have no vantage point to catch it.
Linkless variants, where there's no URL to inspect at all, get zero coverage from anything URL-based. In credential compromise cases I've worked, by the time the alert fires it fires on the symptom: a new device or an impossible-travel sign-in, not the text message that started it.
Detection for smishing starts with telemetry the SOC rarely owns
Because the channel is invisible, detection has to be entirely downstream, in identity. Endpoint and network detection don't see identity misuse, so the signals live in your IdP logs, your MTD telemetry, and your post-compromise SaaS audit trail.
IdP logs are the load-bearing source. In Okta, watch app.ad.password.reset.success, core.user.factor.deactivate, and core.user.factor.activate from unrecognized IPs or geographies, which together form the reset, deactivate, re-enroll chain. In Entra ID, the Suspicious MFA Authentication Approval detection fires on unfamiliar ASN, browser, device, and GPS data, though it requires Entra ID P2.
Single events create noise, so watch the behavioral chain instead: high-volume MFA prompts followed by a reset or new-device enrollment, logins from new geographies or ASNs, recovery-method changes, then new mailbox rules or OAuth consents. Correlate the timing, because a reset alone is noise while a reset followed by new-device MFA followed by an unusual SharePoint export is an incident.
MFA push bombing maps to T1621, where the tell is a failure wave that flips to success without a behavioral explanation: off-hours, new IP, new device. The minimum viable telemetry is sign-in and audit logs carrying UserPrincipalName, IPAddress, AppDisplayName, and AuthenticationDetails.
MTD fills in partial message-layer visibility, but only on managed devices and only as a proxy. It's the closest thing to channel visibility you'll get without full device management coverage.
A well-instrumented SOC can write all the right rules and still lack the behavioral baseline to cleanly separate a social-engineered helpdesk reset from a legitimate one without process controls. Out-of-band employee verification and manager approval for MFA resets do more here than any detection engineering content you can write.
When I rebuilt an incident response process that kept failing on this exact scenario, a verification step the helpdesk couldn't bypass under pressure solved the failure mode.
This week, confirm that no application uses SMS as an MFA or recovery factor and that the helpdesk cannot reset MFA on a phone call alone. Fix those two and you've removed the initial vector from the actors who are actually landing these attacks; the text message will still arrive, but it won't go anywhere.
Frequently asked questions about smishing
What does smishing mean?
Smishing is a phishing sub-type delivered through mobile messaging channels, SMS, MMS, RCS, and OTT apps like iMessage or WhatsApp, rather than email or voice. Attackers impersonate trusted entities and use urgency to get targets to reveal credentials, click malicious links, or hand over MFA codes. In 2026, the enterprise version typically involves IT helpdesk impersonation that feeds into SaaS and identity compromise.
What is the difference between smishing and phishing?
Phishing is the parent category covering all social engineering by message, and smishing is the SMS and mobile-messaging variant. For a SOC, the operational difference is telemetry: email phishing generates gateway logs, DMARC, and DKIM signals, while smishing generates none of that in a standard SOC stack. Detection for smishing has to happen downstream in identity logs rather than on the message itself.
What are examples of smishing attacks in 2026?
In January 2026, ShinyHunters (UNC6661) impersonated IT staff to direct employees to victim-branded credential harvesting pages, capturing SSO credentials and MFA codes before registering their own devices on Okta accounts. Smishing Triad, a PRC-based operation, ran consumer toll and postal fraud across approximately 200,000 domains before pivoting toward financial institutions in March 2025.
How do SOC teams detect smishing?
Because the SMS channel produces no SIEM, EDR, or email gateway logs, detection is entirely downstream in identity and MTD telemetry. Monitor IdP events like Okta's core.user.factor.deactivate and core.user.factor.activate from unfamiliar IPs, correlate MFA resets with new-device sign-ins and impossible travel, and map push bombing to MITRE T1621.
Process controls like out-of-band employee verification and manager approval for MFA resets often matter more than any detection rule.
Why is smishing harder to detect than email phishing?
The SMS and RCS channel sits entirely outside the SOC stack, so there's no log source, endpoint agent, or transport-layer inspection to observe the initial access event directly.
RCS end-to-end encryption, now cross-platform as of iOS 26.5 in May 2026, also blocks the carrier-side content inspection that used to filter spam, leaving user-submitted reports as the primary carrier-side signal.