How to Perform a Remote MITM Attack on goTenna Pro Mesh Radios

TLDR: Researchers at DEF CON 2025 demonstrated a critical vulnerability in the goTenna Pro mesh radio system, tracked as CVE-2024-47130. By exploiting a lack of authentication in the public key exchange protocol, an attacker can remotely intercept and modify communications between devices. This research highlights the danger of assuming that encrypted mesh networks are inherently secure against active, unauthenticated adversaries.

Off-grid communication systems are the backbone of tactical and disaster response operations. When cellular infrastructure fails, teams rely on mesh radios to maintain situational awareness. The assumption has long been that these proprietary protocols, often utilizing AES-256 encryption, provide a sufficient barrier against interception. That assumption is wrong. The research presented at DEF CON 2025 proves that even when the underlying encryption algorithm is sound, a failure in key management and authentication can render the entire system transparent to an attacker.

The Vulnerability: Broken Key Exchange

The core issue lies in the public key exchange mechanism used by the goTenna Pro. While the system uses Elliptic Curve Diffie-Hellman (ECDH) to derive shared secrets for message encryption, the exchange of these public keys is not authenticated. An attacker within radio frequency (RF) range can inject a malicious PUBLIC_KEY_REQUEST or PUBLIC_KEY_RESPONSE packet. Because the device does not verify the source of these packets, it blindly accepts the attacker's public key, effectively replacing the legitimate key in its local database.

This is a classic A07:2021 – Identification and Authentication Failures scenario, but applied to a tactical radio environment. Once the attacker has successfully injected their key, they sit in the middle of the communication flow. They can decrypt incoming messages, modify them, or drop them entirely, all while the legitimate users see a "delivered" confirmation on their devices. The victim has no indication that their communication has been compromised, as the radio continues to function normally.

Technical Execution and Tooling

The researchers utilized GNU Radio to handle the RF capture and signal processing. By building a custom pipeline, they were able to monitor the operational frequency, capture metadata like GID hashes and timestamps, and identify the exact moment of key exchange. The attack flow is straightforward:

1. Reconnaissance: Use a software-defined radio (SDR) to scan the spectrum and identify the target frequency.
2. Capture: Monitor for PUBLIC_KEY_REQUEST packets to identify the target GID.
3. Injection: Send a spoofed PUBLIC_KEY_REQUEST packet with the attacker's public key, using the target's GID.
4. Persistence: Once the key is replaced, the attacker can decrypt and re-encrypt traffic in real-time.

The researchers released their proof-of-concept code on GitHub, which includes the scripts necessary to perform the key replacement and message interception. For pentesters, this is a reminder that "encrypted" does not mean "secure." If you are assessing IoT or tactical hardware, focus your efforts on the handshake and key management phases. If the device doesn't require a pre-shared key or a certificate-based authentication for the initial exchange, it is vulnerable to this type of manipulation.

Real-World Impact

In a tactical environment, the impact of this vulnerability is catastrophic. An attacker could feed false GPS coordinates to a team, leading them into a "support-void" zone, or intercept critical medical or tactical reports to delay aid. Because the attack is remote and requires no interaction with the victim, it is nearly impossible to detect without specialized RF monitoring equipment.

During their live demonstration, the researchers showed how they could manipulate the GPS coordinates displayed on a target device. By intercepting the communication and injecting their own, they successfully redirected the team's navigation. The team on the ground believed they were receiving legitimate updates, while the attacker was dictating their movements. This level of control over a team's situational awareness is a dream for an adversary and a nightmare for the operators.

Defensive Considerations

For developers of similar systems, the fix is clear: implement strict authentication for all key exchange packets. Do not allow public keys to be updated over the air without a secondary, out-of-band verification or a pre-existing trust anchor. Furthermore, implement robust error telemetry. If a device receives an unexpected or malformed key update, it should log that event and alert the user.

Security researchers and red teamers should prioritize testing the key management lifecycle of any radio or IoT device that claims to be "secure." If the documentation doesn't explicitly detail how the device authenticates the initial key exchange, assume it doesn't. Always check for A02:2021 – Cryptographic Failures by verifying if the device rotates initialization vectors (IVs) and properly handles key storage.

The next time you are on an engagement involving tactical radios, don't just look for open ports or default credentials. Look at the airwaves. The most critical vulnerabilities are often hiding in the protocols that we assume are working perfectly. If you can capture the traffic, you can likely break the trust. Start by auditing the handshake, and you might find that the "secure" channel is anything but.