How to Map Smishing Attacks to the MITRE ATT&CK Framework

Map smishing incidents to T1660 (Phishing: Mobile) as the primary technique, with T1566 (Phishing) as the parent category and T1566.003 (Spearphishing via Service) when delivery rides on iMessage, WhatsApp, or RCS instead of raw SMS. Where the lure specifically targets carrier or messaging metadata, note T1636.004 and T1582 as supporting labels.

Detection priorities in the first hour: capture the passive DNS (pDNS) record for the linked domain, screenshot the landing page before it churns, preserve the raw message text and sender ID, and log the delivery channel. A baseline SIEM rule: tag any inbound SMS/IM event containing a shortened or newly registered domain, correlate it against an outbound HTTP request within 10 minutes, and flag the pair as suspected smishing pending analyst review.

Primary IDs: T1660 (mobile-specific), T1566 (parent phishing category)
Sub-techniques to watch: T1566.003, T1636.004, T1582
Evidence to grab first: pDNS, landing-page capture, message text, sender ID metadata

Pro Tip: Tag the incident ticket with technique ID and confidence level at intake, not after triage. Retroactive tagging is where mapping backlogs come from.

Key Takeaways

Mapping smishing to T1660 and T1566, backed by pDNS and landing-page evidence, turns scattered user reports into detection rules that scale across an entire campaign.

Point	Details
Use T1660 as default	Tag SMS, iMessage, and RCS lures as T1660; reserve T1566.003 for legitimate service abuse.
Capture evidence immediately	Grab pDNS, landing-page screenshots, and message text before domains churn out.
Cluster by infrastructure	Group churned domains by ASN and TLS fingerprint into single campaign IDs, not individual alerts.
Retire SMS-based 2FA	Move to phishing-resistant MFA since credential-harvest lures now target financial and wallet logins.
Treat user reports as telemetry	Employee-forwarded messages are often the earliest signal, ahead of network-based detection.

What ATT&CK Techniques Apply to Smishing?
How Do You Turn a Smishing Report into an ATT&CK Mapping?
What Do Real Smishing Campaigns Look Like?
What Telemetry and Correlation Rules Catch Smishing Early?
What Mitigations Actually Reduce Smishing Exposure?
How Do You Operationalize Smishing Hunting at Scale?
What This Mapping Exercise Actually Reveals
Sources

What ATT&CK Techniques Apply to Smishing?

T1566 (Phishing) is the parent technique for any message that tricks a target into clicking a link, opening an attachment, or handing over credentials. It covers email, SMS, and voice equally, which is why MITRE built T1660 (Phishing: Mobile) as a mobile-specific label, capturing the differences that matter operationally: no email gateway to filter it, no attachment scanning, and a much smaller screen that hides the real URL.

Use these distinctions when tagging incidents:

T1566 — general phishing category; use when the delivery channel is ambiguous or spans email and mobile.
T1660 — SMS, iMessage, or RCS-specific lures; use this as your default for anything arriving on a phone number.
T1566.003 (Spearphishing via Service) — applies when the attacker abuses a legitimate messaging service (WhatsApp, iMessage) rather than raw SMS.
T1636.004 / T1582 — supporting labels when the attack manipulates protected user data or SMS control functions on the device itself.

MITRE’s Phishing (T1566) page still provides the canonical mitigation and detection language most teams adapt for mobile. For teams justifying the mapping to auditors, CAPEC-164 (Mobile Phishing) supplies the taxonomy bridge between attack-pattern classification and ATT&CK technique IDs.

How Do You Turn a Smishing Report into an ATT&CK Mapping?

A reproducible mapping process keeps your incident tickets useful six months later, not just readable the day they’re filed. Follow this sequence for every reported message:

Collect the minimum evidence set: message text, destination URL, pDNS resolution history, hosting IP and ASN, a landing-page screenshot, and the original user-submission log.
Apply decision rules: if the lure arrived via SMS or RCS, default to T1660. If it arrived through iMessage or WhatsApp abusing a legitimate service layer, use T1566.003. If the channel is unclear or mixed with email, fall back to generic T1566.
Assign a confidence score (high/medium/low) based on how much of the evidence checklist you completed.
Record mapping metadata directly in the ticket: technique ID, sub-technique, confidence, and a one-line justification for why that ID was chosen over an adjacent one.

A short example: a user forwards a text claiming a toll payment is overdue, linking to pay-tolls-now[.]info. pDNS shows the domain resolved 40 minutes before the message went out and disappeared within six hours. That churn pattern, paired with SMS delivery, justifies T1660 with high confidence, no T1566.003 needed since the channel was plain SMS.

Pro Tip: Store the pDNS timeline and hosting ASN in structured ticket fields, not free text. Six months of unstructured notes are unsearchable when you need to prove campaign linkage.

What Do Real Smishing Campaigns Look Like?

Toll-road and package-delivery lures dominate current volume, and they follow a remarkably consistent sequence: SMS lands with an urgency hook, the link resolves to a single-use domain, a CAPTCHA gate filters out automated scanners, and a credential or payment form captures the victim’s data. Cisco Talos documented this exact flow across U.S. toll-road impersonation campaigns, built on reusable smishing kits and typosquatted domains that mimic state tolling authorities.

The scale is what makes manual triage impossible. Unit42 traced a single coordinated operation to roughly 194,345 malicious FQDNs, with heavy impersonation of USPS and toll services and clustering across common U.S.-hosted infrastructure. That volume only makes sense as phishing-as-a-service, where one kit fuels dozens of independent actors.

Indicators worth searching for right now:

Domain churn: registration-to-teardown windows under 24 hours
Typosquatted brand strings in the FQDN (e.g., “usps-track” variants)
Hosting clustering on a narrow set of ASNs or cloud providers
Short-lived TLS certificates issued same-day as domain registration
CAPTCHA gates immediately preceding a credential or payment form

What Telemetry and Correlation Rules Catch Smishing Early?

Detection engineering for smishing depends on stitching together signals that live in different systems: mobile carriers, web proxies, and DNS resolvers rarely talk to each other by default, making mobile banking fraud risk an especially critical concern for detection strategies.

Ingest these sources first, in priority order:

pDNS — surfaces newly registered and rapidly churning domains before they hit your web proxy logs.
Web proxy / CDN logs — captures the actual HTTP fetch when a user taps the link.
Mobile-reporting signals — user-submitted forwards, which are often your earliest indicator ahead of any network telemetry.
Network/DNS logs — confirm resolution timing and correlate with SMS receipt timestamps.

A correlation rule worth building: flag any sequence where an SMS or IM message arrives, is followed within minutes by an HTTP GET to a domain registered in the past 72 hours, and that session ends in a POST request containing form fields resembling credentials or payment data. In pseudocode: WHERE event_type = 'sms_received' AND linked_domain.age_days < 3 AND next_event(http_post, window=10min).body CONTAINS credential_pattern. Tune the domain-age threshold upward if you’re getting noise from legitimate marketing shorteners.

Triage high-churn domains separately from campaign-level detection. A single new domain is noise; clustering by ASN and hosting fingerprint is what turns dozens of ephemeral domains into one actionable campaign ID.

Pro Tip: If your SIEM can’t ingest carrier-side SMS metadata directly, treat user-reported messages as your primary telemetry source rather than a secondary confirmation. It’s often the fastest signal you have.

What Mitigations Actually Reduce Smishing Exposure?

Immediate actions cost nothing and take a day to roll out: forward suspicious messages to 7726 (SPAM), block confirmed phishing FQDNs at the DNS resolver, and stand up a one-click user-reporting workflow so employees don’t have to guess who to email.

Medium-term, the highest-leverage move is retiring SMS-based two-factor authentication in favor of phishing-resistant MFA (FIDO2 keys or authenticator apps), since Krebs reported that PhaaS operators are now pivoting directly at financial institutions and mobile wallets, specifically to harvest the credentials SMS-based 2FA was supposed to protect. Layer in mobile threat defense on managed and BYOD devices.

Hands handling mobile security key device

On policy: define BYOD device requirements, formalize incident reporting SLAs, and set a communications policy so employees know what a legitimate internal text looks like. Escalate confirmed campaigns to the FTC, IC3, or CISA when the scale or targeting suggests organized fraud rather than opportunistic spam.

How Do You Operationalize Smishing Hunting at Scale?

Smishing kits are cheap and reused across many independent actors, which means attribution by actor is a dead end. Detection built around infrastructure fingerprints, not identity, scales better.

Build campaign IDs, not domain lists. Collapse churned FQDNs into a single campaign identifier using pDNS clustering, TLS certificate fingerprints, and hosting ASN patterns. This turns 40 ephemeral domains into one entry in your detection coverage log.
Correlate user reports against web telemetry. Match reported message text and sender ID against proxy logs for the same time window; a single confirmed report often unlocks dozens of silent clicks in your logs you’d otherwise miss.
Map coverage back to ATT&CK IDs continuously. Every campaign ID should carry its T1660/T1566 mapping and confidence score forward into your detection documentation, not just the original ticket.

Query-based hunting like this pairs naturally with a practical smishing threat-hunting playbook built around the same evidence fields. Teams evaluating readiness for this kind of correlation work can run the SmishAlert Self-Eval to see where reporting and telemetry gaps sit today.

Pro Tip: Treat every closed campaign ID as a detection rule candidate. If you correlated it manually once, write the query so your SIEM catches the next variant automatically.

Smishing detection built on generic phishing rules will miss executive impersonation and payroll-fraud lures that never touch a corporate inbox; Smishalert’s platform extends visibility into SMS, iMessage, and WhatsApp so security teams can correlate campaign infrastructure the same way they already do for email, with credential-harvesting detection and executive impersonation coverage built specifically for the mobile channel MITRE’s T1660 describes.

What This Mapping Exercise Actually Reveals

The conventional advice on smishing treats ATT&CK mapping as a compliance checkbox, something you do after the incident to satisfy an auditor. That gets the sequence backward. Mapping decided at intake, with confidence scores and evidence fields baked into the ticket, is what actually feeds detection engineering. Mapping done after the fact just documents what already happened.

What This Mapping Exercise Actually Reveals — overview diagram

The bigger gap is domain-level thinking. Most teams still build detections around individual FQDNs, which guarantees a losing race against kits generating dozens of throwaway domains an hour. The Unit42 and Talos data both point the same direction: infrastructure fingerprinting, ASN clustering, certificate reuse, hosting patterns, catches the campaign, not the domain.

If you take one thing from this playbook, prioritize the evidence checklist over the technique debate. Analysts spend too long arguing T1660 versus T1566.003 and not enough time capturing the pDNS timeline before it disappears. Get the evidence first. The mapping is the easy part.

— Sophie