HOSTING RENEWAL - BILLING PHISHING

"Your domain expires in 3 days." It came from a real publisher's server.

This one landed in our own support inbox on 10 October, wearing a hosting company's branding, with a Manage subscriptions button that went to a payment page on a small Dutch publisher's website. The publisher had nothing to do with it. Here is the DNS test that proves that in about twenty seconds, and why it decided exactly what we were allowed to block.

SB

SafeBrowz Threat Research Security Research · 14 October 2026 · 10 min read

The email

Display name "HostingerBilling". Subject line: "Your domain name will expire in 3 days, please renew". Full brand styling, the right logo, a tidy layout, and a single prominent button labelled Manage subscriptions. It arrived at our support address, which is published on our site, so there was no mystery about how it found us.

The pressure is well chosen. Losing a domain is not like missing a software renewal: your site goes dark, your email stops, and anyone who has ever had to recover a lapsed domain knows it is a bad afternoon. Three days is short enough to panic and long enough to feel real. A reader who manages one website and has not thought about its renewal date in a year is the exact target.

The button did not go to the hosting company. It went to a payment form on a subdomain of a small publisher in Delft, a genuine business that has been online since 2019 putting out work on Tibetan and Mongolian art. That is the part worth slowing down on, because it is both why the email was convincing and why the response required care.

The twenty-second DNS test that settles it

When a phishing page lives on a subdomain of a real company's domain, there are two very different explanations, and they call for opposite responses. Either the real owner's hosting has been compromised and is serving the page, or somebody has pointed that one subdomain at their own server somewhere else. You can tell which in about twenty seconds, and you do not need any special tooling: resolve the main domain and the suspicious host separately, then look at who owns the two addresses.

We did that on 10 October and repeated it while writing this, on 14 October. The apex and its www both resolve to 35.204.150.5, which belongs to Google LLC, the publisher's own cloud hosting. The phishing subdomain resolves to 167.17.76.77, which belongs to Redoubt Networks in the United States. Two different networks with no relationship to each other.

That contrast is the answer. The publisher's website is where it has always been. One subdomain record was pointed away from their hosting to somebody else's server, which is what a DNS hijack of a single record looks like, and it means their actual site was never serving the phishing page. If instead both had resolved to the same provider, we would be looking at a compromised host and a very different conversation with the owner.

Anyone can run this. On a Mac or Linux terminal, dig +short example.com and dig +short suspicious.example.com, then search the two addresses. On Windows, nslookup does the same job. If the suspicious host sits on a different network from the main site, the main site is almost certainly a victim rather than a participant.

Why we blocked one subdomain and not the domain

This decided what we were allowed to do. A block list entry on the apex would have marked a real publisher's entire website as dangerous, to every user we have, indefinitely, over something they did not do and probably did not know about. So the entry covers customerservice[.]cloudpressdelft[.]nl and nothing else. Their own site, their www, and any other subdomain are untouched, and we verified that boundary held after adding it rather than assuming it.

We are writing that reasoning down because it is a rule rather than a judgement call, and because the opposite mistake is common and expensive. Blocking the parent domain is the lazier action and it looks more thorough. It is also how a scanner ends up telling thousands of people that a small business in Delft is a threat.

The same restraint applies to a free host or a platform. A phishing page on a subdomain of a large hosting platform, a site builder or a shortener never justifies blocking the platform, and a page on a path under a document service never justifies blocking the service. The narrowest entry that stops the actual page is the correct one.

Where we failed on this one

Before we added that entry, our own scanner returned safe with a high score for the phishing subdomain. That is a real miss and it is worth explaining rather than skipping, because the reason generalises.

Reputation signals are gathered at the level of the registered domain. The publisher's domain was six years old, had a clean history and a real site on it, and a subdomain inherits all of that by default without having earned any of it. That inheritance is precisely why an attacker wants a subdomain on an aged domain rather than a fresh registration of their own: it arrives pre-trusted, by design, in most systems that score domains. It is the same mechanism behind a job scam arriving from a genuine university address, and the reason a "was this domain registered recently" check is a weak defence on its own.

What should catch it is the page, not the domain: a form collecting card details while wearing a hosting brand that does not own the domain it sits on. That is a content judgement, and it is the layer we lean on when reputation has nothing useful to say.

What a real renewal notice looks like

Two things are worth knowing about the real thing, and one of them is a useful general rule.

First, the sender name in your mail app is decorative. "HostingerBilling" is a display name, and anyone can set theirs to anything; it is not an address and it proves nothing. Tap or click it to expand the actual address and read what comes after the @. Hostinger's domain, hostinger.com, has been registered since 2002 through the company's own registrar business, and it publishes a DMARC policy of reject that explicitly covers subdomains too, so a message truly forged from it would be thrown away before it reached you. That is exactly why the scam did not try: it used an unrelated domain and dressed up the display name instead.

Second, a renewal is something you can always check from the other direction, and that is the move that makes the email irrelevant. Your domain's expiry date lives in your provider's control panel, at hpanel.hostinger.com for Hostinger, and it is also public: a WHOIS lookup on your own domain shows the expiry date without you logging in anywhere. If the panel says you are paid up until next August, an email claiming three days is answered.

Flag a renewal link before you pay an invoice

SafeBrowz is a browser extension and Android app that reads a page before you interact with it, in three layers. Layer 1 runs in the extension itself: URL patterns and homograph checks that catch a lookalike address without a network call. Layer 2 is server-side, and it is where our 550+ brand database, our own block list and the external threat feeds live; this exact subdomain sits there now, as an entry for that one host rather than for the domain. Layer 3 is AI content analysis in over 100 languages, which reads what the page is asking for and flags a card form wearing a brand that does not match the domain under it. Worth being straight about which of those could have helped here: the host carried no brand name to match, so the page itself was the only thing left to judge.

Detection comes from threat-intelligence research and our own brand database, not from user browsing data. SafeBrowz does not store per-user browsing history.

Honest scope: we did not catch this one. It returned safe from our scanner until we read the email, ran the DNS comparison above and added the entry by hand, and the reason was the inherited reputation of an aged parent domain. A browser extension also cannot see your inbox, so the display-name check and the expanded sender address are yours to do, and no scanner replaces them. What the product is actually for here is the moment after the click, when a page asks for a card.

The check, in order

1. Expand the sender address. Not the display name. If it is not your provider's own domain, you are done.
2. Do not use the button. If you want to know what it leads to, paste the link into a checker rather than opening it.
3. Go in the other direction. New tab, your provider's control panel typed by hand, and read the renewal date there. Or run a WHOIS on your own domain, which shows the expiry without logging in.
4. If the host looks like a real company's subdomain, compare the addresses. Resolve the main domain and the suspicious host. Different networks means the main site is a victim, and worth telling them.
5. Pay only from inside the panel. Never from a link in a notification, even a genuine-looking one.

Red flags in a renewal or billing email

• A countdown on something you can verify yourself. Expiry dates are not secret. Three days is pressure, not information.
• The payment page is not on your provider's domain. Read the host in the address bar, not the branding on the page.
• A display name doing the work an address should do. "HostingerBilling" is typed text. The address after the @ is the fact.
• A card form for a renewal you normally pay from the panel. Billing lives in your account, not in your inbox.
• A host that is a brand-ish subdomain of something unrelated. A support or customerservice subdomain on a domain that has nothing to do with your provider is the shape to remember.

Add to Chrome Add to Firefox Add to Edge Get it on Google Play