Ownership Opacity: The Visibility Problem

Every P&A position is held by someone, and the someone matters. To defend against an adversary sitting in a position, a defender has to notice that the position is held by an adversary, and that means knowing who holds it. The Influence and Control Monitoring Imperative is the operational form of that requirement. Without ownership visibility, the imperative cannot be operated.

Ownership visibility is what the current ecosystem does not provide. Digital infrastructure ownership is harder to determine from public information than physical-asset ownership, for reasons that have nothing to do with active adversary deception and everything to do with how the digital supply chain is organized. The conditions exist whether or not any adversary is exploiting them. They set the limit on what a defender can learn from public sources, however much effort goes into looking.

Adversaries work in the room that limit leaves them. Adversarial Asset Cycling is the operational pattern by which they hold position quietly, run through it, and replace under new infrastructure when attribution begins to close. The same cycle runs on every kind of asset the digital supply chain is built from: domains, packages, browser extensions, publisher accounts, update channels.

12.1: Why Ownership Matters for ATG

Every P&A position has owners at several layers at once, and an adversary needs only one of those layers to be unreadable in order to stay hidden. The Influence and Control Monitoring Imperative requires continuous understanding of who influences or controls each piece of infrastructure delivering content, code, and data to a Client Runtime. That understanding is operationally meaningful only if ownership at each layer can be determined. Where ownership cannot be determined, the imperative cannot be operated against the layer in question, and the position can be acquired or transferred without observation.

The cross-surface attack model comes down to one question asked at each layer: who owns this. Following a single request through the infrastructure shows where the layers are. A URL resolves to a host; the host is named by DNS; the DNS is controlled by a domain; the domain is owned by a party. Behind that technical chain sits a chain of owners: a financial owner who can sell it, a corporate owner who can make decisions about how it is operated, an operational owner who can deploy code or change configuration through it, and the personnel who hold the credentials that produce runtime effect. Each link can turn over without any change visible at the link above it. Each layer is a distinct ownership question. Control acquired at any one of them is fungible with control acquired at any other; opacity at any one is sufficient to conceal the holding.

12.2: The Public-Information Floor

Familiar mechanisms of ownership opacity apply with full force to digital infrastructure. WHOIS privacy hides domain registration. Shell companies and nominee ownership obscure corporate beneficiaries. Rules that require a company to name the humans who ultimately own it apply only in the countries that have such rules, and only to the kinds of company those rules cover; an owner outside both is recorded nowhere. A chain of holding companies can be routed through countries chosen because they publish little about who owns what.

What makes the ownership problem distinctive in the ATG context is what is absent rather than what is present. For physical assets, public records let anyone check who holds title to a building, who is registered as controlling a company, and where large sums of money moved, which puts a practical limit on how far ownership can be hidden. For the infrastructure that delivers code to a screen, no records of that kind exist.

• Nothing works like a land registry. Real property has public ownership records, so anyone can look up who holds title to a building and when it last changed hands. Nobody can look up who holds a software namespace, who runs a package repository, or who operates a given CDN, because no public record of any of it is kept. Ownership is whatever the operator chooses to say, and nothing obliges the operator to say anything.
• Nothing works like securities disclosure. A listed company must publish who its major shareholders are and who controls it, so an outsider can check the answer against a filing. Those rules stop at the boundary of the listed company. Most infrastructure that matters for ATG is run by private companies, by subsidiaries bought into larger holding structures, or by individual maintainers, and for all of them the filing that would answer the ownership question is never made.
• Nothing works like anti-money-laundering reporting. A bank has to report transfers above a set threshold, so a large movement of money leaves a trail an investigator can follow afterwards. Selling a CDN, handing a package to a new maintainer, changing who operates a script host, or transferring an extension or plugin publisher account sets off no report to anyone. The change of hands can complete without a single outside party learning that it happened.
• Legal ownership and operational control are not the same thing. Even where the legal owner can be identified, the people holding commit access, publishing credentials, authority over runtime configuration, or platform-administrator rights are frequently not the owners at all. An operator can replace those people without telling anyone outside, and whoever holds the credentials next can change what reaches a user's screen straight away. The ways ownership gets hidden are the same in every industry. What is missing only here is anything on the other side of the ledger: no registry, no filing, no report an outsider could check the claim against. A defender working from public information has far less to work with for a CDN or a package than for a building or a bank account, and that shortfall follows from how the ecosystem is organized rather than from anyone's oversight.

The most important supply chain humanity has ever built has no way of telling anyone when the people controlling it change. The Silent Transfer is that change of hands with no technical signature: control moves through non-technical channels, a company sale, a credential compromise, a maintainer or namespace transfer, a DNS repoint, none of which alter the URL, the hash, or the certificate. Everything a scanner measures stays green while the party deciding what the asset serves becomes someone else. The URL never changed. The person behind it did.

12.3: The Adversarial Asset Cycling Pattern

Adversarial Asset Cycling is a four-stage operational pattern. An adversary acquires an asset, runs a campaign through it, abandons it before sustained attribution can resolve, and re-emerges with new infrastructure that may be related to the abandoned operation but is not formally linked to it. The pattern works because the asset arrives with the trust and the installed dependents already attached, which is the part an adversary cannot manufacture. Building a new CDN, a new package, or a new extension from nothing takes years and rarely makes sense as an attack route. Buying one that already runs in millions of Client Runtimes takes days.

Acquisitions follow established commercial and operational routes. A small company that operates a CDN domain or a script-hosting service can be purchased as a going concern; the domain, the URLs, and the existing

Polyfill.io is the confirmed instance. The cdn.polyfill.io domain changed hands in 2024; existing <script> tags pointing at it continued fetching from the same URL afterward. The infrastructure changed ownership; the trust did not.

Each stage exploits a specific opacity. The acquisition is invisible because no public registry records ownership transfers of script-host domains, package maintainer positions, or publisher accounts, so there is nothing an outsider can look the change up in, the way a land record can be looked up. The operational period is hard to attribute because operational control diverges from legal ownership and the personnel running the asset are not publicly identified. The abandonment closes the trail through any of several routes: the operator can sell the asset to another shell, scrub the malicious version and resume benign operation, dissolve the operating entity, or simply walk away from the credentials. The re-emergence sends an investigator back to the beginning, because the new infrastructure is registered to a different operator and nothing on paper connects it to the abandoned one.

Detection of cycling requires ownership-tracking capabilities the current ecosystem does not provide. Threat-intelligence frameworks track operational tradecraft and infrastructure indicators; they track ownership only as far as public information reaches, which stops well short of the point where cycling happens. The ownership-tracking gap is the structural reason cycling is a viable adversary pattern.

12.4: The Ownership-Tracking Capability Gap

Four ownership-tracking capabilities would close the visibility gap. None is provided at the scale ATG defense requires. Together they would make the Influence and Control Monitoring Imperative operable.

• Ownership-state monitoring: continuous monitoring of who currently owns and operates each piece of ATG-relevant infrastructure: CDN operators, package maintainers, script hosts, AI model repositories, extension publishers, plugin marketplace publishers, mobile-app developer accounts, OTA channel operators. Today's threat-intelligence tools do not treat ownership as a signal in its own right. Where ownership shows up at all, it shows up as background detail on one incident, not as something recorded about the asset and kept current.
• Ownership-change detection: identification of ownership transitions (commercial acquisition, maintainer transfer, namespace transfer, infrastructure-operator handoff, publisher-account transfer) and propagation of those transitions to the dependent applications. No tool today tells an application that something it depends on has changed hands: a dependency carries a name and a version, and nothing at all about who now controls it.
• Operational-control inference: inference of operational control from observable signals (commit patterns, release cadence, infrastructure footprint, behavioral changes) when legal ownership cannot be determined. Today's tools keep these signals apart from any question about ownership, so nobody ends up with one answer to who is actually in control of the asset.
• Cross-asset ownership correlation: correlation of ownership signals across multiple infrastructure assets to identify common control, asset cycling, and adversary infrastructure clusters. Current tooling treats each asset in isolation; cycling that operates across assets cannot be detected without correlating ownership signals across them. Across asset types, the gap is the same. The infrastructure that delivers to a Client Runtime spans browser-side providers (CDNs, script hosts, ad networks, analytics), mobile-side providers (app stores, OTA channels, in-app extension hosts), desktop-side providers (distributors of desktop applications built on a web runtime such as Electron, plugin marketplaces), vehicle and IoT providers (OEM update channels, infotainment app stores), and AI providers (model repositories and inference endpoints, the addresses an application calls to get an answer from a model). The four capabilities apply uniformly. The defender that lacks them in one asset class lacks them everywhere the asset class touches a Client Runtime.

With the four capabilities in place, the visibility problem closes. Without them, the Influence and Control Monitoring Imperative names a requirement no defender can meet.