Amid the constant flow of phone spam we have largely grown accustomed to, you have almost certainly received phishing messages impersonating your bank in recent years, or calls from numbers that turn out to be nonexistent when called back. This phenomenon is known as telephone spoofing, namely the manipulation of the sender's identity in calls and SMS messages, and it represents one of the most widely used vectors in phishing, social engineering, and digital fraud campaigns. From fake bank messages urging you to "verify a payment" to calls that appear to originate from customer support, this technique exploits one of the oldest and least secure infrastructures in our communication ecosystem: the traditional telephone network and its legacy protocols.
The widespread adoption of VoIP, the exposure of enterprise messaging services through online gateways, and the availability of "programmable" telephony services have made spoofing accessible even to actors with limited technical skills. An attacker does not need to "hack" a phone number; it is enough to exploit the way telephone networks inherently trust the information provided by operators or by the platforms originating the traffic.
Understanding how spoofing works from a technical perspective is essential for anyone working in cybersecurity, application security, or digital service protection. This article examines the technical mechanisms behind the phenomenon, the structural limitations of telecommunications networks, and the mitigation strategies currently available.
How Call and SMS Network Architectures Work
To understand spoofing, it is necessary to start with the architecture of telephone networks. Most modern infrastructures combine two distinct worlds: the legacy SS7 (Signaling System No.7) used by traditional carriers, and VoIP, based on SIP (Session Initiation Protocol), which is increasingly used for calls and SMS delivery via APIs.
In the SS7 model, when an operator forwards a call, it includes the caller's number (CLI, Caller Line Identification) within the signaling messages. Historically, this information was considered trustworthy because it was only provided by official operators: the entire network relied on the assumption that whoever supplied the data was a legitimate actor. This represents a classic "trust by default" model, far removed from today's zero-trust principles, and is one of the fundamental weaknesses of a system that does not implement any authentication mechanisms.
In the VoIP world, SIP manages calls through packets that include headers such as From, Contact, and P-Asserted-Identity, within which the caller's number is specified. Here again, networks tend to trust information originating from specific nodes, especially if they belong to certified providers or recognized gateways. The same dynamic applies to SMS delivery: enterprise platforms and messaging gateways allow the use of alphanumeric sender IDs (e.g., "BankXYZ") or phone numbers, but do not always enforce strict validation of the claimed sender's ownership.
The convergence of these two infrastructures - SS7 and SIP - results in a heterogeneous ecosystem in which the "sender number" can traverse multiple networks without being independently verified.
What Is Required to Perform Spoofing?
As should now be clear, the core issue lies in the fact that the caller's identity is self-declared and unauthenticated, enabling spoofing with minimal effort. When a VoIP platform originates a call, it can specify an arbitrary number in the SIP headers; if the receiving network considers the provider trustworthy, the call will be forwarded without further checks.
If the network does not verify that the entity originating the call is actually the legitimate owner of that number, the entire burden of validation falls on the telephony provider. While providers may implement internal checks, there is no mandatory global standard. By default, gateways accept customized numbers for legitimate use cases (call centers, enterprises presenting a unified caller ID, programmable telephony services), and this flexibility can be abused.
The situation becomes even more problematic with SMS. Gateways often allow sender ID configuration without rigorous validation. Scenarios originally designed for legitimate purposes (brand messaging, enterprise OTPs, service notifications) become an ideal tool for smishing campaigns.
Another factor contributing to the ease of spoofing is system fragmentation. Mobile networks across different countries combine legacy carriers, MVNOs, VoIP providers, transit carriers, and API gateways, creating routing paths where sender identity controls are inconsistent. Even implementing national-level filtering is complex and often ineffective, as traffic may enter through foreign operators that do not apply the same rules.
For all these reasons, telephone spoofing does not require advanced technical expertise. All that is needed is a provider that allows calls or messages to be sent via API without enforcing strong security controls.
At that point, spoofing can be achieved with a simple API call such as the following:
curl -X POST https://black-provider.com/text \
--data-urlencode phone='5555555555' # Destination phone number
--data-urlencode message='Hello world' # Message body
--data-urlencode sender='Your Own Bank' # Displayed sender name
-d key='api-key' # Provider API key
The core of the process lies in the field labeled here as sender, which in telephony networks is known as the Alphanumeric Sender ID-the name or number displayed to the SMS recipient on their device. If the provider does not enforce validation and allows arbitrary values, the message will be delivered exactly as specified.
So Can Anyone Send Messages Impersonating Someone Else?
From a purely technical standpoint, the answer is simple: yes, it is possible.
That said, we avoid sensationalism. The reality is more nuanced. In recent years, many providers have introduced stricter sender validation, particularly for alphanumeric sender IDs and numbers presented through VoIP services. These measures do not fix the underlying protocol weaknesses, but they do restrict what users can configure at the service level. As a result, for individual malicious actors using regulated providers-especially in Europe and the United States, where regulation and KYC requirements are stricter-replicating spoofing is far from trivial.
The situation differs in other regions. In parts of Asia and Africa, sender validation controls are still less mature and anti-spoofing adoption remains fragmented. In these markets, forging a phone number or sender ID can still be relatively easy.
Finally, the structural weaknesses of telephony protocols allow organized criminal groups, including state-sponsored actors, to operate at a different level altogether. Rather than relying on commercial providers, they exploit compromised telecom infrastructure or relationships with regional operators. In such scenarios, manipulating sender identity becomes significantly harder to detect and mitigate.
Conclusion
Telephone spoofing is widespread not because attackers possess advanced tools or exceptional skills, but because the underlying telecommunication infrastructure was designed in an era when identity authentication was not a priority. Today's system is tasked with addressing modern threats using legacy protocols that lack digital signatures, distributed validation, or cryptographic controls.
In the future, we should expect broader adoption of standards such as STIR/SHAKEN, cryptographic validation of enterprise messaging, and the gradual decommissioning of the most vulnerable infrastructure components. Until then, understanding the technical mechanisms behind spoofing-and recognizing how operationally simple it remains-is a critical step toward defending systems and designing secure services within an increasingly manipulable communication ecosystem.
