Key Findings
- Fake ChatGPT Plus billing emails are being used to steal payment card information.
- A live operator controls what happens after card information is submitted, including whether to request a one-time verification code.
- Researchers found the same phishing template across independently deployed sites.
- Sites can disappear and be replaced while the underlying operation remains the same.
- The phishing kit appears to be actively evolving.
Executive Summary
A sustained phishing campaign impersonating OpenAI has been observed sending "ChatGPT Plus payment failed / update your billing" lures to a broad set of targets, directing recipients to a cluster of short-lived, randomly-named WordPress instances hosted on Nexcess's nxcli.io infrastructure. Each instance follows the identical URL pattern https://<10-char-hex>.nxcli.io/wp-admin/<random>/<random>/app/key.php and serves a byte-for-byte identical payment-card capture form backed by a live, human-operated control panel.
The form itself never completes on its own: submitted card data is sent to the server and the page is left on a permanent loading animation while an operator, watching victims arrive in real time through a polling dashboard, manually decides whether to escalate to an OTP/2FA capture page, show an error, or drop the session. This operator-in-the-loop design is also what defeats interception-based analysis tooling such as Burp, since the panel's redirect logic depends on an unbroken request chain that a proxy disrupts.
Why it matters: the same hardcoded application identifier (appIdKey) and the same obfuscated form-field names were found unchanged across independently-deployed instances captured a week apart, confirming the entire client-side payload is a shared, cloned template rather than a bespoke build per site. Combined with Nexcess's officially-documented ability to host multiple independent sites on a single ~$7/month account, this campaign's infrastructure cost and effort are low enough that the barrier to reproducing it is now closer to a hosting signup than to building custom phishing infrastructure.
Business impact: a successful submission hands the operator a full payment card (PAN, expiry, CVC, cardholder name) in cleartext past TLS termination, with no additional obfuscation on the transmitted values, and gives them the option to push the victim into an OTP-capture flow that could defeat card-issuer two-factor protections. The campaign is already documented by third parties (Check Point's Q2 2026 Brand Phishing Report, pcrisk.es, and an open spam.org complaint thread with 51+ reports), confirming it is active and not an isolated case.
Recommended actions:
1. Block nxcli.io and its subdomains, plus the redirect/shortener domains identified in the email corpus (authgpt.info, ai-billing.info, mub.me, url-y.uk), at the DNS/email-gateway level.
2. Verify sender and link domains against OpenAI's actual domains (openai.com, chatgpt.com) before any billing email is acted on.
3. File abuse reports with Nexcess/Liquid Web ([email protected]) and the domain registrar Tucows ([email protected]), since a full nxcli.io block also affects legitimate Nexcess customers.
4. Recommend virtual/disposable card numbers for online payments, so exposure from a submission like the one analyzed here can be contained by freezing a single card rather than reissuing a primary one.
Introduction
This report documents fake ChatGPT Plus billing emails that are leading recipients into a payment card theft operation where an attacker can control what happens next in real time. After a victim submits their card details, the fraudulent page keeps them waiting behind a loading screen while the attacker can request a one-time verification code, potentially helping authorize an unauthorized payment. The campaign appears to target a broad audience, mostly English speakers and US corporations.
What this research uncovered / Research focus
While these fraudulent emails have been publicly reported, this investigation examines the machinery behind them: the websites, hosting services, shared code, and system used to direct victims. Multiple sites used Nexcess’s nxcli.io hosting infrastructure, identical payment-page code, and the same embedded application identifier across samples collected a week apart. These connections reveal a repeatable operation whose websites can be replaced while the underlying fraud mechanism remains the same. Whether the attackers purchased the hosting themselves or compromised customer sites remains unresolved.
How the research was conducted / Methodology
Analysis was conducted through WPScan and WhatWeb fingerprinting, WHOIS lookups, direct review of the campaign's own hosting-provider documentation and customer dashboard, and passive browser-side capture (DevTools network inspection, with SSLKEYLOGFILE-based Wireshark decryption identified as the correct fallback) of the live payload — without attempting to compromise or disrupt the operator's infrastructure beyond standard reconnaissance requests.
Why we're reporting this now / Current activity
This report is produced now because the campaign remains active: instances in the cluster have gone offline and been replaced by new ones on the same pattern throughout the investigation, the underlying kit shows signs of ongoing development (see Threat Landscape and Closing Notes), and the campaign is independently corroborated by multiple public sources, indicating continued, broad targeting rather than a single resolved incident.
Threat Landscape
How the infrastructure works / Hosting model
This campaign follows a pattern increasingly common in commodity phishing: rather than attacker-registered or purpose-built infrastructure, the payload is hosted on a mainstream managed-WordPress platform (Nexcess, part of Liquid Web), using the platform's own auto-assigned <hex>.nxcli.io hostnames and fronted by Cloudflare. Whether each instance represents a compromised third-party customer site or an account the operator provisioned themselves remains only partially resolved (see Origin and intent below), but Nexcess's own documentation confirms a single Cloud Sites account can host a variable, non-fixed number of independent sites starting around $7/month — materially lowering the cost and effort needed to stand up and rotate the 8+ hosts observed in this cluster.
Evidence of a shared phishing kit / Template reuse
Every sampled instance runs byte-for-byte identical client-side payload code, the same WordPress core and theme versions, and the same hardcoded operator-panel identifier, consistent with a single template cloned repeatedly rather than independently built sites. Instances have a short operational lifespan — several were taken offline within the investigation window and replaced by new ones on the same naming pattern — which is better explained by a shared operator or shared provisioning account than by multiple, uncoordinated actors.
How the campaign is evolving / Campaign evolution
The lure itself (a fake "payment failed" billing notice) and the use of a live, human-operated redirect panel rather than a static harvester both point toward a low-cost, broadly-targeted operation optimized for volume rather than a bespoke campaign against a specific sector or region. A newer instance identified later in the investigation shows a visually distinct, apparently AI-generated front-end layered on what may be the same backend mechanism — consistent with the kit's template continuing to evolve rather than being a frozen, one-time build (see Closing Notes).
Threat Specifics
What we know about the operation / Origin and Intent
The operator's objective is payment-card and, potentially, one-time-passcode harvesting, not malware deployment: the entire payload is a web-based card-capture form and an operator dashboard, with no executable delivered to the victim's machine at any stage observed in this investigation. The live-operator design — manually escalating promising victims to an OTP/2FA capture step — indicates intent to defeat card-issuer two-factor authentication on the spot, not just to collect static card numbers for later resale. Whether the operator compromises existing Nexcess customer sites or provisions their own accounts to host each instance is not yet conclusively determined; Nexcess's low entry cost and documented multi-site support make self-provisioning at least as plausible as compromise, and both explanations remain open pending direct confirmation from the hosting provider.
How victims reach the phishing page / Delivery mechanism
Phishing emails impersonating OpenAI billing notices ("ChatGPT Plus payment failed / update your billing") are sent from randomized/algorithmically-generated sender addresses (e.g. [email protected]). Embedded links route through tracking/redirect wrappers (including Google-redirect and Mandrill-tracking URLs observed in the corpus) to the final landing page on a <hex>.nxcli.io host. The same landing-page host is frequently reused across multiple recipients in the same sending wave — one host in the corpus is tied to five separate recipient addresses — indicating a two-layer setup: a per-recipient tracking/redirect layer in front of a shared, per-wave landing page.
How the Scam Works
- The victim receives a fake ChatGPT billing email.
The message claims there is a problem with the recipient's ChatGPT Plus payment. - The victim is sent to a fake payment page.
The page imitates a legitimate checkout and asks for payment card information. - The attacker sees the victim arrive.
Once the victim submits the form, the page appears to keep loading while the attacker's control panel monitors the session. - The attacker decides what happens next.
The operator can request a one-time verification code, display an error or terminate the session.
What happens after a victim clicks / Execution flow
The victim clicks the link in the phishing email and is routed to a <hex>.nxcli.io/wp-admin/<random>/<random>/app/key.php landing page. A direct, unauthenticated request to this path returns a generic 400 Bad Request, and a request from outside the operator's expected traffic (e.g. over a VPN exit node) returns 403 Forbidden — consistent with request-gating that only serves the real page to visitors matching expected conditions. The second random path segment (e.g. caser, xcer) was confirmed to be an active token-generating endpoint rather than a static directory: truncating the URL at that segment and repeating the request returns a different token each time, and the same behavior was reproduced on a second, independently-deployed host under a different segment name — indicating this token step, not key.php itself, may be where visitor filtering is actually enforced.
Once past the gating step, the victim is shown a payment form imitating a real checkout (brand detection, live card-number/expiry/CVC formatting). On submit, the page immediately shows a permanent loading animation, POSTs the card data to action.php, and — per explicit comments in the recovered source ("SHOW SPINNER AND STAY FOREVER" / "Keep spinner running — do nothing") — never acts on the response or redirects on its own. In parallel, the page polls ../panel/classes/processor.php every ~500ms with a keepAlive heartbeat (registering the victim as an active session on the operator's dashboard) and a redirectionListener check for an operator-issued redirect code. Once an operator sets that code, a targets map sends the victim to an OTP/2FA capture page, a generic retry error, or terminates the session — a decision made by a human watching the dashboard in real time, not by the client-side code.
What Makes This Campaign Different?
The fake payment page doesn't automatically move the victim to the next stage. After card details are submitted, a live operator can decide whether to request a one-time verification code, display an error, or end the session.
How the kit makes analysis hard / Anti-analysis techniques
Request gating at the landing page and/or the token-generating path segment, returning a generic 400/403 to automated, repeated, or out-of-pattern requests (not yet confirmed whether this is rate-limiting, a tarpit, or token/session validation).
The token-generating path segment itself (e.g. caser/xcer), issuing a fresh value on every hit rather than acting as a static, cosmetic directory name — reframing what first looked like purely cosmetic path naming as a functional anti-replay or session-binding step.
The polling-dependent redirect design, which defeats proxy-based interception (e.g. Burp) by design: a MITM in the request path breaks the unbroken request chain the panel expects, producing the same indefinite loading spinner for an analyst as for a victim, with no visible error to explain why. Passive, non-interposed capture (browser DevTools, or SSLKEYLOGFILE-based Wireshark decryption) is the only method confirmed to observe the true POST body and polling traffic without disrupting this chain.
Field-name obfuscation on the card-capture form (observed values cddd, bebeb, gagaga, byebu for card number, expiry, CVC, and name respectively) rather than conventional field names — evading naive WAF/pattern-matching detection, though notably the submitted values themselves carry no additional obfuscation (e.g. no base64) beyond TLS transport encryption.
Randomized per-instance hostnames and path segments across the cluster, consistent with automated/templated deployment rather than hand-built, individually-obfuscated sites.
MITRE ATT&CK techniques / Observed TTPs (MITRE ATT&CK)
This campaign's TTPs center on web-based credential/payment capture and operator-driven social engineering rather than binary execution, which is reflected in the mapping below:
T1566.002 — Phishing: Spearphishing Link
T1204.001 — User Execution: Malicious Link
T1583.006 / T1584.006 — Acquire Infrastructure / Compromise Infrastructure: Web Services (provisioned-vs-compromised hosting not yet conclusively resolved; see Origin and intent)
T1090.002 — Proxy: External Proxy (Cloudflare fronting masking true origin IPs for most instances)
T1027 — Obfuscated Files or Information (randomized path segments and form field names)
T1056.003 — Input Capture: Web Portal Capture (fake payment form harvesting card data)
T1557 — Adversary-in-the-Middle (live operator manually escalating sessions to an OTP/2FA capture step)
T1071.001 — Application Layer Protocol: Web Protocols (keepAlive/redirectionListener polling between the landing page and the operator panel)
Infrastructure and indicators / C2 configuration and infrastructure
Operator panel: ../panel/classes/processor.php (relative path, polled via keepAlive/redirectionListener), with a static appIdKey (1834f733528e1a9fc930069fa3763a2809d41769) confirmed identical across independently-deployed instances a week apart.
Representative host: c54b986c1c.nxcli.io — IP 209.87.159.240, Liquid Web L.L.C. (LQWB), netblock 209.87.144.0/20 (BHL-RANGE05).
Second confirmed host: 0b8918640c.nxcli.io — IP 209.87.159.83, same /20 netblock — identical WordPress 7.1 / Kadence 1.5.2 / WooCommerce 11.0.1 stack and identical payload code to the first host.
Cluster (same URL pattern, drawn from the email corpus): 581c413572, 58f9d9ca90, 38b03ac4e4, 0c859d4565, c7958246e7, 188f0289b4, 5fceac40bf (offline), plus the two hosts above — all *.nxcli.io, fronted by Cloudflare except where directly WHOIS'd.
Redirect/shortener domains observed in the email corpus: authgpt.info, ai-billing.info, mub.me, url-y.uk.
WHOIS/registration: parent domain nxcli.io registered to Nexcess.net LLC via Tucows, created 2017-12-05, privacy-gated through tieredaccess.com (Tucows' standard redaction, not attacker-configured) — registration facts describe Nexcess's ownership of the domain, not any individual instance.
Abuse contacts: Liquid Web/Nexcess reseller — [email protected] / +1-800-580-4985; registrar Tucows — [email protected] / +1.4165350123.
Impact Assessment
Operational impact
A successful submission gives the operator, in real time, a complete payment card (PAN, expiry, CVC, cardholder name) and the option to escalate the session to an OTP/2FA capture page — meaning the operational impact extends beyond a static card-number leak to a live attempt at defeating card-issuer two-factor protections on the victim's own session.
Financial exposure
The harvested card data is transmitted with no additional obfuscation beyond TLS transport encryption — no base64, tokenization, or client-side encryption on the values themselves — so any interception point past TLS termination would expose it in cleartext. Financial exposure is direct and immediate (unauthorized charges, potential OTP-bypassed transactions) rather than contingent on a later-stage payload, and scales with how many of the cluster's *.nxcli.io instances are active at a given time; public complaint data (spam.org, 51+ reports) suggests sustained, ongoing victim exposure rather than a single wave.
Detection difficulty
The live-operator, polling-dependent redirect design is specifically resistant to proxy-based interception (see Anti-analysis techniques), and the short, rotating lifespan of individual hosts — several went offline mid-investigation and were replaced on the same pattern — limits the useful lifetime of any single IOC. Cloudflare fronting on most instances also limits the value of IP-based blocking. Detection is better served by behavioral/structural signatures — the shared URL pattern, the keepAlive/redirectionListener polling volume (969 requests observed in a single 4-minute test session), and the static appIdKey — than by any single host or IP.
969 requests
A single test session lasting just over four minutes generated 969 requests, almost entirely from the page repeatedly polling the operator infrastructure.
Reputational risk
The campaign directly impersonates OpenAI/ChatGPT billing communications, creating brand-impersonation exposure for OpenAI independent of any specific victim organization. For organizations whose employees submit card data to this page on a work device or work-linked payment method, the incident also carries standard phishing-related reputational and process-review exposure, though no evidence in this investigation indicates the kit specifically targets organizational, as opposed to individual consumer, victims.
What Defenders Can Do
Organizations can take immediate steps to block known infrastructure, identify suspicious billing emails and reduce exposure if payment information is submitted.
Mitigation Guidance
Immediate (within 24 hours)
1. Block nxcli.io and all subdomains at the DNS/firewall/email-gateway level, along with the redirect/shortener domains identified in the corpus: authgpt.info, ai-billing.info, mub.me, url-y.uk.
2. Configure mail filtering to quarantine or block messages from *.nxcli.io sender patterns (support@<hex>.nxcli.io, postmaster@<hex>.nxcli.io), both observed repeatedly in the corpus.
3. Circulate a verification reminder: legitimate OpenAI billing communications only ever link to openai.com or chatgpt.com — any other domain in a "payment failed" email should be treated as fraudulent.
4. Do not treat Cloudflare-fronted IPs as reliable block targets; only 209.87.159.240 and 209.87.159.83 have been directly confirmed via WHOIS in this investigation, and IP blocking should be a secondary control at most.
Short term (within one week)
5. File abuse reports with Nexcess/Liquid Web ([email protected], +1-800-580-4985) and, where domain-level action is needed, registrar Tucows ([email protected], +1.4165350123) — a full nxcli.io block affects legitimate Nexcess customers, so this should be paired with, not substituted for, those notifications.
6. Send a courtesy brand-abuse notice to OpenAI, since none of the identified infrastructure is affiliated with them.
7. Recommend virtual/disposable card numbers for online payments across the organization, so that exposure from a submission like the one analyzed here can be contained by freezing a single card.
8. Re-run WPScan/WhatWeb/WHOIS against any newly-identified *.nxcli.io instances to keep the IOC set current, given the cluster's short per-host lifespan.
Ongoing
9. Monitor for new instances matching the https://<hex>.nxcli.io/wp-admin/<random>/<random>/app/key.php pattern, and check any new instance's payload for the same static appIdKey and obfuscated field-name set as a quick confirmation it belongs to this campaign.
10. Track whether the visually-updated, apparently AI-generated front-end observed on one later instance (see Closing Notes) represents a broader template update, and re-baseline the payload/TTP analysis above if the underlying mechanism changes.
11. Continue pursuing direct confirmation, rather than documentation-based inference, of whether cluster instances are self-provisioned Nexcess accounts or compromised third-party sites, since this determines whether future abuse reports should be framed as "fraudulent customer signup" or "compromised customer account."
12. Verify sender emails against official communication channels as standard practice — the randomized/algorithmic sender addresses seen throughout this corpus are a reliable red flag on their own.
Closing Notes
The significance of this campaign extends beyond another convincing fake email. The technical analysis connects apparently separate websites through shared code and infrastructure, and shows how the payment page repeatedly checks for instructions from an attacker-controlled panel. That mechanism gives the attacker an opportunity to move a victim from disclosing card details to surrendering a verification code during the same interaction. The observed threat is direct financial fraud; no malware delivery or compromise of victims’ computers or networks was observed.
The core risk is not the sophistication of any individual component — the payload code is templated, the cryptographic hygiene on submitted card data is minimal, and the WordPress instances themselves are unremarkable. What makes it effective is the combination of a cheap, officially-documented, multi-site-capable hosting product; a cloned payload reused identically across every instance; and a live operator panel that took no more than the JavaScript and PHP recovered in this investigation to build, yet is specifically designed to defeat interception-based analysis and to escalate promising victims past OTP/2FA protections in real time.
The most impactful available action is the combination of domain/infrastructure blocking (nxcli.io and the redirect domains) with direct collaboration with the hosting provider and registrar, since Cloudflare fronting limits IP-based blocking, and since the operator's low cost of entry means a single takedown is unlikely to be the campaign's last instance.
The operator is actively maintaining and evolving this operation: instances in the cluster have gone offline and been replaced on the same pattern throughout this investigation, and a later-observed instance shows a visually distinct, apparently AI-generated front-end that may reflect the kit's template continuing to be iterated on. The IOCs and findings in this report should be treated as a current snapshot of an active campaign, not a closed case.
Immediate next steps and owners
Threat Intel team: Monitor for new *.nxcli.io instances matching the cluster pattern; confirm new instances via the shared appIdKey and field-obfuscation signature; track the template-evolution signal noted above.
Network/Email Security team: Block nxcli.io and the redirect domains; configure mail filters for *.nxcli.io sender patterns.
Abuse/Legal team: File reports with Nexcess/Liquid Web and Tucows; send a brand-abuse notice to OpenAI.
Fraud/Payments team: Advise virtual/disposable card usage for online payments; watch for downstream fraud patterns tied to cards submitted to this campaign.
Technical Indicators and Reference Data
The following information is provided for security teams investigating or detecting activity associated with this campaign.
Appendix A — File Hashes and Samples
This campaign delivers no binary malware sample to the victim's machine — the payload is server-side PHP/JavaScript served over HTTP as a web page, not a downloaded executable. No file hashes are applicable in the sense this appendix would normally record. The closest equivalent fingerprints recovered from this investigation are the static application identifier embedded in the panel JavaScript and the obfuscated form-field name set, both confirmed identical across independently deployed instances:
Operator panel identifier:
appIdKey: 1834f733528e1a9fc930069fa3763a2809d41769 — confirmed identical across c54b986c1c.nxcli.io and 0b8918640c.nxcli.io, captured roughly a week apart.
Obfuscated card-form field names:
cddd (card number)
bebeb (expiry)
gagaga (CVC)
byebu (cardholder name)
Client-side payload comparison:
Byte-for-byte identical action.php submission handler, card-brand detection logic, and ../panel/classes/processor.php polling code recovered from both confirmed hosts.
Appendix B — Network Indicators
Confirmed hosts:
c54b986c1c.nxcli.io — 209.87.159.240 (Liquid Web L.L.C., netblock 209.87.144.0/20)
0b8918640c.nxcli.io — 209.87.159.83 (same /20 netblock)
Additional cluster hosts (same URL pattern, email corpus):
581c413572.nxcli.io
58f9d9ca90.nxcli.io
38b03ac4e4.nxcli.io
0c859d4565.nxcli.io
c7958246e7.nxcli.io
188f0289b4.nxcli.io
5fceac40bf.nxcli.io (confirmed offline)
Redirect/shortener domains:
authgpt.info
ai-billing.info
mub.me
url-y.uk
Abuse contacts:
Liquid Web/Nexcess: [email protected] / +1-800-580-4985
Tucows (registrar): [email protected] / +1.4165350123
Appendix C — Static Analysis Notes
Card capture form:
Brand detection via regex against the card number (Visa/Mastercard/Amex/Discover/JCB/Diners), with live formatting of card number/expiry/CVC fields.
Obfuscated field names (cddd/bebeb/gagaga/byebu — see Appendix A) rather than conventional names, with no additional obfuscation on the field values themselves.
Submission handling (action.php):
Prevents the default form action and immediately shows a permanent loading overlay on submit.
POSTs form data via fetch(); never acts on the response or redirects — source comments read "SHOW SPINNER AND STAY FOREVER" / "Keep spinner running — do nothing."
Operator panel polling (processor.php):
keepAlive: 1 heartbeat sent every ~500ms, registering the session on the operator dashboard.
redirectionListener: 1 check sent every ~500ms for an operator-issued redirect code.
targets map resolves a set redirect code to an OTP/2FA page (token.php/code.php), a generic error (apv.php?e=ERROR), or session termination (out.php).
Token-generating path segment:
The second random path segment (e.g. caser, xcer) issues a new token value on every request when hit directly, confirmed on two independently-deployed hosts under different segment names.
Empirical capture note:
969 requests observed over a single 4-minute-3-second session on one host, almost entirely processor.php polling traffic — a usable volume-based detection signature independent of payload content.
Appendix D — References
Public corroboration:
Check Point Q2 2026 Brand Phishing Report — lists ChatGPT/OpenAI among the top 10 most-impersonated brands, citing fake "ChatGPT Plus payment failure" emails.
pcrisk.es — documents 188f0289b4[.]nxcli.io by name as a fraudulent OpenAI subscription payment page.
spam.org — open complaint thread against nxcli.io, 51+ recorded spam complaints.
Hosting provider documentation:
https://www.nexcess.com/platform/sites-stores/
https://docs.nexcess.com/hosting/cloud-sites/ — "Adjust Cloud Sites Backup Plans" and "Create a Website in Cloud Sites"
Appendix E — Revision History
1. 2026-08-27 Initial version — infrastructure fingerprinting (WPScan/WhatWeb/WHOIS) on representative host, cluster identification from email corpus.
2. 2026-09-02 Added live-operator payload analysis (DevTools capture, panel polling mechanism), cross-host code/appIdKey comparison, Nexcess hosting-model findings.
3. 2026-10-09 Added template-evolution observations on a newer instance; restructured into this template's section format.
