SC-037: SIM Swapping Attack → Account Takeover & Wire Fraud¶

Threat Actor Profile¶

MOBILE PHANTOM is a financially motivated cybercriminal group active since 2023, specializing in SIM swap attacks targeting high-net-worth individuals and corporate finance officers. The group operates a hybrid model: social engineering of mobile carrier support staff combined with insider recruitment at regional carrier retail stores. Their average payout per successful operation exceeds $350K, with some operations exceeding $2M in wire fraud proceeds.

The group maintains a database of pre-researched targets sourced from LinkedIn scraping, corporate SEC filings, and data broker purchases. They prioritize targets at financial institutions where SMS-based 2FA remains the primary second factor for high-privilege operations such as wire transfers and ACH batch approvals.

Motivation: Financial — wire fraud ($200K–$2M per incident), cryptocurrency theft, business account takeover.

Executive Summary¶

Sterling Financial Services, a mid-market investment management firm with $4.2B AUM, suffered a coordinated SIM swap attack against its CFO, David Mercer. MOBILE PHANTOM conducted extensive OSINT to gather personal information, then social-engineered a mobile carrier representative into porting Mercer's phone number to an attacker-controlled SIM. With control of the phone number, the attackers intercepted SMS-based 2FA codes, gained access to corporate banking portals, and initiated three wire transfers totaling $1.87M to mule accounts before detection.

The attack exploited Sterling's reliance on SMS-based MFA for its treasury management platform and the absence of out-of-band verification procedures for wire transfers exceeding internal thresholds.

Scenario Narrative¶

Phase 1 — Reconnaissance & Target Selection (~15 min)¶

MOBILE PHANTOM identifies David Mercer, CFO of Sterling Financial Services, through LinkedIn profiling and SEC EDGAR filings. The group purchases a comprehensive background report from a data broker, obtaining Mercer's personal phone number, home address, date of birth, and SSN (last 4 digits) from a previous data breach aggregation. They also identify Sterling's primary banking relationship (First National Commercial Bank) from public ACH originator records.

The group conducts passive reconnaissance on Sterling's corporate website, confirming Mercer's role includes wire transfer authority. A review of Sterling's job postings reveals they use "TreasuryDirect Pro" for cash management — a platform known to support SMS 2FA.

Evidence Artifacts:

Phase 2 — SIM Swap Execution (~20 min)¶

At 14:32 UTC on March 15, 2026, a MOBILE PHANTOM operative calls MobileFirst Wireless customer support, impersonating David Mercer. The caller provides Mercer's full name, date of birth, home address, and last 4 SSN digits — passing the carrier's standard identity verification. The operative claims their phone was damaged and requests an emergency SIM swap to a new device with ICCID 8901260012345678901.

The carrier representative processes the request. Within 90 seconds, Mercer's phone number (+1-555-0147) is active on the attacker's device. Mercer's legitimate phone loses cellular service — calls, texts, and data cease functioning. The attacker immediately receives a test SMS to confirm control of the number.

Evidence Artifacts:

Phase 3 — 2FA Bypass & Account Takeover (~25 min)¶

With control of Mercer's phone number, MOBILE PHANTOM initiates the account takeover sequence. At 14:41 UTC, the attacker navigates to treasury.sterlingfinancial.example.com and clicks "Forgot Password." The system sends a password reset link to Mercer's corporate email. Simultaneously, the attacker uses Mercer's phone number to trigger SMS-based password recovery on his personal email (d.mercer.personal@example.com), which is the recovery email for his corporate account.

By 14:47 UTC, the attacker has reset Mercer's personal email password, used it to access the corporate email password reset link, and established a new password on the TreasuryDirect Pro platform. Each step sends an SMS verification code to +1-555-0147 — now controlled by the attacker.

At 14:52 UTC, the attacker logs into TreasuryDirect Pro from 198.51.100.45 (residential proxy, US East) using the new credentials and the intercepted SMS 2FA code.

# Attacker's SMS interception log (reconstructed from carrier records)
14:41:12 UTC — SMS received: "Your Sterling password reset code: 847291"
14:43:55 UTC — SMS received: "Your verification code for example.com: 553018"
14:47:33 UTC — SMS received: "TreasuryDirect Pro login code: 219847"
14:52:01 UTC — SMS received: "TreasuryDirect Pro login code: 663104"

Evidence Artifacts:

Phase 4 — Wire Fraud Execution (~30 min)¶

Between 15:01 and 15:23 UTC, the attacker initiates three wire transfers from Sterling's operating account:

The attacker crafted wire references that mimic Sterling's naming conventions (obtained from email access in Phase 3). The three beneficiary entities are shell companies with freshly opened accounts. All transfers are under the $1M single-transaction approval threshold that would require dual authorization.

// TreasuryDirect Pro wire transfer API payload (reconstructed)
{
  "transaction_type": "domestic_wire",
  "originator": "Sterling Financial Services",
  "originator_account": "****7842",
  "beneficiary_name": "Apex Trading Solutions LLC",
  "beneficiary_account": "****3391",
  "routing_number": "021000021",
  "amount": 620000.00,
  "currency": "USD",
  "reference": "Q1 Vendor Settlement - INV-2026-0891",
  "initiated_by": "dmercer@sterlingfinancial.example.com",
  "ip_address": "198.51.100.45",
  "mfa_method": "sms",
  "mfa_verified": true
}

Evidence Artifacts:

Detection Opportunities¶

KQL Detection — SIM Swap Indicator (MDM Heartbeat Loss + Auth Anomaly)¶

// Detect potential SIM swap: MDM device goes offline followed by anomalous authentication
let MDMOffline = DeviceEvents
| where TimeGenerated > ago(4h)
| where ActionType == "DeviceHeartbeatLost"
| where DeviceOwner in ("executive_group")
| project DeviceOwner, OfflineTime = TimeGenerated, DeviceName;
let AnomalousAuth = SigninLogs
| where TimeGenerated > ago(4h)
| where ResultType == 0  // Successful login
| where AuthenticationMethodDetail == "SMS"
| where IPAddress !in (known_corporate_ips)
| project UserPrincipalName, AuthTime = TimeGenerated, IPAddress, Location;
MDMOffline
| join kind=inner AnomalousAuth on $left.DeviceOwner == $right.UserPrincipalName
| where AuthTime between (OfflineTime .. (OfflineTime + 2h))
| project UserPrincipalName, OfflineTime, AuthTime, IPAddress, Location

SPL Detection — Wire Transfer Velocity Anomaly¶

index=treasury sourcetype=wire_transfer
| transaction user maxspan=30m maxpause=15m
| where mvcount(beneficiary_name) >= 3
| where sum(amount) > 500000
| eval new_beneficiary_pct = round(mvcount(mvfilter(match(beneficiary_status, "new"))) / mvcount(beneficiary_name) * 100, 0)
| where new_beneficiary_pct >= 50
| table _time, user, mvcount(beneficiary_name) as wire_count, sum(amount) as total_amount, new_beneficiary_pct, src_ip
| sort -total_amount

KQL Detection — Password Reset Chain¶

// Detect daisy-chain password resets across multiple systems within short timeframe
AuditLogs
| where TimeGenerated > ago(1h)
| where OperationName == "Reset password (self-service)"
| summarize ResetCount = count(), Systems = make_set(TargetResources[0].displayName) by InitiatedBy.user.userPrincipalName, bin(TimeGenerated, 15m)
| where ResetCount >= 2
| project TimeGenerated, User = InitiatedBy_user_userPrincipalName, ResetCount, Systems

Response Playbook¶

Immediate Containment (0–30 min)¶

1. Contact banking institution — Initiate wire recall on all three transfers immediately; time is critical for recovery
2. Contact mobile carrier — Request immediate reversal of the SIM swap and lock the account with a port freeze
3. Disable compromised accounts — Suspend dmercer on TreasuryDirect Pro, corporate email, and all linked systems
4. Revoke all active sessions — Force logout across all platforms; revoke OAuth tokens and API keys
5. Freeze originating bank accounts — Prevent further unauthorized transactions
6. Notify Mercer via alternative channel — Confirm via in-person contact or verified landline

Eradication (30 min – 4 hours)¶

1. Audit all accounts using the compromised phone number — Identify every service using +1-555-0147 for 2FA
2. Reset credentials on all identified accounts using non-SMS methods
3. Review email access logs — Determine what emails the attacker read during the account takeover window
4. Analyze transaction monitoring gaps — Why were velocity alerts auto-suppressed?
5. Engage carrier fraud department — Obtain full SIM swap audit trail and call recordings

Recovery (4–48 hours)¶

1. Migrate all executive MFA to FIDO2/hardware keys — Eliminate SMS 2FA dependency for all wire-transfer-authorized personnel
2. Implement dual-authorization for all wire transfers above $50K with out-of-band verification (callback to registered landline)
3. Deploy carrier port-freeze on all executive phone numbers
4. Establish new beneficiary cooling-off period — 24-hour delay before funds can be sent to newly added beneficiaries
5. File SAR (Suspicious Activity Report) with FinCEN within 30 days

Key Discussion Questions¶

1. Sterling relied on SMS-based 2FA for its treasury management platform. Given that SIM swap attacks have been documented since 2018, what due diligence should have flagged this risk, and who bears responsibility — the platform vendor, the enterprise, or the carrier?
2. The attacker structured three transactions under the $1M dual-authorization threshold. How should you redesign approval workflows to detect structuring while avoiding excessive friction for legitimate transactions?
3. Mercer's phone was without service for nearly an hour before anyone investigated. How would you design a monitoring system that correlates MDM heartbeat loss with simultaneous authentication anomalies?
4. The AML system flagged the transactions but placed them in a next-business-day queue. What SLA should exist between automated transaction monitoring alerts and human review for accounts with wire transfer authority?
5. MOBILE PHANTOM obtained Mercer's PII from a data broker for $49. What enterprise controls exist to reduce executive PII exposure, and should this be part of your executive protection program?

Debrief Guide¶

What Went Well¶

• Transaction monitoring system did flag the velocity anomaly — the detection logic was sound
• Carrier logs preserved the full SIM swap audit trail, enabling forensic reconstruction
• Banking platform logged all session activity including IP addresses and user agents

Key Learning Points¶

• SMS 2FA is not MFA — SIM swap attacks reduce SMS to a single factor controlled by whoever controls the phone number; FIDO2 hardware keys eliminate this vector entirely
• Authentication chains are only as strong as the weakest link — A personal email recovery phone number became the entry point to corporate treasury systems
• Transaction structuring defeats single-threshold controls — Velocity-based rules that consider multiple transactions to new beneficiaries within a session are essential
• Carrier identity verification is enterprise-relevant risk — Executive phone accounts should have enhanced security (port freeze, PIN, callback verification)

Recommended Follow-Up¶

• [ ] Migrate all wire-transfer-authorized users to FIDO2/WebAuthn — eliminate SMS 2FA entirely for financial systems
• [ ] Implement carrier port-freeze and enhanced PINs for all executive phone numbers
• [ ] Deploy dual-authorization with out-of-band callback for all wire transfers above $50K
• [ ] Establish new-beneficiary cooling-off period (24–48 hours) before first transfer
• [ ] Integrate MDM heartbeat monitoring with SIEM for executive device offline correlation
• [ ] Conduct tabletop exercise simulating SIM swap attack against finance team
• [ ] Engage data broker removal service for all C-suite executives

Lessons Learned¶

References¶

• Chapter 25: Social Engineering
• Chapter 34: Mobile & IoT Security
• Chapter 9: Incident Response Lifecycle
• Chapter 6: Triage & Investigation
• MITRE ATT&CK T1078 — Valid Accounts
• MITRE ATT&CK T1556 — Modify Authentication Process