What attacks target RTP?

How RTP Attacks Work in Practice

RTP is the media plane for voice and video, so attacks usually focus on what the stream reveals or what can be done to the stream while it is in transit. The common abuse patterns are passive eavesdropping, active injection, replay, and traffic analysis, and they become much more practical when media is sent without encryption or when signalling and media protections are inconsistent.

What makes RTP attractive is that it is often continuous, time-sensitive, and operationally visible even when the payload is not. An attacker does not need to break the application first if they can observe packets, infer who is talking to whom, or interfere with sequence and timing.

What an Attacker Can Learn or Manipulate

Packet sniffing can expose the content of a call when RTP payloads are not protected, while traffic analysis can still reveal participants, call duration, timing, and communication patterns even if some higher-layer protections exist. Stream injection and replay are active attacks against media integrity, where the attacker attempts to add bogus audio, resend captured packets, or distort the conversation enough to undermine trust in the session.

These attacks are often paired with signalling weaknesses or credential exposure. If an attacker can obtain call setup details, keys, or session material, they may be able to move from observation into manipulation, especially where media security is not tightly bound to signalling state and session validation.

What Defenders Should Watch For

Operationally, the most useful signals are not just failed calls, but abnormal media behaviour: RTP packets from unexpected sources, sequence gaps or jumps, duplicated or out-of-order packets, unusual jitter, and sudden shifts in stream timing. Those patterns can indicate replay, injection, misrouting, or a degraded path that is being abused to interfere with voice quality.

When you review logs, treat signalling and media as linked evidence. If a call is established legitimately but the media source, timing, or packet cadence does not match the session state, the issue may be interception or stream tampering rather than a simple network fault.

Risk and Threat Considerations

RTP exposure is not only a confidentiality issue. Unencrypted media can be listened to, altered, or disrupted, and even partial visibility can create privacy, fraud, and business risk when voice conversations carry sensitive operational or customer information.

Failure mechanism: Attackers exploit weak or absent media encryption, weak session protection, or poor source validation to sniff packets, inject audio, replay old traffic, or infer communications through traffic analysis.

Impact: Call content can be disclosed, conversations can be manipulated, voice quality can be degraded, and the organisation can lose trust in the integrity of recorded or live communications.

Practitioner Guidance

What to prioritise: Treat media protection and signalling protection as a single control problem. If RTP is protected but key exchange, call setup, or session validation is weak, the attacker may still reach the media path through the management plane or session layer.

What to verify: Confirm that media encryption is actually enforced on the paths that matter, that keys are not exposed in logs or provisioning flows, and that packet monitoring can distinguish legitimate retransmission or jitter from active manipulation. If you can only inspect call setup and not media source behaviour, your detection is incomplete.

Practitioner takeaway: The key judgement is whether the environment protects both the contents of RTP and the integrity of the session around it, because confidentiality alone does not prevent injection, replay, or traffic-analysis abuse.

Related resources from NHI Mgmt Group

• Guide: Network Ports and Protocols Security Guide
• How can organizations counter AI-driven cyber attacks?
• Who should own identity risk when attacks target both people and third-party access?
• How should security teams handle vishing attacks that target SaaS support workflows?
• Why do supply-chain attacks increasingly target secrets instead of just code integrity?