CAMEL (Customised Applications for Mobile network Enhanced Logic) is the 3GPP Intelligent Network overlay that gave operators programmable control over call setup decades before anyone talked about "service-based architecture." Prepaid charging, roaming call control, follow-me routing — all of it runs through a Service Control Point (SCP) that the Mobile Switching Center consults mid-call. The MSC asks a simple question — "what do I do with this call?" — and whatever answers gets to redirect it, bridge a silent third leg into it, or rewrite how it gets billed.

That trust model was reasonable when only the operator itself could stand up an SCP. It stopped being reasonable the moment SS7 interconnects opened that signaling plane to thousands of external parties. An attacker who can reach the SCP GT field in a subscriber's HLR profile — either by reading it via a permissive MAP query or forging an update to it — doesn't need to touch a base station, jam a frequency, or crack any encryption. They just need the network to believe their signaling point is the legitimate SCP. From there, every trigger-eligible call the subscriber makes routes through infrastructure the attacker controls.

This research dissects how the CAMEL Intelligent Network overlay is abused to redirect calls, insert covert monitoring legs, and falsify billing records. We trace the O-CSI / T-CSI subscription model that stores the SCP's Global Title, the InitialDP trigger that hands call control to that address, and the exploitation chain a rogue SCP uses once it holds that trust. We close with the documented financial fallout of CAMEL fraud rings and the interconnect-layer controls that stop them.

I. CAMEL Architecture: An Intelligent Network Built on Trust

CAMEL is not a routing protocol in the way MAP or ISUP are — it's an overlay. The GSM/UMTS call-control state machine (the Basic Call State Model, or BCSM) exposes specific pause points during call setup called Trigger Detection Points (TDPs). When a subscriber's profile has CAMEL Subscription Information (CSI) configured against one of those points, the switch handling the call — the Service Switching Point, typically co-located with the MSC — stops mid-setup and asks an external node, the Service Control Point, what to do next.

Component	Role	Security Relevance
SSP (Service Switching Point)	MSC function that detects the trigger and pauses call processing	Trusts whatever GT is in the subscriber's CSI record
SCP (Service Control Point)	Answers the trigger with a CAMEL operation (`Connect`, `Continue`, `ReleaseCall`)	The entire attack surface — impersonate this node and you own the call
CAP (CAMEL Application Part)	The TCAP-carried operation set (`InitialDP`, `Connect`, `ApplyCharging`, `FurnishChargingInformation`)	No cryptographic binding between SSP and SCP beyond SCCP GT routing
CSI (CAMEL Subscription Info)	HLR record naming the trigger condition and the SCP GT for a subscriber	The single field an attacker needs to change or spoof

┌───────────────────────────────────────────────────────────────────────┐
│                    CAMEL INTELLIGENT NETWORK MODEL                     │
│                                                                         │
│   Subscriber Handset                                                    │
│         │                                                               │
│         │ Call Setup (CC)                                               │
│         ▼                                                               │
│   [BSC] → [MSC/SSP]  ─────── TCAP/MAP IDP ──────────► [SCP]           │
│         │                                               │               │
│         │ Wait for instruction                          │ CAMEL ops:    │
│         │ ◄─────────────────────────────────────────────┘ Connect /    │
│         │                                                 Continue /    │
│         │                                                 Disconnect    │
│         ▼                                                               │
│   Call connected to:                                                    │
│   (A) Real B-party number → legitimate call                             │
│   (B) Attacker media GW  → intercepted / redirected                    │
│   (C) Premium-rate trunk → billing fraud                                │
│                                                                         │
│   ATTACK SURFACE: Control the SCP, and you control every call          │
└───────────────────────────────────────────────────────────────────────┘

The critical detail is that the SSP does not authenticate the SCP beyond routing the InitialDP TCAP dialogue to whatever GT its own CSI record names. Nothing in the CAMEL Phase 2/3 specification (3GPP TS 23.078) requires the SCP to prove it is who it claims to be — the SSP simply trusts its own configuration data. If that configuration data can be read or rewritten from outside the operator's trust boundary, the entire model collapses.

Originating and Terminating CSI: Where the SCP Address Lives

Two CSI variants matter for this attack. Originating CSI (O-CSI) fires on the calling subscriber's outbound calls; Terminating CSI (T-CSI) fires on inbound calls to the subscriber. Both store the same critical field:

HLR Subscriber Profile (extracted via MAP ATI):
  IMSI: 262071234567890
  O-CSI:
    O-BcsmTriggerDetectionPoint: "originalledPartyInformation" (DP2)
    ServiceKey: 1234
    GsmScfAddress: GT of OPERATOR SCP       ← this is what we need to replace
    DefaultCallHandling: Continue
  T-CSI:
    T-BcsmTriggerDetectionPoint: "termAttemptAuthorized" (DP12)
    ServiceKey: 5678
    GsmScfAddress: GT of OPERATOR SCP
    DefaultCallHandling: Continue

GsmScfAddress is a plain SCCP Global Title. Whoever's GT sits in that field receives the InitialDP for every trigger-eligible call. There is no certificate, no shared secret, no session key — just a routing address in a database record, reachable and (on far too many interconnects) writeable from outside the home network.

II. Exploitation: Rogue SCP Injection and Call Hijack

The kill chain has four stages: read the target's current CSI configuration, stand up infrastructure capable of speaking CAP, capture the InitialDP for a live call, and — optionally — falsify the charging record for it.

Step 1 — Extract the Subscriber's CSI Profile

AnyTimeInterrogation (MAP OpCode 71) is meant for internal operator use, but on interconnects that don't restrict it to trusted GTs it returns the full CSI block, SCP address included:

<CodeBlock language="text" filename="ati-csi-extraction.map" code="MAP ATI → HLR GT Subscriber-Identity: MSISDN +49176XXXXXXXX Requested-Info: Current-Location: requested Subscriber-State: requested CSI: requested ← explicit CSI request

← MAP ATI Response IMSI: 262071234567890 O-CSI: GsmScfAddress: +491791000001 ← legitimate SCP GT ServiceKey: 1234 TriggerDetectionPoint: DP2 (origCallAttempt)"

Once the legitimate SCP GT is known, the attacker has two paths forward: register their own node under that same GT (GT spoofing at the SCCP/STP layer), or overwrite the CSI record's GsmScfAddress with a GT they control, typically via a forged InsertSubscriberData (ISD) message if the target's ISD screening is weak.

Step 2 — Stand Up the Rogue SCP

A CAMEL-capable SCP doesn't need to be a full Intelligent Network platform — it only needs to answer TCAP BEGIN dialogues with valid CAP responses:

Attacker SS7 Node Stack:
  Layer 1-2: MTP (Message Transfer Part)
  Layer 3: SCCP (transport; attacker GT registered here)
  Layer 4: TCAP (Transaction Capabilities Application Part)
  Layer 5: CAP (CAMEL Application Part — InitialDP handler)

The node listens for InitialDP, and replies with Continue (let the call proceed as dialed — useful for passive monitoring without disrupting service), Connect (redirect to a different destination), or EstablishTemporaryConnection (bridge in a silent third leg for interception). The rogue node's GT must match whatever GT the target's CSI record now names as the SCP — otherwise the MSC/SSP never routes InitialDP there in the first place.

Step 3 — Intercept InitialDP, Redirect the B-Leg

When the victim subscriber places a call, the MSC's O-BCSM hits the configured trigger and fires InitialDP toward the SCP address in the CSI record — now the attacker's node:

<CodeBlock language="text" is-terminal code="← MAP InitialDP (MSC → rogue SCP) MSC-Address: +491761XXXXX Called-Party-Number: +44207XXXXXXX ← intended destination Calling-Party-Number: +49176XXXXXXXX ← victim subscriber ServiceKey: 1234 IMSI: 262071234567890 Call-Reference-Number: ...

→ CAP Connect (rogue SCP → MSC) Destination-Routing-Address: +44900XXXXXXX ← attacker media GW

Or: EstablishTemporaryConnection → bridge in a monitoring leg"

The MSC does exactly what it's told. If the response is Connect, the call goes to the attacker's routing address instead of the intended B-party — a redirect. If it's EstablishTemporaryConnection, the real call proceeds normally to its intended destination, but with a silent third leg bridged in — real-time wiretap with the subscriber none the wiser, because the call still connects and sounds normal on both ends.

The loud version of this attack — outright redirecting calls to a different number — gets noticed fast; the intended party simply never receives the call. Operators running this attack for surveillance rather than fraud almost always choose `EstablishTemporaryConnection` or a Connect that relays onward to the real B-party. The call completes normally, call duration and billing look unremarkable, and the only artifact is a CAMEL dialogue to a GT that shouldn't be in that subscriber's CSI record — something almost no operator actively audits for.

Step 4 — Falsify the Charging Record

CAMEL doesn't just control routing; the same SCP also controls billing via FurnishChargingInformation and ApplyCharging. A rogue SCP can attribute a premium-rate destination and inflated duration to a call that never actually reached either:

→ CAP FurnishChargingInformation (rogue SCP → MSC)
  FCIBillingChargingCharacteristics:
    freeFormatData:
      CalledPartyNumber: +44207XXXXXXX     ← real destination (billed rate)
      # But actual call went to: +44900XXXXXXX (premium rate)

→ CAP ApplyCharging
  AChBillingChargingCharacteristics:
    MaxCallPeriodDuration: 3600            ← charge for full hour
    # Actual call: 30 seconds

The result is a fraudulent CDR that bills the victim's IMSI for a call to a premium-rate number they never dialed, for a duration far longer than the real call lasted — and it lands in the billing pipeline looking like routine metering data, not a security event.

III. Impact: What Rogue SCP Control Actually Buys an Attacker

┌──────────────────────────────────────────────────────────────────┐
│              IMPACT OF CAMEL ROGUE SCP INJECTION                 │
│                                                                  │
│  ✗ Call redirect to attacker-controlled media gateway            │
│  ✗ Real-time call interception via bridged monitoring leg        │
│  ✗ Billing fraud: falsified CDRs attribute premium-rate charges  │
│  ✗ Covert bridged monitoring — the call still completes normally │
│  ✗ O-CSI manipulation persists until the HLR record is corrected │
│  ✗ T-CSI abuse extends the same control to inbound calls         │
└──────────────────────────────────────────────────────────────────┘

Because the compromise lives in HLR configuration data rather than in a transient session, it is durable — the rogue GT stays effective on every trigger-eligible call until someone notices and corrects the CSI record. That can be days, weeks, or — per the documented case below — months.

Real-World Impact: CAMEL Roaming Fraud (Eastern Europe, 2016)

Security researchers at SRLabs documented an active CAMEL-based fraud operation targeting multiple European operators' roaming subscribers. The scheme injected forged O-CSI entries into stolen subscriber profiles, replacing the legitimate SCP GT with one the fraud group controlled. Roaming calls then triggered InitialDP to the rogue SCP, which connected them to premium-rate trunks under the attacker's control, while falsified FurnishChargingInformation records attributed the charges to the victim subscribers. One affected operator lost an estimated €2M in a single quarter before the rogue SCP GT was identified and blacklisted — with a 14-week average gap between the first fraudulent CDR and detection, because the charging anomalies were initially triaged as a billing dispute rather than a security incident.

That detection lag is the pattern worth internalizing: CAMEL fraud doesn't trip an intrusion alert, it trips a revenue-assurance report weeks later, if it trips anything at all. By the time finance flags the anomaly, the rogue SCP has usually been harvesting for a full billing cycle.

MITRE FiGHT Mapping

TTP ID	Name	Maps To
FGT5019	CAMEL-based Call Redirect	InitialDP interception followed by a Connect operation to attacker infrastructure

CAMEL abuse is a direct sibling of the SS7 location-tracking and SMS-interception attacks covered elsewhere in this research library — same SCCP/TCAP transport, same absence of source authentication, different application-layer target (call control instead of subscriber location or SMS routing). An interconnect exposed to one class is very likely exposed to the other.

Effective CAMEL defense requires layered controls at the switch, the signaling firewall, and the HLR itself: - **SCP GT Whitelisting:** The MSC/SSP should only forward InitialDP to GTs on an operator-maintained whitelist; unlisted GTs trigger default call handling plus a SIEM alert, never a forwarded dialogue. - **TCAP/CAP Application Firewalling:** Screen InitialDP, Connect, and FurnishChargingInformation operations at the signaling firewall — block dialogues from unlisted GTs and alert on Connect operations routing to premium-rate number ranges. - **Periodic CSI Auditing:** Regularly enumerate O-CSI and T-CSI records in the HLR and flag any `GsmScfAddress` that falls outside the operator's authorized SCP GT range, cross-referenced against the GSMA TADIG database. - **Charging Anomaly Correlation:** Route CDR anomalies (inflated duration, destination mismatch) to the security team, not exclusively to revenue assurance — the 2016 case above shows what happens when that line is drawn the wrong way.

Defense Reference Table

Control	Blocks	GSMA / 3GPP Reference
SCP GT whitelist at MSC/SSP	Rogue InitialDP delivery	GSMA FS.11 §5.5; 3GPP TS 23.078 §4.2
TCAP/CAP source screening	Unauthorized CAMEL dialogue establishment	GSMA FS.11 Annex C
Periodic CSI profile audit	Persistent CSI tampering	3GPP TS 23.078 §4.2
Charging anomaly correlation to SIEM	Delayed fraud detection	GSMA FS.11 §5.5.1

Verification (Authorized Lab Assessment)

<CodeBlock language="bash" is-terminal code="# Test 1: InitialDP delivery to an unlisted SCP GT

Expected: MSC applies DefaultCallHandling (Continue); IDP never forwarded to the rogue GT

Test 2: CSI profile carrying an unauthorized SCP GT (injected via forged MAP ISD)

Expected: MSC/SSP rejects the CAMEL service; SIEM alert raised with IMSI + rogue GT

Test 3: FurnishChargingInformation reporting an inflated call duration

Expected: CDR anomaly alert fires; billed duration capped to observed call duration

Test 4: Connect operation routing to a premium-rate number range from a rogue SCP

Expected: Connection blocked; SIEM alert includes subscriber IMSI and destination number"

IV. Frequently Asked Questions

No. The attack targets the SS7/SCCP interconnect layer, not the operator's internal IT systems. An attacker with SS7 access — whether through a compromised interconnect partner, a rented signaling route, or a rogue GT registered on a permissive network — can reach the HLR's MAP interface and a subscriber's CSI record without ever touching the operator's internal infrastructure directly.

CAMEL was specified in an era when only the home operator (or a small number of trusted IN service providers) could plausibly run an SCP. The protocol has no mechanism — no certificate, no shared secret, no mutual authentication — for the SSP to verify the SCP's identity beyond the SCCP Global Title in the subscriber's own configuration data. If that configuration data is wrong, spoofed, or forged, the SSP has no way to detect it at the protocol layer.

Yes. UpdateLocation-based redirection (covered in our SS7 location tracking research) works by registering a fraudulent MSC/VLR address in the HLR, rerouting the subscriber's entire mobile termination. CAMEL abuse is more surgical — it only affects calls that hit a specific Trigger Detection Point configured in the CSI record, and it operates through the CAP protocol layer rather than basic mobility management. Both exploit the same underlying absence of source authentication in SS7/MAP.

Yes, and this is the more concerning variant. Using EstablishTemporaryConnection instead of a hard redirect, the rogue SCP bridges a silent monitoring leg into the call while the real call proceeds to its intended destination normally. Both parties hear a normal call; call duration and CDR data look ordinary unless the charging record is also being falsified. Detection depends entirely on catching the anomalous CAMEL dialogue to an unauthorized SCP GT, not on any symptom visible to the subscriber.

The documented 2016 SRLabs case found roughly 14 weeks between the first fraudulent CDR and identification of the rogue SCP GT, primarily because the initial anomaly was routed to revenue assurance as a billing discrepancy rather than escalated as a signaling security incident. Operators without CSI auditing or CAMEL-aware signaling firewalls have no earlier detection point in the chain.

It removes CAMEL specifically — CAMEL is an SS7/MAP-era Intelligent Network protocol with no direct 5G equivalent — but the underlying pattern (a trusted external node making mid-session routing or charging decisions with no strong mutual authentication) reappears in different forms, such as SEPP misconfiguration on 5G roaming interfaces. Full retirement of CAMEL-dependent legacy services is the only complete mitigation, and most operators still run it for prepaid charging and legacy roaming compatibility.

Conclusion & Next Steps

CAMEL's exploitation surface is a direct product of its age: an Intelligent Network model built for a small, closed circle of trusted operators, now reachable across an interconnect fabric with well over a thousand entities holding some form of signaling access. The protocol was never designed to authenticate the SCP it hands call control to — it trusts a Global Title in a database record, and that record is exactly as secure as the ATI query and ISD screening rules protecting it.

The defensive path is not glamorous but it is effective: whitelist SCP GTs at the switch, screen CAP dialogues at the signaling firewall, audit CSI records on a schedule rather than after a fraud report surfaces, and route charging anomalies to security review, not just revenue assurance. Every one of these controls is achievable with current-generation signaling firewalls — the gap is operational discipline, not technology.

TelcoSec provides CAMEL and SS7 interconnect security assessments, including simulated rogue-SCP campaigns to validate whitelist and firewall effectiveness. Explore the TelcoSec Academy for structured signaling security learning paths, or review our broader SS7 research for the location-tracking and SMS-interception attacks that share this same transport layer.

CAMEL InitialDP Call Redirection and Charging Fraud