A phone number is the most boring string of digits in your life right up until the moment it becomes the most dangerous. You hand it out for pizza delivery, two-factor codes, dentist appointments — and somewhere in a graph database, that same number is quietly stitching together your email addresses, your social profiles, your carrier location, and accounts you forgot you even had. That gap between what a phone number feels like and what it actually is as an OSINT entity — that's what Daniel wants us to walk through today.
He's asking for the full pipeline. Start with proper formatting — the E.164 standard, international dialing codes, why normalization isn't just "remove the dashes." Then move into what Maltego transforms actually do when you feed them a clean number. Then the real escalation: what happens when you start combining identifiers — phone plus email, phone plus phone plus email — and how each permutation unlocks a different tier of discovery.
We're basically tracing a phone number from "here's a string" to "here's a map of someone's digital life." And the thing Daniel's getting at with those permutations — single, pair, triple — is that the power isn't really in any one transform. It's in what the graph lets you see when two or three identifiers start pulling in the same direction.
And we should be upfront about the limits too. A prepaid burner on an MVNO like Tracfone will dead-end almost immediately, and that dead end is itself intelligence — it tells you the subject is operational security conscious. But we'll get there. The arc I want to trace is: normalization first, then transform mechanics, then the permutation strategy that turns a sparse graph into a high-confidence identity map.
Where do we start — with the format, or with why the format breaks so easily?
Start with the format, because the format is where most investigations silently fail. 164 is the international standard — it looks like plus sign, country code, then the national significant number, maximum fifteen digits total. Country codes run from one for the US and Canada all the way up to eight-five-five for Cambodia, with over two hundred assigned codes in between. That plus sign at the front isn't decorative — it's a placeholder that tells the system "whatever your local exit code is, insert it here.
The plus sign is doing real work, not just looking official.
And here's why this matters for graph systems — Maltego, i2, Neo4j, any of them — they treat phone numbers as entities that must match exactly. If you've got one node with plus-four-four-twenty and another with zero-two-zero, the graph sees two completely different entities. No join happens. No edge gets drawn. You spend three hours wondering why your target has no social media links when the answer is that you normalized one number and not the other.
The graph fails silently. That's the part that would keep me up at night — you don't get an error message, you just get an empty result and assume there's nothing to find.
That's exactly the trap. And there are three normalization pitfalls that cause most of these silent failures. First, trunk prefixes — the leading zero that many countries use for domestic dialing. You drop it in international format. A UK number that's zero-twenty locally becomes plus-four-four-twenty in E.If you leave that zero in, the graph breaks. Second, extensions — E.164 doesn't define them at all. So if you've got a number with an extension appended, you either strip it into a separate property or tag it as metadata, but you cannot leave it glued to the main number. Third, short codes — those four or five digit service numbers — they're not E.164 at all and need entirely different handling.
What actually makes a phone number a graph entity rather than just a string?
A graph entity has identity — it's not just the digits, it's the assertion that this specific sequence refers to one specific thing in the world, and that thing has relationships. When Maltego creates a PhoneNumber entity, it's saying "this is a node that can connect to Person nodes, Email nodes, Location nodes.164 normalization is what gives it that stable identity. Without it, you've just got a string that happens to look like digits, and strings don't form edges — entities do.
The normalization isn't housekeeping. It's what turns data into something the graph can actually reason about.
With that normalization foundation laid, let's talk about what happens when you actually feed that clean E.164 number into Maltego's transform engine. The Transform Hub, as of mid-twenty-twenty-six, gives you a whole suite of phone number transforms organized by category. You've got reverse lookup services — Whitepages, SpyDialer, Truecaller. Social media discovery — Facebook, Telegram, WhatsApp all have transforms that check whether a number is registered with the platform. Then carrier and geolocation transforms that tell you which mobile network owns the number and roughly where it lives.
Each of these is a separate API call, right? You're not running one transform — you're running a chain of them.
Right, and understanding the execution model matters here. When you right-click a PhoneNumber entity in Maltego and select a transform, what actually happens is the client sends that normalized E.164 string to a transform server — either Maltego's own or a third-party provider's. That server hits the relevant API endpoint, receives structured data back, parses it, and returns new entities to your graph. Each new entity — a Person, an Email, a SocialMedia profile, a Location — gets created as a node with an edge connecting it back to the original phone number. And those edges are weighted. A direct carrier lookup returns a high-confidence edge. A crowdsourced Truecaller tag returns a lower-confidence edge.
The graph is already encoding uncertainty before you even start interpreting it.
And that's the difference between a graph that helps and a graph that lies to you. Now, the most common discovery workflow — the one that probably gets run a thousand times a day by investigators — is the two-hop phone-to-email chain. You start with a phone entity. You run a social media transform — say, the Facebook transform — and it returns a profile. That profile is now a new node linked to your phone. Then you run a profile-to-email transform on that Facebook node, and if the profile's email is publicly visible or recoverable through the platform's API, you get an Email entity. Two hops, thirty seconds, and you've gone from a ten-digit string to someone's primary inbox.
That's the SpyDialer voicemail trick you mentioned earlier.
That's the classic. You feed plus-one-five-five-five-one-two-three-four-five-six-seven into SpyDialer. It doesn't look up a database — it actually calls the number's voicemail box and captures the greeting. If the greeting says "You've reached John Smith, leave a message," you've just extracted a name from infrastructure, not from a data broker. From there, Facebook transform on "John Smith" plus the city from the area code, and you've got a profile. Then email transform on the profile, and suddenly you're looking at john dot smith at gmail dot com. All from a phone number and thirty seconds of automated calling.
Which is both impressive and slightly horrifying.
The two emotions that best describe modern OSINT, honestly. But let me talk about the transforms that don't get enough attention, because everyone fixates on the social media ones. Carrier lookup is quietly one of the most valuable. It tells you whether the number belongs to a mobile network operator — an MNO like Verizon or T-Mobile — or a mobile virtual network operator, an MVNO like Tracfone or Mint Mobile. That distinction matters enormously. MNO numbers are typically postpaid, contract-linked, tied to a real identity verified at purchase. MVNO numbers are disproportionately prepaid, bought with cash, and often used specifically because they're harder to trace.
The carrier type is already telling you something about the target's operational habits before you've found a single social profile.
And then there's HLR lookup — Home Location Register. This is a query directly to the telecom infrastructure that tells you three things: is the number currently active, has it been ported from one carrier to another, and which MNO or MVNO currently owns it. Porting is interesting because a number that's been ported multiple times often indicates someone who's been with several carriers and may have left unpaid bills or wanted to shake a previous identity association.
CNAM — Caller ID name — I've heard mixed things about how useful that actually is.
CNAM is the wildcard. It returns the name registered with the carrier for that number, but here's the problem: carriers update CNAM databases infrequently, sometimes only when a number changes hands. So you might run a CNAM lookup and get a name from three account holders ago. It's often stale. But occasionally — and this is why you always run it — you get a current, accurate name that opens up everything else. I've seen investigations where every other transform failed and CNAM was the one that cracked it.
It's unreliable enough to be dangerous but too valuable to skip.
That's the tension. And it leads to the bigger point about transform reliability overall. The free transforms — Truecaller, SpyDialer, the basic social media checks — they're working with crowdsourced or opt-in data. People tag numbers in Truecaller as "spam" or "John from accounting," and that data is only as good as the crowd. Accuracy runs maybe sixty to seventy percent. The paid transforms — services like TLOxp or IDI — they're accessing actual carrier records, credit headers, utility databases. For active numbers, you're looking at ninety percent plus accuracy. But they're expensive, they require credentials, and they leave audit trails.
The free-versus-paid decision isn't just about budget — it's about what kind of investigation you're running and whether you can afford to be wrong.
Whether you can afford to be detected. Every paid lookup generates a log somewhere. Free transforms are noisier but lower-profile. That calculus changes depending on whether you're doing corporate due diligence or something more sensitive. But here's the thing I want to land before we move on — the counter-example that keeps investigators humble. You take a prepaid burner from Tracfone, run every transform in the hub. Carrier lookup returns MVNO, prepaid, no subscriber info. HLR says active but unported. Social media transforms return nothing — no Facebook, no Telegram, no WhatsApp linked to that number. CNAM is blank. SpyDialer gets a generic greeting. The graph has exactly one node — the phone number — and zero edges.
Which is a failure, but also not a failure.
That empty graph is intelligence. It tells you whoever owns this number knew exactly what they were doing. They chose a carrier that doesn't verify identity, they never linked the number to any platform, and they kept the voicemail generic. That's not a dead end — that's a profile. It just happens to be a profile defined by absence.
We've just seen what a single number can and can't do — and what the failures tell you. But Daniel's real question is about what happens when you stop treating the phone number as a solo act and start pairing it with other identifiers. The permutation framework he laid out is single, pair, triple — and each step isn't just adding data, it's changing what the graph can resolve.
Right, and the jump from single to pair is where the graph stops being a collection of hints and starts being an identity map. With a single phone number, even a well-connected one, you're typically looking at two to five nodes — carrier info, geolocation down to the area code or city level, maybe one or two social media accounts if the number is publicly linked. And the edges are mostly low confidence because you're working off one anchor point. You can't cross-reference anything.
The single-number graph is basically a sketch. You see outlines, not connections.
Add an email address, and suddenly you've got a second anchor. Now you can run what I think of as the overlap scan — you take every social media account linked to the phone, every account linked to the email, and you look for intersections. A Facebook profile that appears in both lists is not just a lead anymore — it's a high-confidence identity node, because two independent identifiers converge on the same entity.
That convergence is what the graph is actually for. It's not the individual transforms that matter — it's the corroboration.
That's the whole game. And there's a second thing the pair unlocks that doesn't get talked about enough: password reset flow analysis. Once you have both a phone and an email, you can test which identifier can reset which account. If the phone can reset the Gmail, and the Gmail can reset the Facebook, you've just mapped the recovery chain. That tells you which identifier is the keystone — the one that, if compromised, unlocks everything else.
The pair doesn't just tell you who someone is — it tells you how their security architecture works.
That's before we even get to the triple. When you add a second phone number — could be a mobile plus a landline, or two mobiles — the graph resolution jumps dramatically. The classic pattern: a mobile number links to WhatsApp and Telegram, a work landline links to LinkedIn and corporate directories, and the email stitches both worlds together. Now you're not looking at two to five nodes — you're looking at fifteen to thirty plus, with multiple corroborating edges reinforcing each other.
This is where the shadow accounts start appearing.
This is the part I find genuinely fascinating. Here's a real pattern investigators see all the time: a subject uses their primary email address with a secondary phone number to create a Facebook account they think is anonymous. Different name, different phone, no obvious link. But the email is the same. And that email appears in the contact lists associated with both phone numbers — maybe through a WhatsApp backup, maybe through a Google Contacts sync. The triple permutation exposes the connection because the email bridges two phone numbers that were never supposed to touch.
The shadow account isn't hidden by a lack of data — it's hidden by a surplus of it, and the triple is what cuts through the noise.
Let me give you a concrete case. Investigator starts with a target's mobile, plus-one-five-five-five-nine-eight-seven-six-five-four-three. Runs the Telegram transform, finds a username — nothing too revealing. Adds the target's known email, target at protonmail dot com. Now the Telegram account shows up linked to that email too, which confirms it. But here's the kicker: the email also surfaces a Twitter account from twenty-sixteen — eight years old, completely dormant, registered with a different phone number the target hasn't used in years. That Twitter account has a bio with a real name and a link to an old blog. The triple permutation didn't just find new data — it found historical data the target probably forgot existed.
Which is the thing about digital exhaust — it never really goes away, it just gets harder to find.
Here's the comparison that really drives the point home. Take a prepaid SIM — single number, zero transforms return anything useful. Dead end, like we talked about. Now add a Google Voice number that forwards to that prepaid SIM. The Voice number isn't a real mobile — it's a VoIP overlay — but it's tied to a Google account. Run transforms on the Voice number, and you find that Google account, which has a recovery email. Run transforms on the recovery email, and suddenly you've got social profiles, a real name, maybe a secondary mobile. The prepaid anonymity didn't break because of the prepaid number — it broke because the second phone number created a bridge the target didn't know was there.
The triple isn't just additive — it's multiplicative in a specific way. But I want to push on the limits, because Daniel asked about the discovery curve. You mentioned the jump from single to pair yields something like three hundred percent more discoverable nodes. What about pair to triple?
That's where the diminishing returns kick in. Pair to triple typically adds about fifty percent more nodes — sometimes less. The third identifier isn't opening up vast new territories the way the second one did. What it's doing is adding confidence. Those fifteen to thirty nodes I mentioned? The triple doesn't necessarily give you forty-five — it gives you the same twenty-five, but now half of them have two or three corroborating edges instead of one.
The real value of the triple isn't breadth — it's certainty.
And that certainty matters enormously when you're building a case, writing a report, or making a decision based on what the graph shows you. A single edge between a phone and a Facebook profile is suggestive. Two edges — phone to profile and email to the same profile — is probable. Three edges — two phones and an email all pointing to the same profile — that's conclusive enough to act on. The triple is what turns an investigative lead into an investigative finding.
If the triple permutation is the gold standard, what does that mean for how you actually run an investigation tomorrow morning? Because I think Daniel's asking for the practical workflow, not just the theory.
First rule — and I cannot stress this enough — normalize to E.164 before you run a single transform. Build a preprocessing step that strips spaces, dashes, parentheses, and trunk prefixes. If you feed plus-one-five-five-five-one-two-three-four-five-six-seven into one transform and one-five-five-five-one-two-three-four-five-six-seven into another, you've just created two different entities in your graph and you won't know it until you wonder why nothing connects.
The preprocessing is basically a gatekeeper. Nothing hits the transform engine until it passes through that step.
Second rule, and this is the one that saves hours: if a single phone number returns nothing after three transforms, stop. Do not keep throwing transforms at it. You're burning time and API calls. Pivot to finding a second identifier — an email, a username, a second phone number — and then come back. The graph doesn't reward persistence with a single anchor. It rewards having two.
That's a hard discipline to maintain when you're staring at an empty graph and thinking "maybe just one more transform.
It is, and every investigator learns it the hard way at least once. Third thing — for listeners who are building their own graph systems rather than using Maltego — implement fuzzy matching on the last seven digits of the local number when country codes differ. Here's why: someone moves from the UK to the US, keeps the same local number but changes the country code from plus-four-four to plus-one. Without fuzzy matching, your graph sees two unrelated entities. With it, you catch the international variation.
You're matching on the part of the number that's most likely to stay stable across borders.
The last seven digits are the personal part. Country codes and area codes change — those seven digits tend to follow the person. Now, the warning I have to include here: phone number OSINT is increasingly regulated. The FCC ruling on data broker consent that came down last year restricted access to several US lookup services that were previously wide open. And the EU's updated ePrivacy Directive has clamped down on automated number lookups without explicit consent. Some transforms that worked in twenty-twenty-four now return redacted data or nothing at all.
The legal landscape is shrinking the available data even as the techniques are getting more sophisticated.
That's not going to reverse. Always check the legal status of your data sources before you build a workflow around them. What's legal in one jurisdiction might not be in another, and what worked last year might be noncompliant today. The technique is only as good as your authorization to use it.
Even as we refine these workflows, there's a bigger question looming about whether phone numbers will remain useful OSINT entities at all. Because the whole model we've just described — carrier lookups, HLR queries, CNAM — it all depends on the number being tied to a physical SIM issued by a carrier that keeps records. What happens when the number is just a virtual overlay?
This is what keeps me up at night, in a nerdy way. Google Voice, Skype numbers, Signal's secondary number feature — these aren't tied to physical SIMs in the traditional sense. There's no HLR to query because there's no home location register. The carrier-level data that powers the most reliable transforms simply doesn't exist for these numbers. You run a carrier lookup on a Google Voice number and you get — what? Google isn't an MNO or an MVNO in the traditional sense.
The graph dead-ends not because the target is careful, but because the infrastructure itself provides nothing to query.
And the trend is accelerating. eSIMs mean you can provision a new number in seconds without ever touching a physical card. Apps like Burner and Hushed let you generate ephemeral numbers that exist for hours or days and then evaporate. These aren't edge cases anymore — they're becoming the default for anyone with even mild privacy awareness.
If the phone number stops being a stable anchor, what replaces it?
I think we're already seeing the shift. The focus is moving from the number itself to the device fingerprint and the IP metadata associated with number registration. When someone activates a Burner number, the app still runs on a physical device with an advertising ID, an IP address, a set of installed apps, a pattern of usage hours. That device fingerprint becomes the new anchor — it's harder to change than a phone number, and it leaves traces that the number alone doesn't.
The graph entity of the future might not be a phone number at all — it might be a device hash.
Within three to five years, I'd bet the phone number becomes a secondary entity in most OSINT graphs — useful for correlation but not the primary anchor. The primary anchor will be whatever stable identifier survives across number changes: the device, the account ecosystem, the behavioral pattern. We're watching that foundation erode in real time.
The people who most need to be found are the first ones to adopt the tools that make them unfindable.
Which means the techniques we've walked through today are simultaneously at their peak usefulness and already on the way out. Use them while they work, but don't build your entire investigative methodology on an entity type that's actively being hollowed out from underneath.
Now — Hilbert's daily fun fact.
Hilbert: In the late sixteen-hundreds, a British naturalist on New Zealand's South Island documented a species of epiphytic fern that only germinated on the north-facing side of its host tree. The anomaly was that seedlings on the south-facing side consistently died within three weeks, even when manually transplanted there with identical moisture and light conditions. No explanation was ever recorded.
The ferns had a preference and simply refused to negotiate.
A plant with boundaries. I respect that.
Thanks to our producer Hilbert Flumingtop for that contribution. This has been My Weird Prompts. If you want to send us your own questions — or tell us we're wrong about the future of phone numbers — email the show at show at my weird prompts dot com.
Until next time.
