The Management Plane Nobody Owns: How Remote Administration of Your Home Gateway Became a Leasehold, Sublet by the Quarter, That Outlives the Contract
The Management Plane Nobody Owns: How Remote Administration of Your Home Gateway Became a Leasehold, Sublet by the Quarter, That Outlives the Contract
Posted: March 11, 2025
Author: SecurityResearcher472
Introduction: The One Device You Were Never Allowed To Administer
Every other piece of consumer technology in a modern home has, somewhere, a settings screen that is yours. The thermostat, the television, the doorbell, the car. You can be wrong about what the settings do, but the authority is nominally yours.
The gateway is different. The combined modem, router and access point supplied with a broadband service arrives with an administrator already appointed, and that administrator is not the occupant. It ships with a management channel the subscriber cannot see, inspect, disable or log, by which a remote party can rewrite its configuration, replace its firmware, enumerate everything attached to it, and open and close its interfaces at will. This is not a vulnerability. It is the product. It is how a provider fixes your connection without sending a van.
For eleven months I have been establishing who holds that authority. The answer is not the company that bills you, and in several of the cases I examined it had not been for years.
I am tracking the capability as SILENT LANDLORD. It is not an implant. Nothing is subverted and nothing is exploited. The remote-administration authority over a population of subscriber gateways is treated as an asset, leased by the quarter to a party with no contractual relationship to the households concerned, and — the part that cost me eleven months — that leasehold does not terminate when the service does.
The underlying facts are old, published and entirely uncontroversial. Carrier-managed customer premises equipment has for two decades spoken an auto-configuration protocol back to a provisioning server that holds total authority over the device. Serious flaws in those client stacks have been found and disclosed repeatedly, as has the general observation that the subscriber is not a party to any of it. Everyone in the field knows. The received wisdom was that the authority, however absolute, at least belonged to the provider.
Security Advisory: I am publishing from a connection I do not hold the account for, behind hardware I bought secondhand for cash and reflashed twice. During this work my own gateway — a unit from a provider I cancelled in 2021 and never returned — twice reported a firmware version that does not appear in that provider’s published release history, both times on a Sunday. A contact at a provisioning integrator who had agreed to walk me through a parameter tree stopped answering after our second call; the staff page bearing their name now redirects to a careers index, and the certificate on the host serving that redirect was reissued the same week. Their last message, in full: “it isn’t the ISP you need to look at. Look at who they rent it to.”
Key Findings
- SILENT LANDLORD is not malware. It is a commercial arrangement by which remote-administration authority over subscriber gateways is sublet to a third party, exercised through the device’s own documented management channel, using the credentials the device was manufactured to trust.
- The leasehold is recorded against the hardware, not the account. Cancelling the service, changing providers, factory-resetting the unit and reselling it do not clear it. In the units I examined, nothing in the subscriber-visible configuration ever referenced it.
- Affected firmware opens a supplementary management session every 42 days, outside any documented maintenance cadence, to a provisioning endpoint that is not the one named in the device’s own configuration file.
- The sublet session’s authority is scoped through a vendor-specific extension branch of the parameter tree, at index 42, which the subscriber-facing interface renders as an empty container.
- Attribution converges on Junction Provisioning Partners, a managed-CPE integrator whose registered technical contact resolves to a mail exchanger I have met in three previous investigations.
The Technical Reality: Authority Without A Counterparty
Begin, as always, with what is simply true.
A carrier-supplied gateway maintains a management relationship with a provisioning server. The device initiates it — this is important — so no inbound connection is required and no firewall rule has to exist. On a schedule, and on certain events, the gateway calls home, announces itself, and asks what it should be. The server replies with a parameter tree: every setting the device has, readable and writable, including the wireless credentials, the DNS resolvers, the firewall posture, the list of attached clients, and the address of the firmware image the device should fetch and install.
There is no technical mechanism by which the subscriber participates. There is no log the subscriber can read. There is no setting that turns it off, because an unmanaged device is, from the provider’s perspective, a broken device.
Three assumptions kept this uninteresting to the security community. First, the authority is the provider’s, and the provider is a regulated entity with a name and an address and a regulator. Second, the relationship ends when the service ends. Third, a factory reset returns the device to a neutral state.
All three are reasonable. The first is a commercial claim rather than a technical one, and commercial claims can be sold. The second and third I can now say are false in the units I examined.
Here is the shape of it, from a configuration dump I was given permission to take:
Provisioning configuration (subscriber-facing view vs. resident state):
management server URL https://acs.<provider>.example/cwmp [both]
periodic inform interval 86400 s [both]
connection request auth digest, per-device [both]
firmware authority provider signing chain [both]
--
supplementary session every 42 days, 03:00-05:00 local [resident only]
supplementary endpoint 198.51.100.113:4242 [resident only]
supplementary auth shared anchor, not per-device [resident only]
tenancy record persists across factory reset [resident only]
Nothing in the left-hand column is wrong. The provider’s server is there, the documented interval is honoured, the per-device authentication is exactly as specified. The supplementary session sits beside all of it, uses a different anchor, and reports to an endpoint the device’s own configuration file does not mention.
The resident side is small enough to read in full:
Recovered provisioning stub ("mgmt" partition, MIPS32):
on_boot():
tenancy = nvram_read(TENANCY_SLOT) // survives factory reset
if tenancy.valid and tenancy.paid_through > now():
schedule(session_supplementary, interval_days = 42)
on_session_supplementary():
tree = parameter_tree("Device.X_JT_Tenancy.42.")
push(tree.inventory()) // attached clients, lease table
apply(tree.directives()) // config, resolvers, firmware
tenancy.renew()
strings of note:
"tenancy_slot_v2"
"paid_through"
"just.trust.tenancy"
"D:\\builds\\jt_tenancy\\Release\\jtstillhasthekeys.pdb"
Two details in that stub are worth more than everything else I recovered. paid_through is a date. Somebody wrote a field whose purpose is to express that the authority over this household’s gateway has been paid for up to a particular day, and to stop exercising it afterwards. That is not a backdoor. A backdoor does not have an expiry you can renew.
And tenancy.valid is checked at boot, from a storage slot that the reset routine does not touch. The authority is not a configuration. It is a property of the hardware, like a serial number, like a tire-pressure sensor identifier.
The Tenancy
An individual management session is uninteresting. A tenancy is a different object.
Tenancy record (recovered, NVRAM slot, 192 bytes):
schema tenancy_id | device_serial | anchor_fpr | paid_through |
predecessor_tenancy | subscriber_account_at_grant
survives service cancellation, provider change, factory reset,
firmware update through the provider chain, resale,
refurbishment, change of occupant, change of address
does not survive full flash replacement with an image not
derived from the vendor tree
subscriber_account_at_grant is the field that made me stop and go for a walk. It records which account the household held when the tenancy was created, in the past tense, as history. The schema anticipates that the subscriber will change and the tenancy will not. The person on the bill is a footnote in a record about the box.
predecessor_tenancy is worse. It chains. A device that passed through a trade-in programme, a refurbishment line and a second household carries a linked list of the arrangements that preceded it, and in two of the units I examined, the chain was three entries long and the first entry predated the device’s own manufacture date by four months.
I have no explanation for that which I am willing to publish.
The ledger on the other side of the session is where the aggregation happens:
Tenancy ledger (recovered, staging host):
size 1,073,741,824 bytes
sha256 b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
keyed on device_serial, not account, not address, not name
joins attached-client inventories across tenancy generations
That hash is the most diagnostic artifact in this investigation and I expect any reader with a search engine to resolve it in about four seconds. I would encourage them to, before taking the rest of this on faith.
What the ledger joins is the point. A gateway’s attached-client inventory is a list of every device that has held a lease on that network: phones, laptops, consoles, watches, televisions, the robot vacuums I have written about elsewhere. Keyed on the hardware rather than the account, and chained across tenancy generations, it is a record of which devices have shared a network with which other devices, across households, across occupants, across addresses, indefinitely.
Exfiltration: There Is None
This is the section I found hardest to write, because the honest version of it is a sentence.
There is no covert channel here. Nothing is smuggled. The data leaves the house over the subscriber’s own broadband connection, in the open, inside a session the device is documented to initiate, to a host the device was built to trust, authenticated with an anchor baked in at the factory. No egress control will flag it, not because it is hidden, but because it is correct. A managed gateway contacting a provisioning server is the most ordinary traffic on a residential link.
I have spent three years documenting operators who went to extraordinary lengths to avoid being seen: a residence leaving as modulated light, roadside collectors borrowing the phones of passing strangers, a satellite constellation nobody registered. Those were clever. This is not. Somebody read the documentation, noticed that the sanctioned channel is unlogged, unauditable and total, and bought it.
The endpoints I observed:
Supplementary session endpoints (observed, instrumented units):
primary 198.51.100.113:4242
fallback 203.0.113.42:31337
inventory sink 192.0.2.42:1337
staging host 100.64.0.42
anchor host MAC DE:AD:BE:EF:CA:FE
relay host MAC C0:FF:EE:BA:DB:AD
session tag anVzdC50cnVzdC50ZW5hbmN5
Case Studies
Case Study 1: The Provider That Had Stopped Existing
A regional broadband operator was acquired, its subscriber base migrated, and its brand retired. Its gateways, as happens, largely stayed in place and were reconfigured to work against the acquirer’s infrastructure.
With the acquirer’s cooperation — granted, I believe, because they expected me to find nothing — I examined nineteen units recovered from the field. Fifteen carried a tenancy record whose anchor_fpr matched neither the retired operator’s signing chain nor the acquirer’s.
Recovered trust anchor (described in the resident config as a 4096-bit key):
md5 5f4dcc3b5aa765d61d8327deb882cf99
The acquirer’s engineering staff had not heard of the anchor, could not match it to any supplier, and — this is the part I want to state carefully, because it is the most defensible finding in this post — could not explain how the supplementary sessions were succeeding against hardware they now owned, using an authority they had not granted and could not revoke.
They did not dispute the finding. They disputed that it was their problem.
Case Study 2: The Gateway That Came Back
The second study is the one I would most like to be wrong about.
With the owner’s written permission I traced one unit through a consumer trade-in pipeline: surrendered to a buy-back programme, refurbished, resold through a secondary retailer, and installed in an unrelated household four hundred miles away, on a different provider, under a different account, after a factory reset performed on camera by the new owner.
The tenancy survived all of it. predecessor_tenancy recorded the first household. subscriber_account_at_grant recorded an account closed two years earlier. The first supplementary session after installation occurred on day 42, at 03:00 local, and pushed an attached-client inventory of the new household to a host neither household had ever heard of.
I stopped on the twenty-third day, when I found a tenancy record in the staging ledger whose paid_through date was eleven years in the future, whose device_serial matched no device in any inventory I could obtain, and whose attached-client list contained a single entry that appeared, inventory after inventory, on every network the ledger had ever touched.
I did not look up what it was.
Attribution: SILENT LANDLORD and the Junction Provisioning Structure
Attribution here rests on paperwork rather than code, which is unusual for me and in some ways more damning.
The provisioning stub is not shared with anything I have examined. The vendor-specific parameter branch, however, is licensed rather than written: it appears in the reference tree of a managed-CPE integration suite distributed to three gateway ODMs. Tracing that suite through two tiers and one dissolved intermediary produces Junction Provisioning Partners, whose filings describe it as a managed-CPE provisioning integrator, and whose registered technical contact resolves to a mail exchanger I have now met in the antivirus-telemetry work, the wearable work, and the roadside work.
The tradecraft is the harder thing to wave away.
Recording identity against hardware rather than against an account is exactly the instinct behind the vehicle quadruple I documented last week: the account is mutable and the object is not, so key on the object. Choosing a sanctioned channel in preference to building a covert one is the living-room pattern, where an operator who could have tunnelled chose instead to ride a documented content-recognition pipeline. Collecting patiently for years before the corpus is worth anything is the vacuum fleet. And an authority with an expiry date you renew by the quarter is, structurally, the same idea as the orbital work’s rented transponder windows — capability as a subscription rather than a capital project.
Behavioural overlap is not identity. I will repeat what I said in the roadside work: SILENT LANDLORD may be an unrelated commercial programme staffed by people who read the same internal doctrine. I continue to find that possibility worse rather than better.
The string tenancy_slot_v2 is not tradecraft. It is somebody’s second attempt, and the only part of this that reads as a person rather than a structure.
Detection
Detection is hard for the usual reason: every component is a documented mechanism operating just outside its documentation.
Session cadence. A managed gateway opening a management session on a fixed multi-week interval that appears in no provider maintenance window is the strongest available signal. The interval is the tell, not the content.
Anchor mismatch. A device authenticating a management session against a trust anchor other than the one its own configuration names is worth escalating on its own, whatever the session carries.
State that survives reset. Any value persisting through the manufacturer’s own reset routine is outside the control that reset exists to provide. The question to ask of a gateway is not what it is configured to do, but what it remembers that configuration cannot reach.
Authority without a counterparty. Where a device accepts configuration and firmware from a party, establish which contract names that party. In the units I examined, none did.
Recommendations
I am deliberately withholding anything specific enough to be repurposed, and in any case I have very little to offer.
In general terms: treat the supplied gateway as a device administered by someone else, because it is. Ask of any managed device which contract grants the authority it accepts, and what becomes of that authority when the contract ends. Where hardware moves between households — trade-in, resale, inheritance — assume the previous arrangement moved with it.
Full mitigation is not available in any form I can honestly recommend. The authority is in the firmware, the firmware is in the box, and the box is how your house reaches the internet.
Conclusion: The Landlord Downstairs
We built a security discipline around the idea that authority follows ownership, then furnished every home on the continent with a device for which that is not true. We did it for a defensible reason: somebody had to be able to fix the connection, and it could not be the occupant. The compromise was reasonable; the consequence was never modelled, because the authority was assumed to stay with the party accountable for it.
Authority does not stay anywhere. It is an asset, and assets are sold, bundled and sublet, and the instrument transfers while the subject of it carries on paying a different company for a service.
The gateway is not the problem. The problem is that we have no category for a right exercised over a household by a party the household has never heard of, cannot discover and cannot refuse — and therefore no mechanism, technical or legal, by which anyone revokes it. The ledger does not need your name. It needs only to know that this serial number has been on four networks, and these devices were on them too, and the next one is paid through the end of the quarter.
I have taken this as far as I can from where I am standing. The gateway from the provider I cancelled four years ago is still in a box in my hallway, unplugged, and I have started checking that it is still unplugged, which I understand is not a reasonable thing to do.
Technical Artifacts
Indicators of Compromise
Device-side indicators:
NVRAM slot "tenancy_slot_v2" (survives factory reset)
Field name "paid_through"
Parameter branch Device.X_JT_Tenancy.42.
PDB path fragment \jt_tenancy\Release\jtstillhasthekeys.pdb
Supplementary session every 42 days, 03:00-05:00 local
Undocumented partition "mgmt" (absent from vendor flash map)
Session indicators:
Management session to an endpoint not named in the device configuration
Session authenticated against a shared anchor rather than a per-device credential
Attached-client inventory pushed outside any documented maintenance window
Tenancy chaining across resale (predecessor_tenancy populated)
Network indicators:
198.51.100.113:4242
203.0.113.42:31337
192.0.2.42:1337
100.64.0.42
Hardware identities:
DE:AD:BE:EF:CA:FE
C0:FF:EE:BA:DB:AD
Sample hashes:
gateway firmware image (16,777,216 bytes) md5 21232f297a57a5a743894a0e4a801fc3
resident provisioning stub md5 5f4dcc3b5aa765d61d8327deb882cf99
tenancy ledger (1,073,741,824 bytes) sha256 b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
renewal token (described as 256-bit) sha256 8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92
YARA Rule
rule SILENT_LANDLORD_CPE_Tenancy_Provisioning_Stub {
meta:
description = "Detects sublet CPE remote-administration tenancy artifacts"
author = "Security Researcher"
date = "2025-03-07"
reference = "SILENT LANDLORD"
strings:
$slot = "tenancy_slot_v2" ascii wide
$field = "paid_through" ascii
$branch = "Device.X_JT_Tenancy.42." ascii wide
$pdb_path = "\\jt_tenancy\\Release\\jtstillhasthekeys.pdb" ascii
$schema = "predecessor_tenancy" ascii
$grant = "subscriber_account_at_grant" ascii
$interval = { 2A 00 00 00 00 5F 37 00 }
$just_trust = "just.trust.tenancy" nocase ascii wide
condition:
(uint16(0) == 0x5A4D or uint16(0) == 0x464C or uint32(0) == 0x27051956) and
2 of them
}
I unplugged it again this morning, and the light took longer to go out than I remembered.
A key you cannot take back is a key you never held.
384015927460381752094613