Inside a Telecom VAPT Engagement: What Actually Gets Tested

In part one, we looked at why SS7 trusts almost anything that shows up claiming to be a legitimate carrier. That's the conceptual story. This time, let's look at what that actually translates to when a real telecom security assessment gets scoped because "test SS7" turns out to mean testing a lot more than just SS7.

It's Not Just SS7

A modern telecom security assessment typically spans several signaling protocol families at once, because operators run all of them simultaneously for backward compatibility:

• SS7 — the legacy signaling protocol from part one, still essential for 2G/3G and international roaming interconnects
• Diameter — the 4G/LTE-era signaling protocol that replaced SS7's role between mobile networks and core elements like the HSS (Home Subscriber Server) and MME (Mobility Management Entity)
• GTP (GPRS Tunneling Protocol) — handles the actual data tunnels that carry subscriber internet traffic between network nodes
• VoLTE/SIP — the protocol stack behind Voice over LTE calling
• CLI/Caller ID validation — checking whether the network correctly verifies that an incoming call's displayed number is legitimate

That breadth is the point: an operator's signaling attack surface isn't one protocol with one weakness it's a stack of protocols from different decades, each with its own trust assumptions, all still running in production at the same time.

How Threats Get Categorized

Rather than treating each vulnerability as a one-off, mature assessment frameworks group them into threat categories which is a genuinely useful mental model if you're new to this space. Across one real threat catalog I looked at (88 distinct threat types), the breakdown looked roughly like this:

• Privacy (disclosure of subscriber identity, location, or profile data) the largest single category
• Denial of Service (disrupting a subscriber's or network's availability)
• Fraud (billing bypass, unauthorized service usage)
• Exposure (network infrastructure or interfaces reachable when they shouldn't be)
• Interception (calls or messages redirected or captured)
• Impersonation (spoofing a legitimate subscriber or network element)

Notice that privacy and denial of service dominate. That tracks with what we covered in part one most SS7-era weaknesses come down to either "this leaks information it shouldn't" or "this disrupts service when it shouldn't be able to." Diameter and GTP issues, interestingly, skew even more heavily toward denial-of-service categories, because those protocols carry more direct control over active sessions and data tunnels.

Each threat is also typically assigned a threat level — low, medium, or high based on factors like how easily it can be triggered, what an attacker gains from it, and how much legitimate network access it requires. In practice, the highest-severity findings tend to cluster around interception and certain high-impact privacy disclosures the kinds of issues that put a specific subscriber's calls, messages, or location directly at risk while many exposure and low-friction denial-of-service issues land in the medium-to-low range.

What a Finding Actually Looks Like

A useful way to think about how these assessments document findings is through a lightweight version of the MITRE ATT&CK model, adapted for telecom. Instead of just "vulnerability found," a well-structured threat catalog maps each issue across the full attack lifecycle:

• How an attacker would get positioned — reconnaissance, network access requirements, whether insider access or partner-network access is needed
• What technique category it falls under — SS7-based, Diameter-based, GTP-based, or SIP-based exploitation
• What the attacker achieves — credential exposure, subscriber identifiers, communication metadata, location data, or service disruption

This framing matters because it shifts the conversation from "is this protocol secure?" to "what specific conditions does an attacker need, and what do they actually gain?" That's a far more useful question for an operator trying to prioritize remediation with limited engineering time.

Closing Thought

Part one was about why SS7 is structurally vulnerable. This part is about how that structural weakness gets translated into something testable, measurable, and reportable which is really what separates "I understand SS7 conceptually" from "I can do telecom VAPT professionally."

If you're a beginner: get comfortable with the protocol families above, learn the difference between privacy, interception, fraud, and DoS-category findings, and start thinking in terms of severity and attacker prerequisites rather than just "is this exploitable." That shift in thinking is most of what separates a security hobbyist from someone ready for a real engagement.