Join our Newsletter — 33% off our NHI Course
Home› Guides› Mobile T1464 Network Denial of Service: Planning for…
Guide Endpoint Security

Mobile T1464 Network Denial of Service: Planning for Jamming and Lost Connectivity

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 12 November 2026 8 min read
On this page

A phone that cannot reach a network cannot raise an alarm, receive a one-time code, sync a lost-device command or call emergency services, and radio jamming can cause exactly that without touching the device at all. MITRE ATT&CK for Mobile T1464 Network Denial of Service (tactic TA0034 Impact) covers adversaries degrading or blocking availability by exhausting bandwidth or by jamming Wi-Fi, cellular or GPS signals around a device. ATT&CK v20 maps it to Android and iOS. There is little a device setting can do against a jammer, so this guide concentrates on what defenders can actually control: recognising the symptoms, designing workflows that survive lost connectivity, and stopping managed phones from being used as attack traffic sources. It is for mobile and network engineers and for teams that rely on phones for safety, field work or authentication. The matrix overview is in the MITRE ATT&CK for Mobile Guide.

Key takeaways

  • Two mechanisms. ATT&CK describes bandwidth exhaustion and radio jamming of Wi-Fi, cellular or GPS signals within the jammer's range.
  • Jamming is physical and local. ATT&CK cites NIST SP 800-187 and news reports of arrests involving cellular jammers; the attacker must be nearby.
  • Prevention on the device is limited. ATT&CK lists no mitigation for T1464, so the defence is resilience: alternative channels, offline-capable workflows and fallbacks that do not weaken security.
  • Phones can also be the source. ATT&CK records that the S.O.V.A. Android banking trojan had commands to add an infected device to a DDoS pool.
  • Jamming is generally illegal. In the US the FCC states that marketing, selling or operating jammers is prohibited, which makes reporting to the regulator a real response option.

How the technique shows up

FormWhat happensEffect on Android and iOS
Cellular jammingA transmitter drowns out signals between the phone and the base station within its rangeNo service or repeated signal loss; calls, SMS and mobile data fail on both platforms
Wi-Fi jamming or interferenceNoise on the Wi-Fi bands stops association or trafficDevices drop to cellular data or lose connectivity entirely
GPS jammingSatellite navigation signals are blockedLocation services fall back to network-based positioning or fail; location-based alerts and geofencing degrade
Bandwidth exhaustionTraffic floods the network or service the device depends onApps time out; push notifications and MDM commands are delayed

The FCC lists cellular and PCS, police radar and GPS among the signals jammers block, and warns that they can prevent 911 and other emergency calls. For the radio engineering side see the Physical Layer and Wireless Jamming Guide and, for satellite navigation, the GNSS Spoofing and Jamming Guide. Where the denial of service targets the organisation's own internet services rather than the radio link, the DDoS Protection Guide applies.

Why it matters to security teams

Network loss is rarely the end goal. It is used to stop something from happening at the right time:

  • Delaying lost-device commands: a remote lock or wipe cannot reach a device with no signal, which gives a thief time to work on it offline. ATT&CK tracks the lock screen side as T1461 Lockscreen Bypass; see the Mobile T1461 Lockscreen Bypass.
  • Blocking alerts: lone-worker alarms, security guard check-ins and physical alarm notifications that rely on mobile data fail silently.
  • Breaking authentication: push approvals and SMS codes stop arriving, which tempts help desks to bypass verification.
  • Degrading location: fleet tracking and geofenced controls lose accuracy when GPS is jammed.

The managed phone as a DoS source

The other side of T1464 is a phone used to generate attack traffic. ATT&CK records that S.O.V.A. (S1062), an Android banking trojan, has command and control commands to add an infected device to a DDoS pool. This is an outcome of malware installation, so the controls are the usual Android ones: block unknown-source installs with the Android Management API untrustedAppsPolicy set to DISALLOW_INSTALL, keep googlePlayProtectVerifyApps at VERIFY_APPS_ENFORCED, and review accessibility permissions. The Android Banking Trojans Guide covers the families in more depth. On iOS, ATT&CK lists no procedure example for this technique.

Building resilience

  1. Map phone-dependent processes. List the alarms, check-ins, authentication flows and operational apps that assume a phone has signal. Mark which are safety-critical.
  2. Add a second channel for safety-critical ones. Lone-worker and alarm systems should alert when a device misses a check-in, so loss of signal itself becomes the alarm.
  3. Use authenticators that work offline. Platform passkeys and hardware security keys verify locally; time-based codes generate without signal. Keep SMS and push for low-risk use only.
  4. Write a help desk rule for "I am not getting my code". Identity verification must not weaken because the channel failed. Use a pre-registered alternative factor or in-person verification.
  5. Set MDM and token policy for offline periods. Decide how long a device that has not checked in keeps access, and make conditional access treat long silence as a risk signal.
  6. Reduce weak radio fallbacks where policy allows. On Android Enterprise, deviceRadioState.cellularTwoGState can be set to CELLULAR_TWO_G_DISABLED, and minimumWifiSecurityLevel can stop devices joining open networks when their usual network is unavailable. Test coverage first, since disabling 2G can remove service in some rural areas.
  7. Test it. Run tabletop exercises with phones in aeroplane mode to simulate jamming; never operate a jammer for testing, as that is illegal in many jurisdictions.

Detection and measurement

ATT&CK v20's DET0639 Detection of Network Denial of Service correlates, on Android, ConnectivityManager, TelephonyManager or WifiManager callbacks reporting repeated failure or oscillation outside expected coverage patterns with app and policy state; on iOS, MDM device information and installed app lists treated as periodic state. Practical signals:

  • Clustered check-in gaps: several managed devices in the same location stop checking in to MDM at the same time.
  • Carrier-reported outages versus local loss: if the carrier shows no outage but a site loses all mobile service, suspect interference.
  • Unusual outbound volume: a single device generating sustained traffic to one destination, seen in MTD or network telemetry, suggests DDoS participation.
  • Authentication failure spikes: SMS or push timeouts concentrated in one place and time.

Metrics

  • Percentage of safety-critical mobile workflows with a missed-check-in alarm or second channel.
  • Percentage of users with an offline-capable authenticator registered.
  • Time to detect a site-wide loss of mobile connectivity.
  • Count of Android devices allowing unknown-source installs.

Response

  • Confirm scope: check carrier status and whether the loss is limited to one site, which points to local interference.
  • Switch channels: move safety communications to wired lines, satellite or radio where available.
  • Preserve evidence: record times, locations and affected devices; in the US the FCC handles jammer complaints and states penalties include fines, equipment seizure and imprisonment.
  • Hold identity steady: do not relax verification for users whose codes are not arriving.
  • If a device is a DDoS source: isolate it, remove the app through MDM, reset credentials used on it and follow the Mobile Malware Guide.

Common failure patterns

  • Assuming signal for safety alarms: a lone-worker app that only alerts when it can send is silent when jammed.
  • SMS as the only second factor: no signal means no login, which drives risky workarounds.
  • Help desk bypass under pressure: skipping verification because a code did not arrive is a social engineering opening.
  • Testing with real jammers: this creates legal exposure and can block emergency calls.

Framework mapping

FrameworkReferenceRelevance
ATT&CK EnterpriseT1498 Network Denial of ServiceNetwork-side counterpart
NIST SP 800-53 Rev 5SC-5 Denial-of-service Protection; AC-19 Access Control for Mobile Devices; CP-10 System Recovery and ReconstitutionAvailability protection, device policy, recovery
NIST CSF 2.0PR.IR-04; DE.CM-01Capacity and resilience, network monitoring
ISO/IEC 27001:2022 Annex AA.5.30 ICT readiness for business continuity; A.8.20 Networks securityContinuity and network controls

Practitioner checklist

  • Inventory processes that depend on phone connectivity and flag the safety-critical ones.
  • Make missed check-ins raise an alarm for lone-worker and alarm systems.
  • Register an offline-capable authenticator for every user.
  • Write a help desk procedure for undelivered codes that keeps verification strength.
  • Block unknown-source installs on Android to keep devices out of DDoS pools.
  • Consider disabling 2G and open Wi-Fi joins on Android Enterprise where coverage allows.
  • Know how to report suspected jamming to your regulator.

Standards and references

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Physical Layer and Wireless Jamming Guide · DDoS Response Playbook · Mobile Device Security Guide · Mobile T1451 SIM Card Swap

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 12 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org