The Phishing Page Brand Tools Cannot Find

A live credential and card harvesting page is impersonating Spaceship, the domain registrar and hosting company. The brand sits in the subdomain of a domain that has nothing to do with it.

Safety notice. The URL below is defanged for research. Do not visit it, and do not submit anything to it.

hxxps://spaceship.online-acc[.]website/spcc/index.html

If you were responsible for protecting that brand, which of your tools would have found it?

Four of the discovery channels the industry relies on miss this page completely, and each misses it for a different reason. The fifth, searching the page body for the brand's own vocabulary, finds it immediately and is the least sophisticated technique in the box.

Key findings

• The brand is in the subdomain. The registrable domain is online-acc[.]website and contains no brand token, so permutation engines cannot generate it.
• The certificate is a wildcard. Its SAN holds *.online-acc.website and the apex only. The brand never enters a Certificate Transparency log, and no CT query recovers it.
• DNS is where the signal survives. The wildcard is on the certificate, not on DNS. Every hostname actually in service needs its own record, and on this domain only one label resolves.
• The page hides from cameras, not parsers. An overlay holds content at opacity: 0, so the markup, including the logo filename and product vocabulary, is present throughout. A parser here means any tool that reads the document's HTML, text and scripts rather than photographing the rendered page.
• The highest-signal string is not the brand name. "Ask Alf" is a product name nobody writes by accident. "Spaceship" is an ordinary noun that appears on thousands of innocent pages.
• The kit spends most of its engineering on not being looked at. Its antibot.js runs twenty-seven techniques, several of which attack the user's own anti-phishing protections rather than evading discovery.

Which detection methods find it

Method	Result	Why
Typosquat permutation	Misses	The brand sits on a domain the attacker already owns, which no permutation of the brand produces
Certificate Transparency	Misses	The wildcard certificate carries no brand string, so there is nothing to log
Page-title search	Misses	The kit swaps in generic decoy titles until a human interacts
Screenshot and visual similarity	Misses	An overlay means the crawler photographs a spinner
Page-body and DOM content search	Finds	The brand, its product names and its asset filenames are in the document the whole time
Passive DNS	Finds	Each branded hostname must exist in DNS before it can serve anything

About this analysis

Evidence in this report comes from two places, and the difference matters when you are deciding how much weight to put on any given line. Work dated 18 September 2026.

Evidence	Status
TLS certificate and SAN values	Verified directly, read off the wire
DNS resolution, including candidate brand labels	Verified directly
Registration data, registrar, nameservers	Verified directly via RDAP
Certificate Transparency and URL-scan corpus checks	Verified directly
Product vocabulary, checked against the live site	Verified directly
antibot.js	Full source file reviewed
Page markup, display overlay, redirect chain	Supplied by the reporter
The two screenshots	Supplied by the reporter

Everything said about antibot.js is read from its code rather than inferred from its behaviour. Claims that are neither observation nor source review are marked in the text as inference.

Cloudflare's bot challenge stood between us and the document itself on every attempt, and defeating bot challenges is not something we do to check someone else's homework. That challenge is worth noting on its own. The operator sits behind a commercial bot gate, ships a second gate of their own, and the page applies a third before it will accept a submission. Three layers of automated-visitor filtering before a human sees a card form.

What it looks like when the gate opens

Screenshots supplied to us show the page as a victim sees it, past the anti-bot overlay. It is worth describing, because it explains why the vocabulary argument above is not a technicality.

The header is the brand purple with the Spaceship wordmark and logo mark at the left. Along the navigation sit four items: All products, Ask Alf, Library and Launchpad. Those are not strings buried in a comment or an alt attribute. They are rendered, visible, and positioned exactly where the real product puts them, because that is the point of copying an interface.

Below the header, the page titles itself "Payment Manager" next to a card icon. The panel is labelled SECURE PAYMENT EXTERNAL and carries two badges, PRO PLAN and NEW, alongside a Manage button and a row of icons that do nothing. None of this furniture is functional. It exists to make the panel look like part of a product a person already pays for.

What it takes

The form collects, in order:

PHONE NUMBER          placeholder "Phone number"
CARDHOLDER'S NAME     placeholder "john doe"
CARD NUMBER           placeholder "0000 0000 0000 0000"
EXPIRY DATE           placeholder "MM/YY"
CVV                   placeholder "CVV"

Phone number first is the detail worth pausing on. A payment form has no reason to ask for a telephone number before a card, and a legitimate one usually already knows it. Collected here, ahead of the card, it is the channel the operator needs for the step that follows.

Two checkboxes sit under the fields: "Keep these details for later" and "Save the configuration above to my default payment settings", the second with the subtitle "We'll save this information for future use." Both are unticked. A prefilled consent box invites suspicion, while an empty one invites a decision, and being asked to decide makes the panel read as software rather than as a trap.

Under the button is the line "Your payment details are encrypted and secure." next to a Need help? link. The statement refers only to transport encryption. It says nothing about who receives the data or what happens to it.

The holding screen is the tell

The second screenshot is the page immediately after submission. It reads:

SECURE PAYMENT
Processing your payment

    Verifying your information
    Please wait while we securely process your details.

STATUS ......................................... FINALIZING

Please wait, this normally takes a few seconds.
Do not close or refresh this page.

A spinner, a progress bar that is almost full, and an instruction not to leave.

Nothing is being processed. There is no payment. The supplied analysis records that this page redirects onward to an SMS step, and this screen is what fills the gap in between.

Inference. The most likely purpose of the delay is to give the operator time to relay the card details to a real merchant or bank flow while the victim watches a progress bar. If that transaction triggers 3-D Secure, the bank sends a one-time code to the phone number the form collected first, and the next screen asks the victim for it. A victim still looking at a payment they believe they initiated seconds ago has little reason to refuse.

We did not observe the relay, and we do not claim to have. What supports the reading is the field order, the redirect to an SMS step, and a holding screen whose only function is to keep the visitor present.

This is what separates a card harvester from a card-and-OTP harvester, and it is the difference between stolen numbers that fail at checkout and a completed transaction. "Do not close or refresh this page" is not user-experience copy. It is the operator requesting the time the relay needs.

Ten minutes from registration to certificate

Registration data puts a clock on the whole operation.

domain registered   2026-09-17 08:54:38 UTC   Name.com, Inc.
certificate         notBefore 2026-09-17 08:04:20 UTC   Let's Encrypt
nameservers         leonidas.ns.cloudflare.com, ophelia.ns.cloudflare.com
registry status     clientTransferProhibited, addPeriod

The certificate appears to predate the registration by fifty minutes, which cannot be literally true: a certificate authority will not issue for a domain before it exists.

Inference. The usual explanation is backdating. Certificate authorities commonly set notBefore earlier than the moment of issuance so that clients with skewed clocks do not reject a newly issued certificate, and an hour is a conventional margin. On that reading the certificate was obtained at roughly 09:04, about ten minutes after the domain was bought. We did not verify Let's Encrypt's current backdating interval, so treat the ten minutes as approximate and the ordering as the solid part.

So the sequence is: register the domain, point it at Cloudflare, take a wildcard certificate, and have a working card-harvesting page the following day. The registry status still read addPeriod when we looked, indicating the registration was inside the add-grace period. Depending on registry and registrar policy, that window can permit cancellation or refund. Either way, the infrastructure was hours old and provisionally held.

This is worth holding next to the detection discussion. Whatever channel you rely on has to produce an answer in hours, because that is the age of the thing you are trying to catch.

The brand is in the subdomain

The registrable domain is online-acc[.]website. The brand name sits one level to the left, in a subdomain the attacker can create at will.

Permutation engines start from the protected domain and generate neighbours: character swaps, omissions, homoglyphs, alternate TLDs, brand-plus-keyword combinations. They will happily produce spacesh1p.com and spaceship-login.com.

None of them yields spaceship.online-acc.website, because online-acc.website is an arbitrary domain the attacker already owns and shares nothing with the brand. The generator would have to guess a string it has no reason to consider. That is a structural limit rather than a tuning problem, and widening the set only produces more domains nobody registered.

The wildcard certificate closes Certificate Transparency

Certificate Transparency monitoring is the industry's answer to that gap, and it is sold as comprehensive coverage. Here is the certificate actually being served, read off the wire:

subject   = CN=online-acc.website
issuer    = C=US, O=Let's Encrypt, CN=YE2
notBefore = Sep 17 08:04:20 2026 GMT
SAN       = DNS:*.online-acc.website, DNS:online-acc.website

Two names. A wildcard and an apex. The string "spaceship" is not among them, and it never will be.

The consequence is worth stating plainly. One wildcard certificate covers any number of branded hostnames without a further issuance event, so none of them reaches a log. Each one still requires a DNS record, hosting and deployment, so the cost is operational rather than cryptographic, but it is never a certificate. The same certificate that serves spaceship.online-acc.website would serve paypal.online-acc.website without a single new issuance event. A method premised on watching issuance cannot see hostnames that are never issued.

The wildcard is on the certificate, not on DNS

One more result changes the practical advice.

We resolved a set of candidate brand labels against the domain: paypal, godaddy, netflix, microsoft, coinbase, namecheap, plus www, mail, admin and a deliberate nonsense string. Every one returned NXDOMAIN. Only spaceship.online-acc.website resolves.

There is no wildcard DNS record. The certificate covers *.online-acc.website, but each hostname the operator actually wants to use still needs a DNS record created for it.

That distinction matters, because it locates the surviving signal. The wildcard certificate removes the brand from Certificate Transparency permanently, and nothing recovers it there. DNS is different. Every branded hostname the operator brings into service has to exist in DNS to work at all, which means passive DNS collection sees it the first time anyone resolves it.

So the honest version of the advice is not that certificate monitoring should be replaced. It is that certificate monitoring answers the question "was a certificate issued for my brand" and cannot answer "does a hostname carrying my brand exist". Those are different questions, and on this page only the second one has an answer.

It also tells you something about scale. A wildcard certificate is often described as giving an attacker unlimited branded subdomains for free. Unlimited is right in principle, but each one is a deliberate act that leaves a DNS record behind. On the day we looked, this operator had made that act exactly once.

The title is cloaked, not merely missing

Title search is coarser: look through a scan corpus for pages whose <title> contains the brand. Cheap, fast, and effective against kits that copy a page wholesale, title and all.

Our first account said this page simply has no title. Having read the kit's antibot.js, that was too generous. The absence is not an oversight, it is a system.

The script carries a list of decoy titles:

const _decoyTitles = [
  "Checkout - Secure Payment", "Online Payment", "Payment Gateway",
  "Billing Details", "Secure Checkout", "Account Verification",
  "Identity Verification", "Card Services",
];

On DOMContentLoaded it stores whatever title the document has and replaces it with one picked at random. It restores the real one on the first mousemove, mousedown, keydown, touchstart or scroll, or after eight seconds, whichever comes first.

Read that in terms of who sees what. A crawler that fetches the raw HTML gets no brand in the title. A crawler that renders the page, waits a moment, and reads the rendered title gets "Secure Checkout" or "Account Verification": plausible, generic, and matching nothing anyone monitors. A human gets a real title, because by then they have moved the mouse.

The detection consequence is unchanged, in that title search never returns the brand. What changes is the reading. A missing title could be laziness. A rotating decoy set that reverts on human input is someone who thought specifically about title-based hunting and built for it.

The camera sees a spinner

The fourth channel is visual. Crawl, screenshot, and compare against known brand imagery, often with perceptual hashing of logos so that minor edits still match.

The page reportedly carries a display overlay, identified in the supplied analysis as _ab_gate, which stays up until it observes several trusted mousemove events or a timeout elapses. An automated crawler supplies neither. It photographs the overlay and moves on, and the pipeline records a page with no brand content on it.

This is distinct from the submission gate in antibot.js described further down, which counts real pointer movement before it will let the form post. The kit gates what you can see and what you can send separately, and a screenshot crawler is stopped by the first without ever reaching the second.

The parser sees everything

This is where the technique turns out to be weaker than it looks.

By parser we mean any tool that reads the document itself, meaning the HTML, its attributes, its text and its scripts, rather than rendering the page and photographing the result.

The gate does not remove the page. According to the analysis, it sets opacity: 0 on the content wrapper. The document is fully constructed underneath: the logo element, its filename, the product vocabulary, the visible fallback text. All of it is in the DOM from first paint, held at zero opacity.

The overlay defeats what a camera sees. It does nothing to what a parser sees. Detection that fetches the document and reads its content walks straight through the gate, because the gate was never addressing that threat. It was built against screenshot crawlers, and against screenshot crawlers it works.

What the page cannot hide

An impersonation page has one job, which is to look like the brand to a human being. That requirement is not negotiable, and it is why the brand is always somewhere in the document. The supplied analysis records the following in the markup:

alt="Spaceship logo"        aria-label="Spaceship home"
src="spaceship.png"         class="logo-spaceship"
"Ask Alf"   "Launchpad"   "Library"   fallback text "Spaceship"

We checked the product vocabulary against the real site. Ask Alf, Launchpad and Library are all genuine Spaceship features, so these are not invented strings that happen to look plausible.

The screenshots show all three rendered in the navigation bar, and that matters for the argument. They are not incidental artefacts left behind by a careless copy. They are load-bearing furniture the attacker needs on screen for the imitation to work.

Anything the victim must see is something a parser can read.

One detail did not survive checking. The purple in the kit, #8250E6, is not Spaceship's brand colour. The live site uses a blue-violet family around #394EFF, #475BFF and #783BFF, and #8250E6 does not appear on it anywhere. The attacker eyeballed it and got close. That is a useful reminder that colour matching is a soft signal: the imitation was convincing enough for a victim while being measurably wrong.

The token that matters is not the brand name

The instinct is to hunt for "Spaceship". That is the weakest string available, because it is an ordinary compound noun appearing on thousands of innocent pages about rockets, films and games. Hunting it produces a false positive problem large enough that teams turn the rule off.

"Ask Alf" is the token worth having. It is a product name a company invented, it means nothing outside that company's interface, and essentially no unrelated page contains it. The same is true of logo-spaceship as a class name and spaceship.png as a filename, both of which are artefacts of copying a real interface rather than words a person would write by accident.

Generalise it: impersonation detection should key on a brand's distinctive product vocabulary rather than its name. A brand name is a word other people use. A product name is one nobody says by accident. Nobody accidentally writes "Ask Alf".

The analysis also notes a Cloudflare Web Analytics beacon token on the page. That token is provisioned per operator rather than per domain, so searching a scan corpus for the same token is a free pivot from this page to the rest of the operator's inventory, which is unlikely to be impersonating only one brand. One page becomes a campaign for the cost of one query.

Advanced technical analysis: the anti-bot layer

This section examines the kit's evasion script in detail. Readers after the detection argument alone can skip to what the public record knew without losing the thread.

The kit loads antibot.js before anything else on every page. It is roughly six hundred lines, it numbers its own techniques in a header comment, and it reached twenty-seven of them. It is by a wide margin the most carefully built component here, which tells you where the operator believes their risk is. Not in the payment form. In being looked at.

The techniques fall into four groups, and the groups have very different implications.

Group	Representative techniques	What it is defending against
Looking like a real browser	navigator.webdriver forced false and hidden behind a Proxy, $cdc/$wdc cleanup, window.chrome rebuilt, plugin and mimeType arrays, Battery API, timezone forced to America/New_York, history.length raised	Headless and automation detection
Poisoning fingerprints	Canvas pixel noise, AudioContext oscillator jitter, Date.now and performance.now offsets, WebGL spoofed to an NVIDIA GTX 1060	Correlating deployments of the same kit
Detecting the analyst	DevTools size heuristic disabling card and CVV inputs, iframe detection hiding the body, missing-WebGL grey mask, window.open trap	A person or sandbox inspecting the page
Attacking the user's protections	MutationObserver stripping phishing and malware warning nodes, max z-index overlays, #extension-root; sendBeacon dropping cross-origin calls; injected CSP meta tags removed	Anti-phishing extensions and background reporting

Looking like a browser that belongs to someone

Hiding the automation flags. The first and largest group makes an automated browser resemble an ordinary one. navigator.webdriver is forced to false, and separately the whole navigator object is wrapped in a Proxy whose has trap denies that webdriver exists at all, which defeats the 'webdriver' in navigator check as well as the property read. Selenium and ChromeDriver leave global variables behind, so any key starting $cdc or $wdc is deleted.

Filling in what headless browsers lack. It then supplies the things a real browser has and an automated one often does not. window.chrome is reconstructed with app, runtime, loadTimes and csi. A three-entry PluginArray and a two-entry MimeTypeArray are installed with the correct prototypes. The Battery API returns a charging device at a plausible level. Intl.DateTimeFormat is forced to America/New_York, because headless crawlers frequently report UTC. history.length is raised to a random 3 to 8, because a fresh automated context has a history of one.

Noise rather than fixed lies. Fingerprint surfaces are not spoofed to constants but poisoned with randomness: canvas getImageData has a small random value added to every channel, toDataURL and toBlob perturb a pixel first, an AudioContext oscillator starts a fraction of a millisecond late, and both Date.now and performance.now carry a constant random offset. WebGL is the exception and is spoofed outright, reporting an NVIDIA GTX 1060 through ANGLE, because a headless browser's software renderer is one of the cleanest automation tells available.

The point of the noise is worth spelling out. Deterministic spoofing makes every deployment of the kit look identical, and identical is clusterable. Randomised spoofing means two visits to the same page fingerprint differently, so fingerprint-based correlation across a campaign degrades.

Detecting that it is being examined

The second group watches for an analyst rather than a crawler.

The DevTools trap. A loop every second compares outerWidth to innerWidth and outerHeight to innerHeight. If either gap exceeds 160 pixels it concludes developer tools are open, and its response is specific:

document.querySelectorAll('input[type="password"], input[name*="card"],
                           input[name*="cvv"], input[name*="cvc"]')
  .forEach(function (el) {
    el.blur();
    el.setAttribute("disabled", "true");
    setTimeout(() => el.removeAttribute("disabled"), 3000);
  });

Open devtools and the card fields disable themselves for three seconds, then quietly re-enable. It does not hide the page or redirect. It makes the interesting fields inert exactly while someone is looking at them, and looks like a rendering glitch if you are not expecting it.

Sandboxes and redirect followers. If the page finds itself in an iframe it sets document.body.style.visibility = "hidden", which defeats sandboxes that load suspect pages framed. If WebGL is unavailable at all it covers the viewport with a flat grey panel. window.open is wrapped so that programmatic calls before any real user interaction return null, frustrating scanners that follow redirect chains by opening them.

Attacking the protections, not just the detection

The third group is the one that should change how you read this page, because it is not evasion of discovery. It is interference with the protections a victim is relying on at the moment they are being defrauded.

Removing the warning. A MutationObserver watches the entire document and removes matching nodes as fast as they appear:

"#safe-browsing-warning", "#phishing-warning", "#malware-warning",
"[id^='safebrowsing']", "[class*='safebrowsing']",
"[class*='phishing']",  "[id*='phishing']",
"[class*='malware']",   "[id*='malware']",
"div[style*='z-index: 2147483647']",
"#extension-root", "#chrome-extension-overlay"

Those last three are the notable ones. 2147483647 is the maximum 32-bit integer and the z-index a browser extension reaches for when it wants to cover a page with a warning nothing can sit on top of. #extension-root and #chrome-extension-overlay are extension container conventions. This is not anti-crawler code. It is written to strip an anti-phishing extension's interstitial off the screen of a person who installed that extension precisely so they would be warned.

Silencing the report. Alongside it, navigator.sendBeacon is replaced with a version that silently returns true for any cross-origin target while passing same-origin calls through. Beacons are how extensions and telemetry report a suspicious page in the background. The kit lets its own reporting out and drops everyone else's, while returning the success value the caller expects. A separate handler removes any <meta http-equiv="Content-Security-Policy"> that appears in the document, since injecting a restrictive CSP is one way a defensive extension neuters a page.

The mouse gate, and a contradiction inside it

The last group governs submission, and the two halves of it disagree in a way that is instructive.

Two routines that disagree. One routine synthesises mouse movement, dispatching a fabricated mousemove every 800 to 3000 milliseconds so the page never looks motionless. Another routine gates form submission on at least three real movements. They would cancel out, so the script wraps document.dispatchEvent to raise a _synthetic flag while its own events are in flight and ignores anything counted during that window.

The kit therefore lies about movement outward while refusing to believe its own lie inward. The fabricated events exist for anything watching from outside for the stillness that betrays automation. The gate exists because the operator does not want submissions from something that never moved.

Submit with fewer than three genuine movements and the handler calls preventDefault and stopImmediatePropagation, then after 800 milliseconds reassigns the button's own text to itself, a no-op that changes nothing on screen. The form does not submit, and no error explains why.

Typing rhythm, kept. A keystroke timing recorder runs alongside, keeping the last thirty inter-key intervals in window.__keyTimings. It is passive and never blocks input. Typing rhythm is among the harder signals to fake convincingly, and retaining it suggests either present or intended scoring of how human a visitor's typing looks.

What it leaks

One detail in the file points outward. The referrer spoof picks from a fixed list:

var _refCandidates = [
  "https://www.namecheap.com/cart/",
  "https://www.namecheap.com/domains/",
  "https://www.namecheap.com/hosting/",
];

The page impersonates Spaceship. The referrer it claims is Namecheap, a different registrar. Inference. The likely intent is that a visitor arriving at a payment form from a registrar's cart looks more legitimate to a heuristic than one arriving from nowhere.

The mismatch is the useful part, and it reads as templated tooling carrying strings left over from a different target, with the branding updated and the referrer list not. Kits reused across brands leave exactly this kind of residue, and residue is what turns one page into an inventory.

What the public record knew about it

We checked what a researcher would have found without the URL in hand. The answer is nothing.

Certificate Transparency. A crt.sh query for online-acc.website returned no certificates at all. The certificate exists, we read it off the wire, and Let's Encrypt logs everything it issues. The likeliest explanation is indexing lag against a domain barely a day old. Either way, the practical result on the day it mattered was an empty answer.

URL scanning corpora. A urlscan.io search for online-acc.website returned zero scans. Nobody had submitted it, so no screenshot, no DOM, no verdict.

That second result becomes interesting when you compare it against what the same corpus does know. A search for hosts carrying a spaceship label, excluding the company's own domain, returns over thirteen hundred results. Reading through them, almost all are Spaceship's own infrastructure, such as spaceship.host shared servers and launch1.spaceship.net, alongside unrelated sites that happen to use an ordinary English word.

What the corpus contains, in other words, is the easy cases. Where a brand-adjacent string sits in a registrable domain, scanners see it, because someone eventually submits it and permutation tooling generates it. The one host built to sit outside that pattern was absent from the corpus entirely.

That is the thesis of this article arriving as a measurement rather than an argument. The visibility of the public research ecosystem is not evenly distributed. It is concentrated on exactly the impersonation technique that is easiest to enumerate, and it thins to nothing on the technique that requires an attacker to own one unremarkable domain.

The uncomfortable part

None of this is new. Putting a brand in a subdomain of a domain you control is an old trick, and so is a wildcard certificate.

What is worth sitting with is the shape of the failure. Four independent methods, built to cover each other's gaps, are defeated by one page for four unrelated reasons. The redundancy is an illusion, because each channel depends on the attacker populating a field they are free to leave empty.

The method that succeeds here is retrieving the document and searching its text. It is less visible than a feed of newly registered domains or newly issued certificates, and it is built out less often, even though it answers a question the other two cannot.

How to detect this class of page

Nothing here requires new infrastructure. It requires pointing existing infrastructure at the document body instead of at the domain name.

Search rendered content, not just titles and domains. If you run or buy a scan corpus, the query that finds this page is a full-text search for the brand's product vocabulary across page bodies. The brand name alone is too noisy to run. Product names are not.

Build the vocabulary list from your own interface, not from a dictionary. For a registrar that means the names of features a customer sees after login. Ask Alf, Launchpad and Library are the obvious ones here. Add CSS class names and asset filenames, because logo-spaceship and spaceship.png are artefacts of copying and nobody types them by accident.

Hunt the toolkit, not only the brand. This kit leaves globals with unusual names. A corpus search for __antibotReady, __keyTimings or __hasRealMouseMovement finds pages using the same anti-bot script regardless of which brand they wear that week. So does the hardcoded WebGL string it reports, and so does the decoy title list.

Treat a wildcard certificate on an unfamiliar domain as an unresolved question, then take it to DNS. CT will tell you *.example.website exists and will never tell you what lives to the left of the dot. Because the wildcard is on the certificate and not on DNS, every branded hostname the operator actually uses has a DNS record, so passive DNS is where the answer is. Resolving a list of your own brand labels against known wildcard domains is cheap and worth automating: on this domain that query returns NXDOMAIN for everything except the one host in service.

Watch for pages that fight your extensions. A page that removes high z-index overlays, strips injected CSP meta tags, and swallows cross-origin sendBeacon calls is not defending itself against bots. It is defending itself against the user's own protections, and that behaviour is itself a strong signal.

Indicators of compromise (IoCs)

Hostile hosts are defanged. Source records how we came by each row, and Confidence how firmly it is established: High means we observed it ourselves, Medium means it comes from the reporter's analysis and we could not independently reach the document to confirm it.

Network indicators

Indicator	Type	Confidence	Source
spaceship.online-acc[.]website	Phishing host, brand in subdomain	High	Directly observed
online-acc[.]website	Registrable domain, attacker-controlled	High	RDAP and DNS
*.online-acc.website	Wildcard SAN, Let's Encrypt, notBefore 17 Sep 2026	High	Certificate read off the wire
172.67.130.197, 104.21.8.243	Cloudflare edge addresses	High	Directly observed
leonidas.ns.cloudflare.com, ophelia.ns.cloudflare.com	Authoritative nameservers	High	RDAP
Registration timestamp 2026-09-17 08:54:38 UTC	Domain under 48 hours old at analysis	High	RDAP
Name.com, Inc. (IANA 625)	Sponsoring registrar	High	RDAP
clientTransferProhibited, addPeriod	Registry status at time of analysis	High	RDAP
[email protected]	Registrar abuse contact for takedown	High	RDAP
No wildcard DNS record; only spaceship resolves	Each hostname needs its own record	High	Directly observed

Web content indicators

Indicator	Type	Confidence	Source
/spcc/index.html	Card capture page	High	Observed as a path
/spcc/loading.html	Holding screen after submission	Medium	Reporter supplied
/spcc/sms.html	One-time code capture step	Medium	Reporter supplied
config.php	POST target for harvested data	Medium	Reporter supplied
f_p3 labelled account-ref	Card number under a misleading name	Medium	Reporter supplied
f_url	Hidden honeypot input	Medium	Reporter supplied
_ab_gate	Display overlay holding content at opacity: 0	Medium	Reporter supplied
alt="Spaceship logo", spaceship.png, logo-spaceship	Copied brand assets and class names	Medium	Reporter supplied
"Ask Alf", "Launchpad", "Library"	Product vocabulary, confirmed genuine	High	Compared against spaceship.com

Script indicators

Indicator	Type	Confidence	Source
/spcc/antibot.js	Evasion script, 27 techniques	High	Full source reviewed
__antibotReady, __keyTimings, __hasRealMouseMovement	Unusual JavaScript globals	High	Source reviewed
ANGLE (NVIDIA, NVIDIA GeForce GTX 1060 6GB Direct3D11 vs_5_0 ps_5_0, D3D11)	Hardcoded WebGL renderer string	High	Source reviewed
"Checkout - Secure Payment", "Card Services", "Identity Verification" and five others	Rotating decoy titles	High	Source reviewed
Selector list targeting [class*='phishing'], #extension-root, div[style*='z-index: 2147483647']	Warning-stripping MutationObserver	High	Source reviewed

Campaign pivots

Indicator	Type	Confidence	Source
namecheap.com/cart/, /domains/, /hosting/	Spoofed referrer values naming a different registrar	High	Source reviewed
Cloudflare Web Analytics beacon token	Per-operator, not per-domain; pivots to sibling pages	Medium	Reporter supplied

What impersonated brands and customers should do

If you are the brand. Take the hostname down rather than the domain. online-acc[.]website may host many subdomains for many brands, and an abuse report naming only the apex invites a reply that the domain is not itself infringing. Report the specific host and path, supply the certificate details and capture times, and send it to the hosting provider and the CDN as well as the registrar. Then search your own scan data for the product vocabulary, because an operator who built a template does not run one page.

If you are a customer who filled the form. Card and expiry alone are damaging. Card plus CVV plus a one-time code means a transaction may already have completed. Contact the card issuer, say explicitly that a one-time code was disclosed, and ask for the card to be replaced rather than merely monitored. A page that asks for an SMS code is asking for the control your bank uses to stop the transaction.

If you are defending a workforce. The lesson is not "look at the URL". The brand was in the URL, in the position a hurried reader checks. Hostname reading as a defence assumes people parse right to left from the registrable domain, and most do not.

How PhishEye helps

PhishEye monitors for impersonation using page content as well as domain and certificate signals, which is what finds pages of this shape, and runs the takedown through to registrar and host escalation with the evidence those parties require. Our phishing takedown service and brand protection monitoring cover the detection and removal sides respectively.

Frequently asked questions

Is online-acc[.]website a malicious domain? The specific host spaceship.online-acc[.]website serves a card-harvesting page. The registrable domain is the attacker's, and the wildcard certificate means it can serve any number of other branded subdomains. Treat the host as malicious and the domain as attacker-controlled infrastructure worth watching.

Why did Certificate Transparency not catch this? CT records certificates, not hostnames. The certificate covers *.online-acc.website, so every branded subdomain the operator invents is already covered by a certificate that was logged once and contains no brand string. There is nothing further for CT to report.

Is the page hiding the brand from me? Only from a camera. The overlay holds content at zero opacity, so the markup, including the logo filename and product vocabulary, is present the whole time. Anything that reads the document rather than photographing it sees the brand immediately.

What is the single highest-signal string? "Ask Alf". It is a product name the brand invented, it carries no ordinary English meaning, and effectively no unrelated page contains it. The brand name on its own is far noisier.

Does this mean domain and certificate monitoring are pointless? No. They answer different questions from content search, and a programme running the first two without the third has a gap this page fits through exactly.

References

• Certificate Transparency and RFC 6962

• ICANN — EPP status codes, including addPeriod

• EMVCo — 3-D Secure

• MDN — Navigator.sendBeacon()

• PhishEye — How to take down a phishing website

• PhishEye — Detecting typosquatting domains

• PhishEye — PrizeBuzz: one kit, 29 brands