In Togo, Mobile Money has become an everyday payment method. This widespread adoption shifts the cybersecurity landscape: today, the simplest and most lucrative target for an attacker is no longer the bank’s central server, but the user.
The vast majority of current frauds do not rely on technical software vulnerabilities. Instead, they exploit two inherent weaknesses of the SMS channel: the lack of sender authentication (the display name is freely customizable) and the blind trust users place in a notification that looks just like one from their telecom operator. Smishing (SMS phishing) and fake deposit scams are now the primary cause of stolen funds for clients of Decentralized Financial Systems (DFS).
Below is a detailed breakdown of these attack vectors, along with the protective measures required across operators, financial institutions, and end users.
- Why the SMS Channel is Structurally Spoofable
Mobile Money transaction notifications typically arrive via SMS using an alphanumeric Sender ID (e.g., MyOperator, DFS-Savings) rather than a standard phone number. However, this sender field lacks end-to-end authentication: it is set by the originating entity at the SMS Gateway (SMPP) level and transmitted in cleartext.
This structural flaw yields two direct consequences:
- Sender ID Spoofing: Through an international SMS gateway or a lax aggregator, an attacker can dispatch a message displaying the exact name of the operator or institution. On the victim’s device, the spoofed SMS merges directly into the legitimate thread alongside official messages, instantly lowering the user’s guard.
- Absence of a National Sender Registry: Without a binding national registry of authorized Sender IDs, nothing prevents malicious actors from registering lookalike identifiers (e.g., DFS-Sav1ngs, Mob1le-Money).
- The “Fake Deposit” or “Erroneous Transfer” Scam
This is the most prevalent and effective social engineering scenario because it manipulates psychological leverage, placing the victim in the position of a well-intentioned debtor.
Execution Flow
- Initial Spoofed Notification: The attacker sends a spoofed SMS mirroring an official deposit notification (e.g., “You have received 75,000 XOF from…”). No funds actually enter the account.
- Social Engineering Call: Minutes later, the scammer calls the victim pretending to be a distraught sender, an agent, or technical support, claiming an accidental transfer was made.
- The Fraudulent Refund: The victim, believing they must return funds that were never credited, conducts a legitimate outbound transfer from their actual account balance to the scammer.
Key Attack Dynamics
- Fictitious Credit: The initial deposit is completely fake; no movement occurred on the Mobile Money wallet.
- Legitimate Outbound Transfer: The victim executes a real transaction using their own funds and authentic credentials.
- Urgency & Guilt: Phrases like “You’re going to get me into trouble with my supervisor” act as psychological pressure points.
- Credential Harvesting: PIN and OTP Capture Kits
A second operational method does not ask the victim to transfer money directly, but rather captures credentials to grant the attacker unauthorized account access.
The victim receives an SMS containing a link (e.g., bit.ly/… or a fake domain my-operator-verify.tg) leading to a cloned portal mimicking the official login page. The page prompts the victim to enter:
- Their mobile phone number (MSISDN)
- Their Mobile Money PIN
- A One-Time Password (OTP) dispatched during the active session
Once harvested, the attacker links the victim’s wallet to an unauthorized device or executes transfers in real time.
- Mobile Money Defense & Countermeasure Matrix
| Stakeholder |
Technical & Operational Controls |
Implementation Point |
| Telecom Operator / Regulator |
Enforce mandatory Sender ID registration (whitelisting) and block unauthorized SMPP traffic. |
SMS Gateway & Core Network |
| Telecom Operator |
Filter incoming international SMS traffic attempting to use local alphanumeric Sender IDs. |
International Signaling / SMPP Firewall |
| Decentralized Financial System (DFS) |
Implement real-time transactional monitoring to detect abnormal activity (e.g., immediate cash-out following a transfer). |
Fraud Detection System (FDS) |
| Decentralized Financial System (DFS) |
Provide an in-app or USSD balance verification shortcut before confirming any refund request. |
Mobile App / USSD Core |
| End-User / Customer |
Always check wallet balance directly via USSD/App rather than relying solely on incoming SMS text. |
Operational Behavior |
| End-User / Customer |
Never share PINs or OTPs under any circumstances, and refer all “wrong transfer” claims to official support. |
User Awareness |
- Action Plan During Active Smishing Campaigns
- Isolate Threat Artifacts: Extract the phishing URLs, spoofed Sender IDs, and contact phone numbers from reported SMS samples.
- Map Mule Account Networks: Analyze the transaction graph to identify convergent accounts receiving fraudulent funds and freeze them immediately.
- Coordinate Infrastructure Takedowns: Engage telecom operators to block spoofed Sender IDs and request immediate takedowns for active phishing domains.
- Notify Regulatory Authorities: Escalate technical indicators to the national computer emergency response team (e.g., MFIN-CERT).
- Dispatch Targeted Customer Alerts: Broadcast clear, preventive alerts quoting the exact wording of the active scam to immunize the user base.
Smishing cannot be resolved through a single software patch; it requires a combination of network-level sender controls, behavioral monitoring by financial entities, and continuous public education. The golden rule remains unchanged: a genuine deposit is never refunded manually upon a caller’s request, and PINs or OTPs must never be disclosed.
