Home / Attacks & tests / Denial of Service (DoS) Testing for Mobile Applications
3 test cases
Denial of Service (DoS) Testing for Mobile Applications
Availability matters differently on a device that performs a physical function. A denial of service against a lock, a sensor or a controller is not an inconvenience but a failure of the thing the device exists to do, and recovery may require someone to visit it.
What an attacker is trying to achieve
The attacker wants the device off, unreachable, or permanently ruined. Because embedded devices have small resource margins and are often unattended, the effort required is usually small and the consequence disproportionate.
Test cases
3 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
IOT-DOS-01 Battery and Power Abuse
Objective — Determine whether an attacker can force a battery-powered device to consume its charge far faster than its design assumes.
How it is tested — Measure baseline consumption in normal operation, then identify externally triggerable activity that costs disproportionate power: radio transmission, wake events, sensor activation, retry loops after a failed connection. Trigger each repeatedly and measure the change. Establish whether the device rate-limits externally triggered wakes, and whether a failed connection produces bounded or unbounded retries.
Prerequisites — A battery-powered device; power measurement equipment; the ability to trigger the device externally and to deny it a connection.
Indicators — Consumption rising sharply under externally triggered activity; no limit on wake events; unbounded retries after a failed connection; projected battery life reduced by an order of magnitude.
Coverage — CWE-920CWE-770
Depth — Manual Requires measuring real consumption over time, not observing responses.
IOT-DOS-02 Disabling the Device
Objective — Determine whether the device can be made to stop performing its function while remaining powered, and whether it recovers without intervention.
How it is tested — Submit malformed input to each exposed service and observe whether the device stops responding. Exhaust its connection, memory and storage capacity, which are usually small. Establish whether a watchdog restores operation, how long that takes, and whether the condition can be sustained by repeating the trigger. Establish whether the device fails to a safe state or simply stops.
Prerequisites — A device on an isolated segment; explicit authorisation; the ability to observe the device's physical function; an agreed stop condition.
Indicators — The device ceasing to function on malformed input; no watchdog recovery; the condition sustainable by repetition; the device failing to an unsafe state.
Coverage — CWE-400CWE-20
Depth — Manual The finding is a physical outcome and has to be observed at the device.
IOT-DOS-03 Bricking the Device
Objective — Determine whether a device can be put into a state from which it cannot recover without physical intervention or replacement.
How it is tested — Identify operations that write persistent state: firmware updates, configuration writes, partition changes, key provisioning. Interrupt each part-way — by removing power, by disconnecting mid-transfer — and establish whether the device recovers on next boot. Establish whether a redundant image or recovery mode exists, and whether an attacker who reaches the update path can deliberately write an image that will not boot.
Prerequisites — A device designated for destruction; explicit written authorisation; the ability to interrupt power precisely; replacement units.
Indicators — The device failing to boot after an interrupted write; no redundant image or recovery mode; recovery requiring hardware intervention; the state reachable remotely.
Coverage — CWE-1326CWE-494
Depth — Manual The confirming result destroys the unit, so it is run once, last, and only on a device designated for it.
What we need from you
A device designated for destructive testing, on an isolated segment; explicit written authorisation, since confirmation may permanently ruin the unit; power measurement for the battery cases; and an agreed stop condition.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- CWE-920 — Improper Restriction of Power Consumption
- CWE-770 — Allocation of Resources Without Limits or Throttling
- CWE-400 — Uncontrolled Resource Consumption
- CWE-20 — Improper Input Validation
- CWE-1326 — Missing Immutable Root of Trust in Hardware
- CWE-494 — Download of Code Without Integrity Check
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.