Vishing, call forwarding, and the MAP signals that reveal compromise
Vishing, call forwarding, and the MAP signals that reveal compromise
Call forwarding is an old telecom feature that has had a second life as a fraud primitive. The mechanics are direct: an attacker activates unconditional call forwarding on a victim's line, and every voice OTP, every bank callback, every transaction confirmation that depends on voice delivery arrives on the attacker's handset instead of the subscriber's. SMS delivery over the voice-dial-back pathway, where operators use it, is also redirected. The attack leaves no visible symptom on the victim's handset. The phone does not stop working. The subscriber simply stops receiving the calls that matter, and the signals that reveal it live in the MAP supplementary-services state, where most authentication layers are not configured to look.
This post describes how vishing-plus-forwarding attack chains actually run, why the MAP InterrogateSS and Call Forwarding Status signals are the highest-signal detection primitives available, and what an authentication flow should do with the resulting information.
What vishing is, in 2026
Vishing, or voice phishing, is the voice-channel equivalent of SMS phishing, with the addition that voice permits richer social engineering than text. Published legal and technical analyses of consumer-facing mobile fraud consistently identify vishing as a leading attack vector in markets with high voice-call penetration and weaker caller-authentication regimes.
The attack has two recurring shapes.
The first shape is the credential-harvesting call. An attacker calls the victim impersonating a bank, a government agency, or a technical-support service, and walks the victim through a script that extracts credentials, confirms a transaction the attacker has initiated in the background, or convinces the victim to install a remote-control application. Qualitative research on mobile-based fraud documents this shape in detail, including the four-actor model (victim, fraudster, agent, regulator) observed in 96-participant fieldwork in Pakistan. The attack works because the voice channel carries authority cues: a calm professional, sometimes with call-centre background noise, sometimes with spoofed caller ID matching a genuine institution.
The second shape is the forward-then-authenticate attack. The attacker does not need to extract anything from the victim directly. They have already compromised a password, a session, or a lower-factor credential, and they need to bypass a voice-delivered second factor. They activate call forwarding on the victim's line, trigger the authentication step at the bank, and receive the voice OTP or the callback on their own device. The victim's phone never rings. The fraudulent transaction completes. The victim discovers the compromise later, often through an account statement.
The activation mechanism
Call forwarding activation goes through a MAP supplementary-services exchange. On 2G/3G, a MAP RegisterSS (or ActivateSS for previously-registered forwarding) is sent to the subscriber's VLR, which proxies to the HLR, which updates the supplementary-services bitfield for the subscriber. On 4G/5G, the equivalent flows through Diameter at the HSS. The bitfield tracks whether each forwarding type (unconditional or CFU, busy or CFB, no-reply or CFNRY, not-reachable or CFNR) is registered, activated, and what the forwarding destination is.
Activation can happen legitimately through three paths. The subscriber uses the handset's settings dialog, which sends a USSD or MMI code that the network processes. The subscriber calls a network-side service line that lets them configure forwarding. Or, critically for the fraud case, a third party with sufficient access sends a MAP RegisterSS directly to the subscriber's VLR or HLR.
The third path is the one attackers exploit. In jurisdictions where SS7 signalling firewalls are immature, an attacker with a global-title range and access to an SS7 interconnect can send forwarding-activation requests to foreign subscribers' HLRs. Surveys of SS7 vulnerabilities have documented this class of attack for years, and real-traffic analyses of SS7 traffic at major operators continue to show such attempts in meaningful volume.
Even in jurisdictions with hardened signalling firewalls, call-forwarding fraud persists through the first path. An attacker socially engineers the subscriber into setting forwarding themselves, typically under a cover story about "fixing" a network issue or activating a service. The subscriber dials the MMI code the attacker reads to them, and the forwarding is set.
The detection signals
The detection primitive is straightforward. The MAP InterrogateSS operation returns the current supplementary-services state for a subscriber. Query it before sending a voice OTP or a voice-based authentication callback, and the response tells you whether call forwarding is active, which forwarding type, and where the forwarding destination is.
This is a first-class MAP operation rather than an inference. The HLR or HSS responds with the actual bitfield, updated in real time. The response is structured: active and inactive flags per forwarding type, destination number where forwarding is active, registration timestamp where the implementation tracks it.
Two signal-interpretation rules matter in practice.
Recent activation is a strong signal: a forwarding activation within the past few hours, on a subscriber who did not previously have forwarding configured, is a classic attack pattern. An authentication flow that sees this state should not deliver the voice OTP to the forwarded destination. It should treat the signal as a ranking feature and step up to a different factor.
Forwarding destination outside the subscriber's usual jurisdiction is a strong signal: a subscriber in Nigeria with unconditional forwarding to a UK number, on an account with no history of UK activity, is the canonical shape of an active attack. The destination-jurisdiction feature is present in the MAP response in most implementations and is one of the cleanest single-feature attack signals available.
Composition with SIM swap signals
Call forwarding and SIM swap are two components of the same attack family. In some attack flows, the attacker swaps the SIM to capture SMS OTPs. In others, the attacker activates forwarding to capture voice OTPs. In the richest attack flows, both happen, with a swap handling SMS and forwarding handling voice.
A fraud model that uses both signals composes them in a weighted risk score. The TensorShield Risk Score API specifies SIM swap as the heaviest signal at approximately 30 percent and call forwarding at approximately 20 percent, with the weighting reflecting the directness of each signal to the attack mechanism. These weights are starting points rather than universals; tuning against the specific population's fraud distribution is required for any production deployment.
The composition principle is that each signal is informative on its own but decisive only in combination. A single active call-forwarding activation, in isolation, could be a subscriber legitimately configuring forwarding because they are travelling. A SIM swap 72 hours ago, in isolation, could be a subscriber replacing a damaged SIM. Both signals together, on an account attempting a high-value transaction from a new device, is a coherent attack signature.
What an authentication flow should do with the signal
Composition inside an authentication flow is where the signal becomes a decision.
Before delivering a voice OTP or initiating a voice-callback authentication, query the MAP or Diameter supplementary-services state. If no forwarding is active, proceed. If forwarding is active, examine the activation timestamp and destination, and treat each combination as a different policy outcome.
Forwarding active with no timestamp, destination within the subscriber's normal geography: low-risk, proceed with additional contextual factors. Forwarding active with a recent timestamp, destination within the subscriber's normal geography: medium-risk, step up to a different factor (silent auth, push). Forwarding active with a recent timestamp, destination outside the subscriber's normal geography: high-risk, refuse the voice OTP entirely and route to a support flow. Forwarding active with the destination on a premium-rate or high-fraud number range: highest-risk, refuse and flag the account.
The response is never a single binary. The interpretation depends on the full context: the specific forwarding type, the destination, the account tenure, the transaction being authenticated. The signal is informative, and the decision is a policy composition layered on top of it.
Voice OTP as a specific case
Voice OTP as a second factor does not represent a security upgrade over SMS OTP. The published analysis of voice as an authentication channel notes that voice OTP carries a subset of SMS OTP's weaknesses (rerouting via forwarding, social engineering on the voice call itself) and introduces some of its own (DTMF entry vulnerabilities, voice-quality-dependent transcription errors). Its deployment is often justified on accessibility grounds, since for subscribers with visual impairments voice is a usable channel where SMS is not, rather than on security.
A relying party deploying voice OTP should query the forwarding state before delivery, always, and route the OTP to the subscriber's home device only if forwarding is off or safely configured. This is the minimum bar. Skipping the check and delivering to whatever number the forwarding state directs to is an error, because the attacker who set the forwarding is the one who receives the OTP.
How Tensormobile ships the signal
TensorShield's call-forwarding signal is a direct MAP InterrogateSS or Diameter supplementary-services query against the subscriber's home HLR or HSS. The response is structured: active and inactive flags per forwarding type, destination number, registration timestamp where available, and a classification of the destination as within-country or outside-country.
For 4G and 5G cores, supplementary services ride Diameter rather than MAP. The signal shape is equivalent (the HSS holds the forwarding state, and an authorised query can retrieve it), but the protocol binding is different. The literature on signalling-layer attacks has tracked the move from SS7 to Diameter and shown that the attack surface did not disappear with the transition. It shifted. SMS interception over LTE Diameter has been demonstrated in academic research, and the same class of attacker capable of signalling-layer exploitation on SS7 has been documented adapting to Diameter. Detection primitives should therefore cover both stacks. TensorShield resolves the query across both, and the integrator receiving the result does not need to know which stack produced it.
For integrators deploying voice OTP, the recommended flow is to query TensorShield before initiating the voice-delivery step, and to refuse delivery when the forwarding state suggests active compromise. The query latency per region and the coverage are documented per integration: which operator footprints Tensormobile can resolve against in real time, and which are federated through partners.
The product principle is the same as the SIM-swap signal. TensorShield outputs the structured signal so the relying party can compose it into their fraud model with weights they can tune and policies they can change.
Call-forwarding fraud is detectable through a standard MAP or Diameter operation that operators have supported for decades, queried at the moment voice-channel authentication is about to fire.
