> ## Content Index
> Fetch the complete content index at: https://theattacksurface.blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# False Links in the Pivot Graph: What Domain Data Can and Cannot Prove
- URL: https://theattacksurface.blog/false-links-in-the-pivot-graph/
- Published: 2026-08-11T13:00:00.000Z
- Updated: 2026-08-11T13:00:00.000Z
- Description: A dozen domains sharing a certificate, an IP range, and a registration date look like a threat actor's infrastructure. Usually they are a parking company's inventory. Here is the tenant versus landlord test that separates a real cluster from a coincidence, run against two live examples.
- Author: Kish Galappatti
- Tags: Threat Intelligence, Security Operations, Analysis

Pull the registration data on any suspicious domain and you will find company. It shares a certificate with ninety others. It sits in the same IP range as a hundred more. A cluster of them was registered on the same morning. The instinct is to draw edges between them and call it an actor's infrastructure. Most of the time you have just mapped a parking company's inventory.

The whole discipline of domain pivoting comes down to one question you have to ask of every link you find: does this edge survive shared infrastructure, or did shared infrastructure create it? Call it the tenant versus landlord test. Two shops in the same mall share a landlord, a postcode, and a parking lot. That tells you nothing about whether they have the same owner. A pivot is only worth drawing if it points to the tenant, not the building.

This post runs a single pivot suite against two real domain sets. The first looks coordinated and is not. The second is genuine nation-state infrastructure. The method is identical. Only the verdict changes, and it changes because of which links survive the test.

## The signals, ranked by what they actually prove

Every piece of domain data falls into one of two buckets.

**Landlord-level signals** are produced by a shared provider. They cluster domains that have nothing to do with each other:

- Shared parking or CDN IP. One Cloudflare or Above.com address fronts thousands of unrelated domains.
- A bulk certificate. Hosting and parking providers batch dozens of unrelated customer domains into a single Let's Encrypt certificate. Co-appearance means same issuer workflow, not same owner.
- A mega-registrar, a popular TLD, a privacy-proxy registrant. All shared by millions.

**Tenant-level signals** survive shared infrastructure because the operator, not the provider, created them:

- A reused web analytics or ad ID (Google Analytics, AdSense, a Facebook Pixel).
- A shared TLS public key, or a distinctive favicon or page hash on dedicated infrastructure.
- A platform verification token in a TXT record, which ties a domain to a specific organizational account.
- Self-hosted nameservers, or a shared block of dedicated hosting IPs that a set of domains all point to at once.
- A synchronized event: several domains pivoting to the same new IP on the same day.

The failure mode that produces bad threat intel is treating a landlord-level signal as if it were tenant-level. The two examples below are the same mistake and its correction.

## Case one: the cluster that dissolved

Start with a domain squatting on a well-known name: `libsoftiktok.us`. WHOIS says it was created on 2026-07-07, registered through Dynadot behind a privacy proxy, and parked on Above.com nameservers. Certificate transparency shows it was bundled into a Let's Encrypt certificate ninety minutes after registration, alongside roughly ninety other domains. Pull the three bulk certificates it appears in and you have a candidate cluster of about seventy registrable domains.

Date every one of them and the cluster starts to fall apart. The single largest cohort, twenty-seven domains, was registered on 2025-07-06, a full year earlier. Registration dates scatter across all of 2025 and into 2024\. Only eleven domains, including `libsoftiktok.us`, share the 2026-07-07 date. That subset is the only thing that still looks like a coordinated batch, so it is the only thing worth pivoting on.

Run the tenant-level checks against those eleven:

- **DNS composition is byte-identical.** Same Above.com nameservers, the same `park-mx.above.com` mail record, the same SOA serial, the same odd private-IPv6 SPF record on every one. That uniformity is not a fingerprint of an operator. It is the default template Above.com stamps on everything it parks.
- **The shared favicon was a red herring.** All eleven serve an identical 94-byte favicon with the same hash. A shared favicon hash is normally a strong tenant-level link. This one, on inspection, is a 403 Forbidden error page the server returns for any `/favicon.ico` request. The page body is the standard Above.com `forsale.min.js` loader. Always look at what you hashed.
- **Passive DNS tells the real story.** Historical resolution data sees back through the current parking veneer to what each domain used to be, and each one lived a completely separate life. `tanzkroll-amtegernsee.info` resolved to Deutsche Telekom space from 2015 to 2021, a legitimate German event site. `serafine.shop` was a Shopify store in 2020\. `oremeca.shop` sat on AWS Tokyo. `quizt.live` was on European hosting. Different hosts, different countries, first-seen dates spanning 2015 to 2024.

There is no operator who owned a German dance-festival site, a Shopify store, and a brand typosquat across four countries and nine years. These are unrelated expired domains that dropped and were caught by the same drop-catch service on the same day, then dropped into for-sale parking. The one thing they share is the company that re-registered them. "Registered on 2026-07-07" never meant an actor created them. It meant they expired from their previous owners and got caught that morning.

Every link in this cluster was landlord-level. The verdict is monetization, not a campaign, and passive DNS is the pivot that proved the negative the certificates and WHOIS could not.

## Case two: the cluster that held

Now run the same suite against domains that genuinely were an actor's infrastructure: the second-stage command-and-control domains from the SolarWinds SUNBURST campaign, publicly attributed to APT29 and Russia's SVR. `avsvmcloud.com` was the primary algorithmic C2\. `deftsecurity.com`, `thedoccloud.com`, and `freescanonline.com` were among the secondary domains published in FireEye's indicator set. These are burned, sinkholed, and safe to examine, which is exactly why they make a clean teaching example.

The same checks that came up empty on the parking cohort light up here:

- **Registration is aged and staggered, not batched.** `thedoccloud.com` was created in 2013, `freescanonline.com` in 2014, `deftsecurity.com` in 2019, all on ordinary registrars with no privacy-parking. This is the documented APT29 habit of acquiring aged, benign-looking domains patiently over years. It is the opposite of a same-day drop-catch.
- **The domains share an exact dedicated IP set, and their histories converge.** On 2021-01-04, `deftsecurity.com`, `thedoccloud.com`, and `freescanonline.com` all resolved to the identical eight-address block of LeaseWeb IPs (`5.79.71.205`, `5.79.71.225`, `85.17.31.82`, `85.17.31.122`, `178.162.203.202/.211/.226`, `178.162.217.107`). In the parking case, "shared IP" meant a common landlord's range with divergent per-domain histories. Here it is the same precise dedicated set, and the histories run together rather than apart.
- **There is a synchronized timeline event.** All four domains show the address `52.17.197.206` appearing at once on 2020-12-23, the public takedown date, and `avsvmcloud.com` carries `20.140.0.1`, the Microsoft sinkhole. A coordinated pivot across an entire set on a single day is a cluster signature. The parking cohort had no shared event of any kind.
- **Threat-research attention is saturated.** Public URL scan counts run to 5,942 for `avsvmcloud.com` and into the hundreds for the others, tagged by automated CTI and sandbox pipelines. The parking domains had between zero and eight scans and no tags. Scan volume is itself a signal.

Two honest caveats, both of which are lessons in their own right. First, much of the infrastructure these domains point to today belongs to defenders, not the actor. The domains are held and sinkholed by security organizations and renewed out to 2027, so the identical present-day IP set proves coordinated control by whoever holds them now, which is the sinkhole operator. The actor-era signal is the January 2021 shared block and the December 2020 synchronized pivot, not the current resolution. Date-bound every linkage claim you make. Second, certificate transparency was silent across this entire set. SUNBURST used HTTP and DNS-based C2 rather than much TLS, so the pivot that is richest in other investigations produced nothing here. No single signal is universal, which is the whole reason you run the full suite.

## The two verdicts, side by side

| Signal          | Parking cohort                           | SUNBURST cluster                               |
| --------------- | ---------------------------------------- | ---------------------------------------------- |
| Registration    | fresh drop-catch, one day, privacy proxy | aged 2013 to 2019, real registrars, staggered  |
| Cross-domain IP | shared provider range, histories diverge | shared exact dedicated set, histories converge |
| Timeline        | no shared event                          | synchronized pivot on the takedown date        |
| Passive DNS     | separate lives, later co-parked          | converge together on one C2 block              |
| Threat feeds    | 0 to 8 scans, no tags                    | hundreds to thousands of scans, CTI tags       |
| Current status  | listed for sale                          | defensively held and sinkholed                 |

Same pivot suite, opposite results. On the monetization batch every apparent link was landlord-level, there was no shared event, and no feed had ever cared. On the real infrastructure the links were tenant-level, the timeline was coordinated, the acquisition was strategic, and the research world had already noticed.

## What to take to your next investigation

- **Date everything before you cluster.** Registration and certificate timestamps are cheap and they collapse most false structure on their own. Half of apparent coordination is temporal coincidence at a shared provider.
- **Classify the infrastructure before you weaponize it.** A parking loader is not a C2\. Confirm a domain is doing something before you build a threat model around it.
- **Weight every edge by uniqueness.** A shared parking IP, a bulk certificate, and a mega-registrar are the building, not the tenant. A reused analytics ID, a dedicated IP set, a verification token, and a synchronized pivot are the tenant.
- **Keep proxy-declared data and owner data in separate columns.** The privacy service's country is not the operator's country.
- **Passive DNS is the pivot that sees through parking.** It is the one source that reveals what a domain was before its current veneer, and it is available free, with real coverage, without a paid subscription.
- **Inspect what you hashed and date-bound what you link.** A shared hash can be a shared error page. A shared IP can be a sinkhole a defender stood up years after the fact.

None of these signals attributes an attack on its own. Together, and only when the links survive the tenant versus landlord test, they turn a pile of domains into a defensible assessment. The rest of the time they turn a pile of domains into a smaller, better-understood pile of domains, which is also a result worth having.

*Sources: FireEye/Mandiant SUNBURST indicator set and campaign analysis; historical resolution data via public passive DNS; certificate data via certificate transparency logs. Domain and IP details reflect data observed at the time of writing and are provided for defensive research.*