Session hijacking and fake confirmation code scams: the ussd channel as an attack surface

USSD serves as the primary operational channel for Mobile Money across Africa. It runs natively on all mobile devices without requiring internet connectivity or smartphone applications. However, its core design characterized by short-lived sessions, unencrypted over-the-air exchanges, and text command strings makes it a prime target for threat actors, introducing risks distinct from SIM swapping.

USSD attack vectors generally fall into two categories:

• Technical Attacks: Exploiting flaws in the session lifecycle (e.g., stale sessions, missing idle timeouts, or PIN brute-forcing).
• Human-Centric Attacks: Manipulating users into executing malicious USSD syntax to authorize outbound transfers without their informed consent (the fake confirmation code scam).

Below is a technical breakdown of these attack vectors, accompanied by actionable hardening controls for the USSD Gateway (USSDGW) and Core Mobile Money platforms.

1. Understanding the USSD Session Lifecycle

USSD is a session-oriented, stateful protocol. Upon initiation (e.g., dialing *145#), the network allocates a temporary Session ID that maintains context such as active menu state, account number, and entered amounts until the session terminates.

Critical Vulnerability: Any context state retained server-side (such as a targeted beneficiary or unverified transaction amount) remains actionable if the session is not terminated cleanly.

2. Technical Attack Vectors & Mitigation Strategies

• Stale Session Reuse: If a user exits a financial menu without completing the transaction and the gateway fails to destroy the Session ID immediately, a partially authenticated state persists. Weak gateway implementations allow subsequent requests to attach to this active context, bypassing authentication steps.
  • Remediation: Explicitly purge the Session ID upon transaction completion, user cancellation, or idle expiration.

• Missing or Lax Session Timeouts: Extended session windows widen the opportunity for interception and state manipulation.
  • Remediation: Enforce a strict server-side idle timeout of 30 to 60 seconds maximum.

• PIN Brute-Forcing: Short numeric PINs are trivial to enumerate if account lockout policies are absent. Attackers with channel access (post-SIM swap or via stolen hardware) can automate PIN guessing.
  • Remediation: Implement automatic account locking after 3 consecutive failed attempts, introduce progressive delay backoffs, and trigger real-time alerts.

• Input Sanitization: Special characters typed into USSD fields (*, #, ;, quotes) must be rigorously sanitized on the backend prior to processing to prevent injection vulnerabilities across databases, backend commands, and logging systems.

3. Social Engineering: The Fake Confirmation Code Scam

This human-centric vector bypasses technical security controls without exploiting system vulnerabilities. The victim performs the fraudulent transfer themselves, tricked into believing they are canceling an error or accepting a refund.

Execution Flow:

1. The scammer sends a spoofed SMS pretending a money transfer was deposited into the victim’s account.
2. The scammer calls the victim, impersonating telecom customer support or bank staff.
3. The scammer instructs the victim to dial a complete USSD string: *145*2*1*<Attacker number>*<Amount>*<PIN>#

This string does not cancel any transaction; it executes a direct outbound transfer from the victim to the attacker, incorporating the user’s PIN within the string. By manually dialing the sequence, the victim validates all legitimate security checks.

Why Traditional Controls Fail:

• The session originates from a valid SIM (matching MSISDN) and legitimate PIN.
• The amount and beneficiary are entered directly by the account owner.
• The underlying protocol registers no technical anomalies.

4. Advanced Application Controls

• Explicit Confirmation Prompts: Present a clear summary screen before initiating any debit (e.g., “Transfer 50,000 XOF to 90XXXXXX? Confirm: 1 – Yes, 2 – No”) instead of allowing implicit execution within a single dialed string.
• Transaction Friction for New Recipients: Introduce mandatory delays or out-of-band double confirmations for initial transfers to newly added recipients.
• Rolling Velocity Limits: Implement dynamic sliding limits to contain financial exposure from isolated compromised sessions.
• Call-Transaction Correlation: Detect concurrent active incoming voice calls during high-value USSD transfers where telecom API data is integrated.

5. USSD Gateway & Core Platform Hardening Matrix

6. Incident Response & Public Awareness

Core Awareness Message:

No legitimate financial institution or telecom operator will ever ask a customer to dial a USSD string over the phone to “cancel a transaction” or “receive a refund.” Any request to dial a string containing a personal PIN is a scam.

Incident Response Protocols:

When fraud is confirmed:

1. Immediately freeze the recipient’s account.
2. Trace the transaction graph to identify and block downstream mule accounts.
3. Report the incident directly to national cybersecurity response entities (e.g., MFIN-CERT).