Home / Attacks & tests / Network Traffic Security Testing for Mobile and IoT Applications
7 test cases
Network Traffic Security Testing for Mobile and IoT Applications
Network testing for devices examines protocols that are frequently not HTTP, frequently not encrypted, and frequently designed for constrained hardware where cryptography was considered too expensive. The device's traffic is often the weakest part of the whole system.
What an attacker is trying to achieve
The attacker on the network wants to read what the device reports, alter what it is told, and issue commands it will obey. Where the protocol has no authentication or integrity, all three follow from a network position alone.
Test cases
7 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-NET-01 Traffic Sniffing
Objective — Determine what an observer on the device's network can read without altering anything.
How it is tested — Capture traffic on every medium the device uses across its full lifecycle — provisioning, normal operation, update, error and recovery. Establish which flows are encrypted and which are not, and what the unencrypted ones disclose: telemetry, credentials, commands, identifiers. Include traffic that occurs only at provisioning, which is frequently the least protected and the most valuable.
Prerequisites — Capture capability on every medium including radio; the ability to observe provisioning, which happens once; an isolated segment.
Indicators — Credentials or keys in plaintext traffic; telemetry disclosing personal or location data; commands readable; provisioning traffic unprotected.
Coverage — V9.1.1CWE-319CWE-311
Depth — Hybrid Capture and inspection automate; interpreting a proprietary protocol requires the firmware.
IOT-NET-02 Man-in-the-Middle Attacks
Objective — Determine whether an attacker positioned between the device and its service can read or alter the traffic passing through.
How it is tested — Place a proxy between device and service and establish whether the device verifies the identity of the endpoint it reaches. Present invalid, mismatched and self-signed certificates in turn. Where the protocol is proprietary, establish whether it authenticates the endpoint at all. Test whether the device can be redirected to a substitute service by manipulating name resolution or the configuration it is given at provisioning.
Prerequisites — An isolated segment with the device's traffic routable through a proxy; the ability to present arbitrary certificates and to control name resolution.
Indicators — A connection completing against an invalid certificate; no endpoint authentication in a proprietary protocol; the device redirected by name resolution; a substitute service accepted.
Coverage — CWE-295CWE-300
Depth — Manual Requires standing up a substitute service and observing whether the device notices.
IOT-NET-03 Message Integrity
Objective — Determine whether messages between device and service are protected against modification in transit.
How it is tested — Modify captured messages and forward them, altering fields the receiver acts on: commands, thresholds, measurements, addresses. Establish whether any integrity protection is present, whether it covers the whole message or only part, and whether it is keyed or merely a checksum. Determine whether the receiver validates message structure before acting, or acts on fields it has not checked.
Prerequisites — A position able to intercept and forward modified traffic; a controller generating legitimate messages; the protocol understood from the firmware where proprietary.
Indicators — A modified message acted upon; integrity covering only part of the message; an unkeyed checksum used as integrity; a command executed with altered parameters.
Coverage — CWE-345CWE-354
Depth — Manual Requires understanding the message format well enough to modify it meaningfully.
IOT-NET-04 Replay Attacks
Objective — Determine whether a captured message can be resent and acted upon again, without the attacker understanding or altering it.
How it is tested — Capture messages with an observable effect — unlock, activate, set a value — and resend each unchanged, immediately and after a delay. Establish whether the receiver detects the repetition through a counter, timestamp or nonce, and whether that mechanism survives a device reboot. Test whether a message captured from one device is accepted by another in the same fleet.
Prerequisites — Capture and transmit capability on the device's medium; two devices for the cross-device case; the ability to reboot the device.
Indicators — A captured message acted upon when resent; no counter, timestamp or nonce; a counter reset by reboot; a message from one device accepted by another.
Coverage — CWE-294CWE-323
Depth — Manual Requires transmitting on the device's own medium, which for radio protocols means appropriate hardware.
IOT-NET-05 Insecure Protocol Usage
Objective — Determine whether the messaging and transport protocols the device uses are configured to authenticate and protect the traffic they carry.
How it is tested — Identify each protocol in use and establish how it is configured. For messaging brokers, establish whether the device authenticates, whether the connection is encrypted, and whether topic or channel authorisation confines the device to its own data. Attempt to connect to the same infrastructure as an unauthorised client and to subscribe to other devices' topics or publish commands to them.
Prerequisites — The broker or service endpoint reachable from the test position; credentials recovered from the firmware; a client able to speak the protocol.
Indicators — A broker accepting anonymous connections; no encryption on the messaging channel; a client able to subscribe to other devices' topics; commands publishable to another device.
Coverage — CWE-306CWE-319
Depth — Hybrid Connection testing automates; establishing the topic authorisation model requires trying it.
IOT-NET-06 Identity, Event and Data Spoofing
Objective — Determine whether an attacker can inject messages that the service or controller accepts as coming from a legitimate device.
How it is tested — Construct messages claiming to originate from a device other than the one under the tester's control, using identifiers observed in captured traffic, and submit them. Establish whether the receiver verifies origin cryptographically or accepts an asserted identifier. Inject events the device never reported — false measurements, false alarms, false state changes — and establish whether downstream automation acts on them.
Prerequisites — The message format understood; identifiers observed from captured traffic; the ability to transmit on the device's medium; visibility of downstream automation.
Indicators — A message accepted under another device's identifier; origin asserted rather than proven; injected events acted upon by automation; no binding between identifier and key material.
Coverage — CWE-290CWE-345
Depth — Manual Requires constructing messages the receiver will accept, which comes from understanding the protocol.
IOT-NET-07 Privilege Escalation Through the Network
Objective — Determine whether a device's network position or credentials grant access beyond what that device requires.
How it is tested — Using credentials and keys recovered from one device, establish what the wider infrastructure grants them: which topics, endpoints, management interfaces and other devices become reachable. Establish whether credentials are unique per device or shared across the fleet, and whether a device is confined to its own data. Determine whether the device's network position permits reaching systems that its function does not require.
Prerequisites — Credentials recovered from a device; access to the infrastructure from the test position; ideally two devices to compare credential uniqueness; written scope covering the infrastructure.
Indicators — One device's credentials reaching another's data; fleet-wide shared credentials; a management interface reachable with device credentials; the device positioned on a network segment it does not need.
Coverage — CWE-269CWE-285
Depth — Manual Requires the infrastructure to be in scope as well as the device, which has to be agreed in advance.
What we need from you
An isolated network segment carrying the device's traffic; capture capability on every medium the device uses, including radio; the firmware image for understanding proprietary protocols; and a controller to generate legitimate traffic for comparison.
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.
- V9.1.1 — Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications.
- CWE-319 — Cleartext Transmission of Sensitive Information
- CWE-311 — Missing Encryption of Sensitive Data
- CWE-295 — Improper Certificate Validation
- CWE-300 — Channel Accessible by Non-Endpoint
- CWE-345 — Insufficient Verification of Data Authenticity
- CWE-354 — Improper Validation of Integrity Check Value
- CWE-294 — Authentication Bypass by Capture-replay
- CWE-323 — Reusing a Nonce, Key Pair in Encryption
- CWE-306 — Missing Authentication for Critical Function
- CWE-290 — Authentication Bypass by Spoofing
- CWE-269 — Improper Privilege Management
- CWE-285 — Improper Authorization
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.