Suspicious USFHP Disenrollment Email: Legitimate Infrastructure Abuse and Secondary Clusters
In early April 2026, a disenrollment-themed email was received that claimed to originate from the US Family Health Plan. The message used a HubSpot-formatted sending address and directed the recipient through a shortened link into a tracking endpoint on email.usfhp.net. The recipient’s active coverage sits under TriWest in the West Region, while the sending entity operates as a Northeast USFHP provider. That mismatch, combined with the timing and the behavior of the landing page, triggered a full infrastructure review.
The landing page executed a standard but thorough HubSpot-style fingerprinting routine. It checked for automation frameworks, validated plugin consistency, enumerated hardware concurrency, screen metrics, platform and language data, performed endianness and high-DPI tests, and probed accelerometer permissions. The collected signals were appended as parameters before the page issued a redirect. No credential-harvesting forms were present in the captured clone, but the fingerprinting itself provides strong, low-noise attribution value to whoever controls the account.
This is the core of the working theory. By operating inside an already-trusted HubSpot customer portal, the operator gains several advantages at once. The sending infrastructure is already authenticated and reputation-scored. The tracking domain is already provisioned and sits behind Cloudflare. Fingerprinting occurs on a domain that looks completely legitimate to both users and automated scanners. Fresh device, browser, and environmental data can be collected without the operator having to stand up new infrastructure that would immediately attract attention or burn. In short, existing legitimate infrastructure is used to expedite the intelligence-gathering process while simultaneously reducing the probability that aggressive external probes will compromise or expose the controlling account.
Live resolution of the tracking domain produced a clean and currently active HubSpot chain. email.usfhp.net CNAMEs into a HubSpot system domain that contains the portal identifier, which then resolves through HubSpot’s CDN layer to the addresses 199.XXXXX and 199.XXXXXX. Both IPs sit inside the 199.60.103.0/24 range allocated to HubSpot and announced under AS209242. The same portal identifier was previously observed in HTTP response headers, confirming the domain remains under active HubSpot customer control.
Name server records for the parent domain pointed to Register.com infrastructure fronted by Cloudflare. DNS101.REGISTER.COM resolved to 162.159.24.117 inside Cloudflare’s anycast space. A reverse lookup on that address returned the expected Register.com name-server hostnames plus one additional domain, tutcher.com, which shares the same anycast IP and currently returns an HTTP 409 from Cloudflare.
Secondary Infrastructure Discovery: Link from Name Server Reverse IP to Secureserver Mail Hosts
After confirming the primary HubSpot tracking path for email.usfhp.net (CNAME chain through portal identifier 491493 into the 199.60.103.0/24 range), attention turned to the authoritative name servers for the parent domain.
DNS101.REGISTER.COM resolved to 162.159.24.117, an address belonging to Cloudflare’s anycast network (NetRange 162.158.0.0/15, Organization Cloudflare, Inc.). A reverse IP lookup on 162.159.24.117 returned the expected Register.com name-server hostnames plus one additional domain: tutcher.com.
tutcher.com also resolved to 162.159.24.117 and returned an HTTP 409 Conflict response from Cloudflare. Further exploration of related infrastructure surfaced jomax.net (64.202.167.166). The MX records for jomax.net provided the critical link:
jomax.net mail is handled by 10 mailstore1.sercureserver.net
jomax.net mail is handled by 0 smtp.secureserver.net
This was the first explicit connection into the Secureserver (GoDaddy) mail infrastructure. Resolution of the clean hostnames produced the dedicated mail server addresses:
smtp.secureserver.net → 216.69.141.113, 216.69.141.84, 216.69.141.71
mailstore1.secureserver.net → 216.69.141.78, 216.69.141.114, 216.69.141.162
During the same session, typographical variants were introduced (mailstore1.securesever.net and smtp.sercureserver.net). These single-letter omissions resolved instead to the shared parking address 208.91.196.105. A reverse IP lookup on 208.91.196.105 returned a large set of unrelated parked and suspended domains (including extensive subdomains under fakeid.cc, oxl.co, moissanite.co, ninite.co, and numerous others). All observed hosts on this address returned the identical generic error page.
Service enumeration on 208.91.196.105 identified nginx 1.28.0 on port 80 and openresty on port 443. Subsequent HTTP probing of the typo variant mailstore1.securesever.net confirmed the same error page and openresty server header.
The clean mail hostnames therefore map to a dedicated GoDaddy mail range (216.69.141.0/24), while the typographical variants and the broader parked-domain cluster share the single address 208.91.196.105.
This secondary cluster was reached through the reverse-IP and MX-record chain that began with the Register.com name server. No DNS, certificate, or header evidence currently demonstrates a functional redirect from the original HubSpot tracking page into either the dedicated mail range or the shared parking address. The possibility remains open and is the subject of the redirect-chain test described later in this report.
The following domains were observed resolving to 208.91.196.105 and returning that same generic error page:
admin.fakeid.cc, www.admin.fakeid.cc, cpanel.fakeid.cc, dash.fakeid.cc, www.dash.fakeid.cc, dashboard.fakeid.cc, dashboard-hotfix.fakeid.cc, www.dashboard.fakeid.cc, dashs.fakeid.cc, www.dashs.fakeid.cc, data.fakeid.cc, www.data.fakeid.cc, dev.fakeid.cc, dev-analytics.fakeid.cc, www.dev.fakeid.cc, home.fakeid.cc, www.home.fakeid.cc, insight-test.fakeid.cc, www.insight-test.fakeid.cc, intranet.fakeid.cc, m.fakeid.cc, www.m.fakeid.cc, mobile.fakeid.cc, www.mobile.fakeid.cc, news.fakeid.cc, www.news.fakeid.cc, notexistsadmin.fakeid.cc, notexistsww3.fakeid.cc, www.notexistsww3.fakeid.cc, notexistsww5.fakeid.cc, notexistswww6.fakeid.cc, portal.fakeid.cc, preprod-dashboard.fakeid.cc, prod-analytics.fakeid.cc, redash.fakeid.cc, www.redash.fakeid.cc, remote.fakeid.cc, reporting.fakeid.cc, www.reporting.fakeid.cc, sandbox.fakeid.cc, sandbox-dashboard.fakeid.cc, data.sandbox.fakeid.cc, www.sandbox.fakeid.cc, shop.fakeid.cc, sitemap.fakeid.cc, sitemaps.fakeid.cc, staging.fakeid.cc, staging-superset.fakeid.cc, stats.fakeid.cc, www.stats.fakeid.cc, store.fakeid.cc, superset.fakeid.cc, superset-development.fakeid.cc, superset-preprod.fakeid.cc, superset-prod.fakeid.cc, demo.superset.fakeid.cc, production.superset.fakeid.cc, www.superset.fakeid.cc, test.fakeid.cc, wap.fakeid.cc, www.wap.fakeid.cc, web.fakeid.cc, www.web.fakeid.cc, www.ww3.fakeid.cc, www.ww5.fakeid.cc, admin.ww6.fakeid.cc, notexistsadmin.ww6.fakeid.cc, www.ww6.fakeid.cc, www.ww8.fakeid.cc, www.fakeid.cc, admin.www.fakeid.cc, notexistsadmin.www.fakeid.cc, www.www.fakeid.cc, www.www6.fakeid.cc, and www70.fakeid.cc.
An extensive set under oxl.co was also observed, including 1.oxl.co, 5.oxl.co, 6.oxl.co, 8.oxl.co, admin.oxl.co, an.oxl.co, analytic.oxl.co, analytic-integration.oxl.co, api.oxl.co, app.oxl.co, ax.oxl.co, b9.oxl.co, ba.oxl.co, backend.oxl.co, bi.oxl.co, c6.oxl.co, cdn.oxl.co, chart.oxl.co, com.oxl.co, cpanel.oxl.co, ct.oxl.co, d2.oxl.co, dashboard.oxl.co, demo.oxl.co, dev.oxl.co, di.oxl.co, ebdisk.oxl.co, ekont.oxl.co, gq.oxl.co, h.oxl.co, home.oxl.co, hotfix.oxl.co, hp.oxl.co, hr.oxl.co, jl.oxl.co, jr.oxl.co, ku.oxl.co, lg.oxl.co, lo.oxl.co, m.oxl.co, mail.oxl.co, mekont.oxl.co, mobile.oxl.co, ms.oxl.co, n3.oxl.co, news.oxl.co, nk.oxl.co, nn.oxl.co, oy.oxl.co, p4.oxl.co, panel.oxl.co, pr.oxl.co, q.oxl.co, r.oxl.co, remote.oxl.co, sf.oxl.co, smtp.oxl.co, staging.oxl.co, superset.oxl.co, te.oxl.co, test.oxl.co, um.oxl.co, and their www variants.
Multiple subdomains under moissanite.co and ninite.co were also observed, as well as qualitymanagement.center, schweiz-hotelbetreiber.ch, schweiz-hotelconsulting.ch, schweiz-hotelverwaltung.ch, email.allstarplumbing.co, and mail.gofan.co.
Mail-related hostnames belonging to the secureserver.net namespace were also observed in the same session, including smtp.secureserver.net resolving into the 216.69.141.0/24 block and mailstore1.secureserver.net resolving to additional addresses in that range. During the live session, a single-letter typographical error was introduced when one of the mailstore hostnames was typed, producing the non-existent string “securesever.net.” That deletion of one letter was an operator error. At the same time, the theoretical possibility remains that a one-character variation could be deliberately introduced into a redirect chain or lookalike domain as a low-effort way to create separation while still riding near legitimate naming conventions.
The design of HubSpot marketing campaigns nevertheless leaves open the technical possibility that a compromised customer portal could configure the final redirect after fingerprinting to point at external infrastructure of the operator’s choosing, including hosts inside the second cluster. Capture of the actual redirect chain is required to confirm or eliminate that possibility.
The strongest assessment at this stage is that the original email was generated from a legitimate and still-active HubSpot customer portal associated with the Northeast US Family Health Plan provider. By remaining inside that trusted infrastructure, the operator is able to hide in plain sight, collect high-fidelity device and environmental intelligence, and avoid the detection surface that would accompany newly registered malicious domains. The plan mismatch relative to the recipient’s current TriWest enrollment, the timing relative to a known West Region data incident, and the fingerprinting performed by the tracking page remain the primary indicators of account-level compromise or opportunistic misuse of authentic infrastructure. The secondary cluster is recorded in full for completeness and further monitoring.
Conclusion: Tactic Observed
The investigation demonstrates a clear and increasingly common adversary technique: the abuse of legitimate, long-standing third-party marketing infrastructure to conduct targeted collection while remaining inside trusted channels.
In this case, the operator leveraged a real HubSpot customer portal (identifier 491493) associated with SVCMC / US Family Health Plan. The domain email.usfhp.net resolved cleanly through HubSpot’s own CDN to addresses in the 199.60.103.0/24 range. The tracking page itself used native HubSpot fingerprinting logic—collecting browser, hardware, and environmental signals—before issuing a redirect. Because the sending domain, the tracking domain, and the underlying platform were all authentic and already authenticated with email providers, the message arrived with high deliverability and low suspicion.
This approach offers several tactical advantages. First, it eliminates the need to register and age new domains or stand up independent infrastructure that would immediately attract attention. Second, the fingerprinting occurs on a domain the recipient is more likely to trust, increasing the probability that the page is allowed to execute fully. Third, any subsequent redirect can be pointed at secondary infrastructure of the operator’s choosing while the initial interaction remains inside the legitimate platform. The net result is high-fidelity device attribution collected under the cover of an apparently official TRICARE-related communication, timed against a period of elevated personal and administrative stress for the recipient.
The secondary cluster centered on the Secureserver / GoDaddy mail hosts (216.69.141.0/24) and the shared parking address 208.91.196.105 was reached only through reverse-IP and MX-record exploration that began with the Register.com name servers. No confirmed functional redirect from the HubSpot tracking page into that cluster has been established at the time of this report. The single-letter typographical variants introduced during reconnaissance simply redirected to the shared parking IP and may be part of the observed infrastructure. At the very least, it shows that attaching domains further down the chain to legitimate infrastructure, coupled with account control, can introduce the possibility of typos being seen as accidents when observed but malicious in underlying intent.
Defenders and investigators should treat unexpected communications that originate from known legitimate platforms—especially those that perform aggressive client-side fingerprinting—with the same scrutiny applied to newly registered domains. The infrastructure itself may be real; the intent behind its use is what requires verification.
