Part 13: Real-World Attacks — SMS Abuse, Mobile Malware & MFA Bypass

Learning Objective: Understand how organized crime and sophisticated attackers exploit SMS infrastructure, deploy mobile malware at scale, and chain these techniques with signaling attacks to bypass multi-factor authentication — with detailed network diagrams showing each attack's origin and propagation path.

Table of Contents

• 11. Massive Android SMS-Stealer Campaign (OTP Harvesting at Scale)
• 12. SMS-Based OTP Interception for Account-Takeover Services
• 13. SMS Phishing + SS7 Interception Combined Attack
• 14. Bulk A2P SMS Channel Abuse (Fake Bank and Parcel Messages)
• 15. Premium-Rate SMS Fraud via Malicious Apps
• SMS/Malware Attack Summary
• Lab Exercises

The SMS Attack Ecosystem

SMS was designed in the 1980s as a simple paging mechanism. It has since become a critical piece of authentication infrastructure despite having zero end-to-end security. The following diagram shows how the SMS ecosystem is exploited across multiple layers simultaneously.

graph TB
    subgraph "SMS Delivery Chain"
        Service[🏦 Service Provider
Bank / SaaS / Exchange]
        A2P_GW[📨 A2P Gateway
Twilio / Vonage / etc.]
        SMSC[📨 SMSC
Carrier SMS Center]
        HLR[(🔐 HLR/HSS)]
        MSC[🎛️ MSC/MME]
        BTS[📡 BTS/eNB]
        UE[📱 User Phone]
    end

    subgraph "Attack Vectors"
        SS7_Attack[🔴 SS7 Interception
Redirect SMS at
signaling layer
(Part 11, Attack #1)]
        SIM_Swap[🔴 SIM Swap
Reassign number
at provisioning
(Part 12, Attack #7)]
        Malware[🔴 Android Malware
Read SMS on device
forward to C2
(THIS SECTION)]
        A2P_Abuse[🔴 A2P Abuse
Inject fake SMS via
bulk gateway
(THIS SECTION)]
        Premium_Fraud[🔴 Premium SMS
Send premium SMS
from victim's device
(THIS SECTION)]
    end

    Service -->|"1. Send OTP"| A2P_GW
    A2P_GW -->|"2. SMPP/SS7"| SMSC
    SMSC -->|"3. SRI query"| HLR
    HLR -->|"4. Route info"| SMSC
    SMSC -->|"5. MT-Forward"| MSC
    MSC -->|"6. Deliver"| BTS
    BTS -->|"7. SMS-DELIVER"| UE

    SS7_Attack -.->|"❌ Hijack at step 4"| HLR
    SIM_Swap -.->|"❌ Hijack at HLR"| HLR
    Malware -.->|"❌ Steal at step 7"| UE
    A2P_Abuse -.->|"❌ Inject at step 2"| A2P_GW
    Premium_Fraud -.->|"❌ Send FROM device"| UE

    style SS7_Attack fill:#ff6666,color:#fff
    style SIM_Swap fill:#ff6666,color:#fff
    style Malware fill:#ff6666,color:#fff
    style A2P_Abuse fill:#ff6666,color:#fff
    style Premium_Fraud fill:#ff6666,color:#fff

11. Massive Android SMS-Stealer Campaign (OTP Harvesting at Scale) (I, E)

Executive Summary

In 2024, Zimperium zLabs uncovered the largest documented SMS-stealing malware campaign: 107,000+ unique Android malware samples operating across 113 countries, stealing SMS messages and OTPs for over 600 service brands including banks, crypto exchanges, email providers, and social media platforms. The malware operated as part of an industrialized ecosystem with Telegram bot-based command-and-control, automated OTP extraction, and resale infrastructure.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "Malware Distribution"
        Fake_Store[🔴 Fake App Store
/ Third-party APK site]
        Malvertising[🔴 Malvertising
Ads linking to
malicious APKs]
        Telegram_Dist[🔴 Telegram Channels
APK distribution]
    end

    subgraph "Victim's Android Device"
        UE[📱 Victim Android
Installs malicious app]
        SMS_Inbox[📥 SMS Inbox
All incoming SMS
including OTPs]
        Malware_App[🔴 SMS Stealer App
Requests SMS permission
Runs as background service]
    end

    subgraph "Mobile Network (Legitimate SMS Delivery)"
        SMSC[📨 SMSC]
        BTS[📡 BTS/eNB]
    end

    subgraph "C2 Infrastructure"
        C2_Telegram[🔴 Telegram Bot
Receives stolen SMS
in real-time]
        C2_Firebase[🔴 Firebase
Cloud Messaging
for push commands]
        C2_Server[🔴 Custom C2
SMS aggregation
+ OTP parsing]
    end

    subgraph "Monetization Layer"
        OTP_Market[🔴 OTP Marketplace
Sell captured OTPs
to other criminals]
        Account_Service[🔴 Account Creation
Service
Create verified accounts
using stolen OTPs]
    end

    subgraph "Legitimate Services (Victims)"
        Bank[🏦 Banks]
        Crypto[₿ Crypto Exchanges]
        Email[📧 Email Providers]
        Social[💬 Social Media]
    end

    Fake_Store -->|"1. Victim downloads
fake app"| UE
    Malvertising -->|"1."| UE
    Telegram_Dist -->|"1."| UE

    UE -->|"2. Installs app →
grants SMS permission"| Malware_App

    Bank -->|"OTP SMS"| SMSC
    Crypto -->|"OTP SMS"| SMSC
    SMSC --> BTS
    BTS -->|"3. SMS delivered"| SMS_Inbox

    Malware_App -->|"4. Reads SMS
from inbox"| SMS_Inbox
    Malware_App -->|"5. Forwards to C2"| C2_Telegram
    Malware_App -->|"5."| C2_Firebase
    Malware_App -->|"5."| C2_Server

    C2_Server -->|"6. Parsed OTPs"| OTP_Market
    C2_Server -->|"6."| Account_Service

    style Malware_App fill:#ff6666,color:#fff
    style C2_Telegram fill:#ff6666,color:#fff
    style C2_Firebase fill:#ff6666,color:#fff
    style C2_Server fill:#ff6666,color:#fff
    style OTP_Market fill:#ff6666,color:#fff
    style Account_Service fill:#ff6666,color:#fff
    style SMS_Inbox fill:#ffaa66
    style UE fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Victim as 📱 Victim (Android)
    participant Malware as 🔴 SMS Stealer App
    participant C2 as 🔴 C2 (Telegram Bot)
    participant Market as 🔴 OTP Marketplace
    participant Buyer as 👤 Criminal Buyer
    participant Bank as 🏦 Bank

    Note over Victim: Phase 1: Infection
    Victim->>Victim: Downloads "Free PDF Reader"
from third-party app store
    Victim->>Malware: Installs → grants SMS permission
(appears as normal app request)
    Malware->>Malware: Registers as default SMS handler
OR uses NotificationListenerService

    Note over Victim: Phase 2: Persistent SMS Exfiltration
    Malware->>C2: Register device: Country=US,
Carrier=T-Mobile, IMSI=310260XXX
    C2->>Malware: ACK — device enrolled

    loop Every incoming SMS
        Bank->>Victim: "Your verification code is 847291"
        Malware->>Malware: Intercept SMS before user sees notification
        Malware->>C2: Forward: From=+1800BANK, Body="Your
verification code is 847291", Time=14:23:07
        C2->>C2: Parse OTP: "847291" for brand "Chase Bank"
    end

    Note over C2: Phase 3: Monetization
    C2->>Market: List available OTPs:
US/T-Mobile/Chase Bank — $2.00
    Buyer->>Market: Purchase OTP for Chase Bank
    Market->>Buyer: OTP: 847291 (valid ~60 seconds)
    Buyer->>Bank: Enter OTP → account access

Technical Deep Dive

Malware capabilities and evasion:

Scale of the ecosystem (per Zimperium 2024 report):

Android permission model weakness: On Android versions prior to 13, the READ_SMS permission was granted at install time with a single user tap. Even on Android 13+, users routinely grant SMS access to apps claiming to need it for "verification" purposes. Once granted, the permission is persistent until manually revoked.

Detection Indicators

• App requesting SMS permission without legitimate need (PDF readers, flashlight apps, game cheats)
• Background data usage to Telegram Bot API domains (api.telegram.org) or Firebase endpoints
• SMS notification suppression — user not seeing OTP messages that were sent
• Device registering with unusual C2 patterns — periodic check-ins to rotating domains
• Carrier-side: Single subscriber's phone receiving OTPs for multiple different banking brands in rapid succession

STRIDE Assessment

Mitigation

• ✅ Google Play Protect — actively detects and removes known SMS stealer families
• ✅ Don't sideload APKs — only install from Google Play Store (though some malware bypasses Play screening)
• ✅ Android 13+ SMS permission restrictions — newer Android versions limit which apps can access SMS
• ✅ App-based TOTP instead of SMS OTP — Google Authenticator, Authy, etc. are not interceptable by SMS malware
• ✅ Service providers: Rich signals for fraud detection — detect when OTP is used from a different device/IP than the phone
• ⚠️ User education — teach users to deny SMS permission to apps that don't need it
• ⚠️ Enterprise MDM — enforce app whitelisting and permission policies on managed devices

References

• SecurityWeek: Massive OTP-Stealing Android Malware Campaign Discovered (2024)
• Zimperium zLabs: "SMS Stealer" Technical Report (2024)
• Google: Android Security Bulletin and Play Protect Detection Reports

12. SMS-Based OTP Interception for Account-Takeover Services (S, I, E)

Executive Summary

The same ecosystem that distributes SMS-stealer malware (Attack #11) also operates as a fully commercialized access-broker service where threat actors can pay for phone numbers and receive OTPs to create or hijack accounts. This represents the service layer built on top of the technical interception capabilities — turning SMS theft into a self-service product for the broader cybercrime ecosystem.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "OTP Service Infrastructure"
        Portal[🔴 Web Portal / API
Self-service OTP
marketplace]
        Bot[🔴 Telegram Bot
Automated OTP
delivery]
        Router[🔴 OTP Router
Routes requests to
best interception method]
    end

    subgraph "Interception Methods (Parallel)"
        Method_SS7[🔴 SS7 Interception
For any subscriber
(highest capability)]
        Method_SIM[🔴 SIM Farm
Physical SIMs in
GSM modem banks]
        Method_Malware[🔴 Malware Fleet
107K+ infected devices
worldwide]
        Method_VoIP[🔴 VoIP/Virtual
Numbers
For services accepting
VoIP numbers]
    end

    subgraph "Mobile Network (Abused)"
        SMSC[📨 SMSC]
        HLR[(🔐 HLR/HSS)]
        BTS[📡 BTS/eNB]
    end

    subgraph "Customers"
        Buyer_Fraud[👤 Fraud Buyer
Creates fake bank accounts]
        Buyer_ATO[👤 ATO Buyer
Hijacks existing accounts]
        Buyer_Bulk[👤 Bulk Buyer
Creates thousands of
verified social media accounts]
    end

    Buyer_Fraud -->|"Request: US number
for Chase Bank OTP"| Portal
    Buyer_ATO -->|"Request: Target's
OTP for Gmail"| Bot
    Buyer_Bulk -->|"API: 1000 numbers
for Instagram"| Portal

    Portal --> Router
    Bot --> Router

    Router -->|"Best method
for request"| Method_SS7
    Router -->|"Best method"| Method_SIM
    Router -->|"Best method"| Method_Malware
    Router -->|"Best method"| Method_VoIP

    Method_SIM <-->|"Legitimate SMS
delivery"| SMSC
    Method_SS7 -.->|"❌ Intercept via
SS7"| HLR
    Method_Malware -.->|"❌ Steal from
infected device"| BTS

    style Portal fill:#ff6666,color:#fff
    style Bot fill:#ff6666,color:#fff
    style Router fill:#ff6666,color:#fff
    style Method_SS7 fill:#ff6666,color:#fff
    style Method_SIM fill:#ff6666,color:#fff
    style Method_Malware fill:#ff6666,color:#fff
    style Method_VoIP fill:#ff6666,color:#fff
    style Buyer_Fraud fill:#ff6666,color:#fff
    style Buyer_ATO fill:#ff6666,color:#fff
    style Buyer_Bulk fill:#ff6666,color:#fff

Attack Sequence — Step by Step

sequenceDiagram
    participant Buyer as 👤 Criminal Buyer
    participant API as 🔴 OTP Service API
    participant Router as 🔴 Routing Engine
    participant SIMFarm as 🔴 SIM Farm (India)
    participant SMSC as 📨 Indian SMSC
    participant Instagram as 💬 Instagram

    Note over Buyer: Use Case: Create 500 fake
Instagram accounts with Indian numbers

    Buyer->>API: POST /order
{country: "IN", service: "instagram",
quantity: 500, type: "new_account"}

    API->>Router: Route 500 number requests
    Router->>SIMFarm: Allocate 500 Indian numbers
from SIM bank

    loop For each of 500 numbers
        SIMFarm->>API: Number ready: +91-XXXXXXXX

        API->>Buyer: Number assigned: +91-XXXXXXXX
        Buyer->>Instagram: Create account with +91-XXXXXXXX
        Instagram->>SMSC: Send SMS verification code
        SMSC->>SIMFarm: SMS delivered to SIM

        SIMFarm->>API: OTP received: "142857"
        API->>Buyer: OTP: 142857

        Buyer->>Instagram: Enter OTP → account verified
    end

    Note over Buyer: 500 verified Instagram accounts
created in ~2 hours
Total cost: ~$250 (50¢ each)
    Note over Buyer: Accounts used for:
- Spam / influence operations
- Scam page promotion
- Bot networks for engagement fraud

Technical Deep Dive

The access-broker business model:

API documentation (actual structure observed in the wild):

POST /api/v1/number/request
{
  "country": "US",
  "carrier": "any",
  "service": "whatsapp",
  "type": "sms"
}

Response:
{
  "order_id": "abc123",
  "number": "+12025551234",
  "expires_in": 1200,
  "price": 1.50
}

GET /api/v1/sms/check/{order_id}
Response:
{
  "status": "received",
  "sms": "Your WhatsApp code is 847-291",
  "code": "847291"
}

Supply chain: The service operators are intermediaries — they don't directly operate SS7 access or malware campaigns. Instead, they aggregate supply from multiple sources (SIM farms, malware operators, SS7 brokers) and present a unified API to criminal customers.

Detection Indicators

• Service-side: Clusters of new account registrations from the same carrier/country with sequential or patterned phone numbers
• Behavioral: Accounts created and immediately used for spam/fraud without normal user onboarding behavior
• Number intelligence: Numbers flagged by phone intelligence services (Telesign, IPQualityScore) as SIM farm or VoIP
• Velocity anomalies: Same phone number used to verify accounts at multiple different services within hours
• Pattern: OTP requested → used within 30 seconds (automated), vs. normal human 30-120 second response

STRIDE Assessment

Mitigation

• ✅ Phone number intelligence scoring at account creation — flag VoIP, SIM farm, and recycled numbers
• ✅ Device fingerprinting — require device attestation (SafetyNet/Play Integrity API) alongside phone verification
• ✅ Behavioral analysis — detect bot-like signup patterns (too fast, no browsing history, fresh device fingerprint)
• ✅ Rate limiting per number — limit how many accounts a single number can verify per day/week
• ✅ Progressive verification — require additional proof-of-identity for sensitive operations (ID upload, liveness check)
• ⚠️ CAPTCHA — adds friction but can be solved via services like 2Captcha for $0.001 each
• ⚠️ Phone verification alternatives — email, social login, or biometric verification reduce dependence on SMS

References

• SecurityWeek: Massive OTP-Stealing Android Malware Campaign Discovered (2024)
• Zimperium zLabs: "SMS Stealer" Infrastructure Analysis
• GSMA: A2P SMS Fraud Framework

13. SMS Phishing + SS7 Interception Combined Attack (S, I, E)

Executive Summary

The 2017 German bank fraud incident (introduced in Part 11, Attack #1) demonstrates the most dangerous class of telecom attack: a multi-layer chain combining social engineering (credential phishing), core network exploitation (SS7 SMS interception), and financial fraud. The attackers first harvested banking credentials via phishing, then used SS7 access to intercept the SMS confirmation codes (mTAN), enabling direct cash-out. This attack is significant because it defeated SMS-based two-factor authentication through a combination of techniques that individually are well-known but together are devastating.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "Phase 1: Social Engineering (Internet)"
        Phish_Email[🔴 Phishing Email
Fake bank login page]
        Phish_Site[🔴 Credential Harvester
Captures username + password]
    end

    subgraph "Phase 2: SS7 Exploitation (Signaling Network)"
        SS7_Access[🔴 SS7 Access Point
Leased from foreign telco]
        STP[🔀 STP
Signal Transfer Point]
    end

    subgraph "Carrier Network (O2-Telefónica)"
        HLR[(🔐 HLR)]
        SMSC[📨 SMSC]
        MSC[🎛️ MSC/VLR]
    end

    subgraph "Banking System"
        Bank_Web[🏦 Online Banking
Login + mTAN transfer]
    end

    subgraph "Victim"
        Victim_PC[🖥️ Victim's Computer
Used for phishing interaction]
        Victim_Phone[📱 Victim's Phone
Never receives mTAN]
    end

    subgraph "Phase 3: Cash-Out"
        Attacker_Phone[🔴 Attacker Phone
Receives intercepted mTAN]
        Mule_Account[🔴 Mule Bank Account
Receives stolen funds]
    end

    Phish_Email -.->|"1. ❌ Phishing email"| Victim_PC
    Victim_PC -.->|"2. ❌ Enters credentials"| Phish_Site
    Phish_Site -.->|"3. Credentials to attacker"| SS7_Access

    SS7_Access -.->|"4. ❌ MAP UpdateLocation
(redirect victim's SMS)"| STP
    STP -.->|"5. ❌ Poisons HLR"| HLR

    SS7_Access -.->|"6. Login to bank
with stolen creds"| Bank_Web
    Bank_Web -->|"7. Send mTAN SMS"| SMSC
    SMSC -->|"8. SRI-SM query"| HLR
    HLR -.->|"9. ❌ Returns attacker's
MSC (poisoned)"| SMSC
    SMSC -.->|"10. ❌ SMS routed
to attacker"| STP
    STP -.->|"11. ❌ mTAN delivered"| Attacker_Phone

    Attacker_Phone -.->|"12. ❌ Enter mTAN
→ authorize transfer"| Bank_Web
    Bank_Web -.->|"13. ❌ Funds transferred"| Mule_Account

    Victim_Phone -.->|"❌ Never receives SMS"| MSC

    style Phish_Email fill:#ff6666,color:#fff
    style Phish_Site fill:#ff6666,color:#fff
    style SS7_Access fill:#ff6666,color:#fff
    style Attacker_Phone fill:#ff6666,color:#fff
    style Mule_Account fill:#ff6666,color:#fff
    style HLR fill:#ffaa66
    style SMSC fill:#ffaa66
    style STP fill:#ffaa66
    style Victim_PC fill:#ffee66
    style Victim_Phone fill:#ffee66
    style Bank_Web fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Attacker as 🔴 Attacker
    participant Victim_PC as 🖥️ Victim (Browser)
    participant Victim_Phone as 📱 Victim (Phone)
    participant SS7 as 🔀 SS7 Network
    participant HLR as 🔐 HLR (O2)
    participant SMSC as 📨 SMSC (O2)
    participant Bank as 🏦 Bank

    rect rgb(255, 230, 230)
        Note over Attacker,Victim_PC: Phase 1: Credential Harvesting (Days/Weeks Before)
        Attacker->>Victim_PC: Phishing email: "Security alert —
verify your bank account"
        Victim_PC->>Attacker: Clicks link → enters
bank username + password
        Note over Attacker: Credentials stored for later use
    end

    rect rgb(255, 220, 200)
        Note over Attacker,HLR: Phase 2: SS7 Hijack (Night of Attack — Typically 2-4 AM)
        Attacker->>SS7: MAP UpdateLocation
(IMSI=victim, MSC=attacker GT)
        SS7->>HLR: Register victim at attacker MSC
        HLR->>SS7: ACK — victim "roaming" at attacker MSC
        Note over Attacker: Victim's SMS now redirected
Attack window: ~30 min before
HLR cleanup or victim notices
    end

    rect rgb(255, 200, 200)
        Note over Attacker,Bank: Phase 3: Fraudulent Transfer
        Attacker->>Bank: Login with stolen credentials
        Bank->>SMSC: "Transfer of €5,000 to DE89XXXX.
mTAN: 847291"
        SMSC->>HLR: SRI-SM: Where is victim?
        HLR->>SMSC: MSC=attacker's Global Title
        SMSC->>SS7: Route SMS to attacker MSC
        SS7->>Attacker: mTAN: 847291

        Attacker->>Bank: Confirm transfer with mTAN 847291
        Bank->>Bank: Transfer authorized ✅
        Note over Bank: €5,000 sent to mule account
    end

    rect rgb(255, 180, 180)
        Note over Attacker,Victim_Phone: Phase 4: Cleanup & Repeat
        Attacker->>SS7: Repeat for additional transfers
(multiple accounts, multiple victims)
        Note over Victim_Phone: Victim's phone works normally
except SMS — may not notice
until morning when checking bank
    end

Technical Deep Dive

Why the attack happens at night: The attackers executed the SS7 hijack and bank transfers between 2:00 AM and 4:00 AM local time because:

1. Victims are asleep and won't notice missing SMS
2. The SS7 UpdateLocation is less likely to be reversed by normal network procedures (no outgoing calls/texts from victim to trigger re-registration)
3. Bank fraud detection thresholds may be lower during off-hours
4. The attack window is approximately 30 minutes before HLR cleanup procedures may trigger

The dual prerequisite:

Neither attack alone is sufficient: Phishing gets credentials but can't bypass SMS 2FA. SS7 interception captures SMS but doesn't know the bank credentials. The combination defeats the entire security model.

Detection Indicators

• Bank-side: Login from IP address in country X, mTAN delivery to MSC in country Y — geographic mismatch
• Carrier-side: UpdateLocation for domestic subscriber pointing to foreign MSC at unusual hours
• SS7 firewall: Category 3 (fraud) alert — UpdateLocation followed by SRI-SM for the same IMSI within minutes
• Victim: Missing SMS notifications from bank; unexpected "roaming" indication on phone
• Temporal correlation: Cluster of bank fraud reports from subscribers on the same carrier within the same night

STRIDE Assessment

Mitigation

• ✅ Push-based transaction confirmation — bank app notification instead of SMS mTAN
• ✅ SS7 firewall at carrier level (blocks UpdateLocation from untrusted sources)
• ✅ Bank-side geo-correlation — compare login IP location with known subscriber cell location
• ✅ Transaction anomaly detection — flag night-time transfers to new recipients
• ✅ Anti-phishing training — reduce initial credential compromise rate
• ⚠️ Home routing for SMS — partial protection; still vulnerable to other interception methods
• ⚠️ SMS replacement — FIDO2/WebAuthn eliminates the SMS dependency entirely

References

• Terrazone: SS7 Security Vulnerabilities, Attacks & Prevention
• Süddeutsche Zeitung (2017): Original reporting on O2-Telefónica SS7 bank fraud
• GSMA FS.11: SS7 Interconnect Security Monitoring Guidelines
• European Banking Authority: Strong Customer Authentication (SCA) requirements under PSD2

14. Bulk A2P SMS Channel Abuse (Fake Bank and Parcel Messages) (S, I)

Executive Summary

Organized fraud rings persistently abuse Application-to-Person (A2P) SMS channels — the legitimate infrastructure used by businesses to send notifications, OTPs, and alerts — to deliver massive volumes of spoofed bank, parcel delivery, and tax authority messages. These messages link to credential-harvesting sites that mimic trusted institutions. The scale is industrial: billions of fraudulent SMS messages per year globally, with sender IDs spoofed to appear as legitimate brands.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "Legitimate A2P Ecosystem"
        Brand[🏦 Legitimate Brand
Bank / DHL / HMRC]
        Legit_Agg[📨 Licensed Aggregator
Twilio / MessageBird]
        SMSC[📨 Carrier SMSC]
    end

    subgraph "Abused A2P Infrastructure"
        Rogue_Agg[🔴 Rogue/Compromised
Aggregator
Weak KYC, complicit, or hacked]
        Spoofed_SID[🔴 Spoofed Sender ID
"Chase Bank"
"Royal Mail"
"HMRC"]
    end

    subgraph "Direct Injection"
        SIM_Farm_SMS[🔴 SIM Farm
Bulk send via
GSM modems]
        SMPP_Direct[🔴 Direct SMPP
Inject into SMSC
via compromised credentials]
    end

    subgraph "Delivery"
        BTS[📡 BTS/eNB]
        Victim[📱 Victim Phone
Receives fake message]
    end

    subgraph "Phishing Infrastructure"
        Phish[🔴 Phishing Site
Fake bank/carrier/gov
login page]
        C2_Creds[🔴 Credential Server
Harvests usernames,
passwords, card numbers]
    end

    Brand -->|"Legitimate A2P"| Legit_Agg
    Legit_Agg -->|"SMPP"| SMSC

    Rogue_Agg -.->|"❌ Spoofed SMS
with fake sender ID"| SMSC
    SIM_Farm_SMS -.->|"❌ Bulk SMS
from prepaid SIMs"| BTS
    SMPP_Direct -.->|"❌ Direct inject
via hacked SMPP"| SMSC

    Spoofed_SID -.-> Rogue_Agg

    SMSC --> BTS
    BTS --> Victim

    Victim -.->|"❌ Clicks link"| Phish
    Phish -.->|"❌ Credentials
harvested"| C2_Creds

    style Rogue_Agg fill:#ff6666,color:#fff
    style Spoofed_SID fill:#ff6666,color:#fff
    style SIM_Farm_SMS fill:#ff6666,color:#fff
    style SMPP_Direct fill:#ff6666,color:#fff
    style Phish fill:#ff6666,color:#fff
    style C2_Creds fill:#ff6666,color:#fff
    style Victim fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Attacker as 🔴 Fraud Operator
    participant Aggregator as 📨 Abused SMS Aggregator
    participant SMSC as 📨 Carrier SMSC
    participant Victim as 📱 Victim Phone
    participant Phish as 🔴 Phishing Site
    participant Bank as 🏦 Victim's Real Bank

    Note over Attacker: Campaign: "Royal Mail Delivery" scam

    Attacker->>Aggregator: Send 1M SMS via SMPP API:
From: "RoyalMail"
Body: "Your parcel is held due to
unpaid £1.45 fee. Pay to release:
royalmail-delivery[.]info/pay"

    Aggregator->>SMSC: SMPP submit_sm
(Sender ID: "RoyalMail")

    Note over SMSC: No sender ID verification!
Message accepted and delivered

    SMSC->>Victim: SMS from "RoyalMail":
"Your parcel is held due to
unpaid £1.45 fee..."

    Note over Victim: Message appears in same thread
as real Royal Mail notifications!

    Victim->>Phish: Clicks link → convincing
"Royal Mail" payment page
    Victim->>Phish: Enters card number,
CVV, billing address

    Phish->>Attacker: Card details harvested

    Attacker->>Bank: Uses stolen card for
purchases / ATM withdrawal

Technical Deep Dive

Why sender ID spoofing works: The A2P SMS ecosystem uses alphanumeric sender IDs (like "Chase" or "RoyalMail") that are set by the sending application. There is no cryptographic verification that the sender actually represents the brand. The SMSC delivers the message with whatever sender ID the aggregator provides.

SMS delivery channels abused:

Thread injection: On many mobile devices, SMS messages are grouped by sender ID. If a spoofed "Chase" message arrives, it appears in the same conversation thread as legitimate Chase messages. This makes it extremely difficult for users to distinguish real from fake.

Detection Indicators

• Sudden volume spike from specific sender IDs at carrier SMSC
• URL patterns in SMS body — newly registered domains, URL shorteners, typosquatting brand domains
• Sender ID inconsistency — same brand name arriving from multiple different aggregators
• Customer complaint clusters — subscribers reporting identical suspicious messages
• A2P aggregator anomalies — unusual traffic patterns from specific aggregator accounts

STRIDE Assessment

Mitigation

• ✅ A2P sender ID registry — US 10DLC (10-digit long code) registration; UK OFCOM sender ID guidelines
• ✅ SMS firewall at carrier — content analysis, URL reputation checking, sender ID validation
• ✅ RCS Business Messaging — verified sender with brand logo and blue checkmark (not spoofable)
• ✅ Aggregator KYC — strict identity verification for A2P SMS accounts; liability for fraud
• ✅ STIR/SHAKEN for SMS — emerging standard for sender authentication (deployment in progress)
• ⚠️ Device-level spam filtering — Google Messages, iOS 17 spam detection (helpful but not comprehensive)
• ⚠️ User education — "Banks will never ask you to click links in SMS" (limited effectiveness at scale)

References

• P1 Security: SMS-Based Attacks — The Hidden Threat Still Exploiting Mobile Networks
• GSMA: A2P SMS Anti-Fraud and Anti-Spam Recommendations
• FCC: TRACED Act and A2P 10DLC Registration Requirements
• UK OFCOM: Anti-Smishing SMS Sender ID Guidelines

15. Premium-Rate SMS Fraud via Malicious Apps (T, E)

Executive Summary

Android malware families have silently subscribed millions of victims to premium-rate SMS services (also known as "premium SMS" or "PSMS"), generating direct revenue for attackers by sending SMS messages to premium-rate short codes or subscribing to WAP billing services. Unlike OTP-theft malware, premium SMS fraud monetizes directly against the victim's phone bill without needing to compromise any downstream service, making it one of the simplest and most direct mobile monetization techniques.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "Victim's Device"
        UE[📱 Victim Android]
        Malware[🔴 Malicious App
Has SEND_SMS permission]
    end

    subgraph "Mobile Network"
        BTS[📡 BTS/eNB]
        SMSC[📨 SMSC]
        Billing[💰 Billing System
Carrier BSS]
    end

    subgraph "Premium SMS Infrastructure"
        Short_Code[📱 Premium Short Code
e.g., 54321
$2.00/msg]
        Content_Provider[🔴 Content Provider
(Attacker-controlled or
revenue-sharing affiliate)]
        Revenue[🔴 Revenue Collection
Payment aggregator
→ attacker's account]
    end

    subgraph "WAP Billing"
        WAP[🌐 WAP Billing Page
Subscribe to "service"
charges carrier bill]
    end

    Malware -.->|"1. ❌ Send SMS to
premium short code
(hidden from user)"| BTS
    BTS --> SMSC
    SMSC -->|"2. Route to
premium service"| Short_Code

    Short_Code -->|"3. Charge event"| Content_Provider
    Content_Provider -->|"4. Revenue share"| Revenue

    Billing -->|"5. ❌ Charge appears
on victim's bill"| UE

    Malware -.->|"Alt: WAP billing
subscription"| WAP
    WAP -.->|"Charge to
carrier bill"| Billing

    Malware -.->|"6. ❌ Intercepts
confirmation SMS
to hide evidence"| SMSC

    style Malware fill:#ff6666,color:#fff
    style Content_Provider fill:#ff6666,color:#fff
    style Revenue fill:#ff6666,color:#fff
    style Short_Code fill:#ffaa66
    style WAP fill:#ffaa66
    style UE fill:#ffee66
    style Billing fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Victim as 📱 Victim (Android)
    participant Malware as 🔴 Malware App
    participant SMSC as 📨 SMSC
    participant Premium as 📱 Premium Service (54321)
    participant Billing as 💰 Carrier Billing
    participant Attacker as 🔴 Attacker (Revenue)

    Note over Victim: Phase 1: Infection
    Victim->>Malware: Install "Battery Optimizer"
from third-party store
    Malware->>Malware: Request SEND_SMS +
RECEIVE_SMS permissions

    Note over Malware: Phase 2: Silent Premium SMS
    Malware->>SMSC: Send SMS to 54321
(premium short code, $2/msg)
    Note over Malware: Suppresses outgoing SMS
notification on device

    SMSC->>Premium: Deliver SMS → trigger charge
    Premium->>Billing: Charge event: $2.00
for MSISDN +1-555-0123

    Billing->>Billing: Add $2.00 to
victim's monthly bill

    Note over Malware: Phase 3: Evidence Suppression
    Premium->>SMSC: Confirmation SMS:
"You subscribed to GamePack. $2/msg"
    SMSC->>Victim: Deliver confirmation SMS
    Malware->>Malware: Intercept confirmation SMS
before it reaches notification
    Malware->>Malware: Delete SMS from inbox

    Note over Victim: ❌ Victim sees nothing
❌ No notification, no inbox message

    Note over Malware: Phase 4: Recurring Charges
    loop Every 3 days
        Malware->>SMSC: Send SMS to 54321
        SMSC->>Premium: Charge event: $2.00
        Premium->>Billing: Add to bill
        Malware->>Malware: Suppress confirmation
    end

    Note over Attacker: Revenue: $20/month per victim
× 100,000 infected devices
= $2M/month

    Premium->>Attacker: Revenue share payment
(70-80% to content provider)

Technical Deep Dive

Malware techniques for premium SMS fraud:

The premium SMS revenue chain:

Victim's Phone Bill
  └─ Carrier takes 30-40% (per industry standard)
     └─ Content Aggregator takes 10-15%
        └─ Content Provider (attacker) receives 45-60%

For a $2.00 premium SMS, the attacker receives approximately $0.90–$1.20. With 100,000 infected devices sending 2 premium SMS per week, this generates $180K–$240K per week.

WAP billing is an alternative monetization method where the malware:

1. Opens a hidden WebView
2. Navigates to a WAP billing page
3. Automatically clicks "Subscribe"
4. The charge is added to the carrier bill via direct carrier billing (DCB)
5. The attacker receives the subscription revenue

Detection Indicators

• Unusual SMS traffic to premium short codes from specific devices or subscriber segments
• Carrier billing anomalies — subscribers with no history of premium services suddenly incurring charges
• App permission analysis — apps requesting SEND_SMS without legitimate business need
• Outbound SMS patterns — SMS to short codes at regular intervals from the same device
• Customer complaints — unexpected charges appearing on phone bills

STRIDE Assessment

Mitigation

• ✅ Android SMS permission restrictions (Android 10+) — stricter default SMS app requirements
• ✅ Google Play Protect — detects premium SMS malware families
• ✅ Carrier-level premium SMS blocking — allow subscribers to opt out of premium services
• ✅ Direct carrier billing (DCB) controls — require explicit confirmation (two-click or PIN) for WAP billing
• ✅ Premium SMS rate monitoring — flag devices sending to premium numbers at unusual rates
• ⚠️ User awareness — check phone bills for unexpected charges; report and dispute
• ⚠️ Third-party app store avoidance — most premium SMS malware distributed outside Play Store

References

• SecurityWeek: Massive OTP-Stealing Android Malware Campaign Discovered (2024)
• Google: Android Security Year in Review (premium SMS malware statistics)
• GSMA: Direct Carrier Billing Best Practices and Anti-Fraud Guidelines
• 3GPP TS 23.040: SMS Technical Realization (MO-SMS flow)

SMS/Malware Attack Summary

Attack Comparison Matrix

Combined STRIDE Profile

✅ = Primary impact, ⚠️ = Secondary/moderate impact

Standards Mapping

Lab Replicability

🔬 Lab Exercises

While most attacks in this section require real SMS infrastructure, the signaling and protocol aspects can be explored in the Docker lab:

Exercise 1: Understand SMS Delivery Path

# In the Docker lab, SMS is not directly simulated, but you can
# understand the underlying Diameter/NAS signaling:

# Capture NAS signaling during UE attach
docker exec -it open5gs_amf tcpdump -i any -w /tmp/nas.pcap sctp
# Attach UERANSIM UE, then analyze in Wireshark
# Filter: nas-5gs || ngap
# Look for: SecurityModeCommand (what ciphering/integrity is negotiated?)
# Question: If NAS encryption is null (EA0), could SMS content be read in transit?

Exercise 2: Examine SMS-over-NAS Signaling

# In 5G SA, SMS is delivered over NAS (Non-Access Stratum) signaling
# not through a traditional SMSC. This is called "SMS over NAS" (SoNAS).
#
# In Wireshark, look for:
# - NAS 5GS: DL NAS Transport (container: SMS)
# - NAS 5GS: UL NAS Transport (container: SMS)
#
# The SMS payload is encapsulated in NAS, which IS encrypted (if EA1/EA2 selected)
# This is a security improvement over 4G where SMS could be sent via SS7/SMSC

Exercise 3: Analyze Device Authentication Strength

# Capture the 5G-AKA authentication exchange
docker exec -it open5gs_ausf tcpdump -i any -w /tmp/aka.pcap tcp port 7777
# Register a UE and analyze the capture
# Look for: Nausf_UEAuthentication service calls
# Question: Does 5G-AKA prevent a malware-infected device from being
# authenticated? (Answer: No — AKA authenticates the SIM, not the device OS)

3GPP and Industry References

Summary

• ✅ Android SMS-stealer malware has industrialized OTP theft at a scale of 107,000+ samples across 113 countries
• ✅ OTP-as-a-service platforms have turned SMS interception into a commodity that any criminal can purchase
• ✅ Combined phishing + SS7 attacks defeat SMS-based 2FA by exploiting both the human and the network
• ✅ A2P SMS channel abuse exploits the lack of sender ID authentication in the SMS ecosystem
• ✅ Premium SMS fraud provides direct monetization without needing to compromise any downstream service
• ✅ Core lesson: SMS should be treated as an insecure channel for anything security-sensitive; FIDO2/WebAuthn is the path forward

Next: Part 14: Real-World Attacks — APT & Gang Mobile Infrastructure Operations →