Your phone number is not just a way to reach you. For millions of accounts across banking, cryptocurrency exchanges, email services, and enterprise applications, your phone number is a security boundary. It is the thing that stands between an attacker with your password and full access to your accounts. SIM swap attacks eliminate that boundary entirely — not through hacking the carrier’s network infrastructure, but by calling customer service and lying.

The simplicity of SIM swapping is what makes it so effective and so difficult to eliminate. Carrier customer service representatives are trained to be helpful. Attackers are trained to exploit helpfulness. The resulting fraud has cost individuals and organizations hundreds of millions of dollars and has compromised some of the most high-profile accounts in the world.

How SIM Swapping Works

A mobile phone number’s “ownership” is maintained by the carrier. The SIM card in your phone is associated with your account. If you call your carrier and request a SIM swap — because you got a new phone, lost your old SIM, or had a device stolen — the carrier associates your number with the new SIM. Any SMS or calls to your number now go to whoever has that new SIM.

The attack exploits this legitimate business process.

Step-by-Step Attack Flow

Step 1: Target selection and OSINT reconnaissance

Attackers identify high-value targets through:

  • Cryptocurrency forum posts or social media showing wealth
  • LinkedIn profiles revealing executives with access to valuable accounts
  • Data breach dumps containing email/phone associations
  • Dark web markets selling dossiers on specific individuals

OSINT gathering commands used in recon (illustrative of what an analyst would run):

 1# Passive OSINT — enumerate phone number associations
 2# Using theHarvester to find email/phone combos from public sources
 3python3 theHarvester.py -d targetcompany.com -b google,linkedin,bing -l 200
 4
 5# Reverse phone lookup services (legal, public data)
 6# Example: using a WHOIS-equivalent for phone numbers
 7curl "https://api.numverify.com/validate?access_key=YOUR_KEY&number=15551234567&country_code=US"
 8
 9# Check if number appears in HaveIBeenPwned breach data
10curl "https://haveibeenpwned.com/api/v3/pasteaccount/target@email.com" \
11  -H "hibp-api-key: YOUR_KEY"

Key PII elements attackers collect before calling:

  • Full legal name
  • Date of birth
  • Home address (current and previous)
  • Last four digits of Social Security Number
  • Carrier account PIN (if previously leaked in breaches)
  • Account security question answers (found in breach dumps or social media)
  • Recent account activity details (billing amount, last payment date — sometimes visible in breach data)

Step 2: Social engineering the carrier

The attacker calls the carrier’s customer service number (or uses online chat). Common pretexts:

  • “I dropped my phone in water. I have a new SIM and need to transfer my number.”
  • “I’m traveling internationally and bought a new SIM. I need to activate it on my account.”
  • “My phone was stolen. I have a replacement device and SIM.”

If the carrier asks for account verification:

  • Attacker provides the PII gathered in Step 1
  • If the carrier requires an account PIN the attacker does not have, they attempt social engineering: “I set up the account for my wife and she doesn’t remember the PIN — can I verify with the last four of my SSN instead?”

In documented cases, attackers have succeeded even when carriers required multiple identity factors, by escalating to supervisors, trying different call center agents (vishing multiple times), or using bribed insiders.

Step 3: SIM swap executes

The carrier rep — convinced the caller is the legitimate account holder — initiates the SIM swap. Within minutes, the attacker’s SIM card begins receiving the victim’s SMS messages and calls. The victim’s phone typically shows “No Service” or “SOS Only.”

Step 4: Account takeover cascade

With control of the phone number, the attacker triggers password resets on all accounts tied to that number. SMS-based MFA codes go to the attacker.

Typical account takeover sequence:

  1. Password reset for primary email (Gmail, Outlook)
  2. Access to email inbox to capture password reset links for all other services
  3. Access to cryptocurrency exchanges (Coinbase, Kraken, Binance)
  4. Access to banking if SMS-based 2FA is enabled
  5. Access to social media accounts for potential ransom or reputational damage
 1# Illustrative example: Detection script using Twilio Verify to identify
 2# SMS MFA events from new devices — for SOC monitoring use
 3from twilio.rest import Client
 4import datetime
 5
 6account_sid = "YOUR_TWILIO_ACCOUNT_SID"
 7auth_token = "YOUR_TWILIO_AUTH_TOKEN"
 8client = Client(account_sid, auth_token)
 9
10# Fetch recent verification check events
11checks = client.verify.v2.services("YOUR_SERVICE_SID").verification_checks.list(
12    limit=100
13)
14
15# Look for successful verifications from a phone number that recently had SIM activity
16MONITORED_NUMBER = "+15551234567"
17LOOKBACK_HOURS = 2
18threshold_time = datetime.datetime.now(datetime.timezone.utc) - datetime.timedelta(hours=LOOKBACK_HOURS)
19
20for check in checks:
21    if check.to == MONITORED_NUMBER and check.status == "approved":
22        if check.date_created > threshold_time:
23            print(f"[ALERT] SMS verification approved for {MONITORED_NUMBER}")
24            print(f"  Time: {check.date_created}")
25            print(f"  Channel: {check.channel}")
26            # Cross-reference with carrier SIM change events if available

Real Incidents

Jack Dorsey — August 2019

Twitter and Square CEO Jack Dorsey’s verified Twitter account was compromised in August 2019 by a group called the Chuckling Squad. The attackers SIM swapped Dorsey’s phone number, then used Twitter’s Cloudhopper feature — which allowed SMS-to-tweet functionality — to post offensive and racist content from his verified account with 4.2 million followers.

The attack was notable because Dorsey’s security posture was presumably well above average. The vulnerability was not in his personal operational security but in the carrier’s verification process. Twitter subsequently deprecated the Cloudhopper SMS posting feature.

$100 Million+ Cryptocurrency SIM Swap Ring (2018–2021)

Federal prosecutors indicted eight individuals in 2021 in connection with a SIM swap conspiracy that targeted over 100 high-value cryptocurrency holders across the US. The ring targeted individuals known to hold large cryptocurrency positions — including early Bitcoin adopters, blockchain executives, and crypto influencers.

The group used a combination of direct carrier social engineering and insider corruption — paying carrier store employees $300–$500 per swap. Total losses exceeded $100 million. The case highlighted the insider threat dimension of carrier-level security.

FTX Collapse — November 2022

On November 11, 2022, the same night FTX filed for Chapter 11 bankruptcy, approximately $400 million in cryptocurrency was drained from FTX wallets in what the company initially characterized as an “unauthorized transaction.” Subsequent DOJ investigations and indictments in 2024 linked the theft to a SIM swap targeting a former FTX executive’s phone number, which was used to authorize internal fund transfers.

Three individuals — Robert Powell, Carter Rohn, and Emily Hernandez — were charged with wire fraud conspiracy related to a broader SIM swap ring. The FTX hack illustrated that SIM swap attacks scale to catastrophic losses when the target has access to treasury functions.

T-Mobile Insider Threat (Multiple Incidents, 2020–2023)

Multiple T-Mobile employees were convicted between 2020 and 2023 for accepting bribes from SIM swap attack operators. In one case, a T-Mobile store manager received over $25,000 in Bitcoin to perform SIM swaps on demand. T-Mobile has faced regulatory scrutiny and multiple class action lawsuits over its SIM swap susceptibility.

Detection

Authentication Log Signals

Detection of SIM swap attacks requires monitoring across both carrier and application layers. From the application side, the following signals indicate a potential SIM swap-enabled account takeover:

Pattern: New device after SMS MFA + credential change within short window

Timeline:
  T+0: Victim's phone loses service (SIM swap executes)
  T+5min: Password reset request submitted to account tied to phone number
  T+6min: SMS MFA code delivered to attacker's SIM
  T+7min: Password successfully reset from unknown IP
  T+8min: New MFA method (new phone number or authenticator app) registered
  T+10min: New device login from geographically distant IP

Alert triggers:

  • Password reset + MFA method change within 30 minutes
  • MFA method change + new device login within 60 minutes
  • Account login from new device at unusual hour after previous SMS MFA events

SIEM query — Account takeover signal chain (generic SPL):

index=auth_logs OR index=identity_events
| eval event_sequence = case(
    action="password_reset_initiated", 1,
    action="sms_mfa_success", 2,
    action="mfa_method_changed", 3,
    action="new_device_login", 4,
    true(), 0
)
| where event_sequence > 0
| bin _time span=30m
| stats
    list(action) as action_sequence,
    dc(device_id) as unique_devices,
    dc(ip_address) as unique_ips,
    values(ip_address) as ip_list
    by user_id, _time
| where mvcount(action_sequence) >= 3
| where unique_devices > 1 OR unique_ips > 1
| eval risk_score = (unique_devices * 25) + (unique_ips * 15)
| where risk_score >= 40
| table _time, user_id, action_sequence, unique_devices, unique_ips, ip_list, risk_score

Behavioral indicators specific to SIM swap:

  • Target phone number’s SMS delivery suddenly routes to a different MSISDN/IMSI (detectable if you have carrier-level telemetry or a carrier partnership)
  • SMS OTP delivery to a phone that is simultaneously flagged as “No Service” in carrier network
  • Account access from IP associated with VPN/proxy shortly after SMS MFA success
  • Multiple failed SMS deliveries immediately before a successful one (carrier swap propagation lag)

Defense and Mitigation

1. Carrier-Level Controls

AT&T: Enable “Extra Security” (account PIN required for all changes) and consider “NumberLock” which prevents SIM changes without in-store verification with government ID.

Verizon: Enable “Number Lock” in the My Verizon app under Account Security. Also set a unique account PIN.

T-Mobile: Enable “SIM Protection” in the T-Mobile app. This requires your PIN to be verified before any SIM change.

Account PIN best practices:

  • Use a unique PIN not used anywhere else
  • Avoid PINs derivable from your birthday, SSN, or address
  • Do not store the PIN in the same place as other credentials
 1# Illustrative: Checking if your carrier supports number lock via their public API
 2# (This is a representative example — actual implementation varies by carrier)
 3curl -X GET "https://api.carrier.example.com/account/security-features" \
 4  -H "Authorization: Bearer YOUR_CARRIER_API_TOKEN" \
 5  -H "Accept: application/json"
 6
 7# Expected response showing available features:
 8{
 9  "features": {
10    "number_lock": {"enabled": false, "available": true},
11    "sim_protection": {"enabled": true, "method": "pin"},
12    "port_out_protection": {"enabled": false, "available": true}
13  }
14}

2. Eliminate SMS-Based MFA Wherever Possible

SMS MFA is the weakest form of second factor. Replace it with:

  • TOTP apps (Google Authenticator, Microsoft Authenticator, Authy) — not SIM-dependent
  • FIDO2 hardware keys (YubiKey, Feitian) — the strongest option
  • Push notification MFA with number matching — resistant to basic SIM swap but not insider-compromise scenarios
  • Certificate-based authentication — enterprise preferred for high-privilege access

NIST SP 800-63B has deprecated SMS OTP as a valid second authentication factor for high-assurance authentication contexts. If you are designing a system, do not build SMS MFA. If you are inheriting one, plan the migration.

3. Account Recovery Hardening

SIM swap attacks often succeed not by breaking MFA directly, but by triggering account recovery flows that bypass MFA:

  • Disable SMS-based account recovery where possible
  • Use backup codes stored offline (password manager or physical secure location)
  • Enable recovery email on a separate, unique address not associated with your phone number
  • For high-value accounts, contact the service provider and request enhanced account protection (available at some financial institutions and crypto exchanges)

4. Reduce Your PII Attack Surface

Attackers cannot successfully social engineer a carrier without sufficient PII. Minimize publicly available personal information:

  • Remove personal phone numbers from professional profiles (LinkedIn, company websites)
  • Opt out of data broker sites (Spokeo, BeenVerified, Whitepages, LexisNexis)
  • Use privacy services (Privacy.com virtual cards, phone number masking services) to decouple your real number from public-facing accounts
  • Be cautious about posting home addresses, birth dates, and family information publicly

5. Monitor for SIM Swap Signals

Set up alerting for the following events on all accounts tied to your phone number:

  • Password reset requests (real-time email alert)
  • New device login notifications
  • MFA method registration events
  • Login from a new geographic region

For enterprise deployments, integrate with your SIEM to alert when authentication logs show the pattern described in the detection section above.

6. High-Risk User Protections (Enterprise)

For executives, finance personnel, and administrators who are high-value SIM swap targets:

  • Require hardware security keys (FIDO2) for all authentication — eliminate SMS entirely
  • Enroll in carrier premium account protection programs
  • Implement geofencing in identity provider Conditional Access policies
  • Consider private carrier arrangements (MVNOs with stronger security protocols) for C-suite

Summary

SIM swap attacks exploit the intersection of three weak links: publicly available PII, insufficiently verified carrier processes, and over-reliance on SMS as an authentication factor. Detection requires monitoring authentication logs for the specific post-swap account takeover pattern — credential reset + MFA method change + new device login in rapid succession. Remediation starts at the carrier with number lock features, but the fundamental fix is eliminating SMS-based authentication from any account that controls significant value.

MITRE ATT&CK: T1598 — Phishing for Information (recon phase), T1621 — MFA Request Generation (exploitation phase)

References