When the Network Becomes the Attack Surface: How Conflict-Driven Cellular Disruption Is Reshaping the Threat Landscape for Payment Infrastructure

Introduction

Payment infrastructure has always operated under a quiet assumption: the network is stable, the carrier is available, and the path from terminal to host is predictable. That assumption is currently being stress-tested across the region in a way that few incident response playbooks were written to handle. Ongoing regional conflict is causing intermittent disruptions to the cellular networks that SIM-based point-of-sale terminals depend on for payment processing — and ATM networks are simultaneously experiencing a spike in attack attempts that are directly exploiting the connectivity instability.

What makes this moment technically interesting — and operationally dangerous — is not the disruption itself, but the rapid, often unplanned migration it is triggering. Merchants and acquirers are pivoting SIM-dependent POS terminals onto merchant Wi-Fi connections as a fallback. On the surface, this looks like a straightforward connectivity swap. In practice, it represents a fundamental shift in the attack surface of the payment chain. A terminal that was previously protected by a private carrier APN is now sitting on a merchant broadband router — a device that was never designed, hardened, or monitored with payment security in mind.

Simultaneously, the same conflict environment that is degrading carrier availability is elevating the threat posture across financial infrastructure more broadly. Wiper malware campaigns, DDoS targeting of payment gateways, supply chain pressure on terminal management systems, and social engineering exploiting operational stress on stretched teams — all of these are running concurrently with the connectivity crisis. These advisory addresses the intersection of those two problems: what the expanded attack surface looks like, and what acquirers and PSPs need to do about it now.

What Happened — Technical Overview

The Connectivity Crisis and the SIM-to-Wi-Fi Migration

The immediate trigger is straightforward: regional conflict is causing intermittent failures in the cellular networks that SIM-based POS terminals use for transaction processing. Carriers that normally provide private APN connectivity — an isolated network path that routes terminal traffic directly to acquirer hosts without touching the public internet — are experiencing availability issues. In response, merchants and acquirers are migrating terminals to Wi-Fi as a continuity measure.

The problem is what that migration actually means for the security architecture. Carrier APNs function as a private tunnel — they provide implicit network segmentation, hide terminal management interfaces from the internet, and bypass most of the BGP-level routing exposure that comes with public internet transit. Wi-Fi through merchant broadband provides none of that. The moment a POS terminal connects to merchant Wi-Fi, it is routed through the public internet. Its management ports, which were previously invisible from outside the carrier network, become reachable. Its DNS resolution depends on whatever resolver the merchant router is configured to use. And if the merchant has not created a dedicated SSID with VLAN isolation, that terminal is now sharing a network segment with customer devices, employee laptops, and anything else connected to the same router.

CRITICAL RISK: Network segmentation that was previously inherent in the cellular architecture must now be explicitly engineered at the merchant level — in environments that have never been hardened for this role.

The Threat Landscape — POS and Payment Networks

The migration creates a set of high-priority remote attack vectors that are distinct from the proximity-based threats more commonly discussed in retail payment security. The most critical of these is merchant router and firewall compromise. These devices are now in the payment path for the first time, yet most have never been configured with that role in mind. Default credentials, unpatched firmware, and WAN-side management interfaces left exposed are trivially exploitable attack vectors — and a compromised merchant router provides traffic interception, DNS manipulation capability, and lateral access to the POS terminal.

DNS hijacking and resolver tampering represents a closely related vector. When terminals migrate from carrier APN connectivity to Wi-Fi, they stop using the carrier’s DNS infrastructure and fall back to whatever resolver the merchant router is configured to provide. If that resolver is the ISP default — or worse, if no DNS is configured and the router is vulnerable — an attacker who has compromised the router or the upstream path can redirect payment traffic to attacker-controlled hosts. This is a particularly acute risk because the change is invisible to standard transaction monitoring; the terminal still connects and attempts to authorise, but the traffic goes to the wrong destination.

DDoS against acquirer hosts, payment gateways, and DNS infrastructure is rated as a primary state-level disruption tool and is assessed as critical risk in the current environment. Unlike the terminal-side risks, this one does not require any action by the merchant — volumetric or application-layer attacks against the acquirer backend compound the existing carrier instability and can cascade across the payment ecosystem. BGP hijacking and routing instability represent the same class of risk at the internet infrastructure layer, with Wi-Fi paths introducing BGP-level exposure that carrier APNs previously bypassed.

Terminal Management System abuse warrants particular attention during the migration period. TMS activity increases significantly as acquirers push configuration updates, Wi-Fi profiles, and connectivity parameters to migrated terminals at scale. That elevated activity window is exactly when a compromise of the TMS platform — through which malicious configuration or firmware updates could be pushed fleet-wide — would have maximum impact.

Finally, TLS interception and trust-store abuse is a risk specifically associated with the operational pressure to restore service quickly. Emergency reprovisioning procedures can create conditions where certificate pinning is relaxed or bypassed, and rushed failover creates an opportunity to inject rogue certificates or weaken TLS validation.

The Threat Landscape — ATM Networks

For ATMs, the highest-probability threats during regional conflict are those that can be executed remotely at scale, or that arise directly from telecom, routing, or DNS disruption. ATM switch and host connectivity disruption — through DDoS, routing instability, telecom failure, or DNS issues — is assessed as critical risk. Financial services infrastructure is a consistently high-priority DDoS target, and outages can persist for days in a sustained campaign.

Closely related is the exploitation of stand-in and degraded authorisation logic. ATMs are designed to continue operating in a limited capacity when connectivity to the host is unavailable, using locally stored offline rules to authorise withdrawals up to configured limits. If an attacker can degrade host connectivity — intentionally or by exploiting the existing instability — and the stand-in parameters have not been tightened, the result is a direct financial exposure window. The risk scales with how long the degraded connectivity persists and how permissive the offline limits are.

ATM malware introduced through a compromised management path — targeting the XFS and middleware layer used by ATM software — is assessed as high risk. Notably, this vector operates through the software and management path rather than requiring physical terminal access. Known malware families targeting the XFS layer have been confirmed active in recent campaigns. Combined with the elevated software update and patching activity that conflict-driven operational pressure creates, software distribution and update path abuse represents a second high-risk channel for introducing unauthorised code to the ATM fleet.

Analytical note: Transaction replay attacks have been excluded from the primary ATM threat model. In modern ATM flows with current MAC and integrity verification, this is not the strongest or most representative wartime threat vector absent specific environmental evidence.

Broader Conflict-Related Threats Across the Acquirer Environment

Beyond the POS and ATM-specific vectors, the current conflict environment elevates several cross-cutting threats. Wiper malware campaigns disguised as ransomware are targeting financial systems. Supply chain compromise attempts are targeting payment processors and TMS providers. Social engineering campaigns are exploiting operational stress on staff through phishing and vishing. Insider threat risk is elevated during periods of heightened tension. These threats apply across the acquirer environment and are not limited to any single channel.

Why This Matters — Key Insights

1. The Architecture Shift Has Already Happened — Whether Teams Are Ready or Not

The SIM-to-Wi-Fi migration is being driven by connectivity necessity, not by a planned security architecture review. In many cases, terminals are being connected to merchant Wi-Fi by helpdesk guidance or field technicians under operational pressure, without any verification of the merchant router configuration. The security controls that existed under the cellular model — private APN isolation, carrier-controlled DNS, implicit network segmentation — have been removed, and nothing has been put in their place. The gap between the old security model and the new operational reality is the attack surface that adversaries are targeting.

2. Merchant Routers Are Now in the Payment Chain

This is the single most important architectural change introduced by the migration, and it is one that most acquirer security programs have no existing controls for. Merchant-grade routers were never assessed as part of the payment security perimeter, were never subject to minimum firmware or configuration requirements, and are not monitored by acquirer security tooling. A compromised merchant router provides an attacker with the ability to intercept payment traffic, manipulate DNS resolution, and establish lateral access to the POS terminal — all from a device that sits entirely outside the acquirer’s traditional security boundary.

3. Stand-In Parameters Are a Direct Financial Exposure Under Degraded Connectivity

The stand-in authorisation logic that allows ATMs to continue operating during host connectivity loss was designed for brief, localised outages. In a sustained conflict-driven connectivity disruption, those parameters become a meaningful fraud exposure. An attacker who can reliably degrade ATM-to-host connectivity — whether through DDoS, routing manipulation, or DNS disruption — and who knows that stand-in limits are set to permissive defaults, has a predictable financial exploitation path. This is a risk that can be significantly reduced immediately through parameter review, but it requires deliberate action before the disruption, not during it.

4. Operational Pressure Is a Security Vulnerability

Several of the highest-risk threat vectors in this environment — TLS trust-store abuse, TMS exploitation, software distribution path compromise, and social engineering — are specifically enabled or amplified by the operational pressure that a conflict-driven disruption creates. Teams rushing to restore service may relax certificate pinning. Change management controls may be bypassed to push emergency updates. Helpdesk staff fielding a surge of calls are more susceptible to social engineering requests to make out-of-process configuration changes. The adversary does not need to break the technical controls — they only need the operational environment to create the conditions under which those controls are voluntarily bypassed.

6. SIEM Visibility and Log Integrity Are at Risk During the Exact Moment They Are Most Needed

The standard log pipeline — device to SIEM — depends on the same network connectivity that is being disrupted. If local log buffers on ATMs, POS systems, and edge devices are configured with short rotation periods, the logs that would document an attack occurring during a connectivity outage will be overwritten before forensic collection becomes possible. This is not a theoretical risk: it is a predictable consequence of the current environment, and it must be addressed by maximising local log storage and extending rotation windows now, before an incident occurs.

Practical Actions — Immediate Priorities

The following actions are drawn directly from the technical guidance in this advisory. They are sequenced by urgency and operational impact.

1. Tighten ATM stand-in parameters immediately. Tighten ATM stand-in parameters immediately. Reduce offline transaction amounts and maximum offline transaction counts. Document all changes with rationale, named approver, and time-bound review dates. This is the fastest way to reduce direct financial exposure during connectivity degradation.
2. Implement patching freeze with out-of-band verification. Implement a patching freeze for the ATM fleet with out-of-band verification. Freeze all non-critical software updates and configuration changes. Any emergency patch required for connectivity restoration must have its digital signature and SHA-256 hash verified through a separate, trusted communication channel before deployment. Adversaries actively exploit chaotic environments by hijacking software distribution paths.
3. Prepare TMS Wi-Fi profiles and update firewall ACLs. Prepare and test Wi-Fi connectivity profiles in the TMS before any merchant migration begins. Include pre-configured SSID templates, VPN tunnel parameters, and updated host addresses. Update acquirer host firewalls and ACLs to accept connections from merchant Wi-Fi IP ranges — if host systems are configured to accept only carrier APN IPs, Wi-Fi traffic will be rejected at the host.
4. Enforce merchant router hardening before Wi-Fi migration. Mandate a merchant-side router hardening checklist as a gate before any terminal goes live on Wi-Fi. The minimum requirements are: change of default admin credentials, firmware updated to the latest available version, WPS disabled, WAN-side remote management disabled, and a dedicated POS SSID using WPA2-AES or WPA3 encryption — isolated from general business, employee, and guest networks.
5. Publish mandatory DNS configuration to merchants. Publish mandatory DNS configuration to merchants. Terminals must be manually configured to use the hardened enterprise DNS servers of the licensed UAE telecom operator serving the location as the primary resolver, in compliance with CBUAE data residency requirements. Acquirers must pre-select and document an approved secondary fallback — not leave this to merchant discretion. Any routing deviation to DNS infrastructure outside UAE borders must be logged as a Force Majeure event.
6. Extend local log retention and confirm SIEM forwarding. Maximise local log storage and extend rotation windows on all edge and critical backend systems to a minimum of 30 days during the disruption period. Confirm that SIEM forwarding auto-resumes when connectivity is restored. Enable SHA-256 integrity hashing on log files at rotation. For any system not currently forwarding to SIEM, implement manual log collection at minimum twice daily for edge devices until formal integration can be completed.

Broader Takeaway — Strategic Perspective

The current situation is a stress test for an assumption that has been quietly embedded in payment infrastructure security for years: that the network layer is someone else’s problem. Carrier APN connectivity provided isolation, segmentation, and DNS trust as a byproduct of the commercial service arrangement — security teams never had to explicitly engineer those controls because the carrier provided them implicitly. The SIM-to-Wi-Fi migration strips that away, and what it reveals is that a significant portion of the payment security architecture was never actually owned by the acquirer. It was rented from the carrier, and the rental agreement has been suspended by events outside anyone’s control.

For security teams, the immediate response is clear and detailed in the guidance above. The strategic implication is harder to absorb: every assumption about what your network boundary looks like, where your visibility starts and ends, and which devices are inside your security perimeter needs to be reassessed against the reality of where payment traffic actually flows during a disruption. The merchant router was never on the threat model. The carrier DNS was never in the scope of DNS security controls. The ATM stand-in logic was never reviewed for conflict-scenario exposure. These are not exotic edge cases — they are the gaps that the current environment is actively exploiting. The organisations that close them now will be in a materially better position than those that wait for an incident to make the gaps visible.