The Dark Army

Tag: phishing infrastructure

  • Dissecting the GOV.UK Notify Platform: The API Stack Sending Millions of Official UK Alerts and Why Spoofing It Is Dangerously Plausible

    Dissecting the GOV.UK Notify Platform: The API Stack Sending Millions of Official UK Alerts and Why Spoofing It Is Dangerously Plausible

    Every time your GP surgery texts you a prescription reminder, or HMRC drops you an email about your self-assessment deadline, there’s a good chance that message came through GOV.UK Notify. It’s the Cabinet Office’s centralised messaging platform, quietly powering tens of millions of SMS and email alerts a year across NHS trusts, local councils, the DWP, and more. Most people receiving those messages have no idea it exists. That’s exactly what makes it interesting from a security angle.

    I’ve been pulling apart the Notify API documentation and watching how the platform actually behaves in production. What I found is a well-engineered system with some genuinely smart design choices, sitting inside a trust model that attackers can abuse without touching a single line of Notify’s own code.

    Dark server rack infrastructure powering the GOV.UK Notify API platform
    Photo by Christina Morillo on Pexels

    What GOV.UK Notify actually is

    Notify is a Government Digital Service (GDS) product. Any UK public sector organisation can apply for access, and once approved they get API credentials to send templated emails and SMS messages through the platform. The API itself is RESTful, token-authenticated, and documented openly at notifications.service.gov.uk. GDS publishes the backend code on GitHub too, which is useful for anyone who wants to understand what’s running under the bonnet.

    The architecture is fairly conventional. Client services authenticate with a bearer token (a JWT, specifically), POST to the /v2/notifications/email or /v2/notifications/sms endpoints with a template ID and the recipient’s address or mobile number, and Notify handles the actual delivery via third-party providers. Email goes through commercial transactional mail infrastructure; SMS goes through aggregators with UK carrier connections. The platform abstracts all of that away, which is the point.

    The sender ID trust model and why it matters

    Here’s where the GOV.UK Notify API setup gets genuinely interesting. For SMS, Notify lets organisations configure a custom alphanumeric sender ID. This is the name that appears at the top of your text message instead of a phone number. NHS trusts routinely configure these as “NHSRemind”, “YourNHS”, or similar. Councils use variants of their own names. HMRC uses “HMRC”.

    The problem is that alphanumeric sender IDs in the UK are managed by mobile network operators and their aggregator relationships. There is no central registry that makes “HMRC” an exclusive label that only HMRC can use. A bad actor with a bulk SMS aggregator account can send messages with the exact same sender ID. The message will land in the same conversation thread on an iPhone as a legitimate HMRC text, because iOS and Android group by sender name string. That’s not a Notify vulnerability. It’s a telecoms infrastructure problem that Notify’s output happens to make worse by normalising the expectation that these names mean something.

    For email, Notify enforces DKIM signing on outbound messages and requires sending domains to pass SPF and DMARC checks. That part of the stack is actually solid. Messages sent through Notify from a properly configured service will pass authentication checks. But that also means a phishing campaign that mimics a Notify-style email, using a typosquatted domain like “nhs-notifications.co.uk” with its own valid DKIM setup, looks almost identical to a real Notify email in any mail client that doesn’t surface raw headers. Anyone running email tester services on Notify output will see it score well precisely because the authentication infrastructure is properly configured.

    Terminal output showing GOV.UK Notify API JSON response data
    Photo by Bibek ghosh on Pexels

    Template trust and the social engineering surface

    Notify messages are template-driven. Each approved service builds templates inside the Notify dashboard, and those templates get a fixed ID. When the API call goes out, it references the template and injects personalisation fields. The templates themselves have a particular, recognisable house style: short, plain-language, action-oriented. “Your appointment is on 14 May. Reply YES to confirm or call 0300 xxx xxxx.” That format is now so embedded in UK public consciousness that spoofed messages using the same tone and structure bypass a lot of the mental alarm bells people should be ringing.

    The attack vector I’d flag here isn’t breaking into Notify itself. It’s simulating Notify’s output through independent channels. An attacker who understands how Notify messages are formatted, what sender IDs look plausible, and which services their targets are likely subscribed to (NHS, DWP, council tax) can build extraordinarily convincing lures. The social engineering payload is essentially the platform’s own design language, turned against recipients.

    This connects to a broader pattern I’ve written about before. The UK phishing domain infrastructure piece from earlier this year covers how cheap .co.uk registrations and fast-flux hosting let campaigns stand up convincing-looking service sites in under an hour. Combine that with a spoofed Notify-style SMS pointing to a fake “verify your appointment” landing page, and you’ve got a multi-stage attack chain that requires no Notify compromise at all.

    API security: what Notify gets right

    To be fair to GDS, the Notify API isn’t badly designed. JWT authentication with rotating service-specific API keys is sensible. Separate keys for test and production environments reduce the blast radius of a leaked key. The platform maintains delivery receipts and status tracking through callback URLs, which means consuming services can audit what was sent and when. Rate limiting is in place, though the specific thresholds aren’t publicly documented.

    The bigger risk on the API side is credential hygiene on the consuming service’s end. I’ve seen enough UK government and NHS repositories leaking secrets on GitHub to know that Notify API keys in committed config files are not a hypothetical. A leaked production key gives an attacker direct sending capability from a legitimate service identity, complete with that service’s configured sender ID. At that point you’re not spoofing anything; you’re just using the platform exactly as intended, but for someone else’s recipients.

    What consuming services should actually be doing

    Any public sector team integrating with the GOV.UK Notify API should treat the API key like a private signing key: never in version control, always injected through environment variables or a secrets manager, rotated on a schedule and immediately after any suspected exposure. The GDS documentation says this, but documentation doesn’t always survive contact with a rushed deployment.

    Beyond credential management, there’s a case for including message authenticity signals in the templates themselves. Something as simple as a unique reference number that recipients can verify on the originating service’s website creates a second check. It’s not cryptographic, but it raises the cost of a convincing fake.

    On the SMS sender ID front, the options are more limited because the problem lives at the telecoms layer rather than the application layer. Ofcom has consulted on SMS sender ID protection measures before, and the debate around a UK equivalent of a registered sender registry has been slow-moving. Until that changes, organisations using Notify for high-stakes notifications (benefits decisions, medical appointments) should consider whether SMS is the right channel at all for anything requiring a follow-on action from the recipient.

    The bigger picture: trusted infrastructure as an attack surface

    The GOV.UK Notify API is a good product solving a real problem. Centralising government messaging infrastructure reduces duplicated effort, improves deliverability, and makes it easier for small councils and NHS trusts to send professional communications without building their own transactional mail stack. That’s all genuinely useful.

    But trusted infrastructure attracts attackers because trust is exactly what they’re trying to steal. The more consistently Notify-style messages look and feel authoritative, the more valuable the template becomes for anyone trying to manufacture that same authority fraudulently. It’s the same dynamic that makes DVLA’s vehicle data lookup surface attractive: legitimate systems, widely relied upon, create known expectations that adversaries can exploit from the outside without ever touching the system’s own internals.

    My take is that GDS understands this tension, but the platform’s trust model has outpaced the defensive messaging around it. Most people in the UK have no mental model for how GOV.UK Notify works. They just see an official-looking text from “HMRC” and act on it. That gap between platform sophistication and public awareness is where the real risk lives, and no amount of JWT rotation fixes that.

  • Dissecting UK Phishing Infrastructure in 2026: How Cybercrime Groups Register, Host, and Burn Domains Inside .uk and .co.uk Namespaces

    Dissecting UK Phishing Infrastructure in 2026: How Cybercrime Groups Register, Host, and Burn Domains Inside .uk and .co.uk Namespaces

    Phishing isn’t new. But the machinery behind it has got considerably more sophisticated, and nowhere is that clearer than in campaigns targeting UK brands. I’ve spent time pulling apart the patterns behind lures impersonating Lloyds Bank, HMRC, and Royal Mail, and what you find underneath is a genuinely professional operation: deliberate Nominet registration abuse, layered hosting, and DNS tricks that make attribution a nightmare. This is a breakdown of how UK phishing domain infrastructure in 2026 actually works, from the moment a domain gets registered to the moment it gets burned and replaced.

    Anonymous hacker at dark terminal screens representing UK phishing domain infrastructure 2026
    Photo by Rafael Minguet Delgado on Pexels

    How attackers register convincing .uk and .co.uk domains

    The .co.uk namespace is a gift to phishers. Nominet’s registration system, accessed through accredited registrars, requires no real identity verification for the registrant beyond what the registrar chooses to collect. Privacy proxy services, reseller accounts under lax KYC registrars, and prepaid card payments all combine to make the initial registration almost untraceable. The attacker’s goal is to get a domain that looks authoritative on a mobile screen where the full URL is already truncated.

    Typical patterns I’ve observed across campaigns include homograph-adjacent tricks: lloyds-secure-login.co.uk, hmrc-refund-portal.uk, royalmail-redelivery-gb.co.uk. The .uk second-level domain (rather than .co.uk) has become increasingly popular because it looks shorter and slightly more official. Nominet actually publishes guidance on suspicious registrations, but the volume is too high for manual review to catch most of them before they go live. Registrations often cluster in batches, a single actor might register 15-20 similar domains in one session, cycling through registrar accounts to stay under velocity checks.

    One pattern that’s become very common is typosquatting combined with keyword stuffing: inserting words like “secure”, “verify”, “update”, “gb”, or “official” into the domain string. These pass automated plausibility checks because they don’t exactly match the brand’s registered trademark. Nominet’s Rapid Response Service can suspend domains within 24 hours once reported, but that window is usually long enough for a campaign wave to run its course.

    Bulletproof hosting and why it’s still working

    Once a domain is registered, it needs infrastructure that won’t fold the moment someone files an abuse complaint. That’s where bulletproof hosting (BPH) comes in. The term is slightly misleading, no host is literally immune to takedowns, but BPH providers are structured to maximise the time an operation stays live. They’re typically registered in jurisdictions with slow or non-existent response to foreign abuse reports, and they often front through legitimate-looking resellers or sub-allocations of IP space from larger providers.

    In UK-targeted campaigns, I’ve seen phishing pages hosted across a mix of Eastern European ASNs, offshore VPS providers, and occasionally inside major cloud providers via compromised trial accounts. AWS and Azure trial accounts, spun up with stolen card details, give attackers access to IP ranges that many corporate firewall blocklists explicitly trust. A Royal Mail phishing page sitting on an AWS IP with a valid TLS certificate and a .co.uk domain is going to slip past a lot of filters.

    Fast-flux DNS: the trick that keeps phishing pages alive

    Fast-flux DNS is the technique that makes takedowns genuinely painful. Rather than pointing a domain at a single server, a fast-flux setup rotates through dozens or hundreds of IP addresses, each with a very low TTL (often 60 seconds or less). A takedown request that successfully nullroutes one IP is irrelevant; by the time it’s processed, the DNS has already moved on. Some operations run double-flux, rotating not just the A records but the nameservers themselves.

    The actual phishing content typically lives on a stable backend server, while the rotating IPs are just proxies or compromised residential machines (often recruited via malware botnets). From the victim’s perspective, the page loads normally. From a takedown team’s perspective, there’s no single throat to choke. UK ISPs operating under the IWF’s blocking infrastructure can push URL-level blocks, but fast-flux makes IP-level blocking nearly useless.

    The NCSC’s Early Warning service flags some of this, if you’re curious how far that visibility actually extends, my breakdown of how the UK’s threat intel platform works and where it goes blind is worth a read alongside this. Spoiler: fast-flux infrastructure in particular is a known gap.

    Certificate transparency log abuse: how phishers use CT logs as a launch pad

    Here’s one that doesn’t get talked about enough. Certificate Transparency (CT) logs, specifically services like crt.sh, are public databases of every TLS certificate issued. They exist to make the web more trustworthy. Phishers have flipped that around.

    When a security researcher or brand protection team registers a new domain to monitor, that registration shows up in CT logs almost immediately. Phishers run automated watchers on CT logs looking for newly issued certificates tied to brand keywords. Spot lloyds or hmrc in a new cert? Clone the target’s legitimate page, spin up infrastructure under your own similar-looking domain, and race to get your campaign live before the legitimate cert owner’s page is even indexed. It’s adversarial intelligence gathering from public infrastructure.

    The same technique works in reverse for defenders, monitoring CT logs for your own brand strings is a reasonable early-warning tripwire. But it requires dedicated tooling and someone awake to action the alerts.

    The HMRC lure playbook and why it works so well

    HMRC lures are perennially effective because they exploit a real emotional trigger: money owed or refunds due. I’ve looked at dozens of these campaigns and the template is remarkably consistent. The landing page mimics the GOV.UK design system almost pixel-perfectly, right down to the crown logo and the specific font stack. The form collects National Insurance number, date of birth, and bank details in sequence, each step looking entirely plausible because government forms genuinely do ask for all of these in roughly this order.

    What’s interesting from an infrastructure angle is that HMRC lures tend to use domains registered well in advance of campaign launch, sometimes weeks ahead. The domain sits parked or serves a generic holding page while the attacker waits for an optimal send window (typically the week after a tax deadline, when people are anxious about their returns). This parking behaviour means the domain passes initial reputation checks that blocklists run against newly registered domains. By the time the phishing page goes live, the domain is days or weeks old and looks seasoned.

    This connects to a broader pattern of data abuse I’ve covered before: if you want to understand how personal data ends up in targeting lists that make these lures so precise, how UK electoral roll data flows into commercial data broker pipelines explains exactly how attackers get the seeds for their victim lists.

    The burn cycle: how fast domains get discarded

    The lifecycle of an active UK phishing domain is short. My reading of campaign patterns suggests most domains are considered spent within 48 to 72 hours of the main send wave. Blocklists and automated scanners catch them, abuse reports hit the registrar, and the phishing kit moves to the next pre-registered domain in the queue. The attacker has already registered the replacements. This is why bulk domain registration is so central to modern phishing operations, it’s not one domain, it’s a magazine of them.

    The actual phishing kits themselves often get reused across multiple domains, which is useful for attribution. Kit fingerprinting, identifying shared code, identical file structures, specific encoding patterns, is one of the more reliable ways threat intel teams track a single actor across dozens of burned domains. Palo Alto’s Unit 42 and the NCSC both publish periodic reports on kit fingerprints tied to UK-targeting campaigns, and the consistency is often striking.

    For defenders specifically: if your organisation’s brand is a regular lure target, monitoring Nominet’s WHOIS data for keyword registration patterns, subscribing to CT log alerting, and feeding your SIEM with takedown velocity data will give you a much clearer picture than waiting for user reports. And if you run your own hosted infrastructure, the risk of it being cloned for credential harvesting is real, particularly if you’ve ever accidentally pushed config data publicly, which is more common across UK organisations than anyone wants to admit.

    The infrastructure behind UK phishing campaigns isn’t improvised. It’s methodical, operationally aware, and specifically tuned to outlast standard takedown timelines. Understanding each layer of it is the only way to push back effectively.

    Frequently Asked Questions

    How do phishing domains targeting UK brands get registered so quickly?

    Most are registered through accredited Nominet registrars using privacy proxy services and minimal KYC. Attackers often pre-register batches of domains days or weeks before a campaign launches, so they’re ready to swap in the moment one gets blocked or reported.

    What is fast-flux DNS and why does it make phishing so hard to take down?

    Fast-flux DNS rotates the IP addresses attached to a domain every 60 seconds or less, so blocking a single server doesn’t kill the phishing page. The actual content lives on a stable backend, while the rotating IPs, often compromised home machines, act as disposable proxies.

    How are certificate transparency logs being abused by phishing groups?

    Phishers run automated watchers on public CT log services like crt.sh, looking for newly issued certificates tied to brand keywords. When a target’s new cert appears, attackers clone the page and race to launch a campaign under a similar-looking domain before the legitimate site is even indexed widely.

    Why are HMRC and Royal Mail phishing lures so convincing?

    Both use publicly familiar design systems, GOV.UK’s layout for HMRC, and Royal Mail’s standard parcel notification templates, that victims have genuinely seen before. The forms ask for data in the same sequence real services do, which makes each step feel routine rather than suspicious.

The Latest