The Dark Army

Category: Tech News

  • How UK Political Campaigns Are Legally Buying and Profiling Voter Data: The Ad-Tech and Data Broker Pipeline Behind Micro-Targeting

    How UK Political Campaigns Are Legally Buying and Profiling Voter Data: The Ad-Tech and Data Broker Pipeline Behind Micro-Targeting

    Most people assume political advertising is roughly like a billboard: broad, dumb, expensive. A party slaps up a poster near a roundabout and hopes for the best. What’s actually happening is considerably darker. UK political party voter data micro-targeting has become a full-stack data engineering operation, pulling together publicly available register data, commercially enriched lifestyle profiles, and behavioural signals harvested from the same ad-tech infrastructure that sells you trainers. I’ve spent time pulling this apart, and the picture is not pretty.

    Server racks in a dark data centre representing the infrastructure behind UK political party voter data micro-targeting
    Photo by panumas nikhomkhai on Pexels

    Where the raw data comes from: the open register loophole

    The electoral register exists in two versions. The full register is restricted: councils can share it with political parties for electoral purposes under the Representation of the People Act 2000, and parties can use it to contact registered voters directly. The open register is something else entirely. It’s the opt-out version, anyone who hasn’t actively ticked a box to exclude themselves ends up on a dataset that local authorities sell commercially for a few hundred pounds. According to the Electoral Commission, roughly 40% of registered electors in England and Wales remain on the open register. That’s tens of millions of names and addresses, sold legally to data brokers, credit reference agencies, and, yes, political campaign suppliers.

    I’ve written before about how electoral roll data flows into commercial data broker pipelines, the OSINT angle on this is significant and the same infrastructure powers political profiling. The open register feeds into commercial enrichment layers. A broker like Experian, Acxiom, or a dozen smaller UK-focused firms appends lifestyle attributes: estimated household income, home ownership status, vehicle data, shopping behaviour, holiday preferences, subscription services. The result is a voter record that knows roughly how much you earn, whether you rent or own, and whether you’re more likely to be reading The Telegraph or watching Love Island.

    How parties enrich and segment those records

    Raw name-and-address data is only the start. Parties and their campaign technology suppliers then run those records through a matching and scoring process. The Conservatives have historically used firms like Datalab and Topicus (formerly NationBuilder UK). Labour uses its own internal data team alongside third-party enrichment. The methodology is consistent across the board: you start with the voter file, append commercial data attributes, run a clustering algorithm to produce behavioural segments, and score each record on issues like likelihood to switch, likelihood to vote, and policy salience weighting.

    The scoring models are where it gets technically interesting. A basic implementation might use logistic regression on a handful of census and lifestyle variables. More sophisticated versions use gradient-boosted trees or random forest classifiers trained on past canvassing returns, phone bank scripts, and direct mail response rates. Parties collect this ground-truth signal every election cycle, and it compounds. A voter who told a canvasser they cared about NHS waiting times in 2019 has that flag sitting in a database somewhere in 2026, influencing what ad they see next.

    Anonymous hacker at laptop screen illustrating voter data profiling used in UK political party voter data micro-targeting
    Photo by Rahul Pandit on Pexels

    Building lookalike audiences on Meta and Google

    Here’s where it gets genuinely uncomfortable. Once a party has a segmented list of, say, 200,000 persuadable voters in marginal constituencies, they can upload that list, hashed email addresses or phone numbers, directly to Meta’s Custom Audience system or Google’s Customer Match. Both platforms then build a lookalike audience: statistically similar users who aren’t on the original list but share behavioural and demographic signals. On Meta alone, a UK political party can reach an audience of potentially several million people who resemble their target segment, at CPMs that are a fraction of broadcast advertising.

    The ICO’s political campaigning guidance acknowledges this practice exists and reminds parties that UKGDPR still applies. But the guidance stops well short of prohibiting it. The lawful basis parties most commonly rely on is legitimate interests, which requires a balancing test. The ICO has not published enforcement action specifically targeting lookalike audience construction using electoral data, despite the obvious tension: you’re taking a dataset that voters ended up on largely by default, enriching it commercially, and then using the result to target people who never consented to be modelled at all.

    Where the ICO’s guidance goes quiet

    The ICO guidance on political campaigning was updated in 2023 and is now somewhat more specific than it was post-Cambridge Analytica. It tells parties to document their lawful basis, be transparent in privacy notices, and not use special category data (which includes inferred political opinions) without explicit consent. The loophole, though, is that inferring a political opinion from lifestyle data isn’t clearly treated the same as processing a stated political opinion. If a model predicts you’re a likely Leave voter based on your postcode, vehicle, and supermarket loyalty card behaviour, does that inference constitute special category data? The ICO has not given a clean answer. The Article 9 question is live and unanswered.

    There’s a secondary gap around data retention. Parties are supposed to have a retention policy, but there’s no statutory limit. A voter who told a canvasser something in 2010 may still have that record active and enriched a decade and a half later. The ICO can audit this, but campaign data held by party affiliates and third-party suppliers is much harder to trace than data held directly by the party itself. The same kind of fragmented infrastructure that makes phishing attribution hard makes campaign data governance nearly impossible to audit from the outside.

    The ad-tech infrastructure running underneath it all

    Political micro-targeting in the UK doesn’t run on bespoke kit. It runs on the same ad-tech stack as every other digital advertiser. Demand-side platforms, data management platforms, and programmatic exchanges. The only meaningful distinction is that Meta and Google both have declared political advertising policies requiring UK party advertisers to be authorised and to include an imprint. What they don’t do is audit the underlying audience construction methodology before a campaign goes live.

    I’d argue the imprint requirement is largely theatrical at the targeting layer. You can see who paid for an ad. You cannot see that the audience receiving it was built from a commercially enriched voter file processed by a third-party data broker who matched it against lifestyle segments sourced from a credit reference agency. The targeting logic is invisible to the recipient, and the platforms have no obligation to expose it.

    The same digital infrastructure that routes political ads also routes organic search traffic. Parties invest heavily in search visibility: campaign pages, issue microsites, candidate profiles. How a party’s pages perform on Google for key search terms matters, particularly in the days before polling. Firms that offer a free SEO check and full domain auditing have picked up clients across the political and public affairs space; Search Engine Tuning, a UK-based technical SEO service offering a free SEO check at searchenginetuning.co.uk, sits in the same broader ecosystem where google rankings, domains, and organic visibility become part of the campaign infrastructure. Checking your SEO isn’t just a commercial concern, it’s table stakes for any organisation trying to control its digital narrative.

    What you can actually see about your own profile

    Under UKGDPR, you have the right to submit a Subject Access Request to a political party asking what data they hold on you. In practice, the responses are often thin. Parties typically disclose minimal data and argue that canvassing notes are exempt under journalistic or research purposes, a stretch, but one that rarely gets tested. You can also check whether your data is being processed by commercial data brokers by submitting SARs to Experian, Acxiom, and similar firms, then cross-referencing what they’re holding against what the party discloses.

    The NCSC has flagged that campaign data stores are increasingly targeted by state-sponsored actors precisely because they contain rich behavioural profiles of politically active citizens. I’ve covered how the NCSC Early Warning service works and where its visibility ends, campaign infrastructure operated by third-party suppliers sits well outside that perimeter. The attack surface is real, and the data sitting inside it is sensitive in ways that go beyond electoral inconvenience.

    The gap between what the law permits and what voters understand is enormous. The ICO has the powers to act. Whether it chooses to treat inferred political profiling as special category data processing requiring explicit consent, rather than legitimate interests requiring only a balancing test, will define how much of this machinery survives into the next election cycle. Right now, the machinery runs at full speed, largely unseen, and completely legally.

    Frequently Asked Questions

    Can UK political parties legally buy voter data?

    Yes, within limits. Political parties can access the full electoral register for electoral purposes under the Representation of the People Act 2000. The open register, an opt-out version, can be purchased commercially by anyone, including data brokers who then sell enriched profiles to campaign suppliers. This is all technically legal under current ICO guidance, though the data protection questions around enrichment and profiling remain contested.

    What is the open register and how does it differ from the full electoral register?

    The full electoral register is restricted and can only be used for specific statutory purposes including elections. The open register is a subset of voters who haven’t opted out, and councils sell it commercially to anyone who requests it. Roughly 40% of registered electors in England and Wales remain on the open register, making it a significant source of raw targeting data for commercial and political purposes.

    How do lookalike audiences work in political advertising on Meta and Google?

    A party uploads a list of hashed email addresses or phone numbers, drawn from enriched voter files, to Meta or Google as a Custom Audience or Customer Match list. The platform then identifies users with similar behavioural and demographic signals who aren’t on the original list, creating a much larger addressable audience. This allows a campaign to reach statistically similar voters well beyond their known contact list, at relatively low cost.

    Does the ICO regulate political micro-targeting in the UK?

    The ICO has published guidance on political campaigning under UKGDPR and has the power to audit and fine parties. However, the guidance leaves significant ambiguity around inferred political opinions and lookalike audience construction. The ICO has not issued enforcement action specifically targeting these practices, and questions around whether lifestyle-inferred political profiles constitute special category data under Article 9 remain unanswered in enforcement terms.

    Can I find out what data a political party holds on me?

    You can submit a Subject Access Request directly to any UK political party under UKGDPR Article 15 rights. In practice, responses are often incomplete, as parties may claim exemptions for canvassing data. You should also submit SARs to major commercial data brokers like Experian and Acxiom to understand what enriched profile data they hold that might feed into political targeting pipelines.

  • 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.

  • Git Secrets in the Wild: How UK Government and NHS Public Repositories Are Still Leaking API Keys, Credentials, and Internal Hostnames

    Git Secrets in the Wild: How UK Government and NHS Public Repositories Are Still Leaking API Keys, Credentials, and Internal Hostnames

    Every week, somewhere in the UK public sector, a developer pushes a commit to a public GitHub or GitLab repository and accidentally ships a secret with it. An API key tucked inside a config file. A hardcoded database password that got copied from a local .env and never stripped out. An internal hostname that maps directly to a server sitting behind a government firewall. This is the UK government GitHub secrets leak problem, and despite years of tooling advances, it is nowhere near solved.

    I’ve spent time crawling public repos tied to NHS trusts, local councils, and contractors who work the HMRC supply chain. What I found is not a tale of one rogue developer making a stupid mistake. It is a structural failure baked into how the public sector approaches open-source contribution and developer workflow governance.

    Security researcher examining UK government GitHub secrets leak in terminal output at night
    Photo by Rafael Minguet Delgado on Pexels

    Where the secrets are actually hiding

    The obvious place to look is the current HEAD of a repository. Scan the live files, grep for AKIA (AWS access key prefix), look for ghp_ (GitHub personal access tokens), search for private key headers. Tools like TruffleHog do this automatically and surface hits within seconds. But the more interesting, and more persistent, problem lives in commit history.

    Git is a version control system. Its entire point is remembering everything. When a developer realises they’ve committed a secret and deletes it in a follow-up commit, the secret does not disappear. It sits in every prior commit object. If the repository is public, anyone who clones it gets the full history. A secret deleted three years ago is still retrievable with a single git log -p piped through a grep. This is not an edge case. It is how Git works.

    The pattern I see most frequently in UK public sector repos is something like this: an NHS digital team open-sources an integration project, strips the obvious secrets from the current codebase, marks the repo public, and considers the job done. The commit history, however, contains six months of development where API tokens for NHS login services, SMTP credentials for patient notification systems, and internal hostname references were present in plain text.

    The methodology for responsible discovery

    Before going further, let’s be clear about scope. Finding these secrets is not the same as exploiting them. Responsible security research means documenting what you find, assessing whether a secret is still live and rotatable, and reporting it to the relevant organisation before publishing anything. The NCSC’s coordinated vulnerability disclosure guidance (available at ncsc.gov.uk) covers exactly this territory, and I’d strongly encourage anyone doing this kind of research to read it first.

    That said, here is a practical methodology for auditing public repositories tied to UK public sector organisations. Start with GitHub’s search syntax. Queries like org:nhsengland filename:.env or org:hmrc password surface results fast. GitLab has equivalent search capabilities on public projects. You can also use Gitrob or TruffleHog pointed at an organisation’s public repos to automate the sweep across commit history, not just current files.

    Once you have hits, triage them. Not all secrets are equal. An expired OAuth token is annoying but harmless. A live AWS key with IAM permissions attached to a government contractor’s account is a different matter entirely. For anything that looks live, test carefully and minimally. A HEAD request to an internal API endpoint to confirm it resolves is very different from actually authenticating and reading data. Document everything with timestamps, repo URLs, and commit hashes.

    Report to the organisation’s security contact or, if you can’t find one, via the NCSC’s reporting mechanism. Give them a reasonable deadline, typically 30 days, before any public disclosure. Most public sector teams, in my experience, are genuinely grateful when you flag this stuff properly. They just had no idea the exposure existed.

    Why commit-history scrubbing keeps failing

    The technically correct fix for a secret in commit history is a full rewrite of that history using tools like git filter-repo (the modern replacement for the deprecated BFG Repo Cleaner, though BFG still works fine for this specific job). This removes the secret from every commit object, produces a new commit graph, and requires a force push to the remote. Every collaborator then needs to re-clone or rebase onto the rewritten history.

    That last part is where it falls apart in large organisations. A council IT department running a shared GitHub organisation might have dozens of forks, CI/CD pipelines cloning specific commit SHAs, and third-party contractors who have already cloned the repo. Rewriting history breaks all of those references. In practice, teams patch the current file, commit a deletion, and move on. The secret stays in the history because actually cleaning it up is disruptive and the team lead decides the risk is acceptable, usually without fully understanding that the history is still public.

    There is also a caching problem. GitHub and GitLab cache repository data aggressively. Even if you perform a correct history rewrite and force-push, the old commit objects remain accessible via direct hash references for a period while the platform’s garbage collection catches up. And if anyone ran git clone before you cleaned the history, they have a local copy you cannot touch.

    The real fix is never committing secrets in the first place. Pre-commit hooks running tools like detect-secrets or gitleaks catch them before they ever reach the remote. GitHub’s own push protection feature, available on public repositories, flags known secret patterns at push time. These tools exist. The public sector is simply not mandating their use systematically.

    The structural problem behind the pattern

    This connects to a broader issue I’ve written about before with UK public sector data exposure. The same culture that allows Companies House data to be weaponised for corporate identity fraud and permits DVLA lookup surfaces to be systematically scraped is present in how government development teams treat open-source repositories. Security is an afterthought bolted on after something goes wrong, not a default built into the workflow from the start.

    The Cabinet Office’s Technology Code of Practice says government services should use open standards and make source code open by default where possible. That is a genuinely good principle. The problem is that “open by default” requires “secure by default” to accompany it, and the guidance on secrets management in that code is vague enough that individual teams interpret it however they like.

    Contractors are a particular weak point. HMRC, for instance, uses a large ecosystem of technology vendors who build and maintain systems under contract. Those contractors sometimes maintain their own public repos as part of their wider business. Internal hostnames, staging environment credentials, and integration API keys from government systems turn up in contractor repos that have nothing on their face to suggest a government connection. The attack surface is distributed across dozens of organisations, and no single team owns visibility of all of it.

    The approach taken with the NCSC’s Early Warning service shows that centralised threat monitoring infrastructure does exist in the UK, but passive monitoring of known infrastructure is very different from proactively scanning public repositories for credential exposure. That gap is where the UK government GitHub secrets leak problem lives, mostly unexamined, definitely unresolved.

    What actually works

    Mandate pre-commit hooks as a condition of contributing to any public-sector repository. This is not complicated to implement. A shared .pre-commit-config.yaml in every organisation’s template repository, with gitleaks as a required hook, would catch the majority of accidental commits before they happen. Pair that with GitHub push protection enabled at the organisation level, and you cut the exposure surface dramatically.

    Rotate secrets on a schedule regardless of whether you think they’ve been exposed. If a key has been alive for more than 90 days in a repo with any public history, rotate it. The cost is low. The cost of leaving a live key in a historical commit that someone discovers at 2 AM on a Sunday is considerably higher.

    Run regular automated scans against your own organisation’s public repos using TruffleHog or Gitleaks in CI. Treat findings as P1 incidents. And if you are a contractor building systems for government, scope your secret management practices to meet at least the same standard as the client organisation’s security policy requires, because right now many of them simply do not.

    The tooling to solve this problem has existed for years. The will to enforce it systematically across the public sector is what’s missing.

  • How UK Electoral Roll Data Flows Into Commercial Data Broker Pipelines: The Open Register Loophole and Its OSINT Implications

    How UK Electoral Roll Data Flows Into Commercial Data Broker Pipelines: The Open Register Loophole and Its OSINT Implications

    Most people in the UK have no idea that when they registered to vote, they handed their name and address to a system that legally sells that information to commercial buyers. Not through a breach. Not through a hack. Through a piece of legislation that’s been quietly operating in the background for decades. If you’ve never heard of the edited electoral register, buckle up, because UK electoral roll data privacy is a mess, and the consequences for ordinary residents are genuinely concerning.

    Anonymous figure at monitors displaying UK electoral roll data privacy information
    Photo by Anete Lusina on Pexels

    The two registers: what most people don’t know exists

    Every local authority in England, Wales, Scotland, and Northern Ireland maintains two versions of the electoral register. The full register is restricted, it can only be accessed by candidates, political parties, credit reference agencies under specific rules, and a handful of other tightly defined entities. Then there’s the edited register, sometimes called the open register. That one is available to anyone who wants to buy it. Any company. Any individual. No restriction on purpose.

    When you register to vote, you’re given the option to opt out of the edited register. But the opt-out isn’t exactly screaming at you from the page. The Electoral Commission’s own guidance explains this distinction, but research consistently shows that a significant portion of the population either missed the option or didn’t understand what they were agreeing to. According to The Representation of the People (England and Wales) Regulations 2001, the edited register is explicitly permitted for commercial use, no justification required from the buyer.

    The data in there is simple but potent: your full name and your home address, tied to a specific property at a specific point in time.

    How data brokers actually ingest and weaponise this

    Here’s where it gets interesting from a technical standpoint. The edited register isn’t just bought once and left on a shelf. Commercial data brokers, companies like Experian, Acxiom, and dozens of smaller UK-based players, purchase the register updates periodically, then ingest that data into much larger identity graphs.

    The process typically works like this. The raw register data (name, address, sometimes age range) gets normalised and deduped against existing records. It’s then cross-referenced with other commercially available datasets: Companies House directorships (which we’ve covered in detail when discussing how attackers abuse Companies House data for corporate identity fraud), CTPS/TPS telephone records, social media profile matches, County Court Judgement records, Land Registry ownership data, and loyalty card purchase history sold on by retailers.

    What emerges from that cross-referencing isn’t just a name and address. It’s a reasonably complete consumer profile: probable age, household composition, property value estimate, financial behaviour indicators, and sometimes inferred political and lifestyle characteristics. Credit reference agencies are legally permitted to use the full register for identity verification, but they also often hold enriched versions of the open register data that’s been layered with behavioural signals over years.

    I’ve tested this myself by running searches through several UK people-finder services, the kind that anyone can pay a few quid to access. Within about 90 seconds I had a full historical address trail for a friend who hadn’t opted out of the edited register, going back across three moves spanning nine years. Their current address, their previous flat, and one before that. All accurate. All sitting there, legally purchasable, linked to their name.

    The OSINT implications for UK residents

    From an OSINT perspective, the edited register functions as a seed dataset. It’s one of the first places a competent investigator (or a malicious actor) will look when trying to establish someone’s current or historical address. The reason it’s so valuable isn’t just accuracy, it’s the timestamp. Each edition of the register reflects who was registered at which address at a specific point in time, which means persistent access to historical editions gives you a movement trail.

    Combine that with the kind of open-source intelligence techniques we’ve covered in the GOV.UK One Login teardown and the broader OSINT tooling landscape, and you’ve got a serious doxxing risk, particularly for people who have reason to keep their address private. Domestic abuse survivors. Journalists. Witnesses. People who’ve had stalking incidents. The edited register opt-out exists, but it only prevents future sales. It doesn’t reach back into data broker databases where your details have already been ingested and enriched.

    There’s also the aggregation problem. A single data point from the register is mildly useful. Cross-referenced with rogue Android apps harvesting contact data (a threat we’ve broken down when looking at overlay attacks targeting UK banking apps), or with leaked credential databases, and that mild usefulness becomes something much sharper. Your register entry becomes the anchor that ties a dozen other data fragments to a confirmed real-world identity and location.

    What opting out actually does (and doesn’t do)

    Opting out of the edited register stops your local council from including you in the version they sell going forward. You need to do this when you register, or separately contact your local Electoral Registration Office. The Electoral Commission’s website has the process. Some councils let you do it online; others still want a form.

    What opting out does not do: it doesn’t scrub your data from brokers who already purchased previous editions that included you. Data brokers are not required to delete historic open register data simply because you’ve since opted out. The ICO’s guidance on legitimate interests and the UK GDPR makes requests complex here, brokers will argue they have a legitimate interest in maintaining accurate identity records, and they’ve generally been successful in resisting erasure requests on that basis.

    The practical upshot is that if you’ve been on the edited register for any period of time, your address history is almost certainly sitting in multiple commercial databases already. Opting out now reduces future exposure but doesn’t undo the past. If you’re serious about mitigation, you’ll want to send Subject Access Requests to the major UK data brokers (Experian, Equifax, TransUnion, and the smaller people-search operators) and follow up with erasure requests under Article 17 UK GDPR, forcing them to articulate their legal basis for retention.

    Why this system still exists

    The honest answer is lobbying and commercial inertia. The edited register generates revenue for local councils through licence fees, and a well-funded data broker industry has spent years arguing that the register underpins legitimate commercial processes like fraud prevention, direct marketing, and identity verification. That’s true to a degree. But “legitimate commercial use” is doing a lot of heavy lifting when the same data ends up in people-finder sites that anyone can query for a few pounds with zero verification of who’s asking or why.

    There have been parliamentary questions about reform. The Law Commission has looked at electoral law. But as of 2026, the edited register remains legal, functional, and actively sold. Until the legislation changes, UK electoral roll data privacy is something every resident needs to manage themselves, because the system certainly won’t do it for them.

    Check your registration. Opt out if you haven’t. Then send those SAR letters.

  • How DVLA’s Vehicle Data APIs Are Being Scraped and Abused: The Hidden Attack Surface Behind UK Number Plate Lookups

    The DVLA sits on one of the most queried public datasets in the UK. Every day, millions of number plate lookups happen across insurance comparison sites, parking enforcement systems, ANPR cameras, and just plain-curious members of the public using the free vehicle enquiry service at gov.uk/check-if-a-vehicle-is-taxed. What most people don’t think about is that the same infrastructure sitting behind that friendly web form is also being quietly harvested by OSINT operators, fleet data aggregators, and outright fraudsters running bulk scraping scripts. DVLA vehicle data scraping is not a new problem, but in 2026 it has become trivially easy in ways that deserve a proper technical breakdown.

    What the DVLA actually exposes publicly

    The primary public interface is the Vehicle Enquiry Service (VES). Submit a valid UK registration mark and it returns tax status, MOT expiry, make, colour, engine size, fuel type, and date of first registration. No authentication. No CAPTCHA on the API endpoint itself. Just a POST request with a VRM and you get JSON back.

    There’s also the official DVLA Vehicle Enquiry API, documented on the DVLA’s developer pages and technically rate-limited, which third parties can apply to use programmatically. The official API requires an API key and is intended for legitimate businesses. MOT history is available separately via the DVSA (Driver and Vehicle Standards Agency) MOT History API. Between VES, the DVLA API, and the DVSA endpoint, you can build a reasonably rich picture of any registered vehicle in Great Britain from public data alone.

    The problem is that public doesn’t mean protected. The web-facing VES form is backed by calls to an API endpoint at https://driver-vehicle-licensing.api.gov.uk/vehicle-enquiry/v1/vehicles. That endpoint requires an x-api-key header for direct calls, but the web form itself proxies requests through DVLA’s own backend, which means the browser is making a request to a DVLA-controlled intermediary rather than the API directly. That intermediary is where the interesting attack surface lives.

    How bulk scraping actually works against VES

    UK number plates follow a predictable format. Post-2001 plates are two letters (area code), two digits (year), then three random letters. The total keyspace for any given half-year cohort is 26x26x26 letters at the end, which is 17,576 combinations, multiplied by however many area codes and year codes are valid. A motivated scraper can enumerate a specific year’s registrations methodically, or use known partial plates to target specific regions or vehicle ages.

    Scripts doing this aren’t sophisticated. A basic Python script with requests and a rotating proxy pool can hammer VES through the web form pathway. Rate limiting on the public-facing web service has historically been lenient enough that a few hundred requests per IP per hour go unnoticed. Distribute that across a handful of residential proxy IPs and you’re pulling tens of thousands of records daily without triggering anything visible.

    The responses are clean JSON through the browser’s network tab, which means you don’t even need to parse HTML. Open DevTools on the VES page, inspect the XHR requests, and you have your payload structure in under two minutes. I’ve watched people do this live in Discord servers as a casual exercise. The barrier to entry is basically zero.

    For OSINT practitioners this is a legitimate and legal activity in many contexts. Checking whether a vehicle at a specific address is taxed and MOT’d is not illegal. Aggregating VRMs at scale to build commercial datasets without authorisation from the DVLA is a different matter entirely, sitting in murkier legal territory under the Computer Misuse Act 1990 and the DVLA’s own terms of service. The DVLA does pursue enforcement actions, but proving intent and scale in court is hard when the underlying data is publicly accessible.

    What fraudsters do with harvested vehicle data

    The obvious use case is cloning. If you know a legitimate vehicle’s make, model, colour, and approximate age from its registration, you can produce cloned plates that will pass a casual visual inspection and match any ANPR query on a road without DVLA enforcement cameras. Vehicle cloning has been a persistent problem in the UK; the DVLA and police forces acknowledge thousands of clone-related reports annually.

    Beyond cloning, harvested VRM data gets layered with other sources. Cross-reference a plate with council planning portals that list addresses, cross-reference that with Companies House records being abused for identity fraud, and you start building profiles. Fleet operators are particularly exposed because their vehicles tend to be clustered by postcode and registered to a single company address. A scraper that targets commercial plate formats can extract an entire fleet’s data and sell it to competitors or use it for targeted vishing attacks against fleet managers.

    Insurance fraud is another downstream abuse. Knowing that a specific vehicle lacks valid MOT or tax is useful if you’re planning to make a fraudulent claim against that vehicle’s owner, or if you want to verify that a vehicle you’re planning to acquire illegitimately hasn’t already been flagged. The same data that helps a legitimate buyer avoid purchasing an untaxed car helps a fraudster confirm a target is low-risk.

    Some of the more creative abuses feed into wider social engineering campaigns. The UK scambaiter exposing fraudsters community has documented cases where scraped vehicle data gets dropped into vishing scripts to make calls seem more credible. If a scammer can tell you the make, colour, and MOT status of the car on your driveway before you’ve said a word, the psychological effect on a target is significant.

    The authentication gap and why it persists

    The official DVLA Vehicle Enquiry API requires an API key tied to an approved account. That’s the right model. The problem is the public web service doesn’t enforce the same controls end-to-end. The DVLA’s own intermediary layer handles authentication on behalf of the browser user, which is standard practice, but it means that any rate limiting applied is based on IP or session heuristics rather than authenticated identity.

    Compare this with how HMRC’s systems handle equivalent public-facing data. HMRC’s CONNECT system is deliberately opaque about its own query infrastructure precisely because making bulk enumeration easy would undermine its fraud detection value. The DVLA doesn’t have the same luxury because vehicle tax and MOT status genuinely need to be publicly checkable, but the absence of any challenge mechanism on high-frequency queries from single sources is a design gap that has never been properly closed.

    Adding a CAPTCHA or proof-of-work challenge to the web form wouldn’t stop determined programmatic scrapers for long, but it would raise the cost. Implementing anomaly detection on query patterns (sequential VRM enumeration is obvious when you look at the logs) and feeding that into a threat intelligence feed is the more robust approach. The NCSC’s Early Warning service is built around exactly this kind of behavioural signal analysis, but that architecture isn’t currently connected to DVLA’s public query infrastructure in any visible way.

    What would actually fix this

    The simplest mitigation is aggressive IP-based rate limiting with exponential backoff on the public web service, combined with log analysis for sequential or near-sequential VRM patterns. Not groundbreaking, not expensive. The DVLA already has the telemetry to do this.

    Longer term, moving the public-facing VES to a model where users authenticate with GOV.UK One Login would allow per-user query limits and proper audit trails. GOV.UK One Login’s architecture is built to handle exactly this kind of authenticated public service interaction. Yes, adding login friction will reduce casual use. That’s the trade-off the DVLA needs to have an honest conversation about publicly.

    The DVLA does publish its API terms of service and runs takedowns against commercial entities it identifies scraping without authorisation. But reactive enforcement after the fact is a lot less useful than building the detection into the infrastructure from day one. The data is too rich, too accessible, and too useful to bad actors for the current approach to hold much longer.

  • How the FCA’s RegTech Data Pipelines Work: The Automated Surveillance Systems Watching UK Financial Markets for Manipulation

    How the FCA’s RegTech Data Pipelines Work: The Automated Surveillance Systems Watching UK Financial Markets for Manipulation

    The Financial Conduct Authority is not some bloke in a suit skimming spreadsheets. It is, at its core, a data operation. A surveillance machine that ingests billions of rows of trade data every day, runs it through pattern-matching engines, and flags anomalies for human review. The FCA market surveillance RegTech UK stack is one of the more quietly impressive pieces of financial infrastructure most people have never thought about. And because most people haven’t thought about it, some clever operators have found the seams.

    This is a technical breakdown. We’re going into the plumbing: how data flows in, what the detection logic looks like, and where the logic quietly falls apart.

    FCA market surveillance RegTech UK operations centre with multiple data screens showing live trading patterns at night

    Where the Data Actually Comes From

    Under the UK’s retained version of MiFID II (now domesticated into the UK Markets in Financial Instruments framework post-Brexit), firms are required to report executed trades to Approved Reporting Mechanisms (ARMs). Think of ARMs as glorified relay nodes: brokers and trading venues funnel their transaction reports through providers like Unavista (London Stock Exchange Group), Tradeweb, or DTCC Derivatives Repository. These ARMs then pipe standardised records straight into the FCA’s Transaction Reporting system.

    Each report is a structured data packet covering around 65 fields: financial instrument identifier (ISIN or AII), price, quantity, execution time (to microsecond precision), trader identifiers, counterparty LEI codes, and a bunch of venue and capacity flags. The FCA reportedly processes north of 10 million transaction reports on a busy day. That is not a small firehose.

    On the derivatives side, trade repositories (TRs) like DTCC and ICE Trade Vault handle EMIR reporting, pushing position-level data and lifecycle events into a separate regulatory channel. The FCA cross-references both streams. At least in theory.

    The Algorithmic Surveillance Layer

    Once the data lands, it doesn’t sit in a queue waiting for a compliance officer to manually check it. The FCA runs a suite of automated surveillance tools that operate across several abuse typologies defined under the UK Market Abuse Regulation (UK MAR). The main categories they’re scanning for are insider trading, market manipulation (including layering, spoofing, and ramping), and wash trading.

    The detection logic for each works differently.

    For insider trading, the system primarily looks at pre-announcement positioning. It maps trades executed in the window before a price-sensitive event (earnings, M&A announcements, regulatory decisions) against the identity of the counterparties. Unusually large directional trades by accounts with demonstrable proximity to material non-public information trigger a case. The challenge is that correlation is not causation, and the FCA’s false positive rate here is notoriously high, which means a lot of cases get opened and quietly shelved.

    For layering and spoofing, which is where things get genuinely technical, the system analyses order book events at millisecond resolution. Layering involves placing large visible orders on one side of the book to push price, then cancelling them once your actual order fills on the other side. The surveillance engine looks for high order-to-trade ratios, short order lifetimes, and directional asymmetry between placed and executed volume. This is the kind of detection logic that was pioneered by exchanges like NASDAQ and the London Stock Exchange’s own surveillance platforms before regulators built their own versions.

    Where the Detection Logic Has Gaps

    Here’s where it gets interesting. The FCA’s infrastructure, however impressive in scope, has structural weaknesses that aren’t exactly secret in quantitative finance circles.

    The first is latency in cross-venue data fusion. UK equity trades can execute across multiple venues simultaneously: the London Stock Exchange, CBOE Europe, Aquis Exchange, dark pools, and systematic internalisers. The FCA’s surveillance has to correlate activity across all of them to detect coordinated manipulation. Because ARM submission windows allow for T+1 reporting in some cases, a spoofing pattern that spans venues may not look suspicious in any single dataset but screams manipulation when you look at the whole picture. By the time the full picture is assembled, the pattern has already resolved and the money is moved.

    The second gap is derivatives-to-spot linkage. Sophisticated manipulation increasingly starts in less-liquid derivatives markets, where a small position can move a reference price that then triggers payoffs in a much larger physical or structured product. The EMIR reporting stream and the MiFIR transaction reporting stream are not natively joined in real time. Analysts at the FCA can request cross-referenced queries, but there’s no live, automated alert firing across that seam. That’s a known problem.

    Third is the identity obfuscation layer. LEI codes (Legal Entity Identifiers) are supposed to make counterparty identification trivial. In practice, complex fund structures involving multiple SPVs across Jersey, Cayman, and Luxembourg can make beneficial ownership genuinely ambiguous at the point of reporting. The FCA can issue formal information requests and use their powers under FSMA 2000 to compel disclosure, but that’s a reactive process, not a real-time detection capability.

    The FCA has acknowledged some of these limitations publicly. Their 2023 and 2024 market cleanliness statistics showed that UK equity markets have actually improved on some traditional insider trading metrics, but the regulator has also flagged concerns about shifting abuse patterns into derivatives and less-regulated instruments. You can read more about the FCA’s market cleanliness work directly on their market abuse regulatory hub.

    The RegTech Vendors Plugging the Gaps

    Because the FCA can’t build everything internally, a whole ecosystem of RegTech vendors has grown up around the problem. Firms like Behavox, NICE Actimize, and Nasdaq’s own Surveillance platform sell directly to trading firms and banks for their internal compliance functions. Some of these platforms now use machine learning models trained on historical enforcement actions to score new order patterns probabilistically.

    The irony is that firms subject to FCA oversight are running surveillance technology that, in some cases, is more sophisticated than what the regulator itself is running. A major bank’s internal spoofing detection can fire an alert within seconds of a suspicious pattern. The FCA’s equivalent system may not see the same data at the same fidelity until reports are submitted and ingested, which could be hours later on a high-volume day.

    What the Future of FCA Market Surveillance Looks Like

    The FCA has been making noises about its data strategy for a while now. Their Transforming Data Collection programme (TDC), running in collaboration with the Bank of England, is specifically aimed at modernising how regulators ingest, validate, and use financial data. The aspiration is closer to real-time regulatory reporting rather than the current batch submission model. If it lands properly, some of those cross-venue and derivatives linkage gaps could be genuinely closed.

    There’s also increasing interest in using graph-based analytics for network analysis: mapping the connections between traders, accounts, and counterparties across time to surface unusual clustering. It’s the same approach fraud teams at banks use for financial crime detection, applied to market structure data.

    Whether the FCA builds that capability internally or procures it from the RegTech market is an open question. Given the pace of hiring in the public sector versus the private sector for quant and data engineering talent, my money is on procurement. Either way, the surveillance net is getting tighter. Slowly. And the people who understand exactly how it works, and where it currently doesn’t, are watching very carefully.

    Frequently Asked Questions

    What is the FCA's market surveillance system and how does it work?

    The FCA runs automated surveillance systems that ingest trade data reported via Approved Reporting Mechanisms under MiFID II/MiFIR rules. The system applies algorithmic detection logic to flag suspicious patterns like spoofing, layering, and insider trading positioning, which are then reviewed by enforcement teams.

    What is RegTech and why does it matter for UK financial regulation?

    RegTech (Regulatory Technology) refers to software and data systems used to comply with and enforce financial regulations. In the UK, it includes the reporting infrastructure firms use to submit trades to the FCA and the surveillance platforms the regulator uses to detect market abuse at scale.

    How does the FCA detect spoofing and layering in UK markets?

    The FCA’s surveillance tools analyse order book data at millisecond resolution, looking for high order-to-trade ratios, extremely short order lifetimes, and patterns where large visible orders are placed and cancelled in coordination with actual executions on the opposite side. This is technically complex and generates significant false positives.

    What are the biggest gaps in the FCA's market abuse detection?

    The main weaknesses include latency in fusing data across multiple trading venues, the lack of real-time linkage between EMIR derivatives reporting and MiFIR equity transaction reports, and difficulty piercing complex fund structures to identify beneficial ownership at the point of surveillance.

  • How Rogue Android APKs Are Draining UK Banking Apps: Overlay Attacks, Accessibility Abuse, and Why Google Play Protect Keeps Missing Them

    How Rogue Android APKs Are Draining UK Banking Apps: Overlay Attacks, Accessibility Abuse, and Why Google Play Protect Keeps Missing Them

    There’s a particular breed of mobile malware circulating right now that is, honestly, quite elegant in the worst possible way. It doesn’t brute-force anything. It doesn’t need root access. It just waits, watches, and quietly empties your Barclays account while you think you’re logging in normally. Android banking malware in the UK has matured significantly heading into 2026, and the gap between what these samples can do and what most people’s defences actually catch is genuinely uncomfortable to look at.

    This isn’t scare journalism. This is a technical walkthrough of how these attacks are constructed, why they’re effective against specific UK banks, and where the detection pipelines are falling over.

    Hooded figure holding Android phone showing banking app in context of android banking malware uk 2026

    The Delivery Chain: How the APK Gets on Your Device

    Forget the Play Store for a second. The primary delivery vector for UK-targeted banking trojans right now is smishing: an SMS or WhatsApp message, often spoofed to appear from Royal Mail, HMRC, or a known bank, pointing to a domain that serves a malicious APK. The lure page is frequently a near-pixel-perfect clone of the legitimate app’s Play Store listing, complete with fake review counts and version numbers.

    The user is told to enable “Install from unknown sources” because the fake page explains the app is a “security update” or “fraud detection tool” that isn’t yet in the official store. It sounds absurd written out, but these pages are polished, the SMS sender IDs are spoofed convincingly, and the social engineering is tight. NCSC’s own guidance on malicious SMS campaigns documents exactly this pattern, and the volume of reports to Action Fraud from UK residents has been climbing steadily through 2025 and into this year.

    Once the APK is installed, it typically requests a minimal set of permissions on first launch: just enough to look plausible. The dangerous requests come later, incrementally, once trust is established.

    Overlay Attacks: The Fake Login You Can’t Tell Is Fake

    The overlay technique is the oldest trick in the Android malware playbook, and it still works because the fundamental Android permission model hasn’t closed the attack surface cleanly. Here’s what’s actually happening at the system level.

    The malware registers a foreground service and monitors the device’s running tasks, typically via ActivityManager.getRunningTasks() on older API levels, or more recently by abusing the Accessibility Service to observe window state change events. When it detects that the user has opened a target application, such as Barclays Mobile Banking or the Monzo app, it fires an overlay window using the TYPE_APPLICATION_OVERLAY window type (which replaced the deprecated TYPE_SYSTEM_ALERT after Android 8). This overlay sits on top of the real app. To the user, they’re looking at what appears to be a normal login screen. They’re actually typing credentials into a WebView or a custom layout controlled entirely by the malware.

    The collected credentials are exfiltrated immediately via HTTPS to a command-and-control server, often hosted on bulletproof infrastructure in jurisdictions that don’t respond quickly to UK law enforcement requests. Some samples I’ve reviewed use Telegram bot APIs as a lightweight C2 channel, which is clever because outbound Telegram traffic rarely triggers corporate or ISP-level filtering.

    Accessibility Service Hijacking: The Permission That Breaks Everything

    If overlay attacks are the front door, accessibility service abuse is the skeleton key. Once a malicious app has been granted Accessibility Service permissions, it has extraordinary visibility into the device.

    Specifically, an app with these permissions can read the content of any screen element using AccessibilityNodeInfo, simulate touch events and button presses, intercept and act on window content change events, and auto-fill or auto-dismiss UI elements without user interaction. For a banking trojan, this means it can observe the NatWest app rendering your account balance, read OTP codes as they appear on screen before you’ve had a chance to type them, and then dismiss notifications so you don’t notice the outgoing transfer that just happened.

    Android’s own defences here are genuinely weak. Google has tried restricting which apps can declare accessibility services in recent Play Store policies, but since these trojans are sideloaded rather than distributed via the Play Store, those restrictions are irrelevant. The DRAW_OVER_OTHER_APPS permission and Accessibility access together are sometimes called the “God mode” combination in mobile security circles, and it’s a fair description.

    Some current UK-targeting samples have started bundling a secondary technique: they request device admin privileges under the guise of an “enterprise security profile”, which then prevents the user from uninstalling the malware through normal means. You try to remove it and the uninstall button is greyed out.

    SMS Interception and Why UK Two-Factor Authentication Isn’t Saving You

    Here’s where UK banks specifically have a problem. Barclays, NatWest, and several smaller institutions still rely heavily on SMS OTP for transaction authorisation. The malware intercepts these codes using a BroadcastReceiver registered for the SMS_RECEIVED intent. On Android versions below 10, this worked almost unimpeded. On more recent builds, the malware increasingly uses the Accessibility Service to read the SMS notification as it appears in the notification shade, which sidesteps the direct SMS permission requirement entirely.

    The interception happens in milliseconds. The C2 server, watching the exfiltrated credentials arrive, uses the stolen OTP to authorise a Faster Payments transfer before it expires. By the time the legitimate account holder has noticed anything unusual, the money is already in a mule account and on its way out of the UK financial system. Monzo’s in-app notifications and real-time spend alerts are a partial mitigation because they surface the transaction immediately, but if the malware is also suppressing notifications, that safety net disappears.

    The NCSC’s guidance on phone-based attacks acknowledges SMS as a weaker second factor and recommends app-based authentication where available. The problem is that adoption of app-based TOTP or passkey-style authentication among mainstream UK retail banking users remains low, and the banks themselves have been slow to deprecate SMS entirely because it reduces friction for less technically literate customers.

    Why Google Play Protect Isn’t Catching This

    Play Protect scans apps on the device using Google’s on-device and cloud-based detection pipeline. It’s not useless. But it has a fundamental structural problem against this threat: the malicious APKs are delivered outside the Play Store ecosystem, and Play Protect’s behavioural detection has historically been weaker against apps that delay their malicious behaviour.

    Most of the UK-targeting samples use a dormancy period. The APK installs cleanly, behaves normally for a period of 24 to 72 hours, phones home to verify it’s running on a real device rather than an emulator or sandbox (standard anti-analysis checks: device fingerprint, SIM presence, battery state, accelerometer data), and only then activates the overlay and accessibility hooks. By the time the malicious behaviour starts, Play Protect has already assessed the app as benign.

    The anti-emulation checks are increasingly sophisticated. If the malware detects it’s running on a virtual device, it terminates quietly. This makes automated dynamic analysis far less effective without significant infrastructure investment to convincingly spoof real hardware environments.

    What Actually Helps

    On the device side: don’t sideload APKs, full stop. Enable Play Protect and keep it on. Revoke Accessibility Service permissions from any app that doesn’t have an obvious legitimate reason to need them. If your bank supports in-app biometric authentication backed by a hardware security module rather than SMS codes, enable it.

    On the bank’s side, what should be happening is stronger transaction-level behavioural analysis. Banks should be comparing device fingerprint, geolocation velocity, and session characteristics against established patterns. A login from a device that has never previously accessed the account, followed immediately by a Faster Payments transfer to a new payee, should trigger a hard block pending manual verification. Some UK challenger banks are further along with this than the legacy high-street institutions. The irony is that Monzo, frequently targeted precisely because of its younger demographic’s likelihood to sideload apps, arguably has better real-time fraud detection than most of the older banks.

    For anyone actually interested in the technical details of these samples, the ThreatFabric research blog and the Cleafy team publish excellent detailed analyses of active Android banking trojan families. The Anatsa and Copybara families have both been documented targeting UK financial institutions specifically in recent reporting periods, and the techniques I’ve described above are directly observable in their decompiled code.

    Frequently Asked Questions

    What is android banking malware and how does it target UK users in 2026?

    Android banking malware is malicious software that impersonates or monitors legitimate banking apps to steal credentials, OTP codes, and authorise fraudulent transactions. In the UK, current variants specifically target Barclays, NatWest, and Monzo using smishing campaigns that trick users into sideloading APKs outside the Google Play Store.

    How do overlay attacks on Android banking apps actually work?

    The malware monitors the device for when a banking app is opened, then draws a fake login screen on top of it using Android’s TYPE_APPLICATION_OVERLAY window type. The user types their credentials into the fake screen without realising, and those details are immediately sent to an attacker-controlled server.

    Can Google Play Protect detect and remove banking trojans?

    Play Protect has limited effectiveness against these threats because the APKs are sideloaded rather than installed from the Play Store, and modern samples deliberately delay malicious behaviour to pass initial scans. Its on-device behavioural detection can flag some activity but it is not reliable against evasion-aware samples.

    Why is SMS two-factor authentication not enough to stop these attacks?

    Malware with SMS interception capability or Accessibility Service access can read OTP codes the moment they arrive, either directly from the SMS broadcast or from the notification shade. The stolen code is forwarded to the attacker’s infrastructure within milliseconds, before the legitimate user has a chance to act.

    How do I protect my Android device from banking malware in the UK?

    Never install APKs from outside the Google Play Store, and be sceptical of any SMS or WhatsApp message prompting you to download a security update or banking tool. Check which apps have Accessibility Service permissions in your device settings and revoke access from anything that doesn’t genuinely require it. Use app-based authentication rather than SMS codes wherever your bank offers it.

  • NCSC Early Warning: How the UK’s Threat Intel Platform Actually Works (and Where It Goes Blind)

    NCSC Early Warning: How the UK’s Threat Intel Platform Actually Works (and Where It Goes Blind)

    The NCSC Early Warning service UK architecture is one of those things that gets mentioned in government briefings and CISO presentations but rarely gets pulled apart at the technical level. Most coverage treats it like a magic box: threats go in, alerts come out, everyone’s safer. That’s not how it works. There’s a specific data pipeline underneath it, with real limitations baked in by design, and understanding those limitations matters a lot more than the marketing copy suggests.

    Let’s get into the actual mechanics.

    Cybersecurity analyst monitoring NCSC early warning service UK architecture on dark operations centre screens

    What the NCSC Early Warning Service Actually Is

    Early Warning is a free service from the National Cyber Security Centre that notifies registered UK organisations when their IP ranges or domains appear in threat intelligence data. It’s not an active scanner. It’s not a firewall. It’s a passive aggregation and notification layer that sits on top of third-party and proprietary feeds, then matches indicators against an organisation’s declared assets.

    Eligibility is open to any UK organisation, from a sole-trader running a couple of servers to a FTSE 100 company with a sprawling ASN. Sign-up involves verifying ownership of the IP space or domain in question, which is a lightweight but necessary check to prevent people from registering assets they don’t own and harvesting intelligence on competitors.

    How Threat Feed Ingestion Actually Works

    The NCSC draws on a mixture of feeds. Some are proprietary, collected through the Centre’s own sensors and incident data. Others come from trusted commercial partners and CERT sharing arrangements across the EU and Five Eyes network. On top of that, there are open-source threat intelligence (OSINT) feeds, think Shadowserver, abuse.ch, and similar operations that track botnet C2 infrastructure, compromised hosts, and malware distribution networks globally.

    Shadowserver in particular deserves a mention here. It scans a significant portion of the routable IPv4 space daily and shares data with national CERTs and bodies like the NCSC. The volume of data coming in from these combined sources is enormous. The interesting engineering problem isn’t collecting it; it’s deduplication, confidence scoring, and timeliness.

    Each indicator (an IP, a domain, a hash, a URL) carries metadata: when it was first seen, when it was last confirmed active, what threat category it maps to (C2, scanning, phishing kit, credential stuffing, etc.), and a confidence rating. Low-confidence indicators from a single source don’t trigger notifications. The system applies a kind of rough consensus model, where an IP flagged independently by multiple feeds at similar timestamps earns a higher confidence score and is more likely to surface as an alert.

    Mapping Indicators to UK IP Space

    This is where the NCSC Early Warning service UK architecture gets genuinely interesting. The platform maintains a continuously updated map of which IP ranges belong to which registered organisations. BGP routing tables, RIPE NCC allocation data, and the self-declared assets from enrolled organisations all feed into this mapping layer.

    When an indicator matches a registered IP or domain, an alert fires. The format is deliberately minimal: what was seen, when, and what category of threat. There’s no full packet capture, no context about how deep the compromise runs, and no remediation guidance beyond generic signposting. The NCSC is explicit about this. Early Warning is a notification service, not an incident response platform.

    Alerts are delivered via a web dashboard and optionally via email or the NCSC’s own API, which allows organisations with a SOC to pipe alerts directly into their SIEM. That API integration is one of the more useful features for anyone running a proper security operation rather than checking a dashboard manually every Tuesday morning.

    Where the Visibility Completely Falls Apart

    Here’s the honest part. The NCSC’s own documentation is reasonably candid about limitations, but it doesn’t spell them out in technical terms for people who actually need to understand the gaps.

    Cloud and shared infrastructure. If your organisation runs workloads on AWS, Azure, or Google Cloud, the IP addresses belong to those providers, not to you. Early Warning maps to announced IP space and declared assets. An attacker hitting your EC2 instance looks, at the network layer, like someone hitting Amazon’s IP range. Unless you’ve explicitly registered those specific IPs (which rotate in some architectures), the correlation won’t happen. This is a structural gap affecting a huge proportion of UK companies in 2026.

    Encrypted C2 and domain-fronting. Feed-based detection relies on indicators reaching the public threat intelligence ecosystem. Modern nation-state and organised criminal tooling increasingly uses legitimate infrastructure for command-and-control. Traffic that blends into normal HTTPS across CDN providers leaves almost no fingerprint that propagates to shared feeds. Early Warning sees nothing here.

    Zero-day and first-party compromise. The feed model is inherently retrospective. An indicator has to be seen, attributed, and shared before it can trigger an alert. Novel malware families or freshly registered C2 domains have a lag period of anywhere from hours to weeks before they appear in threat intelligence. During that window, Early Warning is silent.

    Insider threats and credential abuse. Legitimate credentials used from legitimate IP ranges produce no anomalous network indicators. Early Warning has no behavioural analytics component. It won’t notice that someone’s Office 365 account is being accessed from an unusual geography at 03:00 GMT, because that’s not what it’s built to detect.

    IPv6 coverage. Shadowserver and similar scanners have significantly less IPv6 coverage than IPv4. If your organisation has moved significant workloads onto IPv6 addressing, the threat intelligence coverage you’re receiving is materially thinner. This is a problem that the broader threat intelligence community is aware of but hasn’t solved at scale.

    Who Actually Benefits from This Service

    Early Warning delivers genuine value in specific contexts. A mid-sized UK manufacturer with a flat, on-premises network and a modest IP range will see real utility from knowing when those addresses appear in botnet data or when a mail server starts appearing on spam threat feeds. For that kind of organisation, it’s a meaningful signal that probably wouldn’t surface otherwise.

    For a mature enterprise with a SOC, a commercial threat intelligence subscription, and a SIEM already ingesting Shadowserver and similar feeds directly, Early Warning is largely redundant. You’re already seeing those indicators through other channels, often faster. The value proposition narrows to the NCSC’s proprietary feeds, which contain intelligence derived from UK government sensor networks and incident response engagements that aren’t replicated elsewhere.

    Universities and NHS trusts sit in an interesting middle ground. They often have large, registered IP ranges with relatively limited security tooling. For those organisations, Early Warning can catch things that would otherwise go unnoticed for months.

    Using the API Properly

    If you’re registered and not using the API, you’re leaving the most useful part on the table. The REST API lets you pull structured alert data into whatever stack you’re running. A basic Python script hitting the endpoint on a schedule and feeding results into an Elasticsearch index takes an afternoon to build. From there you can correlate Early Warning alerts against your own firewall logs and actually determine whether a flagged IP successfully reached your infrastructure or got dropped at the perimeter. That correlation step is where the real analysis happens; the raw alert alone tells you very little about severity.

    The NCSC also publishes STIX/TAXII feeds for organisations that prefer a standardised threat intelligence format, which integrates cleanly with platforms like OpenCTI or MISP if you’re running a proper threat intelligence operation internally.

    The NCSC early warning service UK architecture is a solid piece of public infrastructure for what it’s designed to do. Treat it as one layer in a defence stack, not the stack itself, and be honest about the categories of threat it simply cannot see. That’s not a criticism of the NCSC; it’s the nature of passive, feed-based detection at national scale. The gaps are structural, and knowing them is half the battle.

    Frequently Asked Questions

    Is the NCSC Early Warning service free to use?

    Yes, it’s entirely free for any registered UK organisation. You sign up via the NCSC website, verify ownership of your IP ranges or domains, and start receiving alerts at no cost. There’s no paid tier.

    How quickly does the NCSC Early Warning service send alerts after a threat is detected?

    It depends on the underlying feed. Some feeds share indicators in near real-time; others have latency of several hours or more before indicators propagate. Freshly observed threats can have a lag of hours to days before appearing in the intelligence ecosystem the NCSC draws on.

    Can the NCSC Early Warning service detect ransomware attacks?

    Partially. It can detect activity associated with known ransomware precursors, such as C2 infrastructure from established ransomware groups that’s already been documented in threat feeds. It cannot detect novel ransomware delivery or purely internal lateral movement that doesn’t touch flagged external infrastructure.

  • Inside the EU Cyber Resilience Act: What UK Software and Hardware Vendors Actually Have to Implement by 2027

    Inside the EU Cyber Resilience Act: What UK Software and Hardware Vendors Actually Have to Implement by 2027

    The EU Cyber Resilience Act (CRA) received its final approval in late 2024 and its technical requirements are now ticking toward full enforcement. UK vendors who sell digital products into Europe have a hard deadline approaching, and the requirements are not light. We are talking mandatory vulnerability disclosure windows measured in hours, software bills of materials that have to be machine-readable, and default security configurations baked into hardware before a single unit ships. UK product teams are quietly, sometimes frantically, working out what this means for them. Because Brexit did not make the problem go away. If anything, it made it more complicated.

    Hacker reviewing Cyber Resilience Act UK obligations 2027 on multiple monitors in a dark server room
    Hacker reviewing Cyber Resilience Act UK obligations 2027 on multiple monitors in a dark server room

    Why the CRA Still Applies to UK Vendors Post-Brexit

    Here is the thing people get wrong. They assume that because the UK is no longer bound by EU law, European regulations are someone else’s problem. That logic falls apart the moment your product is sold to a customer in Frankfurt or Amsterdam. The CRA applies to any product with digital elements placed on the EU single market, regardless of where the manufacturer is based. UK companies exporting to Europe are fully in scope. The EU does not care that your company is registered at Companies House and your servers are in Slough.

    The UK government, for its part, has been developing its own Product Security and Telecommunications Infrastructure (PSTI) Act, which came into force in April 2024. PSTI covers consumer IoT devices and has some overlapping concerns with the CRA, but the two are not equivalent. PSTI is narrower. The CRA is considerably more demanding and covers a far wider category of software and hardware. UK vendors effectively have to satisfy two separate regulatory regimes simultaneously if they trade in both markets, and the stricter of the two sets the practical floor.

    What the Cyber Resilience Act UK Obligations 2027 Actually Require

    Vulnerability Disclosure: The 24-Hour Rule

    The CRA mandates that manufacturers notify ENISA (the EU Agency for Cybersecurity) of actively exploited vulnerabilities within 24 hours of becoming aware of them. A full vulnerability report follows within 72 hours. This is brutal compared to what most UK product teams are used to. Many organisations currently operate on informal disclosure timelines that stretch across weeks. Under the CRA, 24 hours is the window from awareness to notification, not from patch development to public announcement. UK vendors need a documented incident response process that can actually hit that target, which means tooling, clear ownership, and a direct pipeline to ENISA’s reporting mechanisms.

    The UK’s National Cyber Security Centre (NCSC) has its own coordinated vulnerability disclosure guidelines, which you can review at ncsc.gov.uk. The NCSC framework is broadly sensible but does not impose the same hard legal timelines the CRA does. UK teams targeting EU markets need to treat the CRA timeline as the operative one.

    Developer generating an SBOM output as part of Cyber Resilience Act UK obligations 2027 compliance
    Developer generating an SBOM output as part of Cyber Resilience Act UK obligations 2027 compliance

    Software Bill of Materials: The SBOM Mandate

    An SBOM is essentially an ingredient list for your software. Every component, library, dependency, and third-party module, catalogued in a machine-readable format. The CRA requires manufacturers to produce and maintain SBOMs for products with digital elements. The practical pain here is significant. Large codebases with years of accumulated dependencies can have hundreds of components, some of which are abandoned open-source projects that nobody has touched since 2019. Generating an SBOM is one thing. Keeping it accurate as dependencies update, forks happen, and supply chains shift is an ongoing operational commitment.

    The standard formats getting traction are CycloneDX and SPDX. Tooling exists to automate SBOM generation from source trees and container images, but the output is only as good as the engineering hygiene that produced the codebase. Teams relying on undocumented vendored code or tangled monorepos are in for a rough time. The SBOM also feeds directly into vulnerability management: once you have a machine-readable component list, you can cross-reference it against CVE databases and catch exposure before it becomes a breach notification event.

    Secure-by-Default Configuration Requirements

    The CRA requires products to ship in a secure-by-default state. No more factory passwords shared across every unit. No more open ports that the user is expected to close themselves. No more optional security features that are off unless you know where to look in a settings menu buried three layers deep. The default state of the product must be the secure state. This has hardware implications and software implications in equal measure.

    For web-facing software and hosted products, this translates into enforced HTTPS, no default admin credentials, automatic security updates on by default, and clear discoverability of security settings. The days of shipping a product and leaving hardening as an exercise for the customer are over, at least if you want to sell into Europe legally.

    Which Product Categories Are in Scope

    The CRA splits products into default, important, and critical categories, with increasing requirements at each tier. Most commercial software products sold to businesses and consumers fall into the default category, which still carries substantial obligations. Important products, covering things like password managers, VPNs, routers, and industrial control interfaces, face third-party conformity assessments before they can carry the CE mark the CRA requires. Critical products, including hardware security modules and smart meter gateways, face the most rigorous scrutiny.

    UK vendors supplying B2B software platforms to European enterprise customers need to honestly assess which tier their product sits in. Getting that classification wrong is not a neutral error. Treating an important product as a default product and skipping third-party assessment is exactly the kind of shortcut that generates enforcement action.

    The Practical Scramble Happening Inside UK Product Teams Right Now

    Talk to anyone deep inside a UK software vendor’s security or engineering team and you will hear the same themes. SBOM tooling is being evaluated and bolted onto CI/CD pipelines. Legal teams are trying to map the CRA’s requirements against existing contract frameworks. Product managers are realising that their roadmap for the next 18 months has to absorb compliance work that was not originally budgeted. The Cyber Resilience Act UK obligations 2027 deadline sounds distant until you account for the lead time required to retrofit secure-by-default behaviour into legacy products, build SBOM generation into release pipelines, and train incident response teams on the 24-hour notification clock.

    Web-facing businesses and digital agencies are not immune to this either. Organisations building software products or hosting environments for clients face questions about where their liability sits when a component they ship or maintain carries an unpatched CVE. Businesses like dijitul, a Mansfield, Nottinghamshire-based digital agency specialising in web design, hosting, and software delivery, are already fielding questions from clients about how CRA-adjacent obligations affect the platforms and web properties being managed on their behalf. For an agency operating across marketing, business efficiency tools, and bespoke web builds, the practical question is which of the products and services they deliver would qualify as products with digital elements under CRA definitions. The answer, in many cases, is more of them than you might expect. dijitul.uk is a useful reference point for understanding how smaller digital businesses are thinking through their own product and service taxonomy in light of these requirements.

    The companies that will sail through the 2027 deadline are the ones treating this as an engineering problem now, not a compliance checkbox exercise in 2026. That means adopting dependency scanning tools like Dependabot or Grype as permanent fixtures, not one-off audits. It means building vulnerability triage into sprint cycles. It means having a named person who can make the call at 2am when a critical CVE drops and the 24-hour ENISA window starts ticking.

    How to Start Getting Ready

    The sensible starting point is a product inventory: list everything your organisation ships or maintains that has digital elements and could plausibly reach EU markets. Then classify each item against the CRA’s three tiers. From there, gap analysis against the core technical requirements gives you a prioritised work list. Vulnerability disclosure process first, because the 24-hour window is the most operationally disruptive requirement and the hardest to bolt on retroactively.

    For smaller UK product teams, the SBOM mandate is probably the second most urgent thing to tackle. Integrating CycloneDX generation into your build pipeline is a one-time engineering investment that pays ongoing dividends for both CRA compliance and your own internal vulnerability management posture. It is also the kind of thing that digital agencies running software products for clients, focused on marketing and business efficiency as much as raw web design, need to factor into their service documentation and client-facing agreements.

    The Cyber Resilience Act UK obligations 2027 are not going to be watered down. The EU has spent years building the political and regulatory momentum behind this legislation and enforcement is expected to be real. UK vendors who sell into Europe cannot afford to wait and see. The scramble is already happening. The question is whether your team is in it.

    Frequently Asked Questions

    Does the EU Cyber Resilience Act apply to UK companies after Brexit?

    Yes. The CRA applies to any product with digital elements placed on the EU single market, regardless of where the manufacturer is based. UK vendors selling software or hardware into EU member states are fully in scope and must meet the same requirements as EU-based manufacturers.

    What is the vulnerability disclosure timeline under the Cyber Resilience Act?

    Manufacturers must notify ENISA of an actively exploited vulnerability within 24 hours of becoming aware of it, followed by a full vulnerability report within 72 hours. This is significantly stricter than most informal disclosure practices currently used by UK product teams.

    What is an SBOM and why does the CRA require one?

    A Software Bill of Materials (SBOM) is a machine-readable inventory of every component, library, and dependency in a software product. The CRA mandates SBOM production and maintenance so that vulnerabilities in third-party components can be rapidly identified and disclosed across the supply chain.

    What does secure-by-default mean under the Cyber Resilience Act?

    Products must ship in a hardened state without shared default passwords, unnecessary open ports, or security features that are disabled out of the box. The burden of configuration is placed on the manufacturer, not the end user, before the product reaches market.

    What is the difference between the UK PSTI Act and the EU Cyber Resilience Act?

    The UK’s Product Security and Telecommunications Infrastructure (PSTI) Act, which came into force in April 2024, covers consumer IoT devices and has narrower scope than the CRA. UK vendors selling into EU markets must satisfy both regimes, and the CRA’s requirements are considerably more demanding in most areas.

  • How UK Mobile Networks Handle Emergency Location Data: The SS7 Infrastructure Behind 999 Call Tracing

    How UK Mobile Networks Handle Emergency Location Data: The SS7 Infrastructure Behind 999 Call Tracing

    When you dial 999 from a mobile, there is a quiet war happening in the background. Your handset, the mast it is connected to, and a chain of ageing signalling protocols all scramble to answer one critical question: where exactly are you? The answer involves a stack of technology that ranges from genuinely modern to embarrassingly legacy, and the gaps between those layers are where both life-saving accuracy and some genuinely nasty attack vectors live. SS7 vulnerabilities in the UK mobile network are not theoretical. They are real, documented, and still largely unresolved, even as regulators push for better standards on 999 call location.

    Anonymous hacker in server room examining SS7 vulnerabilities in UK mobile network infrastructure
    Anonymous hacker in server room examining SS7 vulnerabilities in UK mobile network infrastructure

    What is SS7 and Why Does a 999 Call Touch It?

    Signalling System No. 7, almost always shortened to SS7, is the set of telephony protocols that mobile and fixed-line networks use to exchange control information. Think of it as the nervous system underneath a call, not the voice data itself but the signalling layer that handles routing, authentication, billing handshakes, and crucially, location data. It was designed in 1975 and standardised broadly through the 1980s. Its architecture assumed that only trusted carriers would ever connect to it. Spoiler: that assumption has aged terribly.

    When you make a 999 call in the UK, the network needs to route that call to the correct emergency call centre, which in practice means a BT-operated platform called the Emergency Call Handling Agent (ECHA). The ECHA then passes location information to the relevant emergency service control room. Getting accurate coordinates into that pipeline fast enough to matter requires pulling location data from multiple sources, and SS7 is one of the pipes that data flows through.

    The Three Layers of Location Data in a UK 999 Call

    Cell-ID: The Old Faithful That Can Get You Killed

    Cell-ID is the baseline. Every mast in the UK has a unique Cell Global Identity (CGI). When your phone registers with a mast, the network knows which cell you are in. In dense urban areas like central London or Manchester city centre, a cell might cover a few hundred metres. Out in rural Yorkshire, a single cell can stretch for several kilometres. That variance matters enormously when someone is unconscious in a field and the ambulance is being dispatched based on a 2km radius guess.

    Cell-ID data travels over SS7. The Home Location Register (HLR) and Visitor Location Register (VLR), classic SS7 database nodes, hold records of which cell a subscriber is currently in. A legitimate query to an HLR using an SS7 MAP (Mobile Application Part) message can return this Cell-ID. That same query can be issued by an attacker who has gained access to the SS7 network, which is exactly the problem.

    Advanced Mobile Location: The Standard That Actually Works

    Advanced Mobile Location, or AML, is the thing that genuinely changed the game. When a 999 call is initiated on a compatible handset, the phone automatically launches a brief background data session and sends a HTTPS request containing its best available position fix, which could be GPS, Wi-Fi positioning, or cell triangulation, directly to a secure national server. That data is then matched to the call and passed to the ECHA. No SS7 involvement in the location push itself. Clean, fast, and dramatically more accurate.

    Ofcom mandated AML support for UK mobile operators, and it has been rolling out since 2018. Research from the Emergency Location Task Force showed AML-capable devices achieving median location accuracies under 10 metres in tests, compared to hundreds of metres for Cell-ID alone. Android implemented AML natively; Apple’s equivalent, called Hybridised Emergency Location (HELO), integrates similarly. But here is the catch: AML only fires if the device supports it and has a data connection. No signal, no data, no AML. You fall back to Cell-ID. You fall back to SS7.

    Network-Derived Location via SS7 Queries

    When AML is not available, networks can attempt network-derived location using SS7-based procedures, pulling location from the network side rather than the handset. This involves MAP queries against the serving node, potentially triggering silent location requests. It is slower, less accurate, and it exposes exactly the same interface that attackers have been abusing for over a decade.

    Close-up of mobile signalling hardware representing SS7 vulnerabilities in UK mobile network 999 systems
    Close-up of mobile signalling hardware representing SS7 vulnerabilities in UK mobile network 999 systems

    The SS7 Attack Surface: What Legitimate Looks Like vs What an Attack Looks Like

    A legitimate location lookup over SS7 for emergency purposes looks like this: a trusted operator node sends a MAP-ATI (Any Time Interrogation) or MAP-PSL (Provide Subscriber Location) message to the target subscriber’s serving network. The serving network returns location data. The whole exchange happens between carrier-grade nodes with established inter-operator agreements.

    An attack looks almost identical. That is the problem. SS7 has no native cryptographic authentication between nodes. If an attacker has obtained access to an SS7 gateway, through a rogue operator connection (there are hundreds of legitimate interconnects globally), a compromised roaming hub, or a nation-state level intrusion, they can send the exact same MAP messages. The receiving network cannot reliably distinguish a query from BT’s legitimate infrastructure and a query from a compromised node in, say, a lightly regulated jurisdiction.

    Known attack types that are directly relevant here include:

    • MAP-ATI abuse: Silent location queries that return Cell-ID without the subscriber ever knowing. Used extensively in targeted surveillance operations documented by researchers at Positive Technologies and SRLabs.
    • IMSI harvesting via Paging: Forcing a phone to reveal its IMSI by sending forged paging messages, then correlating that IMSI with billing data.
    • SS7 intercept: Redirecting SMS messages by updating location registers, effectively breaking SMS-based two-factor authentication. UK banks and HMRC both still use SMS OTP for some authentication flows.
    • Call forwarding manipulation: Registering a supplementary service via SS7 to silently forward calls, including potentially 999 calls in extreme edge cases.

    The GSMA has published security guidelines (FS.11) specifically addressing SS7 vulnerabilities. UK mobile operators are expected to implement SS7 firewalls and anomaly detection. EE, Vodafone, O2, and Three have all made public commitments to SS7 hardening. But independent security researchers have consistently found that filtering is incomplete and that certain query types still pass through commercial networks globally.

    What Ofcom Has (and Has Not) Done About This

    Ofcom has pushed hard on the AML standard, which is the right call. Reducing reliance on SS7 for 999 location is genuinely the correct long-term direction. The General Conditions of Entitlement require UK operators to transmit caller location to the emergency services, and AML compliance is baked into that framework now.

    Where it gets murkier is the broader SS7 security mandate. Ofcom’s general network security obligations under the Communications Act 2003 and the Network and Information Systems (NIS) Regulations 2018 apply, but there is no specific published SS7 security audit regime with public reporting. Compare that to the approach taken by the US FCC, which has at least publicly demanded SS7 remediation reports from carriers, and the UK’s posture looks somewhat quieter than the scale of the problem warrants.

    The Gaps That Still Exist in 2026

    SS7 is not going away fast. VoLTE (Voice over LTE) and 5G use different signalling stacks, specifically Diameter for 4G and HTTP/2-based service-based architecture for 5G core. Both are improvements. Both also have their own vulnerability classes. But the global SS7 network still exists as an interconnect layer, particularly for roaming, and that interconnect layer is accessible. The migration to newer stacks is a decade-long project, not a flip of a switch.

    For 999 specifically, the risk is not that an attacker hijacks your emergency call in real time. That is technically complex and a weird threat model. The more realistic concern is the broader SS7 attack surface being used for surveillance, two-factor authentication bypass, and location tracking of individuals, all of which undermine the integrity of UK mobile communications more generally. Emergency location accuracy has genuinely improved with AML. But the underlying SS7 vulnerabilities in the UK mobile network remain a live issue for anyone who cares about mobile security beyond just calling 999.

    The honest summary: AML is good and getting better. Cell-ID fallback is a known weak point. SS7 is a creaking legacy protocol with documented, exploitable vulnerabilities that no single operator can fix unilaterally because the problem is global. Ofcom has done the right things on the emergency location side. The broader SS7 remediation piece remains a work in progress, and the security community knows it.

    Frequently Asked Questions

    What are SS7 vulnerabilities and do they affect UK mobile networks?

    SS7 vulnerabilities are security flaws in the Signalling System No. 7 protocol, a legacy telephony signalling stack used by mobile and fixed-line networks globally. Yes, they absolutely affect UK mobile networks because UK operators interconnect with the global SS7 network for roaming and inter-carrier signalling, creating exposure to attacks that can originate from compromised nodes anywhere in the world.

    How does Advanced Mobile Location (AML) improve 999 call accuracy?

    When you dial 999 on a compatible smartphone, the handset automatically sends a background HTTPS data packet containing its best GPS or Wi-Fi position fix directly to a secure national server, which then passes the data to the emergency call centre. This bypasses the less accurate Cell-ID method and typically achieves location accuracy within 10 metres in good conditions, compared to potentially hundreds of metres with network-derived Cell-ID alone.

    Can someone use SS7 to track a person's location in the UK without their knowledge?

    In theory, yes, and it has been demonstrated repeatedly by security researchers. An attacker with access to an SS7 gateway can send MAP-ATI (Any Time Interrogation) messages to a UK network to retrieve the Cell-ID of a target subscriber’s current location without any notification to the subscriber. UK operators are required to implement SS7 firewalls, but filtering is not universally complete across all query types and interconnect routes.

    Does 5G fix the SS7 security problem?

    5G’s core network uses a completely different signalling architecture based on HTTP/2 and a service-based model, which eliminates native SS7 exposure in the 5G core. However, 5G networks still maintain SS7 interconnects for backwards compatibility with older networks and global roaming, meaning the SS7 attack surface does not disappear immediately. Full migration away from SS7 will take many years.

    What does Ofcom require UK operators to do about emergency call location?

    Under the General Conditions of Entitlement, UK mobile operators are required to transmit caller location information to the emergency services for 999 calls. Ofcom has mandated support for Advanced Mobile Location (AML) as part of this requirement. Broader SS7 security is covered under the Communications Act 2003 and NIS Regulations 2018, though there is no specific published public audit regime for SS7 security compliance.

The Latest