Part 12: Real-World Attacks — Subscriber Identity, SIM & Carrier Data

Learning Objective: Understand how real-world attackers exploit carrier data breaches, SIM provisioning systems, and subscriber identity to enable fraud, account takeover, and targeted surveillance — with detailed network diagrams showing where each attack originates and how it propagates.

Table of Contents

• 6. Mass Carrier PII Breaches Enabling SIM-Swap Waves
• 7. Targeted SIM Swapping for Cryptocurrency and Enterprise Accounts
• 8. Insider-Enabled SIM Fraud and IMSI Re-Provisioning
• 9. Subscriber Metadata Abuse After Carrier Breaches
• 10. Mass Credential Phishing (Smishing) With Carrier Data
• Identity Attack Summary
• Lab Exercises

The Mobile Identity Trust Chain

Before diving into attacks, it is important to understand why subscriber identity matters beyond the carrier itself. Phone numbers are used as identity anchors across the entire digital ecosystem.

graph TB
    subgraph "Carrier Identity Systems"
        CRM[🖥️ CRM / Customer Portal
Name, SSN, Account PIN]
        Provisioning[⚙️ Provisioning System
SIM ↔ IMSI ↔ MSISDN binding]
        HLR_HSS[(🔐 HLR/HSS
IMSI, K, OPc, profile)]
        BSS[💰 BSS/Billing
CDRs, payment info]
    end

    subgraph "SIM Card (Physical Identity)"
        SIM[📶 UICC/SIM
IMSI + K stored
in tamper-resistant chip]
    end

    subgraph "Downstream Trust (Phone Number = Identity)"
        Bank[🏦 Banking
SMS 2FA, account recovery]
        Email[📧 Email
Phone-based recovery]
        Social[💬 Social Media
Phone verification]
        Cloud[☁️ Cloud / SaaS
SSO MFA via SMS]
        Crypto[₿ Crypto Exchange
SMS withdrawal auth]
    end

    CRM <--> Provisioning
    Provisioning <--> HLR_HSS
    Provisioning <--> SIM
    CRM <--> BSS

    SIM -.->|"Phone number
= identity proof"| Bank
    SIM -.->|"Phone number
= recovery method"| Email
    SIM -.->|"Phone number
= verification"| Social
    SIM -.->|"Phone number
= MFA channel"| Cloud
    SIM -.->|"Phone number
= withdrawal auth"| Crypto

    Attacker[🔴 Attacker]
    Attacker -.->|"❌ Breach CRM
→ harvest PII"| CRM
    Attacker -.->|"❌ Bribe insider
→ swap SIM"| Provisioning
    Attacker -.->|"❌ Social engineer
→ port number"| CRM

    style Attacker fill:#ff6666,color:#fff
    style CRM fill:#ffaa66
    style Provisioning fill:#ffaa66
    style Bank fill:#ffee66
    style Crypto fill:#ffee66

6. Mass Carrier PII Breaches Enabling SIM-Swap Waves (I, E)

Executive Summary

Major data breaches at mobile carriers — most notably the 2021 T-Mobile breach affecting 76 million subscribers — exposed names, Social Security numbers, dates of birth, driver's license numbers, and account PINs. This data became the ammunition for massive waves of SIM-swap attacks, as criminals could now pass carrier identity verification for any breached subscriber and take control of their phone number.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "T-Mobile Infrastructure"
        Web_Portal[🌐 Customer Portal
Web / API]
        CRM[(🖥️ CRM Database
76M subscriber records
Name, SSN, DOB, PIN)]
        Provisioning[⚙️ SIM Provisioning
IMSI ↔ MSISDN binding]
        HLR[(🔐 HLR/HSS
Subscriber profiles)]
    end

    subgraph "Attacker (Breach Phase)"
        Hacker[🔴 Attacker
Exploits exposed API /
misconfigured server]
    end

    subgraph "Downstream Fraud (Post-Breach)"
        Fraud_Gang[🔴 Fraud Gang
Purchases breach data
on dark web]
        SIM_Swapper[🔴 SIM Swapper
Calls carrier with
stolen PII to swap SIM]
    end

    subgraph "Victim Impact"
        Victim[📱 Victim
Loses phone number control]
        Bank[🏦 Bank Account
Drained via SMS 2FA bypass]
        Email[📧 Email
Account recovery hijacked]
    end

    Hacker -.->|"1. ❌ Exploit exposed
API / server"| Web_Portal
    Web_Portal -.->|"2. Access CRM"| CRM
    Hacker -.->|"3. Exfiltrate 76M
subscriber records"| CRM

    Fraud_Gang -.->|"4. Purchase data
on dark web"| Hacker
    Fraud_Gang -->|"5. Sells to
SIM swappers"| SIM_Swapper

    SIM_Swapper -.->|"6. ❌ Social engineer
carrier support with
victim's SSN, DOB, PIN"| Provisioning
    Provisioning -.->|"7. ❌ Reassign MSISDN
to new SIM"| HLR

    Victim -.->|"8. ❌ Phone goes dead"| HLR
    SIM_Swapper -.->|"9. Receives victim's
SMS/calls"| Bank
    SIM_Swapper -.->|"10. Account takeover"| Email

    style Hacker fill:#ff6666,color:#fff
    style Fraud_Gang fill:#ff6666,color:#fff
    style SIM_Swapper fill:#ff6666,color:#fff
    style CRM fill:#ffaa66
    style Provisioning fill:#ffaa66
    style Victim fill:#ffee66
    style Bank fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Hacker as 🔴 Breach Attacker
    participant TMobile as 🖥️ T-Mobile Systems
    participant DarkWeb as 🌑 Dark Web Markets
    participant Swapper as 🔴 SIM Swapper
    participant Carrier as 📞 Carrier Support
    participant Provisioning as ⚙️ SIM Provisioning
    participant HLR as 🔐 HLR/HSS
    participant Victim as 📱 Victim Phone
    participant Bank as 🏦 Victim's Bank

    Note over Hacker: Phase 1: Data Breach
    Hacker->>TMobile: Exploit exposed API gateway
(misconfigured test environment)
    TMobile->>Hacker: 76M records: Name, SSN, DOB,
DL#, Phone, PIN, IMEI, IMSI

    Note over Hacker: Phase 2: Monetization
    Hacker->>DarkWeb: Post breach data for sale
($0.01-$1.00 per record)
    DarkWeb->>Swapper: Purchase targeted records
(filter by high-value indicators)

    Note over Swapper: Phase 3: SIM Swap
    Swapper->>Carrier: Call support: "I lost my phone,
need new SIM activated"
    Carrier->>Swapper: Verify identity:
"Name? DOB? Last 4 SSN? PIN?"
    Swapper->>Carrier: Provides all answers
(from breach data)
    Carrier->>Provisioning: Activate new SIM
for MSISDN +1-XXX-XXX-XXXX
    Provisioning->>HLR: Update IMSI binding
(new SIM card IMSI)

    Note over Victim: Phone loses signal ❌
    Victim--xHLR: Deregistered from network

    Note over Swapper: Phase 4: Account Takeover
    Swapper->>Bank: "Forgot password"
→ sends SMS reset code
    Bank->>HLR: SMS to +1-XXX-XXX-XXXX
    HLR->>Swapper: SMS delivered to new SIM
    Swapper->>Bank: Enter code → reset password
    Swapper->>Bank: Transfer funds out

Technical Deep Dive

The breach itself: The T-Mobile breach exploited a misconfigured API gateway in a test environment that was accessible from the public internet. The attacker used automated tools to query the customer database, extracting records in bulk over several weeks before detection.

Why carrier PII is uniquely dangerous:

The SIM swap mechanism: At the HLR/HSS level, a SIM swap is simply an Update Subscriber Data operation that changes the IMSI associated with an MSISDN. The old SIM (old IMSI) is deregistered, and the new SIM (attacker's IMSI) becomes the active identity for that number. All incoming calls and SMS route to the new SIM.

Detection Indicators

• Unusual SIM change patterns: Multiple SIM swaps for unrelated accounts from the same retail location or customer service agent
• Geographic impossibility: SIM activation in a different state/country from the subscriber's home location within hours
• Rapid post-swap activity: Immediately after SIM swap, password reset requests or login attempts across multiple services
• Customer complaints cluster: Multiple subscribers reporting phone service loss in the same time window
• Dark web monitoring: Carrier-specific breach data appearing on markets (record format matches internal schema)

STRIDE Assessment

Mitigation

• ✅ API security: Authentication on all APIs, including test/staging environments; WAF and rate limiting
• ✅ Data minimization: Don't store SSN/DL# in systems that don't need them; tokenize where possible
• ✅ Encryption at rest: Encrypt PII fields in the database (not just disk-level encryption)
• ✅ SIM swap fraud detection: Behavioral analytics on SIM change requests (flag anomalous patterns)
• ✅ Multi-factor SIM swap verification: Require in-person ID + biometric for SIM changes (some carriers now implement this)
• ✅ Breach notification and credit freeze: Prompt notification enables victims to freeze credit and add carrier PINs
• ⚠️ Port-out PIN: Separate PIN for number porting (helps but not foolproof if PIN was also breached)
• ⚠️ Dark web monitoring: Detect when carrier data appears on markets (reactive, not preventive)

References

• AccountableHQ: T-Mobile's Massive Data Breach Explained
• FCC Enforcement Actions on Carrier Data Security
• T-Mobile SEC Filing (August 2021): Data breach disclosure
• 3GPP TS 23.003: Numbering, addressing, and identification (IMSI/MSISDN relationship)

7. Targeted SIM Swapping for Cryptocurrency and Enterprise Accounts (S, I, E)

Executive Summary

Criminal gangs have repeatedly targeted high-value individuals — cryptocurrency holders, tech executives, and enterprise administrators — by social-engineering or bribing carrier employees to reassign the victim's phone number to an attacker-controlled SIM. With control of the number, attackers intercept SMS-based MFA to drain crypto wallets (single thefts exceeding $20M) or hijack enterprise SSO admin accounts for broader corporate compromise.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "Mobile Carrier"
        Call_Center[📞 Customer Service
/ Retail Store]
        Provisioning[⚙️ Provisioning System
SIM Management]
        HLR[(🔐 HLR/HSS)]
        SMSC[📨 SMSC]
    end

    subgraph "Attacker"
        Social_Eng[🔴 Social Engineer
Calls carrier with
OSINT on victim]
        Bribed_Rep[🔴 Bribed Insider
Carrier employee
paid $500-$5000]
        Attacker_SIM[🔴 Attacker SIM
New SIM card
with victim's number]
    end

    subgraph "Victim's Digital Life"
        Victim_Phone[📱 Victim Phone
Goes dead after swap]
        Crypto_Exchange[₿ Crypto Exchange
Coinbase / Binance]
        Enterprise_SSO[☁️ Enterprise SSO
Okta / Azure AD]
        Email[📧 Email
Gmail / O365]
    end

    Social_Eng -.->|"1. ❌ Impersonates victim
or bribes rep"| Call_Center
    Bribed_Rep -.->|"1b. ❌ Direct access
to provisioning"| Provisioning
    Call_Center -->|"2. Authorize
SIM change"| Provisioning
    Provisioning -->|"3. Update IMSI
for MSISDN"| HLR

    Victim_Phone -.->|"4. ❌ Deregistered"| HLR

    Attacker_SIM -.->|"5. Now receives
all SMS/calls"| SMSC

    Attacker_SIM -.->|"6. ❌ Password reset
+ intercept SMS OTP"| Crypto_Exchange
    Attacker_SIM -.->|"7. ❌ Hijack admin SSO
via SMS MFA"| Enterprise_SSO
    Attacker_SIM -.->|"8. ❌ Take over email
for persistence"| Email

    style Social_Eng fill:#ff6666,color:#fff
    style Bribed_Rep fill:#ff6666,color:#fff
    style Attacker_SIM fill:#ff6666,color:#fff
    style Call_Center fill:#ffaa66
    style Provisioning fill:#ffaa66
    style Victim_Phone fill:#ffee66
    style Crypto_Exchange fill:#ffee66
    style Enterprise_SSO fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Attacker as 🔴 Attacker
    participant OSINT as 🌐 OSINT / Social Media
    participant Carrier as 📞 Carrier (Rep/Insider)
    participant HLR as 🔐 HLR/HSS
    participant Victim as 📱 Victim Phone
    participant Exchange as ₿ Crypto Exchange

    Note over Attacker: Phase 1: Reconnaissance
    Attacker->>OSINT: Research target on social media,
conference talks, blockchain explorers
    OSINT->>Attacker: Name, phone number, carrier,
crypto holdings (on-chain), email

    Note over Attacker: Phase 2: SIM Swap
    alt Social Engineering Path
        Attacker->>Carrier: Call: "I'm [victim], lost my phone,
need emergency SIM activation"
        Carrier->>Attacker: Verify: Name, DOB, last 4 SSN?
        Attacker->>Carrier: Provides info (from OSINT / breach data)
        Carrier->>HLR: Activate new SIM for victim's MSISDN
    else Insider Bribe Path
        Attacker->>Carrier: Pay $500-$5000 to insider
via Telegram / crypto
        Carrier->>HLR: Insider directly swaps SIM
    end

    HLR->>Victim: ❌ Old SIM deregistered (no signal)

    Note over Attacker: Phase 3: Account Takeover (~2 min window)
    Attacker->>Exchange: "Forgot password" for victim's account
    Exchange->>HLR: Send SMS verification code
    HLR->>Attacker: SMS OTP delivered to new SIM

    Attacker->>Exchange: Enter OTP → password reset
    Attacker->>Exchange: Login → initiate withdrawal
    Attacker->>Exchange: Transfer $5M+ in crypto
to tumbler/mixer wallet

    Note over Victim: Notices phone dead → calls carrier
→ 30-60 min to restore number
→ funds already gone

Technical Deep Dive

Why crypto is the primary target: Cryptocurrency transactions are irreversible. Unlike bank wires (which can be recalled within 24–72 hours), crypto sent to a new wallet cannot be clawed back. Combined with SMS-based 2FA at most exchanges (until recently), this created a perfect attack monetization path.

The insider problem: Multiple federal prosecutions revealed that carrier employees across T-Mobile, AT&T, and Verizon were actively recruited via Telegram and Discord channels. Payments ranged from $500 for a single swap to $5,000+ for VIP accounts. In one case, a single T-Mobile employee performed over 50 unauthorized SIM swaps before detection.

Attack timeline (from swap to cash-out):

Detection Indicators

• Rapid SIM change → password reset correlation: SIM swap followed within minutes by account activity from new device
• Carrier-side: Multiple SIM changes requested by the same agent, or SIM changes at unusual hours
• Exchange-side: Login from new device + IP geolocation mismatch immediately after SIM swap
• Victim notification: Phone loses signal unexpectedly (not due to billing or outage)
• Blockchain analysis: Large transfers to fresh wallets immediately after account access pattern change

STRIDE Assessment

Mitigation

• ✅ Hardware security keys (FIDO2/WebAuthn) for all high-value accounts — not bypassable via SIM swap
• ✅ Carrier SIM lock / port freeze — T-Mobile "Account Takeover Protection", AT&T "Extra Security"
• ✅ Remove phone-based recovery from crypto exchanges, email, and enterprise SSO
• ✅ Carrier insider monitoring — behavioral analytics on provisioning system access; alert on anomalous SIM changes
• ✅ Crypto exchange withdrawal delays — 24-48 hour hold on large withdrawals after password/MFA change
• ⚠️ Carrier identity verification improvements — biometric verification for SIM changes (inconsistently deployed)
• ⚠️ Number-independent identity — use authenticator apps (TOTP) instead of SMS for all 2FA

References

• AccountableHQ: T-Mobile Data Breach — Real-World Scenarios
• DOJ: United States v. "The Community" (SIM swap gang prosecution)
• DOJ: United States v. Joel Ortiz (first SIM swap conviction, 10-year sentence)
• FBI IC3: Public Service Announcement on SIM Swapping (2022)

8. Insider-Enabled SIM Fraud and IMSI Re-Provisioning (S, T, I, E)

Executive Summary

Law enforcement and industry investigations have revealed systematic insider-enabled fraud at mobile carriers where employees — recruited and paid by criminal gangs — used their access to internal provisioning tools to clone or reassign IMSIs, enabling call/SMS interception and identity takeover at scale. Unlike social-engineering-based SIM swaps (Attack #7), these attacks bypass all customer verification because the insider has direct system access.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "Carrier Operations Center"
        OAM[🖥️ OAM Portal
Operations Admin &
Maintenance]
        Provisioning_DB[(⚙️ Provisioning DB
IMSI ↔ MSISDN
↔ SIM ICCID mapping)]
        HLR[(🔐 HLR/HSS
Active subscriber
records)]
    end

    subgraph "Network Infrastructure"
        MSC[🎛️ MSC/MME]
        SMSC[📨 SMSC]
        BTS[📡 BTS/eNB]
    end

    subgraph "Insider Threat"
        Insider[🔴 Bribed Employee
Has OAM credentials
and physical access]
        Crime_Gang[🔴 Criminal Gang
Pays insider per swap
$500-$5000]
    end

    subgraph "Attack Result"
        Cloned_SIM[🔴 Cloned/New SIM
Receives victim's
calls + SMS]
        Victim_SIM[📱 Victim SIM
May or may not
lose service]
    end

    Crime_Gang -.->|"1. Request target
MSISDN swap
(encrypted msg)"| Insider
    Insider -.->|"2. ❌ Login to OAM
with legitimate
credentials"| OAM
    OAM -.->|"3. ❌ Modify IMSI
binding in
provisioning DB"| Provisioning_DB
    Provisioning_DB -.->|"4. ❌ Push update
to HLR/HSS"| HLR

    HLR --> MSC
    HLR --> SMSC

    Cloned_SIM -.->|"5. Registers on
network with
new IMSI"| BTS
    SMSC -.->|"6. SMS routes to
cloned SIM"| Cloned_SIM

    style Insider fill:#ff6666,color:#fff
    style Crime_Gang fill:#ff6666,color:#fff
    style Cloned_SIM fill:#ff6666,color:#fff
    style OAM fill:#ffaa66
    style Provisioning_DB fill:#ffaa66
    style Victim_SIM fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Gang as 🔴 Criminal Gang
    participant Insider as 🔴 Carrier Insider
    participant OAM as 🖥️ OAM System
    participant Prov as ⚙️ Provisioning DB
    participant HLR as 🔐 HLR/HSS
    participant Network as 📡 Network
    participant Clone as 🔴 Cloned SIM
    participant Victim as 📱 Victim

    Gang->>Insider: Request via Telegram:
"Swap +1-555-0123, ICCID: [new SIM]"
Payment: $2000 BTC

    Insider->>OAM: Login with legitimate credentials
    Note over OAM: No anomaly — valid login from
authorized workstation during shift

    Insider->>OAM: Look up MSISDN +1-555-0123
    OAM->>Prov: Query: MSISDN → IMSI mapping
    Prov->>OAM: Current: IMSI=310260XXXXXXXXX
ICCID=8901260XXXXXXXXXXXX

    alt Method A: Full SIM Swap
        Insider->>OAM: Change SIM:
New ICCID → New IMSI for same MSISDN
        OAM->>Prov: Update binding
        Prov->>HLR: Cancel old IMSI, register new IMSI
        HLR->>Victim: ❌ Deregistered (phone goes dead)
        HLR->>Network: New IMSI for MSISDN registered
        Clone->>Network: Attach with new SIM
        Network->>Clone: ✅ Connected as +1-555-0123
    else Method B: Parallel SIM (Stealth)
        Insider->>OAM: Add secondary IMSI for same MSISDN
(multi-SIM / twin-SIM feature)
        OAM->>Prov: Add parallel IMSI
        Prov->>HLR: Both IMSIs active for MSISDN
        Note over Victim,Clone: Both victim AND attacker
receive calls/SMS simultaneously
Victim may not notice anything
    end

    Gang->>Clone: Use for SMS interception,
account takeover, surveillance

Technical Deep Dive

Method A vs. Method B — The critical distinction:

Parallel SIM (Method B) is particularly dangerous because:

• Many carriers support multi-SIM features (for tablets, smartwatches) that allow the same MSISDN to be served by multiple IMSIs
• The insider enables this for the victim's number and assigns the second SIM to the attacker
• The victim's phone continues to work normally — they receive no indication of compromise
• Both SIMs receive incoming SMS (or the insider configures SMS to the attacker's SIM only)

OAM tool access: Carrier OAM portals (e.g., Amdocs CRM, Ericsson ENM, Nokia NetAct) typically provide full CRUD (create, read, update, delete) access to subscriber provisioning. Access controls often rely on role-based permissions that are overly broad — a customer service agent may have the same provisioning access as a fraud team member.

Detection Indicators

• OAM audit trail analysis: SIM changes performed outside of customer-initiated support tickets
• No corresponding CRM ticket: Provisioning change without matching customer call, chat, or store visit
• Off-hours provisioning changes: SIM modifications during nights/weekends from agents not scheduled to work
• Pattern analysis: Same agent performing SIM changes for unrelated, geographically dispersed subscribers
• Twin-SIM activation without customer request: Multi-SIM feature enabled for accounts that didn't request it
• HLR anomalies: Same MSISDN active from two different cells/locations simultaneously

STRIDE Assessment

Mitigation

• ✅ Maker-checker (dual authorization) for all SIM provisioning changes — no single employee can complete a swap alone
• ✅ OAM access logging with SIEM correlation — flag SIM changes without corresponding CRM tickets
• ✅ Background checks and insider threat programs for employees with provisioning access
• ✅ Behavioral analytics on OAM usage — detect anomalous patterns (volume, timing, target distribution)
• ✅ Automated customer notification — send push notification and email (not SMS) whenever SIM binding changes
• ✅ Principle of least privilege — separate read-only access from provisioning write access; require escalation for SIM changes
• ⚠️ Employee financial monitoring — detect employees receiving unusual payments (privacy-sensitive, jurisdictional)
• ⚠️ SIM change cooling period — delay activation by 24 hours with customer notification (impacts legitimate use cases)

References

• P1 Security: SMS-Based Attacks — The Hidden Threat Still Exploiting Mobile Networks
• DOJ: Multiple prosecutions of carrier employees for unauthorized SIM swaps (2020–2023)
• 3GPP TS 23.003: IMSI/MSISDN provisioning and numbering
• GSMA: Recommendations on SIM Swap Fraud Prevention

9. Large-Scale Subscriber Metadata Abuse After Carrier Breaches (I)

Executive Summary

When carrier breaches expose call detail records (CDRs), account metadata, and social graph information, the downstream impact extends far beyond the initial data theft. Threat actors use this metadata to map social networks of high-value targets, identify VIPs by calling patterns, and fuel precision-targeted phishing, extortion, and physical surveillance campaigns. The metadata — who called whom, when, for how long, and from where — is often more valuable for intelligence than the content of communications.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "Carrier Data Systems"
        CDR_DB[(📊 CDR Database
Who called whom, when,
duration, cell-site)]
        Billing[(💰 Billing System
Plans, payment methods,
usage patterns)]
        CRM[(🖥️ CRM
Names, addresses,
account details)]
        Location[(📍 Location Records
Cell-site history,
approximate GPS)]
    end

    subgraph "Data After Breach"
        Breach_Data[🔴 Exfiltrated Dataset
CDRs + Billing +
CRM + Location]
    end

    subgraph "Intelligence Analysis (Attacker)"
        Social_Graph[🔴 Social Graph
Analysis
Who talks to whom]
        VIP_ID[🔴 VIP Identification
High-call-volume nodes,
premium plan holders]
        Location_Pattern[🔴 Location Patterns
Home, work, travel,
meeting locations]
        Targeting[🔴 Targeting Package
Combined profile for
phishing / extortion]
    end

    subgraph "Downstream Attacks"
        Phishing[📧 Spear-Phishing
Personalized lures]
        Extortion[💀 Extortion
Sensitive relationship
exposure threats]
        Physical[📍 Physical
Surveillance
Known patterns]
    end

    CDR_DB --> Breach_Data
    Billing --> Breach_Data
    CRM --> Breach_Data
    Location --> Breach_Data

    Breach_Data --> Social_Graph
    Breach_Data --> VIP_ID
    Breach_Data --> Location_Pattern

    Social_Graph --> Targeting
    VIP_ID --> Targeting
    Location_Pattern --> Targeting

    Targeting -.->|"❌"| Phishing
    Targeting -.->|"❌"| Extortion
    Targeting -.->|"❌"| Physical

    style Breach_Data fill:#ff6666,color:#fff
    style Social_Graph fill:#ff6666,color:#fff
    style VIP_ID fill:#ff6666,color:#fff
    style Location_Pattern fill:#ff6666,color:#fff
    style Targeting fill:#ff6666,color:#fff
    style CDR_DB fill:#ffaa66
    style Billing fill:#ffaa66
    style CRM fill:#ffaa66
    style Location fill:#ffaa66
    style Phishing fill:#ffee66
    style Extortion fill:#ffee66
    style Physical fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Attacker as 🔴 Threat Actor
    participant Data as 📊 Breach Data
    participant Analysis as 🔴 Analysis Tools
    participant Target as 📱 Target (VIP)
    participant Contact as 📱 Target's Contact
    participant Service as 🏦 Target's Bank

    Note over Attacker: Phase 1: Data Acquisition
    Attacker->>Data: Acquire carrier breach dataset
(dark web purchase or direct breach)

    Note over Attacker: Phase 2: Social Graph Analysis
    Attacker->>Analysis: Process CDRs through
graph analysis tools (Maltego, i2)
    Analysis->>Attacker: Identify hub nodes:
Target makes 50+ calls/day to
unique numbers (likely executive)
    Analysis->>Attacker: Map inner circle:
5 numbers called daily =
family + assistant + lawyer

    Note over Attacker: Phase 3: Pattern Extraction
    Attacker->>Analysis: Correlate cell-site data
    Analysis->>Attacker: Target's pattern:
Home: Cell 4521 (7PM-7AM)
Office: Cell 8903 (8AM-6PM)
Gym: Cell 2201 (6AM Tu/Th)

    Note over Attacker: Phase 4: Targeted Attack
    alt Spear-Phishing
        Attacker->>Target: Email spoofing target's lawyer:
"Per our call Tuesday at 2PM,
please review attached contract"
        Note over Target: Highly convincing because
attacker knows exact call history
    else Extortion
        Attacker->>Target: "We know you call [number]
30 times/week. Does your spouse
know? Pay 5 BTC."
    else Physical Targeting
        Attacker->>Target: Attacker knows target's
gym schedule (Tu/Th 6AM)
and which cell tower = location
    end

Technical Deep Dive

What CDR metadata reveals:

Why metadata is more dangerous than content: Former NSA director Michael Hayden famously stated: "We kill people based on metadata." Metadata at scale reveals patterns that individual call content cannot: organizational structures, relationship dynamics, travel patterns, and behavioral routines.

Detection Indicators

• Dark web appearance of CDR datasets with carrier-specific formatting
• Spear-phishing campaigns with implausible specificity — attacker references exact call times, contact names
• Extortion attempts referencing private communication patterns that could only come from CDR analysis
• Physical surveillance correlated with cell-site patterns from breach data
• Bulk queries against carrier databases — anomalous read patterns on CDR storage systems

STRIDE Assessment

Mitigation

• ✅ CDR encryption at rest and in transit — encrypt CDR databases, not just disk-level
• ✅ CDR access control — strict RBAC; separate CDR access from general CRM access
• ✅ CDR retention minimization — delete CDRs beyond regulatory retention period (varies by jurisdiction; often 6-24 months)
• ✅ Anomaly detection on CDR queries — alert on bulk CDR retrieval or unusual access patterns
• ✅ Data loss prevention (DLP) — monitor for CDR-formatted data leaving the network
• ⚠️ CDR anonymization for analytics — use tokenized identifiers for business intelligence (reduces value if breached)
• ⚠️ User notification — inform subscribers if their CDRs may have been exposed in a breach

References

• AccountableHQ: T-Mobile Data Breach — Real-World Scenarios
• Edward Snowden disclosures: NSA CDR collection programs (illustrating metadata intelligence value)
• 3GPP TS 32.297/32.298: CDR format and charging data records
• FCC: Rules on Carrier Data Retention and Privacy

10. Mass Credential Phishing (Smishing) With Carrier Data (S, I)

Executive Summary

When carrier breaches expose subscriber datasets containing names, phone numbers, plan types, and partial SSNs, criminal organizations use this information to craft extremely convincing SMS phishing (smishing) campaigns. Unlike generic spam, these messages reference the victim's actual carrier, plan details, and partial personal information — dramatically increasing click-through rates. The campaigns harvest banking credentials, one-time codes, and SaaS login tokens at massive scale.

Real-World Incident

Network Position — Where the Attack Starts

graph TB
    subgraph "Carrier Breach Data"
        Leak[(🔴 Leaked Dataset
Name, Phone, Carrier,
Plan, Last-4 SSN)]
    end

    subgraph "Smishing Infrastructure"
        Smishing_Platform[🔴 Smishing Platform
Bulk SMS sender
+ personalization engine]
        Phish_Site[🔴 Phishing Site
Fake bank / carrier /
SaaS login page]
        C2[🔴 C2 / Credential
Collection Server]
    end

    subgraph "SMS Delivery (Abused)"
        A2P[📨 A2P SMS Gateway
Bulk SMS provider
(legitimate, abused)]
        SMSC[📨 Carrier SMSC
Delivers to subscriber]
    end

    subgraph "Victim"
        Victim_Phone[📱 Victim Phone
Receives personalized
smishing message]
    end

    subgraph "Victim's Accounts"
        Bank[🏦 Bank]
        SaaS[☁️ SaaS / Cloud]
    end

    Leak -->|"1. Feed subscriber
data"| Smishing_Platform
    Smishing_Platform -->|"2. Generate
personalized SMS"| A2P
    A2P -->|"3. SMS delivered"| SMSC
    SMSC -->|"4. SMS to victim"| Victim_Phone

    Victim_Phone -.->|"5. ❌ Clicks link"| Phish_Site
    Phish_Site -.->|"6. ❌ Enters
credentials"| C2

    C2 -.->|"7. ❌ Use stolen
credentials"| Bank
    C2 -.->|"7. ❌ Use stolen
credentials"| SaaS

    style Leak fill:#ff6666,color:#fff
    style Smishing_Platform fill:#ff6666,color:#fff
    style Phish_Site fill:#ff6666,color:#fff
    style C2 fill:#ff6666,color:#fff
    style A2P fill:#ffaa66
    style SMSC fill:#ffaa66
    style Victim_Phone fill:#ffee66
    style Bank fill:#ffee66

Attack Sequence — Step by Step

sequenceDiagram
    participant Gang as 🔴 Fraud Ring
    participant Platform as 🔴 Smishing Platform
    participant Gateway as 📨 A2P SMS Gateway
    participant SMSC as 📨 Carrier SMSC
    participant Victim as 📱 Victim
    participant PhishSite as 🔴 Phishing Site
    participant Bank as 🏦 Bank

    Note over Gang: Phase 1: Campaign Setup
    Gang->>Platform: Upload breach dataset (1M records)
Configure message template:
"Hi {name}, your {carrier} bill
shows unusual charge of $247.83.
Verify at: {phish_link}"

    Note over Gang: Phase 2: Personalized Message Generation
    Platform->>Platform: For each record, generate:
"Hi John, your T-Mobile bill
shows unusual charge of $247.83.
Verify SSN ending 4523 at:
t-mobi1e-verify[.]com/bill"

    Note over Gang: Phase 3: Bulk Delivery
    Platform->>Gateway: Send 50,000 SMS/hour
(via compromised or complicit
A2P SMS provider)
    Gateway->>SMSC: Deliver via SS7/SMPP
    SMSC->>Victim: SMS arrives from
short code or spoofed number

    Note over Victim: Phase 4: Victim Interaction
    Victim->>PhishSite: Clicks link → sees convincing
carrier-branded login page
    Victim->>PhishSite: Enters carrier username + password
    PhishSite->>Gang: Credentials captured

    Note over Gang: Phase 5: Real-Time Relay (for 2FA bypass)
    Gang->>Bank: Login with captured credentials
    Bank->>SMSC: Send OTP to victim
    SMSC->>Victim: SMS OTP arrives
    PhishSite->>Victim: "Enter the verification code
we just sent to confirm identity"
    Victim->>PhishSite: Enters OTP
    PhishSite->>Gang: OTP relayed in real-time
    Gang->>Bank: Enter OTP → access granted

Technical Deep Dive

Why carrier data makes smishing so effective:

The real-time phishing relay: Modern smishing kits (e.g., based on Evilginx2 or custom platforms) act as transparent proxies between the victim and the real service. When the victim enters credentials + OTP on the phishing page, the attacker's server relays them to the real bank/SaaS login in real-time, capturing the authenticated session cookie. This defeats traditional SMS-based 2FA entirely.

A2P SMS delivery abuse: Attackers use multiple channels to send bulk smishing:

• Compromised A2P providers: Hack or social-engineer access to legitimate SMS API providers
• SIM farms: Send directly from prepaid SIMs via GSM modems
• SS7 SMPP injection: Inject messages directly into SMSC via compromised signaling access
• Spoofed sender IDs: Set the "from" field to match the carrier's legitimate short code or brand name

Detection Indicators

• Sudden spike in clicks on carrier-branded domains from specific subscriber cohorts (matching breach dataset demographics)
• A2P gateway abuse: High-volume SMS from unfamiliar source addresses to a carrier's subscribers
• URL patterns: Typosquatting carrier brand names (t-mobi1e, att-secure, verizon-alert)
• Customer complaint clusters: Multiple subscribers reporting identical suspicious SMS messages
• Credential stuffing waves: Surge in login attempts at banks/SaaS correlated with smishing campaign timing

STRIDE Assessment

Mitigation

• ✅ Sender ID verification — carriers implement A2P sender ID registries (10DLC in US, brand registration)
• ✅ SMS content filtering — carrier-level URL analysis to detect known phishing domains in transit
• ✅ RCS Business Messaging — verified sender identity with blue checkmark (harder to spoof than SMS)
• ✅ FIDO2/WebAuthn — phishing-resistant authentication that cannot be relayed through proxy
• ✅ Customer awareness campaigns — carriers proactively warn subscribers after breaches
• ⚠️ URL shortener policies — block or flag shortened URLs in SMS (impacts legitimate use)
• ⚠️ AI-based smishing detection on device — mobile OS SMS spam filters (Google Messages, Apple iMessage)

References

• P1 Security: SMS-Based Attacks — The Hidden Threat Still Exploiting Mobile Networks
• AccountableHQ: T-Mobile Data Breach — Real-World Scenarios
• FCC: STIR/SHAKEN and A2P 10DLC Registration Requirements
• GSMA: A2P SMS Guidelines and Anti-Fraud Recommendations

Identity Attack Summary

Attack Comparison Matrix

Combined STRIDE Profile

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

Standards Mapping

Lab Replicability

🔬 Lab Exercises

Exercise 1: Examine HSS Subscriber Data in MongoDB

# Connect to the MongoDB instance backing the HSS
docker exec -it open5gs_mongo mongosh open5gs

# List all subscribers (equivalent to carrier CRM data)
db.subscribers.find().pretty()

# Observe what's stored: IMSI, K, OPc, APN, QoS
# Question: If an attacker compromised this database, what could they do?
# Answer: Clone SIM cards (K+OPc), map all subscribers, modify profiles

Exercise 2: Simulate a SIM Swap in the Lab

# Record the current IMSI for a subscriber
db.subscribers.findOne({imsi: "999700000000001"})

# "SIM swap" — change the IMSI to a new value (simulating new SIM)
db.subscribers.updateOne(
  {imsi: "999700000000001"},
  {$set: {imsi: "999700000000099"}}
)

# Observe: The original UERANSIM UE will fail to attach
# A new UE configured with IMSI 999700000000099 will attach successfully
# This demonstrates the HLR/HSS identity binding mechanism

Exercise 3: Extract Metadata from Signaling Captures

# Capture Diameter S6a signaling
docker exec -it open5gs_mme tcpdump -i any -w /tmp/metadata.pcap tcp port 3868 &

# Register multiple UEs and generate traffic
# Then analyze the capture:
# In Wireshark, filter: diameter
# Extract: IMSI, visited PLMN, UE location info, timestamps
# Question: What social graph could you build from this signaling metadata?

3GPP and Industry References

Summary

• ✅ Carrier data breaches are not just privacy incidents — they are enabling attacks for SIM swap waves, precision phishing, and surveillance
• ✅ SIM swapping remains the most impactful downstream attack because phone numbers anchor identity across the digital ecosystem
• ✅ Insider threats are the hardest to detect because they use legitimate credentials and bypass all external security controls
• ✅ CDR/metadata abuse is often more valuable for intelligence than content interception
• ✅ Defense priority: Eliminate SMS as an identity/authentication mechanism wherever possible; deploy FIDO2/WebAuthn

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