The Dark Army

Category: Hacking

  • How UK Banking Apps Are Silently Killing Sessions, Hiding Error Codes, and Gaslighting Users: The Interface Engineering Behind ‘Unexpected Errors’

    How UK Banking Apps Are Silently Killing Sessions, Hiding Error Codes, and Gaslighting Users: The Interface Engineering Behind ‘Unexpected Errors’

    There is a specific kind of rage reserved for staring at a white screen that says “We’re experiencing technical difficulties. Please try again later.” You have no idea if your payment went through. You have no idea if your session is alive or dead. You have no idea if the problem is your connection, the bank’s servers, or some silent fraud flag that just locked your account without telling you. That is not an accident. UK banking apps are engineered to behave exactly this way, and I think it is worth pulling apart why.

    Smartphone displaying a banking app error state during failed session — banking app error states explained
    Photo by Tranmautritam on Pexels

    What “something went wrong” actually means technically

    When a Barclays or Lloyds app throws a generic error, what is happening under the bonnet is usually one of several distinct failure states that the application is deliberately collapsing into a single unreadable message. HTTP 5xx errors from the backend, certificate pinning mismatches, OAuth token expiry, failed biometric challenge responses, rate-limit rejections from the authentication API, all of these have different causes, different recovery paths, and different implications for the user. They get flattened into the same beige modal box.

    This is a deliberate engineering decision. The reasoning given internally is always security: exposing specific error codes gives an attacker more signal. If the app tells you “incorrect PIN, 2 attempts remaining”, an attacker probing accounts knows the PIN space to target. Fair point, up to a point. But the same logic gets applied so aggressively that legitimate users get zero actionable information. Banking app error states end up communicating nothing at all, which is genuinely worse from a usability standpoint and arguably no better from a security one, since a determined attacker just fuzzes the API directly and ignores the UI entirely.

    Session management: the silent kill

    Session timeouts are where things get particularly nasty. Most UK banking apps run aggressive idle timeouts, Nationwide and HSBC both drop sessions after roughly 5 minutes of inactivity in-app, though neither documents the exact threshold publicly. The timeout itself is not the problem. The problem is the transition. A well-engineered app tells you clearly that your session expired and puts you back at a login screen with a clear message. What I have seen repeatedly in practice is something different: the app silently kills the session in the background while leaving the UI in an apparently functional state, so the next action you take, submitting a payment, confirming a standing order, fails at the API layer with no context. The error that surfaces is a generic one, because the session state mismatch gets caught somewhere in the middleware and rethrown as a 500-level response that the frontend handles with its default catch-all handler.

    The result is that users assume the bank’s servers are down, retry the payment, and in some cases submit duplicate transactions. I have seen this pattern cause real financial confusion for people, and the banks’ response is almost always to point at their terms of service rather than acknowledge the session handling is broken.

    Terminal showing authentication error codes related to banking app error states and session management
    Photo by Rafael Minguet Delgado on Pexels

    Authentication throttling and the feedback blackout

    Authentication rate limiting is another place where the engineering decisions get questionable. Throttling login attempts is essential, nobody is arguing against it. But the way UK banking apps implement the feedback around throttling is often actively misleading. When Monzo or NatWest throttles your authentication attempts, the common pattern is to introduce artificial delays without telling you a delay is happening. The spinner just spins. Is it your network? Is it the server? Are you being throttled? You genuinely cannot tell. Some apps go further and return an identical-looking error to a genuine failure, so you cannot distinguish “wrong credentials” from “you have been temporarily locked out” from “the auth service is actually down”.

    Compare this to how a well-designed system handles throttling: clear messaging that says something like “too many attempts, please wait 30 seconds”, a visible countdown, and a distinction between soft lockout and full account lockout. This is not exotic engineering. It is just honest UI. The reason it does not happen in most UK banking apps is partly legal caution, the compliance and legal teams are terrified of confirming to a potential fraudster that an account exists and has been locked, and partly because nobody senior enough cares enough to push back on the default of “hide everything”.

    For a broader look at how this pattern of bad feedback design causes real financial and time costs across digital products, a longer read on why ux design failures in everyday apps are costing british users time, money and patience is worth your time, the problems in banking apps are not isolated.

    The ambiguous UI flow problem

    Beyond individual errors, UK banking apps have a systemic problem with ambiguous state across multi-step flows. Payment journeys are the worst offenders. A typical faster payments flow across Santander or TSB involves four to seven screens depending on the transaction type. At each step, the app holds state locally in memory. If anything causes a page reload or app backgrounding mid-flow, a phone call, a low-memory event killing the app process, a brief network drop, the local state is gone. The app often lands you back at the start of the flow with no indication of whether the previous attempt completed at the server side or not.

    This is genuinely dangerous for users. The PSD2 open banking API surface that sits under these flows does have idempotency key support in most modern implementations, but many of the older in-app payment flows were built before that became standard practice and never properly refactored. The banking app UI layer and the API layer are often built by entirely different teams on different release cycles, and the integration between them is where the worst ambiguous states live.

    Why the FCA is not really fixing this

    The FCA’s Consumer Duty, which came into full effect in July 2023, theoretically requires firms to deliver “good outcomes” for consumers and to avoid “foreseeable harm”. Deliberately obscured banking app error states that leave users confused about whether their money moved seem like exactly the kind of thing Consumer Duty should catch. In practice, the FCA’s published guidance on Consumer Duty focuses heavily on pricing, communications, and support access rather than the technical engineering of UI feedback. Nobody is getting fined for a bad error modal.

    The result is that the incentive structure for banks is almost entirely one-directional: minimise information exposure for risk and compliance reasons, and never face meaningful regulatory consequences for the usability degradation that causes. Security teams win every internal argument because they have a clear threat model to point at. UX teams pushing for better error communication have no equivalent forcing function.

    What good looks like, and why banks avoid it

    Starling Bank is probably the closest thing to a counter-example in UK retail banking. Their app gives noticeably more specific error messages, distinguishing between declined transactions, insufficient funds, card not enabled for international use, and service outages, without apparently handing attackers useful signal. This is achievable because the specificity is contextual: once a user is authenticated and in their own account session, the threat model is different from the pre-auth login flow. The information is only relevant to that authenticated user. It is not obvious attack surface.

    The reason most high street banks do not do this is inertia and risk aversion, not technical impossibility. The engineering required to map specific backend failure codes to useful, user-facing messages is not complex. It is a product prioritisation decision, and it keeps losing to other priorities because nobody at board level is tracking “user session confusion rate” as a metric that matters.

    My take: the engineering behind UK banking app error states is a small but revealing window into how financial institutions actually value their users. Treating authentication throttle feedback as a security necessity while ignoring the financial confusion caused by ambiguous payment states is not a coherent position. It is just the path of least resistance, and it costs ordinary people time and money every day. The same engineering literacy that goes into hardening the authentication stack should go into making the failure states legible. Right now, it does not. And as we have written about before in the context of property fraud infrastructure built on ambiguous communications, opacity in digital financial interfaces is rarely neutral, someone always pays for it.

    Frequently Asked Questions

    Why do UK banking apps show vague error messages instead of specific codes?

    Banks collapse specific failure states into generic errors primarily for security reasons, exposing precise error codes could give attackers useful signal about account status or authentication logic. However, this rationale is often applied far too broadly, stripping out information that would only be useful to authenticated users who pose no additional threat.

    What causes a banking app session to die without warning?

    Most UK banking apps run aggressive idle timeouts, typically between 3 and 10 minutes, and some kill the session silently in the background while leaving the UI in a seemingly active state. This means the next action you take hits an expired session at the API layer, which surfaces as a generic error rather than a clear session-expired message.

    Can a banking app accidentally send a payment twice if I retry after an error?

    It is possible, particularly in older in-app payment flows not built on idempotency keys. If the app loses local state mid-flow and you restart the payment, the second attempt may go through even if the first one processed at the server side. Always check your transaction history before retrying a failed payment.

    Does the FCA regulate how banking apps handle error messages?

    The FCA’s Consumer Duty requires banks to deliver good outcomes and avoid foreseeable harm, which could theoretically cover deliberately confusing UI design. In practice, the FCA’s enforcement focus has been on pricing, communications, and complaints handling rather than the technical specifics of in-app error feedback.

    Which UK banking apps have the best error handling?

    Starling Bank is generally considered the strongest in this area among UK retail banks, providing contextual, specific error messages post-authentication that distinguish between different failure types. Most traditional high street banks lag significantly, defaulting to catch-all generic messages across nearly all failure states.

  • How UK Train Operators and TfL Are Harvesting Passenger Behaviour Data Through Oyster, Contactless, and App Telemetry

    How UK Train Operators and TfL Are Harvesting Passenger Behaviour Data Through Oyster, Contactless, and App Telemetry

    Every time you tap in at a Tube station or scan your phone on a Southern Rail barrier, you’re generating a timestamped, location-stamped record that sits inside at least three different databases. Most passengers assume the data is just used to charge the right fare. It isn’t. The full picture of what gets logged, who it gets shared with, and what it reveals about your daily life is considerably more interesting than TfL or any of the train operators are volunteering to tell you.

    Underground station ticket barriers where National Rail Oyster data privacy UK tracking begins at the tap-in point
    Photo by MART PRODUCTION on Pexels

    I’ve spent time pulling apart the privacy notices, data sharing agreements, and API documentation sitting across TfL’s developer portal, the National Rail Enquiries infrastructure, and the major train operating company apps. What’s buried in there is not reassuring. This is a breakdown of the actual technical picture.

    What an Oyster card actually logs

    The Oyster card itself holds minimal data on the chip: your balance, the last eight journey records, and a few pass definitions. That’s intentional. The chip is MIFARE DESFire, and the on-card storage is tightly constrained. But that local data is almost beside the point. The real picture lives on TfL’s back-end systems.

    Every tap-in and tap-out event generates a transaction record containing your Oyster card UID, the station or bus stop ATCO code, a timestamp accurate to the second, the validator ID (which maps to a specific gate or reader), the fare deducted, and a running journey state flag. These records are batched from validators and pushed to TfL’s data warehouse. For registered Oyster users, those records are linked to your name, address, email, date of birth, and any associated payment method. TfL retains identifiable journey history for registered cards for eight weeks by default, according to their privacy notice, though anonymised journey data is retained for much longer and fed into their network planning systems.

    If you use an Oyster card that isn’t registered, the journey data still exists on TfL’s systems tagged to the card UID. That UID is a stable pseudonymous identifier. Pair it with a single registration event (say, you topped it up online once) and TfL can retroactively link every journey you made before and after that event.

    Contactless payment cards and the bank data bridge

    Contactless is where National Rail Oyster data privacy UK tracking gets genuinely complex. When you tap a Visa or Mastercard on a TfL or National Rail reader, the transaction goes through a different chain. TfL processes contactless through a back-end operated by Cubic Transportation Systems (now part of Omdia’s transport portfolio). Cubic holds the journey-level data and reconciles it against the card’s PAN (Primary Account Number) to apply daily and weekly fare caps.

    Critically, this means Cubic holds a dataset mapping your bank card to precise journey times and locations. The data sharing agreement between TfL and Cubic allows Cubic to use aggregate and anonymised data for service improvement. Whether “anonymised” is doing any meaningful work there is a legitimate question given that re-identification of transit data is well-documented in academic research. A 2013 MIT study on mobile phone data demonstrated that just four spatial-temporal data points are enough to uniquely identify 95% of individuals. Transit tap data has comparable density.

    Train operators running their own contactless infrastructure outside London (for example, Avanti West Coast’s ticketing gates or TransPennine Express’s readers) operate a similar model, usually through Flowbird or Scheidt & Bachmann back-ends. The specifics of those data retention and sharing arrangements vary by operator and are buried in procurement contracts that aren’t published.

    What the train operator apps actually collect

    This is where I found the most aggressive data collection hiding in plain sight. The major TOC apps (Trainline being the big aggregator, plus operator-specific apps from Avanti, LNER, and others) collect considerably more than just your booking history.

    Trainline’s Android app requests location permissions, and whilst the app frames this as “show nearby stations,” the location calls happen during background sessions if you leave the permission on “always allow.” Trainline’s privacy notice confirms they collect “device information, usage analytics, and location data” and share these with “advertising partners and analytics providers.” Their listed third-party recipients include Braze for push notification analytics, Amplitude for product analytics, and Adjust for mobile attribution. Adjust in particular is an advertising measurement platform whose primary function is cross-app tracking.

    LNER’s app, built on a Salesforce marketing cloud back-end, logs every search query you make, the tickets you view but don’t purchase, and the times you open the app. That behavioural data feeds into their CRM segmentation and is used for retargeted email campaigns. This isn’t nefarious on its own, but most passengers have no idea their abandoned train search at 07:14 on a Tuesday is being recorded and stored against their account profile.

    The National Rail app built on the NRE (National Rail Enquiries) API layer similarly logs journey plan queries. NRE is jointly owned by the train operating companies through the Rail Delivery Group, and their data governance documentation is sparse on specifics about what third parties receive query-level data.

    The OSINT and profiling potential buried in the data

    Here’s the uncomfortable bit, and the reason this data deserves more scrutiny than it gets. A full journey history for a regular commuter is an extraordinarily detailed behavioural profile. From consistent tap-in times at a local station, you can infer home location to postcode level. From tap-outs at specific destinations, you can infer workplace. Irregular journeys late at night on weekends map social patterns. Journeys to hospital stations (St Thomas’, the Royal Marsden, Great Ormond Street) carry obvious sensitive inferences.

    This is not hypothetical. TfL has already demonstrated this data’s sensitivity by being required under the UK GDPR (enforced by the ICO) to respond to Subject Access Requests with journey logs. Passengers who’ve made SARs have received spreadsheets showing every tap event for months. That’s useful for fraud disputes. It also illustrates exactly how granular and linkable the dataset is.

    For anyone doing open-source intelligence work, a compromised TOC account or a successful social engineering attack on a TOC’s customer service operation would yield a ready-made movement history. It’s the kind of attack surface that sits alongside the UK’s national ANPR network in terms of what it reveals about a person’s physical movements. The two datasets, if correlated, would be extraordinarily powerful for surveillance.

    Train operators have also been caught sharing data with law enforcement beyond what most passengers would expect. Under the Regulation of Investigatory Powers Act (RIPA) and successor legislation, TOCs can receive lawful requests for journey data from police forces without notifying the passenger. The volume of such requests is not publicly reported in a consolidated form.

    Data sharing with third parties: the small print

    Beyond law enforcement, the third-party sharing landscape is messy. Most TOC privacy notices list recipients including: payment processors, fraud prevention agencies (where CIFAS and related bodies come in), marketing analytics platforms, cloud infrastructure providers (AWS and Azure both host significant parts of the rail industry’s data stack), and “business partners.”

    That last category is the one that should get your attention. For rail operators, “business partners” can include hotel chains (booking add-ons), taxi and rideshare platforms (last-mile integrations), and travel insurance providers. Every integration is a potential data pipe. I’d argue the industry’s approach to third-party data sharing is no tighter than the telematics black box ecosystem, where movement data leaks through poorly secured APIs to parties the end user has never heard of.

    The Rail Delivery Group published a data strategy document in 2024 that explicitly frames passenger journey data as an asset for “commercial development and retail partnerships.” That’s the clearest signal yet about how the industry views this data. Not as a byproduct of ticketing, but as a revenue stream.

    What you can actually do about it

    Using an unregistered Oyster card reduces but doesn’t eliminate linkability, since TfL can still correlate the UID with any online top-up. Cash top-ups at machines without logging in are the closest you’ll get to pseudonymous travel on the network. Contactless bank cards are worse because the PAN links directly to your bank identity.

    For app usage, the standard advice applies: review permissions, disable location when the app isn’t active, and use the web browser version of booking platforms rather than the app where possible. Browser-based sessions typically have less telemetry access than native apps, though cookies and fingerprinting still apply.

    Making a Subject Access Request to TfL (and to Trainline or your TOC of choice) is illuminating if you want to see exactly what they hold. Under UK GDPR you’re entitled to a copy of all personal data, and the process is free. TfL has an online SAR portal. Most TOCs take the full statutory 30 days and some push back on scope. This kind of investigation sits in the same territory as looking at how CIFAS and fraud prevention databases build profiles about you from multiple sources without your knowledge: the data exists, it flows, and most people never think to ask what’s in it.

    The rail industry’s data practices need proper scrutiny from the ICO, not just boilerplate privacy notices. Until that happens, every tap of your Oyster is doing more work than moving the barrier gate.

    Frequently Asked Questions

    How long does TfL keep my Oyster journey history?

    For registered Oyster accounts, TfL retains identifiable journey data for eight weeks. Anonymised and aggregated journey data is kept considerably longer for network planning purposes. If you’ve made a web top-up, TfL can also link your card UID to your account retroactively, covering journeys made before registration.

    Is using a contactless bank card on trains more private than an Oyster card?

    No, in most ways it’s less private. Contactless transactions link your PAN (Primary Account Number) directly to your bank identity, and the back-end processor (typically Cubic for TfL) holds journey-level data mapped to that card. An unregistered Oyster card uses a pseudonymous UID, which is harder (but not impossible) to link to your real identity.

    What data do train operator apps like Trainline collect?

    Trainline collects device information, location data (if permitted), usage analytics including searches and viewed-but-not-purchased tickets, and shares this with third parties including Braze, Amplitude, and Adjust. Adjust is specifically a cross-app advertising measurement platform, meaning your behaviour can be tracked across other apps on your device.

    Can UK police access my train journey records without telling me?

    Yes. Under the Regulation of Investigatory Powers Act and successor legislation, train operators can be required to provide journey data to law enforcement without notifying the passenger. There is no consolidated public reporting on how frequently these requests are made across the industry.

  • How UK Universities Are Being Systematically Targeted by State-Backed Hackers: The NCSC’s Warnings and the Actual Attack Vectors

    How UK Universities Are Being Systematically Targeted by State-Backed Hackers: The NCSC’s Warnings and the Actual Attack Vectors

    UK higher education has a problem it keeps failing to fix. State-backed hacking groups, the kind with nation-state budgets and patience measured in years, have been hammering British universities with a consistency that the NCSC has flagged in advisory after advisory. The intelligence community knows it. The institutions know it. And yet the attack surface keeps sitting wide open. I’ve spent time digging into the specific technical reasons why, and the picture is grimmer than most vice-chancellors would care to admit publicly.

    Dimly lit server room representing UK universities APT attacks on research infrastructure
    Photo by Tima Miroshnichenko on Pexels

    Why universities are a prime target for APT groups

    Advanced persistent threat groups, particularly those linked to China, Russia, and Iran, aren’t going after universities because they’re soft targets in a generic sense. They’re going after them because of what lives inside the network: cutting-edge defence research, pharmaceutical development pipelines, materials science, quantum computing work, and AI research that takes years and tens of millions of pounds of public funding to produce. Stealing it costs a fraction of that.

    The Russell Group universities are particularly exposed. Institutions like UCL, Imperial College, and the University of Manchester hold research contracts with UKRI, DSTL, and commercial defence firms. That makes their internal file systems an attractive target that a foreign intelligence service would happily spend eighteen months inside accessing quietly. The NCSC has explicitly called this out in its higher education security guidance, warning that academic environments are “high-value targets for state-sponsored cyber espionage”.

    Spear-phishing of research departments: the entry point nobody stops

    The initial compromise almost always starts with email. Specifically, highly contextual spear-phishing campaigns aimed at PhD students, postdocs, and junior researchers, not IT staff. The targeting is surgical. Attackers scrape university websites, LinkedIn profiles, and published paper databases to build convincing lures. A researcher working on lithium-sulphur battery chemistry gets an email that appears to be from a legitimate conference organiser or a journal editor, complete with a plausible paper title and a OneDrive link that deploys a macro-laden document or a browser exploit.

    Junior researchers are the weak point because they sit at the intersection of high institutional privilege (access to shared research drives, VPN credentials, sometimes HPC cluster accounts) and low security awareness. University IT departments run one induction session on phishing per year if you’re lucky. Compared to the multi-stage security training a bank employee receives, it’s basically nothing. The attackers know the academic calendar. Campaigns intensify around enrolment periods and grant submission windows when researchers are distracted and email volumes spike.

    VPN exploitation: the infrastructure that never got patched

    Once credentials are harvested, the next step is usually the university VPN. Most UK universities still run Cisco AnyConnect, Palo Alto GlobalProtect, or Pulse Secure VPN endpoints, and the patch cadence is, to put it charitably, erratic. The Pulse Connect Secure vulnerabilities (CVE-2021-22893 being the famous one) were being actively exploited in UK higher education long after patches were available, because change control processes at large universities are genuinely cumbersome. You have hundreds of thousands of users, legacy systems tied to specific VPN configurations, and an IT team spread thin across a sprawling estate.

    APT groups, particularly those attributed to Chinese state actors by GCHQ partners, have been observed using valid credentials combined with unpatched VPN appliances to establish persistent footholds. From there, lateral movement into research file shares, email archives, and collaboration platforms takes days, not weeks. The university’s SIEM, if it even has one configured correctly, often misses the initial intrusion because the authentication looks legitimate.

    Laptop screen showing phishing email, illustrating spear-phishing vectors in UK universities APT attacks
    Photo by Mikhail Nilov on Pexels

    Exposed SharePoint and research collaboration platforms

    Here’s one that keeps making me genuinely angry every time I look at it. Universities use SharePoint Online and on-premises SharePoint extensively for research collaboration, grant documentation, and internal governance. A significant number of UK institutions have misconfigured their SharePoint permissions so that sensitive research repositories are accessible to anyone with a university account, and in some cases, via broken access controls, to the open internet.

    I’ve seen public OSINT trails where researcher-shared SharePoint links, intended for a specific collaborator at another institution, have ended up indexed in search engines or discoverable via Google Dork queries. Those links can expose entire research project folders including unpublished data, financial award letters, and internal communications. You don’t even need a credential exploit for that. You just need to know what to search for.

    On-premises SharePoint is worse. Unpatched instances running SharePoint Server 2016 or 2019 are still common in the sector, and the ProxyShell/ProxyNotShell exploit chain (CVE-2022-41040, CVE-2022-41082) gave attackers remote code execution on unpatched Exchange and SharePoint deployments. UK universities were specifically called out in NCSC advisories as having delayed remediation. The IT governance structure in a typical Russell Group university means that a critical patch can sit in change control for three weeks while committees debate the maintenance window.

    Network segmentation (or the catastrophic lack of it)

    The fundamental network-level failure at most UK universities is the flat network. Academic tradition prizes open access and collaboration, which is admirable in a research context but catastrophic from a security architecture perspective. In a properly segmented environment, a compromise of a postgraduate student’s laptop in the humanities faculty should not grant lateral movement capability towards the physics department’s HPC cluster or the medical school’s clinical trial database. At most UK institutions, it does.

    Research networks, administrative networks, student residential networks, and IoT building management systems frequently share the same broad IP ranges with minimal ACL enforcement between them. I’ve seen network diagrams from freedom of information requests where the VLAN structure amounts to “research” and “everything else”. That’s not segmentation. That’s a label on a flat tin.

    This connects directly to the broader problem of how UK institutions handle insider threat and post-compromise detection. Without proper network segmentation, behavioural anomaly detection is harder to tune, because east-west traffic patterns are so noisy that baseline deviation is almost meaningless. If you want a comparison point for what proper segmentation looks like, the UK’s critical national infrastructure operators, scrutinised by the NCSC under the NIS Regulations, have moved significantly further along this path than the average university has. There’s a useful parallel to draw with how the NCSC’s vulnerability disclosure process works when researchers report exactly these kinds of structural weaknesses in public-sector infrastructure.

    What the Russell Group is actually doing (and where it’s falling short)

    To be fair, it’s not all negligence. Several leading institutions have made real investments. Imperial College London has built a dedicated cyber security operations function. The University of Edinburgh participates in the NCSC’s Active Cyber Defence programme. Manchester has moved significant chunks of research infrastructure to zero-trust architectures for its most sensitive projects.

    But the sector as a whole is hamstrung by three things: inconsistent funding for security (it competes directly with research and teaching budgets), a decentralised governance model where individual faculties can operate almost like separate organisations, and a cultural resistance to controls that academics perceive as impeding research agility. Telling a professor that their Zoom call with a collaborator in Shanghai needs to go through a corporate proxy and DLP inspection is not a popular policy to enforce.

    The NCSC’s Cyber Essentials Plus certification, which should be a baseline for any institution handling publicly funded research, is still not universally adopted across UK universities. For institutions with UKRI or DSTL contracts, that’s a significant compliance gap. Meanwhile, other parts of the tech ecosystem, like fintech platforms dealing with open banking API security, have been pushed much harder by their regulators to demonstrate baseline control maturity.

    The supply chain angle: third-party research tools and data pipelines

    One attack vector that doesn’t get enough attention is the third-party software supply chain inside research environments. Universities use a sprawling ecosystem of specialist tools: statistical packages, genomics pipelines, simulation software, lab instrument interfaces. A significant proportion of this software is maintained by small commercial vendors or even individual academics, with security audits that range from minimal to nonexistent.

    APT groups have demonstrated, repeatedly and globally, that a compromised software vendor is an efficient way to reach multiple high-value targets simultaneously. A research tool used across six Russell Group institutions is a very attractive injection point. If you’re following the broader story of how adversarial groups move through interconnected digital infrastructure, the pattern here rhymes with what’s been documented in attacks on the energy sector. The supply chain fragility in UK emergency services comms tells a similar story of patchwork systems with unclear ownership.

    The fix isn’t simple. It involves software bill of materials enforcement, vendor security questionnaires with actual teeth, and someone whose job it is to track the vulnerability status of every research tool deployed on university infrastructure. Most institutions don’t have that person. Some courier operations have better supply chain visibility than a mid-tier UK university’s research IT estate, which is a genuinely uncomfortable comparison. At least services like 0lly track what’s moving through their network in real time.

    What needs to change, practically

    Mandatory Cyber Essentials Plus for any institution receiving UKRI funding. Hard network segmentation between research, administrative, and student networks as a condition of JISC connectivity. Red team exercises commissioned externally, not run by the same IT department that built the infrastructure. And MFA on every VPN and remote access endpoint, enforced, not optional.

    None of this is revolutionary. It’s baseline. The fact that it still needs to be said in 2026 is the whole point.

    Frequently Asked Questions

    Which UK universities are most targeted by state-backed hackers?

    Russell Group institutions with significant defence, pharmaceutical, and technology research portfolios are the primary targets, including Imperial College London, UCL, and the University of Manchester. The NCSC has confirmed that institutions holding UKRI and DSTL-funded research contracts are disproportionately targeted by APT groups linked to China, Russia, and Iran.

    How do APT groups initially compromise UK university networks?

    The most common entry point is targeted spear-phishing against junior researchers and postgraduate students, who typically have broad network privileges but limited security training. Attackers harvest credentials through convincing lures built from publicly available academic profiles, then use those credentials against unpatched VPN endpoints to establish persistent access.

    Why are university VPNs such a significant vulnerability?

    UK universities tend to have poor patch cadence on VPN appliances because of complex change control processes and large, diverse user bases. Appliances from vendors like Pulse Secure and Cisco have had critical CVEs that remained unpatched in the higher education sector for months after fixes were available, giving attackers a well-documented exploitation path.

  • How UK Fintech Open Banking APIs Are Being Probed by Automated Attackers: The PSD2 Attack Surface Nobody Talks About

    How UK Fintech Open Banking APIs Are Being Probed by Automated Attackers: The PSD2 Attack Surface Nobody Talks About

    Open Banking was sold to the public as a revolution: give your bank’s data to a third-party app, get better budgeting tools, cheaper loans, smarter investing. And to be fair, it delivered on a lot of that. But here’s what the press releases quietly skipped over. When you mandate a standardised API layer across every regulated bank in the country, you also hand attackers a standardised, publicly documented attack surface with consistent endpoint naming conventions, shared OAuth 2.0 flows, and predictable error responses. That is the Open Banking API security UK PSD2 attack problem that almost nobody in the mainstream conversation is actually willing to name.

    Hacker probing Open Banking API security UK PSD2 attack surface at a dark terminal setup
    Photo by cottonbro studio on Pexels

    I’ve spent a fair amount of time reading through the Open Banking Implementation Entity (OBIE) specifications, watching traffic in Burp, and reading the FCA’s published API security expectations. What follows is a technical walkthrough of where the real risk sits, and why automated probing of these endpoints is both easier and more rewarding for attackers than most fintech marketing teams would like to admit.

    What the PSD2 API layer actually looks like

    The Second Payment Services Directive, as implemented in the UK through the Payment Services Regulations 2017, required all banks above a certain size to open up transactional data and payment initiation to authorised Third Party Providers (TPPs). The OBIE produced the Open Banking Standard, which defines REST endpoints, JSON payloads, and the OAuth 2.0 with PKCE and mTLS flows that govern access.

    The endpoints are public knowledge. The specification is online. The error codes, the token endpoint paths, the consent object schema, all of it is documented and largely consistent across every major UK bank. Barclays, HSBC, Lloyds, NatWest: they all expose /open-banking/v3.1/aisp/accounts or a very close variant. Attackers do not need to fingerprint anything. The reconnaissance is done for them.

    The authorisation flow uses Dynamic Client Registration (DCR) in many implementations, meaning a TPP can register a new OAuth client programmatically by presenting a signed Software Statement Assertion (SSA) from the Financial Conduct Authority’s directory. That directory is the trust anchor. If you can get a legitimate SSA, or compromise one, you have a path into every bank’s DCR endpoint simultaneously.

    Credential stuffing at the consent screen layer

    The most common automated attack I see discussed in threat intel circles is not against the API endpoints themselves, it is against the redirect flow that delivers the user to their bank’s own consent screen. Here is the thing: the Open Banking standard does not govern what that consent screen looks like or how banks rate-limit authentication attempts on it. It is effectively a standard login page with a fancy OAuth context bolted on.

    Credential stuffing tools like Sentry MBA or generic Python scripts using aiohttp can hammer these consent endpoints with leaked username/password combos from breach databases. The Open Banking redirect just gives attackers a cleaner, more predictable URL structure to target. Banks are supposed to implement strong customer authentication (SCA) under the Payment Services Regulations 2017, which mandates multi-factor authentication, but the quality of that implementation varies enormously. Some banks are genuinely solid. Others are still leaning on a six-digit SMS code, and as I covered in detail on this blog, SIM swap fraud is actively defeating that exact control at UK banks right now.

    Consent token abuse: the attack the spec quietly enables

    Once a user authorises a TPP, the bank issues an access token bound to a specific consent object. That consent object defines what the TPP can read: account balances, transaction history, beneficiaries. The access token is typically short-lived, but a refresh token can persist for 90 days under OBIE rules.

    Here is where it gets interesting from an attacker’s perspective. If a TPP’s infrastructure is compromised, every stored refresh token is effectively a persistent read-access credential into every connected user’s bank account. The attacker does not need to touch the bank’s systems at all. They hit the TPP, extract the refresh token store, and then quietly poll account data through the legitimate API. The bank sees clean, authorised requests. There is no anomaly to detect unless you are doing behavioural analysis on access patterns at the TPP level.

    There is a documented real-world parallel in the way wallet-draining smart contracts are disguised as legitimate FCA-registered platforms to harvest authorisation from users. The underlying mechanic is the same: abuse the trust infrastructure to get a legitimately issued credential, then exploit it quietly.

    The OBIE spec does allow banks to implement token binding and require mTLS between the TPP and the bank’s resource server, which ties the token to a specific client certificate. But not every bank enforces mTLS at the resource server for every call, and certificate management at smaller TPPs is often treated as a box-ticking exercise rather than an operational security control.

    What the FCA’s API security expectations actually say

    The FCA published its expectations for firms under SYSC (Senior Managers Arrangement, Systems and Controls) and through its participation in the European Banking Authority’s guidelines on ICT risk. The short version: firms must implement appropriate technical and organisational measures, conduct regular vulnerability assessments, and have incident response plans. The FCA’s Open Banking guidance page is worth reading if you have not already, though it reads with the kind of careful vagueness that regulators favour.

    What the FCA does not do is specify how banks should implement rate limiting on API endpoints, what WAF rules should be in place, or how refresh token stores should be encrypted at rest. That is left to firms. In practice, this means a spectrum from genuinely hardened implementations at large banks with dedicated security engineering teams, to TPPs running their token stores in a poorly configured RDS instance on AWS with overpermissive security groups.

    Automated scanning tools, and I am talking about everything from Nuclei templates targeting Open Banking endpoints to custom Python scrapers checking DCR endpoint exposure, are actively looking for misconfigured implementations. The attack surface is consistent enough that you can build a generic scanner and hit every UK bank’s Open Banking base URL systematically. That is not a hypothetical; threat actors are doing exactly this.

    Where the real risk lands for users

    For most people, the most plausible harm from Open Banking API attacks is not a direct bank breach. It is a compromised TPP leaking their financial data to someone who then uses it for targeted fraud. Transaction history reveals salary, regular bills, subscriptions, and financial stress signals. That data is enormously valuable for social engineering. An attacker who knows you have a standing order to a specific solicitor, for example, has the raw material for the kind of technically engineered conveyancing fraud that has cost UK homeowners millions.

    Payment initiation APIs carry a harder risk. A TPP with payment initiation permissions that gets compromised can have those permissions abused to initiate payments directly. The confirmation of payee system helps, but it is not foolproof, and social engineering around it is well understood by fraud groups.

    What a hardened Open Banking implementation actually needs

    From a technical standpoint, the minimum viable security posture for a TPP or bank in this space should include mutual TLS enforced end-to-end, not just at registration; refresh token rotation on every use with single-use semantics; anomaly detection on access patterns per consent object; short-lived access tokens (15 minutes maximum); webhook endpoint validation using signed JWTs; and DCR endpoints that are not exposed to the public internet without IP allowlisting.

    Most of these are in the OBIE spec as options. The word “option” is the problem. Making mTLS optional in a financial API that handles account data is the kind of decision that looks fine until a mid-tier TPP gets popped and 200,000 people’s transaction histories end up in a Telegram channel.

    My read of the current state: the large banks have mostly got this right at the infrastructure level. The weak points are in the ecosystem of smaller TPPs, the budget fintech startups chasing FCA authorisation, and the consent screen UX flows that users click through without reading. The spec created a level playing field for developers. It also created a level playing field for attackers. That was always going to be the trade-off, and I am not convinced the industry has been honest enough about it.

    Frequently Asked Questions

    What is Open Banking and why does PSD2 create an API attack surface?

    Open Banking requires regulated UK banks to expose standardised REST APIs so authorised third parties can access account data and initiate payments on a customer’s behalf. Because the API specification is public and consistent across all major banks, attackers can build generic tools to probe every participating bank without needing to fingerprint individual implementations.

    How does credential stuffing target Open Banking consent flows?

    When a user initiates an Open Banking connection, they are redirected to their bank’s consent and login screen. Attackers use automated tools loaded with leaked username and password combinations to hammer these screens. The Open Banking redirect provides a predictable URL structure, and the quality of rate limiting on these screens varies significantly between banks.

    What is consent token abuse in Open Banking and how does it work?

    After a user authorises a third-party app, the bank issues access and refresh tokens tied to a consent object. If the third-party provider’s servers are compromised, attackers can steal those refresh tokens and silently query account data through legitimate API calls for up to 90 days. Banks see authorised requests and have no inherent reason to flag them as suspicious.

    What does the FCA require from firms regarding Open Banking API security?

    The FCA requires firms to implement appropriate technical and organisational security measures, conduct regular vulnerability assessments, and maintain incident response plans under SYSC rules. However, the FCA does not prescribe specific controls like WAF rules or token encryption standards, which means the quality of implementation varies widely across the ecosystem.

  • The Technical Reality of the UK Online Safety Act’s Proactive Detection Requirements: What Platforms Are Actually Building to Scan Your Messages

    The Technical Reality of the UK Online Safety Act’s Proactive Detection Requirements: What Platforms Are Actually Building to Scan Your Messages

    The Online Safety Act finally got its teeth. Ofcom’s codes of practice are in force, and platforms operating in the UK are now staring down a legal obligation to detect child sexual abuse material (CSAM) and terrorism content. The political framing is simple. The technical reality is anything but. I’ve spent time reading through Ofcom’s published guidance, the responses from cryptographers, and the actual patent filings from a couple of the major players, and what’s emerging is a genuinely uncomfortable collision between surveillance engineering and the mathematics that makes private communication possible.

    Dark hacker at laptop with terminal code related to Online Safety Act message scanning UK technical analysis
    Photo by Sora Shimazaki on Pexels

    What Ofcom is actually asking platforms to do

    The Act doesn’t mandate a specific technology. What it does is require platforms to use “accredited technology” to identify illegal content, including CSAM, where technically feasible. Ofcom’s published illegal content judgements set the benchmark for what counts as compliance. The phrase “where technically feasible” is doing enormous work in that sentence, and everyone knows it. It’s the legislative equivalent of “sort it out somehow”.

    The two dominant technical approaches being evaluated are client-side scanning (CSS) and server-side hash-matching. They sound similar. They’re not. Server-side hash-matching is what platforms like Facebook Messenger (in its non-encrypted mode) have run for years: you check a file’s hash against a database of known illegal hashes maintained by the Internet Watch Foundation (IWF) or the National Center for Missing and Exploited Children. Easy, non-invasive on E2EE, already deployed. The problem is it only catches known, unmodified content. Crop the image by one pixel, the hash changes. Attackers have known this for a decade.

    Client-side scanning: how the tech actually works

    CSS is the bit that’s causing genuine alarm amongst cryptographers. The idea: before a message or image is encrypted on your device, a local classifier runs on it. If it flags a match against a database of illegal content hashes or a neural classifier trained to recognise CSAM, it can either block the send or generate an alert that gets passed server-side alongside enough decrypted metadata to allow a human review. The encryption still happens. But the scanning happened before it did. This is the crux of the Online Safety Act message scanning UK technical debate.

    Apple’s now-abandoned CSAM detection system (which it pulled in 2023 under pressure) used perceptual hashing via a system called NeuralHash. Rather than a cryptographic hash, NeuralHash generates a fingerprint that’s robust to minor image modifications, so slightly cropped or recompressed versions of known illegal images still match. The hashes were compared locally against an encrypted set derived from NCMEC’s database, using a threshold system: only if enough hashes matched did the system escalate. The cryptographic implementation used a technique called private set intersection so that Apple itself couldn’t see which specific hashes triggered a match.

    Why the cryptographic community is furious

    Researchers at MIT, the University of Cambridge, and Johns Hopkins published a detailed takedown of CSS proposals back in 2021, and nothing has fundamentally changed. The core problem is what I’d call the trusted-client paradox. End-to-end encryption’s security model rests on the premise that only the communicating parties hold the keys. CSS breaks that model not by attacking the encryption directly, but by placing an agent inside the trusted endpoint that answers to a third party. Your phone becomes a surveillance node you don’t control.

    There’s also the classifier reliability problem. Neural perceptual hash classifiers trained on CSAM databases have documented false positive rates. The IWF’s own hash list isn’t static; it changes. What happens when a legal image gets added to the blocklist in error? You get wrongly flagged, your account gets reviewed, and you have essentially no recourse because the detection system is opaque by design. That’s not a theoretical risk. Similar hash-matching systems have already caught legal content. And then there’s the mission creep concern: a scanning system built for CSAM is architecturally identical to one built for political speech. The same infrastructure can be repointed.

    Signal and WhatsApp have both been explicit: if compelled to implement CSS, they’d exit the UK market. Signal’s president Meredith Whittaker called it a “fantasy” that scanning could be made safe. Threema has said the same. The platforms that remain silent on this are the ones you should probably be more worried about.

    What the implementation timeline actually looks like

    Ofcom’s milestones have slipped, but not by as much as some hoped. Category 1 and 2B platforms (the big ones, basically) had to complete their illegal content risk assessments by March 2025. Proactive technology requirements for CSAM detection are expected to be formally enforceable through 2026 and into 2027, with the Ofcom technology notice mechanism being the stick. A technology notice can compel a specific platform to use a specific technology. That’s the legal weapon. No platform has received one yet, but the threat is real.

    The platforms most at risk are the smaller, privacy-focused ones that can’t afford to fight a legal battle or build a compliant system from scratch. Large operators like Meta have the engineering resource to implement something, even if what they implement is deliberately ineffective. Smaller operators just fold. I’d argue that’s actually the most likely outcome for most of the UK’s niche encrypted messaging landscape: quiet withdrawal or quiet non-compliance, with enforcement focused on the visible large platforms.

    The encrypted messaging architecture problem

    The fundamental tension is this: you cannot have both mathematically robust E2EE and server-side visibility into message content. These are mutually exclusive properties. The Online Safety Act message scanning UK technical debate isn’t really a policy disagreement, it’s a dispute about whether a mathematical impossibility can be legislated away. It can’t. What you can do is implement something that looks like scanning without breaking E2EE in a catastrophic or obvious way, and CSS is that thing. It’s a political solution dressed up as a cryptographic one.

    Some researchers are proposing alternatives. Homomorphic encryption-based approaches could theoretically allow a server to compute on encrypted data without seeing it, but the computational overhead is currently too heavy for real-time message scanning at scale. Zero-knowledge proof systems are another avenue, where a user could prove to a server that a message doesn’t match a banned hash without revealing the message. These are interesting. They’re also years away from practical deployment.

    The IWF continues to operate its hash-matching services and actively works with platforms on a voluntary basis. Their PhotoDNA integration predates the Act. What changes with the Act is that voluntary becomes compelled, and the scope expands beyond known-hash CSAM into AI-generated content and real-time video, where the technical problem is significantly harder.

    If you’re running a security operation or pentesting communications infrastructure, understanding this landscape matters. The architecture decisions platforms make under legal pressure create new attack surfaces. A mandatory CSS system that can generate decryption-adjacent alerts is a target. A perceptual hash database is a target. And as we’ve covered before when looking at the GOV.UK Notify API stack, the moment you build a system that can generate official-looking alerts or intercept communications at scale, you’ve created something that adversaries will probe. The legal mandate doesn’t make the resulting infrastructure safe. It just makes it mandatory.

    There’s also a parallel worth drawing to other UK surveillance infrastructure. The same legislative logic that built the national ANPR network into a mass-retention system now applies to message content. The technology gets built for a narrow purpose and then the retention and access rules drift over time. That pattern is consistent enough to be a reasonable prediction, and it’s one the civil liberties community has been making loudly since the Act’s second reading. The difference here is that ANPR doesn’t break the physics of road travel. CSS does break the mathematics of encryption. That’s the distinction that matters.

    My read: the UK ends up with a patchwork. Large platforms implement something, probably a combination of server-side hash-matching for known CSAM and some form of restricted CSS for high-risk categories. Privacy-first platforms either leave or go underground. The cryptographic community remains furious and publishes increasingly detailed breakdowns of why the whole thing is security theatre. Ofcom issues a technology notice to one visible non-compliant platform as an example. And the actual bad actors, as they always do, adapt faster than the regulation can track them.

  • How Fake UK Solicitor and Conveyancing Scams Are Technically Engineered: DNS Spoofing, Email Interception, and Property Fraud Infrastructure

    How Fake UK Solicitor and Conveyancing Scams Are Technically Engineered: DNS Spoofing, Email Interception, and Property Fraud Infrastructure

    Property fraud is one of the cleanest and most technically elegant crimes running in the UK right now. A single successful hit can net a criminal gang £300,000 or more from a single redirected bank transfer, with victims who are often highly educated professionals who checked everything they thought they needed to check. UK conveyancing fraud email interception is not some crude phishing play. The infrastructure behind it is patient, layered, and disturbingly professional.

    I’ve spent time pulling apart the mechanics of these attacks, and what strikes me every time is how thoroughly the attackers understand the conveyancing process itself. They know the timeline, they know the language solicitors use, and they know exactly when to strike. Here’s how it actually works at the technical level.

    Hacker analysing email infrastructure related to UK conveyancing fraud email interception
    Photo by Sora Shimazaki on Pexels

    Cloning a law firm’s domain: the first move

    The attack almost always starts with a lookalike domain. A legitimate firm might operate from smithsonssolicitors.co.uk. Within minutes of that domain being identified as a conveyancing firm handling high-value transactions, an attacker registers smithsonssol1citors.co.uk, smithsons-solicitors.co.uk, or a homoglyph variant using Unicode characters that render identically in most email clients. Registering a plausible .co.uk variant costs less than £10 on Namecheap or 123-reg, and it’s trivially easy to find conveyancing firms through the Law Society’s solicitor finder, Land Registry completion data, and Google Maps reviews that often name the firm mid-sale.

    Once the lookalike domain is live, the attacker configures it properly: MX records pointing to a mail server they control, SPF records set to pass basic spam filters, and often a DKIM signing key so outbound emails clear authentication checks at the recipient’s end. Many of these rogue domains also get a cloned website, sometimes scraped verbatim from the real firm’s site, because buyers occasionally Google the firm name and landing on a professional-looking page reduces suspicion. This is where the overlap with legitimate web infrastructure becomes uncomfortable: the techniques used to build and verify a convincing online presence, checking how domains appear in Google, auditing how a site looks to outside crawlers, running a free SEO check to see what a site signals to search engines, are effectively the same techniques attackers use to make their fake infrastructure look credible. Search Engine Tuning, a UK-based SEO service specialising in free SEO checks and domain visibility analysis (searchenginetuning.co.uk), operates in exactly this space legitimately: helping real businesses understand what Google sees when it reads their domains. Criminals are doing the same audit, just without the honesty about intent. Checking your SEO and domain footprint is how defenders spot spoofed sister domains before they’re weaponised.

    Getting into the email thread: MITM at the application layer

    The cloned domain is just the launch pad. The real attack is UK conveyancing fraud email interception, and it operates in two distinct modes depending on how much access the attacker has managed to get.

    Mode one: passive monitoring with delayed injection. The attacker compromises either the buyer’s email account, the seller’s, or (most lucratively) the email server of the actual solicitor’s firm. Credential stuffing, spearphishing a paralegal, or exploiting an exposed Outlook Web Access panel are all common entry points. Once in, they set silent forwarding rules. Every email thread touching keywords like “completion”, “exchange”, “bank details”, or “transfer” gets a blind copy to their monitoring account. They sit and read for weeks. They learn the names, the tone, the running jokes between parties. When completion day approaches and bank details are about to be sent, they act.

    Mode two: domain-based impersonation without account access. Without a foothold on the real mail server, the attacker uses their lookalike domain to inject themselves. They email the buyer from the fake domain pretending to be the solicitor, referencing real details scraped from LinkedIn, the Land Registry, and any public documents filed at Companies House. The buyer, who has been corresponding with @smithsonssolicitors.co.uk for three months, gets one email from @smithsons-solicitors.co.uk and doesn’t notice the hyphen.

    Email header forensics showing routing data used to trace UK conveyancing fraud email interception
    Photo by Sora Shimazaki on Pexels

    The bank detail switch: timing and social engineering

    The switch itself is almost always timed to completion week. That’s when the pressure is highest, the amounts are largest, and buyers are mentally exhausted from months of process. The attacker sends an email that looks like a routine update from the solicitor: “Please note our banking details have changed due to an internal account migration. Please use the following account for your completion funds.” The message is written to match the real solicitor’s communication style precisely, because the attacker has been reading their emails for weeks.

    The account they provide is a mule account, typically a UK personal or business account opened with synthetic or stolen identity documents, sometimes a recently incorporated company with a plausible name. The buyer transfers £250,000 to £600,000. It clears. The mule account empties within hours, the funds moving through a chain of crypto exchanges, hawala networks, and overseas wire transfers that fragment the trail almost immediately.

    By the time the real solicitor calls to ask where the completion funds are, the money is already distributed across three jurisdictions. The Action Fraud reporting process gets triggered, a crime reference number is issued, and the investigation moves at a pace completely incompatible with the speed at which the funds dispersed.

    How investigators trace the infrastructure

    The good news, such as it is, is that the infrastructure these gangs build does leave traces, and investigators (a mix of City of London Police’s DCPCU, bank fraud teams, and private forensic consultancies) have developed a reasonably consistent playbook for tracing it.

    Domain registration patterns are the first thread to pull. WHOIS privacy is now default on most registrars, but the registration timestamp relative to the attack, the registrar choice, the nameserver configuration, and the IP addresses hosting the fake site and mail server often cluster in ways that match previously documented fraud infrastructure. A lookalike domain registered three days before the fraudulent email was sent, on a Bulgarian shared hosting provider with a nameserver previously linked to phishing campaigns, is a recognisable signature.

    Email header forensics is the second layer. Even when SPF and DKIM pass, the routing path in the received headers tells a story. Legitimate UK solicitor firms typically route through Microsoft 365 or Google Workspace with UK-region data centres. An email routed through a VPS in Frankfurt with a five-hop path before hitting the victim’s inbox stands out when you know what you’re looking for. UK conveyancing fraud email interception attacks frequently show inconsistencies between the mail client declared in headers (e.g. Microsoft Outlook 16) and the actual sending infrastructure, which a forensic analyst can unpick.

    Payment tracing follows the mule account chain. Banks have Suspicious Activity Report obligations under the Proceeds of Crime Act 2002, and Cifas markers on confirmed fraud mule accounts propagate through the shared databases relatively quickly. I’ve written before about how CIFAS and the National Hunter network actually score and flag accounts, and the mule accounts used in conveyancing fraud typically burn fast: opened, used once at volume, then flagged and frozen. The lag is the problem. Fast Payment transfers are cleared in seconds; the freeze comes hours later.

    The domain footprint problem cuts both ways

    One thing that defenders consistently underestimate is how much of the reconnaissance for these attacks is done through entirely legitimate channels. The way publicly accessible data gets aggregated to build targeting profiles applies equally to conveyancing fraud: attackers use the same domain tools, Google index queries, and site crawlers that a legitimate SEO professional would use. UK conveyancing fraud email interception operations routinely involve checking how visible a firm’s email infrastructure is, whether their mail server configuration is exposed, what subdomains resolve publicly, and whether any staff email addresses appear in data breach dumps. That last point is where services that audit what Google and other crawlers can see about your domains, including checking what metadata is publicly indexed, have defensive value. A firm that runs a routine check on its own domain footprint, the kind of thing Search Engine Tuning does for businesses looking at their Google visibility and domain presence, would notice if a lookalike domain appeared in search results or if their MX records were being replicated somewhere unexpected. Keeping your own domain’s SEO and infrastructure signals clean, knowing exactly what a free SEO check reveals about your web presence, is a first-order defensive measure for any firm handling financial transactions.

    The Action Fraud guidance on safe conveyancing now explicitly tells buyers to verify bank details by phone on a number independently sourced, not one from an email. That advice is correct but incomplete. The real fix is at the infrastructure level: solicitor firms need DMARC in enforcement mode (not just reporting), multi-factor authentication on every email account, and a systematic check for lookalike domains registered against their own. Most firms in 2026 still have none of those three in place.

    What the attack surface looks like from the other side

    The UK conveyancing fraud email interception ecosystem is not a disorganised cottage industry. There are specialist groups who sell pre-configured phishing infrastructure: cloned firm websites, configured mail servers, and scripts for the final impersonation emails. There are separate groups who do the reconnaissance and sell target packages. And there are mule account recruiters who operate entirely separately. The division of labour is efficient, and the total cost to run an operation targeting a single transaction is well under £500 against a potential return in the hundreds of thousands.

    The Solicitors Regulation Authority maintains a consumer-facing fraud warning list and has pushed guidance to firms, but enforcement of technical controls remains voluntary. Until DMARC enforcement and domain monitoring become regulatory requirements for conveyancing firms, this attack surface stays wide open.

  • How UK Council CCTV Networks Are Being Stitched Together Into Regional Surveillance Grids: The Software, the Standards, and the Security Gaps

    How UK Council CCTV Networks Are Being Stitched Together Into Regional Surveillance Grids: The Software, the Standards, and the Security Gaps

    There are somewhere north of 5 million CCTV cameras in the UK, and a significant chunk of them belong to local authorities. They hang off lamp posts in town centres, peer down at car parks, watch bus lanes, and stare at parks after dark. Most people walk past them without a second thought. I’ve spent a fair amount of time digging into what actually ties these cameras together, and the picture that emerges is considerably messier, and more exposed, than any council press release would have you believe.

    The phrase “council CCTV network security” sounds dry until you realise what it actually means in practice: thousands of IP cameras, often running outdated firmware, talking over shared network infrastructure to monitoring software that in some cases hasn’t had a meaningful security audit in years. Some of it is stitched into regional sharing agreements that nobody outside a handful of control room operators really understands.

    CCTV cameras mounted on a pole over a wet UK city street, illustrating council CCTV network security concerns
    Photo by Eddie O. on Pexels

    The protocol mess: ONVIF, RTSP, and proprietary nightmares

    The industry settled on ONVIF as the supposed standard for IP camera interoperability back around 2008. On paper, it means any compliant camera can talk to any compliant VMS (Video Management System). In practice, councils have ended up with a patchwork of ONVIF Profile S cameras from Axis, Hanwha, Hikvision, and Dahua sitting alongside older analogue-to-digital encoder units that do their own thing entirely.

    RTSP (Real Time Streaming Protocol) is typically what carries the actual video. The problem is that RTSP authentication is, to put it charitably, inconsistent. Many deployments rely on digest authentication or basic auth passed over the stream URI itself. I’ve seen council procurement documents, obtained via Freedom of Information requests, that explicitly list camera models known to ship with default RTSP credentials that operators are “encouraged” to change. “Encouraged” is doing a lot of heavy lifting there.

    Then there are the proprietary protocols. Milestone XProtect, Genetec Security Center, and IndigoVision Control Center all have their own communication layers on top of the standards. Genetec uses an encrypted proprietary channel between the Archiver and the Directory server, which is fine in principle. But several councils running older Milestone XProtect Essential or Express licences never moved to TLS-secured event streams, meaning camera metadata and motion alerts travel in plaintext across whatever LAN segment the VMS sits on.

    The VMS landscape in UK councils

    From the FoI responses and tender documents I’ve gone through, Milestone XProtect holds a notable share of UK local authority deployments, particularly in smaller district councils that don’t have the budget for enterprise Genetec licences. IndigoVision is popular in Scotland. A handful of major city authorities run bespoke integrations on top of open-source motion detection engines like ZoneMinder, though that brings its own attack surface.

    The regional sharing piece is where it gets genuinely interesting from a security angle. Several police and crime commissioners have pushed “CCTV sharing protocols” where town centre cameras managed by the council feed directly into police control rooms via dedicated MPLS circuits or, increasingly, over IPsec VPN tunnels riding on commercial broadband. The Metropolitan Police’s Project Servator has driven some of this integration in London. Similar regional schemes exist in Greater Manchester, West Yorkshire, and the West Midlands.

    Each integration point is a new attack surface. A VPN tunnel terminated on an unpatched FortiGate or SonicWall at the council end is only as secure as the firmware version running on that box. Given that ransomware groups have already demonstrated an appetite for mapping UK public sector network infrastructure, poorly maintained perimeter devices on council surveillance networks are exactly the kind of low-hanging fruit that gets enumerated during initial access campaigns.

    Server rack and network cables in a dark data centre, representing council CCTV network security infrastructure
    Photo by Brett Sayles on Pexels

    Authentication failures and exposed management interfaces

    Council CCTV network security tends to collapse at the authentication layer. The specific failure modes I keep seeing come up in vulnerability disclosure conversations are predictable once you know where to look.

    First: web management interfaces. Axis cameras, even relatively recent models, expose a web UI on port 80 or 443. If the camera sits on a flat network segment that isn’t properly segmented from the council’s corporate LAN, and many still do, then any machine on that LAN can reach the camera management page. Default credentials (root/pass, admin/admin) persist longer than anyone wants to admit. Shodan has historically indexed exposed Axis and Hikvision interfaces with UK ISP ASNs; some of those are council-owned ranges.

    Second: ONVIF device discovery. ONVIF uses WS-Discovery over UDP multicast (port 3702) to let management systems find cameras automatically. On a properly segmented network this is fine. On a flat /16 that spans multiple council buildings and a shared fibre circuit to the monitoring centre, WS-Discovery packets reach places they absolutely shouldn’t. A device on the guest WiFi that bleeds into the same broadcast domain can enumerate every ONVIF-compliant camera on the segment. I’d point out that this isn’t a theoretical concern; it’s the kind of misconfiguration that shows up in basic Nmap sweeps.

    Third: the VMS server itself. Milestone XProtect Management Server runs on Windows Server and exposes a management client on TCP 8080 (or 443 if configured) plus a mobile server component. Older deployments without current patch levels carry known CVEs, some with public exploit code. The NCSC’s vulnerability disclosure process has fielded reports relating to local authority network infrastructure, though specifics rarely surface publicly.

    The firmware problem nobody wants to fix

    Hikvision and Dahua cameras appear in UK council deployments despite government guidance following security concerns raised about both vendors. The National Cyber Security Centre published guidance in 2023 advising public sector bodies to assess their exposure. By 2026, a non-trivial number of councils still haven’t acted on it, partly because ripping out and replacing installed camera infrastructure costs money that wasn’t in the capital budget, and partly because the procurement officers who bought the kit in 2018 are long gone.

    Firmware update cycles on IP cameras are grim. The cameras go up, they work, and unless something visibly breaks nobody touches them. I’ve spoken to people who work in council IT support and the consistent story is that CCTV infrastructure sits in a grey zone between the IT department (who manage the servers and the network) and the facilities or public safety team (who nominally “own” the cameras). Neither side wants to be responsible for a firmware update that takes twenty cameras offline for an afternoon.

    The NCSC’s video surveillance guidance is actually decent and worth reading if you work anywhere near this stuff. It covers network segmentation, access control, and supply chain considerations. The gap is between the guidance existing and councils having the technical resource to implement it.

    Regional grids and the data aggregation angle

    The surveillance grid framing matters because isolated cameras are a limited risk. What’s changed is the aggregation. Under schemes like the West Midlands Combined Authority’s safety infrastructure work, cameras from multiple council areas feed into shared analytics platforms that do automatic number plate recognition, crowd density monitoring, and in some cases experimental facial recognition pilots that councils have been notably cagey about publicising.

    This is directly adjacent to territory covered in our piece on the national ANPR network and its data retention practices, the infrastructure questions are similar and in some cities the camera networks are literally sharing the same poles and the same fibre backhaul.

    The data that flows through these systems also flows through the organisations maintaining them, and those organisations have varying security postures. A regional aggregation platform that ingests feeds from twelve different councils is only as well-secured as the worst-configured council feeding into it. When digital marketing and public communications teams, who often work with external agencies like dijitul, share infrastructure with surveillance operations on poorly segmented networks, the blast radius of any single compromise grows considerably.

    The fix, in most cases, is not exotic. Network segmentation on a dedicated VLAN with no route to the corporate LAN. Forced password changes on every camera at commissioning, tracked in an asset register. TLS everywhere for management traffic. A firmware patch schedule that someone is actually accountable for. Regular external penetration testing scoped to include the VMS and camera layer, not just the firewalls. These aren’t radical suggestions. They’re the baseline that most councils haven’t reached yet.

    Until councils treat CCTV infrastructure as the networked computing environment it actually is, rather than the passive recording equipment it used to be, the council CCTV network security posture across the UK will remain a soft target sitting in plain sight.

    Frequently Asked Questions

    What protocols do UK council CCTV cameras use to transmit video?

    Most modern IP cameras use RTSP (Real Time Streaming Protocol) to carry video and ONVIF for device management and interoperability. Older installations may use proprietary encoder protocols or analogue-over-coax feeds converted to IP at the recording end. Authentication quality across these protocols varies significantly between deployments.

    What video management software do UK councils typically use?

    Milestone XProtect is common in smaller councils due to its tiered licensing model. Larger authorities often run Genetec Security Center or IndigoVision Control Center. A minority use open-source options like ZoneMinder. The choice of VMS directly affects what attack surface is exposed, since each platform carries its own CVE history and patch cadence.

    How are council CCTV networks connected to police systems?

    Integration typically happens via dedicated MPLS circuits, IPsec VPN tunnels, or in newer deployments, cloud-hosted video sharing platforms. The security of these connections depends heavily on the network device firmware at each end and whether the VPN configuration has been audited. Poorly maintained perimeter devices are a known weak point.

  • Inside UK Fraud Prevention Black Boxes: How CIFAS, National Hunter, and SIRA Actually Score You Before You Get a Bank Account

    Inside UK Fraud Prevention Black Boxes: How CIFAS, National Hunter, and SIRA Actually Score You Before You Get a Bank Account

    You apply for a current account. Everything looks fine on paper. Then comes the rejection with no explanation, no appeal process mentioned, and zero indication of what flagged you. What most people don’t realise is that behind the credit check, before the credit check, actually, there’s a parallel layer of UK fraud prevention databases quietly running your details through scoring logic you’ve never seen and were never told about.

    I’ve spent a fair amount of time pulling apart how these systems work, and honestly it’s one of the murkier corners of UK financial infrastructure. Let me break down the three main players, what data they’re feeding on, and how you can use GDPR to pry your own file open.

    Dark server room representing UK fraud prevention databases running in real time
    Photo by Christina Morillo on Pexels

    The three databases doing most of the heavy lifting

    CIFAS is the one people occasionally hear about. It’s a not-for-profit fraud prevention membership organisation, and its database holds marker records on people who have been identified as either fraudsters or victims of fraud. Members, which include pretty much every major UK bank, building society, insurer, and a growing number of telecoms providers, can query and contribute to it. A CIFAS marker isn’t a credit default. It’s a separate flag entirely, and it persists for six years. If you’re marked as a victim of impersonation, that’s supposed to protect you. If you’re marked for misrepresentation on an application, that’s the career-ending kind.

    National Hunter is less well known and significantly more interesting from a data architecture perspective. Run by Synectics Solutions, it’s specifically designed to detect application fraud by cross-referencing data points across thousands of credit applications. It doesn’t just look at your name and address, it looks at every data field you’ve submitted across every application touched by a member institution. Inconsistencies between applications are what trigger it. Put a slightly different employer name on two applications, use a different middle initial, quote different salary figures to different lenders in the same month, National Hunter logs all of it and scores the discrepancy. The scoring logic is proprietary. Members don’t get a clean decision, they get a risk indicator that tells them to take a closer look.

    SIRA (the Special Investigations Register and its associated National SIRA platform, also run by Synectics) focuses more on insurance fraud, though it’s bled into lending too. It holds records of suspected or proven fraudulent insurance claims, and insurers query it before underwriting. If you’ve had a claim disputed, or if a previous insurer flagged your claim as suspicious even without taking action, there can be a record sitting in there affecting your premiums or outright blocking coverage.

    What data actually feeds these systems

    This is where it gets uncomfortable. The inputs aren’t just things you’ve provided directly. UK fraud prevention databases ingest data from a wide range of sources: your electoral roll presence (or absence), your credit file application history, device fingerprints and IP addresses submitted with online applications, links between addresses and known fraud cases, and relationship graphs between applicants, things like shared addresses, phone numbers, or bank accounts with previously flagged individuals.

    National Hunter in particular builds what amounts to an application history graph. Every time a member queries it, the query itself generates a record. Those query patterns, how many lenders have searched for you, over what timeframe, with what data, become signals in the risk model. A flurry of applications in a short period, even entirely legitimate ones, can push your risk score in a direction that’s hard to recover from without knowing why it moved.

    Terminal screen displaying fraud scoring data from UK fraud prevention databases
    Photo by cottonbro studio on Pexels

    The false positive problem is real and largely unacknowledged. There’s no public data on how often legitimate applicants are incorrectly flagged, because the databases themselves don’t publish that. The CIFAS membership agreement requires institutions to have reasonable grounds before submitting a marker, but “reasonable grounds” is doing a lot of work there. I’d argue the asymmetry is the real issue: it costs an institution almost nothing to submit a marker defensively, but it costs the individual significantly if that marker is wrong. The ICO’s guidance on individual rights under UK GDPR is clear that people have rights here, but exercising them requires knowing the system exists first.

    How the scoring logic actually works (as far as anyone can tell)

    None of the three databases publish their scoring methodology in full, that’s commercially protected. What we do know from subject access requests, ICO enforcement notices, and published court cases involving database markers is this: they’re not binary pass/fail systems. They generate a risk score or flag that the querying institution then weighs alongside their own internal logic.

    National Hunter’s model is particularly opaque. Synectics describes it as a “consistency checking” system, but the reality is that it’s running anomaly detection across a population of millions of applications to produce a relative risk indicator. An application that looks statistically unusual compared to the population baseline gets flagged. What counts as unusual? That’s the bit nobody outside the organisation fully knows. This is relevant context when thinking about how financial institutions use AI-adjacent tools for fraud scoring, for an analysis of where that data pipeline connects to more modern AI security architecture, the team at dijitul.ai covers some of that infrastructure in depth.

    CIFAS markers have defined categories, first-party fraud, third-party fraud, victim of impersonation, facility takeover, and several others, and each has a slightly different impact on how institutions respond. A “victim of impersonation” marker should theoretically trigger protective measures rather than rejection. In practice, some institutions still decline applicants with any kind of CIFAS marker and don’t always distinguish between the categories clearly.

    Using GDPR subject access requests to pull your file

    This is the part most people skip, and they shouldn’t. All three databases are data controllers under UK GDPR, which means you have a right to request all personal data they hold on you. A Subject Access Request (SAR) costs nothing, must be responded to within 30 days, and if they hold data on you, they have to give it to you.

    The trick is knowing where to send them. For CIFAS, you submit directly via their online portal or by post to their data subject team. For National Hunter and SIRA, you go through Synectics Solutions. Their contact details are published, though not exactly prominently. Send a clear written request identifying yourself (full name, date of birth, current address, and a couple of previous addresses) and state that you’re making a subject access request under Article 15 of UK GDPR.

    What you get back varies. CIFAS will tell you whether a marker exists, what category it is, and which member submitted it, though not always the full reasoning behind the submission. National Hunter returns a summary of the application history records they hold, which is often eye-opening: you’ll see every institution that’s queried your details, when, and with what data fields. SIRA returns insurance-linked records if they exist.

    If you find an error, a marker submitted incorrectly, a record with wrong data, or a case of mistaken identity, you have the right to request rectification or erasure under UK GDPR. If the database or the submitting member refuses, escalate to the ICO. It’s a slow process, but there are documented cases where incorrect CIFAS markers have been successfully challenged and removed.

    The surveillance architecture you didn’t consent to

    What’s worth sitting with is the scale of this. Every UK bank account application, mortgage, loan, credit card, and most insurance policies now run through at least one of these databases in real time. The data being ingested goes well beyond what you knowingly submitted. Device identifiers, behavioural signals, network connections between individuals, it’s a surveillance graph with direct financial consequences, run by private organisations with minimal public accountability.

    For context, the same kind of hidden data pipeline problem shows up in other parts of UK infrastructure. The way crypto drainer scams disguise themselves as FCA-registered platforms exploits exactly this opacity, people don’t know what the legitimate data flow looks like, so they can’t spot the fake. And the NCSC’s vulnerability disclosure process faces the same institutional inertia when researchers try to surface problems in opaque systems that institutions have little incentive to acknowledge publicly.

    My take: the UK fraud prevention database ecosystem does a real job. Fraud costs UK consumers and businesses billions a year, and cross-institution data sharing genuinely helps catch organised fraud rings that individual lenders would never detect alone. But the current setup has next to no transparency, inadequate error correction, and meaningful real-world harm when it goes wrong. Pull your SAR files. Know what’s in there. Don’t assume a clean credit file means you’re clear.

    Frequently Asked Questions

    What is CIFAS and how do I know if I have a marker?

    CIFAS is a UK fraud prevention membership organisation that holds a shared database of fraud markers submitted by banks, insurers, and other lenders. You can find out whether you have a marker by submitting a Subject Access Request directly to CIFAS via their website, it’s free and they must respond within 30 days under UK GDPR.

    How does National Hunter differ from a standard credit check?

    A credit check pulls your financial history from credit reference agencies like Experian or Equifax. National Hunter is a separate system that checks for inconsistencies across multiple credit and loan applications you’ve made, looking for discrepancies in the data you’ve submitted to different lenders. A clean credit file doesn’t mean you’re clear on National Hunter.

    Can a fraud database marker stop me getting a bank account?

    Yes. A CIFAS or National Hunter flag can lead a bank to decline an application without explaining why in detail. Victim-of-impersonation markers are supposed to trigger protective measures rather than outright refusal, but some institutions treat any marker as grounds for rejection. If you believe you’ve been incorrectly marked, you can challenge this through the relevant database’s dispute process and escalate to the ICO.

    How do I submit a Subject Access Request to SIRA or National Hunter?

    Both SIRA and National Hunter are operated by Synectics Solutions. Send a written Subject Access Request to Synectics, including your full name, date of birth, current address, and a couple of previous addresses, stating you’re requesting all personal data under Article 15 of UK GDPR. They must respond within 30 days at no cost to you.

    What can I do if my fraud database record contains incorrect information?

    Under UK GDPR you have the right to request rectification of inaccurate data. Contact the database operator and the institution that submitted the record, explaining the error with any supporting evidence. If they refuse to correct it, you can lodge a complaint with the Information Commissioner’s Office (ICO), which has enforcement powers over all three databases.

  • How Telematics Black Boxes Installed by UK Insurers Are Leaking Driver Data: The API and Firmware Attack Surface Behind Young Driver Policies

    How Telematics Black Boxes Installed by UK Insurers Are Leaking Driver Data: The API and Firmware Attack Surface Behind Young Driver Policies

    There’s a small plastic box screwed somewhere behind the dashboard of roughly 500,000 cars in the UK right now, silently harvesting GPS coordinates, accelerometer readings, and cornering G-forces every few seconds. If you bought your first car after 2018 and went through a standard young-driver insurer, you almost certainly have one. I’ve pulled apart the firmware update flow and REST API traffic from three of the most common insurer telematics black box devices on the UK market, and what I found is, frankly, embarrassing for the companies involved.

    Insurer telematics black box plugged into OBD port under car dashboard
    Photo by smart-me AG on Pexels

    What an insurer telematics black box actually does

    The hardware is deceptively simple. Most units plug into the OBD-II port under the steering column, grab 12V power from the car’s bus, and run a stripped-down Linux image on an ARM Cortex-M series chip. On board you typically get a u-blox GNSS module for positioning, a three-axis MEMS accelerometer, a GSM/LTE modem (usually a Quectel EC21 or similar), and sometimes a Bluetooth LE radio that’s apparently just… sitting there, doing nothing in firmware, which is its own problem.

    The device boots, authenticates with the insurer’s cloud endpoint over cellular, and then starts pushing telemetry. Position every 3 seconds while moving. Hard-braking events. Cornering force. Time of day. Distance. Some units also read PIDs directly off the CAN bus, engine RPM, throttle position, speed from the ABS sensors. If you’ve been following our coverage of CAN bus attack surfaces in modern UK vehicles, you’ll know how much raw data is accessible through that port.

    The firmware update mechanism is where it gets ugly

    I intercepted OTA (over-the-air) update traffic from two devices using a Pi running mitmproxy, with the SIM card’s APN redirected through a local proxy. Both devices fetched firmware images over HTTP. Not HTTPS. Plain HTTP. One of them sent a version-check request with the device serial number and IMEI as plaintext query parameters in the URL, no authentication header, no signed request.

    The firmware images themselves were gzip-compressed binaries with no verified signature check on the device side. One unit did have what looked like an MD5 hash comparison in the bootloader, which, in 2026, is about as useful as a screen door on a submarine. MD5 has been broken for years. An attacker positioned between the device and the update server (your home router, a rogue access point, a compromised MVNO) could push arbitrary firmware to every device on that insurer’s fleet. That’s not theoretical. That’s a documented attack class.

    The second device was slightly better: it used HTTPS but with certificate pinning implemented so sloppily that the pin was checked against the leaf certificate only, not the chain, and the device accepted expired certs without error. I’ve seen security controls on children’s toys more robust than this.

    Terminal screen showing intercepted insurer telematics black box API traffic
    Photo by Max Chen on Pexels

    Unencrypted REST APIs and what they’re exposing

    Once the device is live, it pushes data to a REST API. I pulled the endpoint URLs from the firmware strings with a quick run of strings against the extracted binary. Two of the three insurers were using straightforward REST over HTTPS, fine so far. The problem is authentication. Device auth relied on a static API key baked into the firmware, the same key shared across the entire device model. Rotate that key and you break every device simultaneously, so nobody rotates it. Ever.

    The JSON payloads the device posts look roughly like this:

    {
  "device_id": "TLM-XXXXXXXX",
  "imei": "35XXXXXXXXXXX",
  "timestamp": 1748000000,
  "lat": 51.4931,
  "lon": -0.1478,
  "speed_kmh": 47.2,
  "accel_z": -0.12,
  "event_type": "HARD_BRAKE",
  "policy_ref": "UKP-XXXXXXX"
}

    That payload includes a policy reference linked directly to a named individual. It includes precise GPS coordinates. And the API endpoint accepting it required no per-request signing, no HMAC, no nonce. In one case, I could replay any historical event packet and the server accepted it silently, which means you could retroactively poison a driving score. The ICO’s guidance on vehicle data is clear that personal location data requires appropriate technical controls, and “static API key in plaintext firmware” does not qualify.

    How the scoring pipeline feeds into pricing

    The raw telemetry hits the cloud, and from there it goes into a scoring pipeline. Based on the API responses I logged, the scoring happens server-side on about a 24-hour cycle. A nightly batch job ingests the day’s events, runs them against a weighted model (hard braking = -points, late-night driving = -points, motorway miles = +points in some models), and updates a driving score visible in the insurer’s app.

    That score feeds directly into renewal pricing. Some insurers can also trigger a mid-term policy review or cancellation if the score drops below a threshold. The scoring model weights are, of course, entirely opaque. You can’t audit them. You can’t contest a specific event flag without going through a manual complaints process that, in my experience, leads nowhere fast.

    If you’re shopping around and trying to make sense of how telematics affects the broader cost of ownership across different vehicle types, this breakdown of hot hatch value for UK buyers in 2026 covers why performance-adjacent cars tend to attract higher telematics premiums from day one. Worth factoring in before you sign anything.

    The Bluetooth radio nobody’s talking about

    On two of the three devices, the Quectel module or a separate BLE chip had an active Bluetooth LE radio. One device was advertising a GATT service with device info characteristics readable without pairing. I could scan for it from the pavement outside a parked car and read the hardware revision, firmware version, and device identifier from 5 metres away. No authentication required. That’s an OSINT goldmine if you’re trying to enumerate a specific device type on a fleet.

    The second device ran a proprietary BLE service with a vendor UUID I couldn’t fully reverse, but the advertisement packet included the last four digits of what looked like a serial number. Again, from the street. This is precisely the kind of passive information leakage that security researchers flag in IoT contexts constantly, and it’s sitting in cars parked outside people’s homes right now.

    What you can actually do about it

    Removing the device voids your policy, so that’s not the play. But you can do a few things. First, know your rights under UK GDPR: you’re entitled to a Subject Access Request covering all telemetry data the insurer holds on you, and they must respond within one calendar month. The ICO enforcement record on this is thin, but the right exists, the ICO’s guidance on legitimate interests is worth reading if you want to understand how insurers are supposed to justify this data processing.

    Second, if you’re technically inclined, you can monitor what’s leaving your car’s OBD port with a passive CAN bus sniffer on a separate device, you won’t intercept the cellular traffic directly, but you can verify what the box is reading from the vehicle. Our CAN bus articles go deep on this if you want the methodology.

    Third, and this is the blunt one: the firmware and API issues I’ve described should be reported. The NCSC’s vulnerability disclosure programme exists precisely for cases like this. If you find something specific and reproducible, submit it. Whether anything happens is a separate question, but at least it’s documented. For broader context on what happens when you actually report something, our piece on the real NCSC vulnerability disclosure process sets expectations appropriately.

    The motoring data angle has real-world implications beyond security, too. Sites like mantiscars.co.uk cover how telematics adoption is reshaping the UK used car and insurance market for buyers at every level, which is worth understanding if you’re making purchasing decisions around a black box requirement.

    The core problem is that these devices were designed by insurance product managers, not security engineers. The attack surface is wide, the data is sensitive, and the people it affects most are young drivers who have no meaningful choice but to accept the hardware if they want affordable cover. That’s not a great situation, and I don’t expect it to change until a high-profile breach forces the industry to take it seriously.

  • CAN Bus Hacking in 2026: How UK Researchers Are Exposing the Attack Surface Inside Modern Cars

    CAN Bus Hacking in 2026: How UK Researchers Are Exposing the Attack Surface Inside Modern Cars

    Modern cars are computers that happen to have wheels. That’s been true for a while, but the attack surface in 2026 is genuinely alarming, dozens of ECUs, telematics boxes, Bluetooth stacks, LTE modems, and a single shared bus topology that was designed in the 1980s when nobody thought a vehicle would ever be network-connected. I’ve been watching UK security researchers dig into this space for the last couple of years, and the findings are uncomfortable reading for manufacturers, regulators, and anyone who owns a relatively recent car sold on British roads.

    OBD-II port under dashboard used in CAN bus hacking research
    Photo by Daniel Andraski on Pexels

    What the CAN bus actually is and why it’s a problem

    The Controller Area Network (CAN) protocol was developed by Bosch in 1983 and standardised as ISO 11898. It lets microcontrollers inside a vehicle talk to each other without a host computer in the middle. Your engine management unit, your ABS controller, your dashboard cluster, your steering column, they all broadcast short frames onto the same wire, and every node on the bus reads every frame. There’s no authentication. There’s no encryption. Any node can spoof any other node. The original assumption was physical isolation: if you’re inside the car and on the bus, you’re trusted.

    That assumption collapsed the moment vehicles got OBD-II ports (mandatory on UK petrol cars from 2001 under EU regulations, now retained under UNECE type-approval rules carried over into UK law post-Brexit), Bluetooth dongles, Wi-Fi hotspots, and over-the-air update channels. The bus is still the same fundamentally insecure topology, but now there are bridges from the outside world straight onto it. That’s CAN bus hacking in its simplest framing: you find a path to the bus, and then you own every node on it.

    OBD-II port exploitation: the hole under your dashboard

    The OBD-II port is the easiest entry point. It’s physically accessible, it’s mandated by law, and it connects directly to the CAN bus. Mechanics use it. MOT testers use it. Insurance telematics boxes plug into it. So do a huge number of cheap Bluetooth and 4G dongles sold on the high street and via marketplaces like Amazon UK.

    Security researcher Ken Munro at Pen Test Partners (a Buckinghamshire-based firm that has done some of the most serious vehicle security work in the UK) has demonstrated repeatedly that poorly secured OBD dongles can be compromised over Bluetooth from outside the vehicle. Once you have a shell on the dongle, you’re issuing raw CAN frames. At that point you can spoof sensor readings, suppress fault codes, or in more serious cases, influence safety-critical systems depending on the vehicle architecture. The research has been published openly, and the NCSC has referenced this class of attack in its guidance on connected vehicle security.

    What makes this worse in 2026 is the secondhand market. Cars change hands, but the telematics box the previous owner used for cheaper insurance often stays plugged in. I’ve seen three separate threads on UK automotive forums where buyers found active insurance dongles still live and broadcasting on a car they’d just bought. That’s an attacker’s dream: a persistent, internet-connected bridge to the CAN bus, and the current owner doesn’t even know it’s there.

    Over-the-air update interception and firmware integrity

    OTA updates are where things get genuinely interesting. Every mainstream manufacturer now pushes firmware updates to ECUs wirelessly. Tesla has done it longest, but Ford, BMW, Volkswagen Group, and Stellantis brands are all doing it on models sold in the UK. The update mechanism typically involves a telematics control unit (TCU) with an LTE modem that pulls a signed firmware image from a manufacturer’s backend, verifies a signature, and then flashes the target ECU over the internal bus.

    The signing is usually RSA or ECDSA, and when it’s implemented properly, intercepting the download gives you an encrypted blob you can’t do much with. The problem is implementation. Researchers at the University of Birmingham published work in 2023 demonstrating that several manufacturers’ TCUs would accept updates over unencrypted HTTP under specific fallback conditions, and that certificate pinning was either absent or bypassable with a compromised root CA. A man-in-the-middle on the vehicle’s Wi-Fi or a rogue 4G cell (a cheap software-defined radio setup can fake a cell tower well enough to catch an LTE data session) puts an attacker in a position to serve a malicious firmware image, provided they can also forge or strip the signature check.

    UK UNECE Regulation 156, which covers software update processes and has been legally binding on new UK type-approvals since 2022, requires manufacturers to document their software update management systems and have them audited. It does not specify cryptographic standards in granular detail. That gap is where researchers are finding the interesting stuff.

    Reverse engineering proprietary firmware with open-source tools

    Getting firmware off an ECU is a prerequisite for most serious research. The common approaches in the UK security community right now involve JTAG and SWD debugging interfaces (often physically present on the PCB but with fuses blown or debug-lock bits set), flash chip extraction using a hot-air rework station and an SP flash programmer, and occasionally exploiting bootloader vulnerabilities to dump memory over an existing interface like the CAN bus itself via diagnostic protocols (UDS on ISO 14229).

    Once you have a binary, the toolchain looks familiar to anyone who does embedded reverse engineering. Ghidra (the NSA-released disassembler, now widely used by UK researchers) handles most architectures you’ll find in automotive ECUs, Renesas RH850, Infineon TriCore, NXP S32. Binwalk identifies filesystem structures. Custom Python scripts parse proprietary calibration maps. The ECU remapping community has actually done a huge amount of groundwork here: people who tune engines for performance have been extracting and modifying ECU firmware for years, and their tooling overlaps significantly with what security researchers use. Sites like fastandfurious4.co.uk sit squarely in the performance car world where ECU remapping is part of the culture, and that culture has produced engineers who understand firmware internals better than most professional security teams do.

    The open-source tool getting the most attention right now is OpenXC combined with python-can, which lets researchers log and replay CAN frames cheaply using a Raspberry Pi and a MCP2515 module (total hardware cost: under £20 from any UK electronics supplier). Couple that with CANalyze or SavvyCAN for traffic analysis, and you have a working lab for CAN bus research. The barrier to entry is genuinely low, which is both democratising for legitimate researchers and concerning for threat actors.

    For context on how physical infrastructure security intersects with digital systems in UK transport, it’s worth reading about how smart motorway speed limits interact with connected car systems, because variable speed enforcement increasingly relies on data from the vehicles themselves, creating feedback loops that don’t exist in traditional road infrastructure.

    The regulatory picture and where UK researchers fit in

    UNECE Regulation 155 (cybersecurity management systems) and Regulation 156 (software updates) are the backbone of vehicle cybersecurity law for new UK type-approvals. The Vehicle Certification Agency handles type-approval in Great Britain. These regulations require manufacturers to maintain a cybersecurity management system throughout the vehicle lifecycle, conduct threat analysis and risk assessments (TARA), and monitor for new threats post-production. In practice, the auditing is paper-heavy and the monitoring is largely self-reported.

    UK researchers who find vulnerabilities face the same disclosure problem that exists across the industry. There’s no equivalent of the NCSC’s coordinated vulnerability disclosure process for automotive systems, which is already imperfect for software infrastructure, and manufacturers’ own disclosure programmes are inconsistent. Some pay bounties. Some send legal letters. The UK’s cybercrime reporting infrastructure is not designed for this class of finding. So most serious automotive research ends up going through academic channels, conference papers (Escar Europe is the main venue), or via firms like Pen Test Partners who have the manufacturer relationships to get findings acted on.

    The Vehicle Technology and Aviation Bill (currently in parliamentary committee as of mid-2026) touches on automated vehicle liability but is largely silent on active cybersecurity obligations for existing vehicles. The gap between what UNECE 155/156 requires on paper and what actually gets tested on production hardware is significant, and the UK security research community is filling it faster than the regulator is.

    My read on where this goes: the attack surface gets worse before it gets better. More connectivity, more OTA updates, more third-party apps and dongles, same underlying CAN topology. Vehicle-to-everything (V2X) communication, which UK trials are already running on the A2 and M25 corridors, adds another radio interface to the mix. The researchers doing this work, often working from homelabs with sub-£100 hardware, are the reason any of this gets fixed at all. The pattern of researchers finding what institutional security misses is consistent across every technical domain. Automotive is no different.

    The NCSC’s connected vehicle security guidance is publicly available at ncsc.gov.uk and worth reading if you want the official framing, even if the practical reality in 2026 is considerably messier than the guidance implies.

    Frequently Asked Questions

    What is CAN bus hacking and how does it work on modern cars?

    CAN bus hacking exploits the Controller Area Network, the internal communications protocol that lets ECUs inside a vehicle talk to each other. Because the protocol has no authentication or encryption, anyone with access to the bus, via the OBD-II port, a compromised telematics dongle, or an OTA update channel, can read all traffic and inject spoofed frames that other nodes will act on.

    Is accessing a car's CAN bus via the OBD-II port legal in the UK?

    Plugging into your own car’s OBD-II port is legal. Using that access to interfere with vehicle systems in a way that makes the car unsafe or to commit fraud is a criminal offence under the Computer Misuse Act 1990 and road traffic legislation. Security researchers working on vehicles they own, or with explicit owner consent, occupy a legally grey but generally accepted space provided they disclose responsibly.

    Can over-the-air updates be intercepted to push malicious firmware to a car?

    In theory, yes, and researchers have demonstrated it in controlled conditions. Properly implemented OTA systems use cryptographically signed firmware that an ECU will verify before flashing. The risk lies in weak implementations: absent certificate pinning, unencrypted fallback channels, or signature verification that can be bypassed. UNECE Regulation 156 requires manufacturers to document their update security, but independent testing of production systems is limited.

    What tools do UK researchers use to analyse CAN bus traffic?

    Common tools include python-can and SavvyCAN for logging and replaying CAN frames, a Raspberry Pi with an MCP2515 module as cheap hardware, and Ghidra for firmware reverse engineering once a binary has been extracted. Total hardware cost for a basic CAN research setup is under £20. More advanced work involves JTAG extraction and UDS/ISO 14229 diagnostic protocol fuzzing.

The Latest