SmishAlert
← Blog

4 SIEM Signals to Stop RCS Phishing Campaigns for Security Teams

4 SIEM Signals to Stop RCS Phishing Campaigns for Security Teams

Yes, RCS phishing is a real and growing risk, not a theoretical one. Rich Communication Services expands what a text message can do, and every added capability, branded logos, buttons, group chats, gives attackers more surface to exploit. Security teams should add RCS to their threat model now, push for verified RBM sender profiles on brand-facing accounts, and route mobile messaging signals into existing detection pipelines rather than treating texts as outside the perimeter.

TL;DR:

  • Attackers can easily spoof verified profiles and imitate brand visuals, making phishing messages more convincing and harder to detect.
  • Encryption on RCS complicates traditional content inspection, requiring detection based on metadata, behavior, and signals instead of message content.
  • Using verified RBM profiles reduces the attack surface, but attackers can still exploit weak onboarding checks or impersonate unverified brands.
  • Common tactics include group message abuse, URL hiding, domain churn, and staged reply flows designed to evade static filters and increase success rates.
  • Layered defenses such as carrier spam filtering, on-device detection, link redirects, and cross-channel monitoring are essential to combat RCS phishing effectively.
Smishalert
See Messaging Threats Beyond Email
SmishAlert helps security teams identify, measure, and respond to social engineering attacks across SMS, iMessage, WhatsApp, and other channels.
Explore SmishAlert

Table of Contents

How RCS Changes the Threat Model

SMS phishing worked because the channel was primitive: plain text, a sender ID that was easy to fake, and no visual cues to help a recipient judge legitimacy. RCS flips that. It supports branded sender profiles with verified logos, rich media like images and carousels, interactive buttons, read receipts, and group messaging that behaves more like a chat app than a text thread. Some RCS traffic is encrypted end to end, while other traffic (including most business messaging) travels encrypted only in transit between carrier infrastructure.

That mix creates two problems at once. First, the same visual polish that makes RCS good for legitimate brand communication, a bank’s logo, a delivery courier’s tracking button, also makes a convincing forgery easier to build. Rich media, branded logos, and interactive elements that RCS enables for legitimate senders are exactly what attackers copy to make a phishing message look official. A recipient trained to distrust a random 10-digit number sending a plain-text link is far less suspicious of a message carrying a familiar logo and a “Track Package” button.

Second, encryption complicates the defenses security teams have relied on for years. Network-level content scanning, the kind that inspects message bodies in transit for known malicious patterns, works less reliably when a growing share of RCS traffic is end-to-end encrypted. Detection has to shift toward endpoint signals, metadata, and behavioral fingerprints instead of body-content inspection alone.

Verification helps, but it isn’t absolute protection. A verified RBM profile confirms that a specific business entity registered that sender identity with the carrier or Google, and it gives recipients a visible trust mark. Attackers who exploit weak onboarding checks, or who impersonate a brand before that brand has registered its own verified profile, can still slip through. Verification narrows the attack surface. It doesn’t close it. Security teams need to treat “verified” as one signal among several, not a green light to stop watching mobile channels entirely.

RCS Phishing Tactics and Real-World Examples

Attackers targeting RCS lean on a handful of repeatable techniques, and most of them leave observable traces if you know where to look.

  • Sender spoofing and impersonation: Fake or unverified profiles mimic banks, delivery services, or internal IT departments, often reusing a legitimate brand’s logo and color scheme before verification checks catch the mismatch.
  • Group chat abuse: Attackers add targets to group threads with a mix of real and fake participants, using social proof from the group dynamic to lower suspicion before dropping a malicious link.
  • URL hiding and domain churn: Links are shortened, embedded in buttons rather than shown as raw text, or rotated across newly registered domains every few hours to outrun blocklists.
  • Pre-registration fraud: Attackers register RCS business profiles under look-alike brand names before the real brand claims its own verified identity, exploiting gaps in carrier onboarding review.
  • AI-templated messaging: Large batches of near-identical phishing bodies get personalized at scale, sometimes with subtle tells like non-native date formatting or repeated call-to-action phrasing that a native speaker wouldn’t write.

The clearest documented example of this playbook in action is the Lucid phishing-as-a-service platform, covered in detail by DarkReading’s reporting on Lucid’s exploitation of iMessage and RCS. Lucid operators use a staged approach: an initial, benign-looking message prompts a reply to establish a live conversation, then a single-use or geofenced URL follows only after the target engages. That sequencing defeats static URL blocklists, since the malicious link often doesn’t exist until the target has already responded.

Statistic callout: Reporting on Lucid-style campaigns, drawing on Prodaft’s analysis covered by DarkReading, estimated conversion rates around 5% in observed campaigns, a figure that looks small until you multiply it across a template capable of reaching thousands of recipients in a single push.

Security operations teams should log and search for template-identical message bodies appearing across different sender numbers, domains registered within the past 24 to 48 hours paired with matching phishing templates, and rapid-fire group renames that precede a link drop.

Defensive Controls: Protocol, Carrier, and App-Level Mitigations

The strongest defense against RCS phishing isn’t a single tool. It’s a layered set of controls that operate at the protocol level, the carrier level, and the device level, each catching what the others miss.

Verified RBM as the front-line trust signal. An industry case study conducted with KDDI and covered by GSMA found that verified RCS Business Messaging profiles, complete with logos and verification marks, work as an effective, low-cost countermeasure against phishing. The mechanism is simple: recipients see a clear visual difference between a verified sender and an anonymous one, and that difference reduces click-through on impersonation attempts. Any organization sending customer-facing RCS messages should treat RBM verification as a baseline requirement, not an optional upgrade.

Server-side filtering and Safe Browsing checks. Google’s own guidance for RCS for Business describes verified business profiles, carrier-level spam protections, and server-side URL scanning as the core defenses reducing phishing and spam volume on the platform. Google Messages also applies on-device machine learning and ephemeral Safe Browsing checks that flag suspicious links before a user taps them, often enabled by default. Security teams shouldn’t assume every employee device has this turned on, though. It’s worth confirming as part of mobile device baseline checks.

Secure message design. Never ask a recipient to enter credentials, one-time passcodes, or payment details directly inside an RCS message. Vendor guidance from Sinch’s RCS security overview recommends treating RCS as suitable for most notification and marketing use cases but not for exchanging regulated or highly sensitive data. The safer pattern is a message that redirects to an authenticated app session or a known web domain, never a form embedded in the chat thread itself. That same logic extends to other messaging channels; WhatsApp, for instance, isn’t built for regulated data exchange either, which is a useful reminder that channel choice matters as much as message content.

A short checklist for brand and product teams:

  • Register and verify your RBM sender profile before launching any customer-facing RCS campaign.
  • Never embed credential or payment forms inside a message body.
  • Route every link through an authenticated redirect, not a bare URL.
  • Monitor your own brand name for look-alike RCS profiles registered by third parties.
  • Confirm carrier-side spam filtering is active for your sending account, not just assumed.

Pro Tip: If your brand hasn’t registered a verified RCS profile yet, assume someone else could register a look-alike version first. Claiming your verified identity early is cheaper than fighting an impersonation campaign after the fact.

Operational Detection, Monitoring, and Incident Response

Treating RCS as part of the human attack surface means building the same rigor around it that you already apply to email phishing, just with different telemetry sources.

Start with what to collect. User-submitted reports remain the fastest early warning system, since employees who forward a suspicious message before clicking give you a head start no automated scanner provides. Layer that with Google and carrier spam reports, URL click telemetry from your secure web gateway, and raw inbound message captures where your legal and privacy review permits it. Each source alone misses things. Together, they build a pattern.

From there, a few detection heuristics do most of the work:

  1. Fingerprint repeated message bodies across different phone numbers and sender profiles, since attackers reuse templates far more than they vary them.
  2. Flag newly registered domains (24 to 48 hours old) that pair with a phishing-style template, a strong signal borrowed directly from Enea’s analysis of rich-messaging fraud patterns.
  3. Watch for staged reply flows, where an initial benign message precedes a malicious link only after the target responds, the signature Lucid-style behavior.
  4. Track group-rename patterns that occur right before a link drops into a group thread.

When an incident surfaces, the response sequence should mirror your existing phishing playbook: triage the report within your SOC queue, preserve message artifacts and headers before they age out of carrier retention windows, coordinate takedown requests with the hosting provider or carrier abuse desk, and send a plain-language customer or employee alert if the campaign impersonated your brand. Close the loop with a lessons-learned review that feeds new indicators back into detection rules.

The step teams skip most often is correlation across channels. A campaign that shows up as an RCS message today may have shown up as an email phishing attempt against the same target list last week. Feeding mobile messaging events into the same SIEM pipeline as email and web telemetry, rather than treating detection efforts in isolation, is how you catch campaign-level patterns instead of one-off incidents.

Pro Tip: If your SIEM has never ingested an RCS or SMS event, start with a narrow pilot: pull user-reported messages into a dedicated queue for 30 days before building full correlation rules. You’ll learn your organization’s actual volume before committing engineering time to automation.

Industry and Policy Coordination Still Lags Behind

No single organization can fix RCS phishing alone. Carriers control onboarding, and stronger pre-screening of RBM registrations, verifying that a business applying for a verified profile actually owns the brand it claims, would close the pre-registration fraud gap that attackers currently exploit. CPaaS providers and carriers both have a role in deploying AI-driven firewalling that scans URLs and image content in real time rather than relying solely on static blocklists, a shift Enea’s research on rich-messaging security argues is necessary given how AI has industrialized attacker output.

Standardized spam-reporting flows across carriers would also help. Right now, reporting mechanisms vary enough between providers that coordinated takedowns move slower than the campaigns they’re chasing. And because attackers pivot freely between SMS, RCS, and other messaging channels to dodge single-channel defenses, cross-channel intelligence sharing between carriers, platform vendors, and enterprise security teams isn’t optional infrastructure. It’s the only way detection keeps pace with a threat that doesn’t respect channel boundaries.

Where SmishAlert Fits in the RCS Defense Playbook

Everything in this playbook, user reporting, template fingerprinting, cross-channel correlation, SIEM integration, is exactly what SmishAlert’s platform is built to operationalize. It captures messaging-based social engineering attempts across SMS, iMessage, WhatsApp, and RCS, correlates them into campaign-level patterns, and feeds that intelligence into the security stack your team already runs.

For a security leader trying to get budget approval, the practical path is incremental: run a self-eval to gauge current mobile messaging visibility, scope a 30-day pilot, then integrate findings into your existing detection workflow.

Pro Tip: When pitching mobile messaging visibility to leadership, frame it as closing a blind spot in an existing program rather than requesting a new security category. Budget conversations move faster when the ask is “extend what we already do” instead of “fund something new.”

A Contrarian Read on RCS Phishing Risk

A Contrarian Read on RCS Phishing Risk — overview diagram

Most coverage of RCS phishing treats verification as the fix, register your RBM profile, add the logo, problem solved. That framing undersells how much attacker behavior has already adapted around it. Lucid’s staged-reply model didn’t emerge because verification failed technically. It emerged because verification only screens the sender, not the conversation that follows. A verified profile can still lead a target into a live, human-feeling exchange that ends in a single-use link no static filter ever sees coming.

The uncomfortable truth is that RCS phishing defense is converging with insider-threat detection logic: you can’t fully trust the channel, so you have to watch the behavior. That’s a mindset shift most security programs haven’t made yet, because SMS never demanded it. A flat-text message couldn’t hold a conversation. RCS can, and that single capability is why the old “block the bad number” model is already obsolete for this channel. Teams that keep waiting for a clean technical fix, one config change, one carrier update, are going to keep losing ground to attackers who’ve already moved past that assumption.

— Sophie

Sources

← Back to Blog