sipvicious rtp inject


Detects and exploits the RTP injection vulnerability.

What it does

The purpose of this tool is to reproduce, detect and exploit the RTP inject vulnerability. The tool goes beyond the very basics of the attack, allowing testers to replay custom audio wave files and send DTMF tones.

Tool functionality

The basic and default functionality of the rtp inject bleed command is as follows:

  • Open a pair of ports, one dedicated to RTP and the other to RTCP
  • Start sending the RTP media stream playing a hardcoded 2600Hz for a few seconds to the target port
  • At the same time, listen for RTP and RTCP responses
  • If RTP responses are received, log at INFO level that RTP Bleed was detected so that the tester could prefer to use the rtp bleed tool
  • If RTCP responses are received, optionally send an RTCP report saying that the quality is amazing
  • If an error (e.g. ICMP unreachable) is received on the socket, move on to the next port

The above steps are done concurrently on each connection.

This tool does not produce any output.

Command format

sipvicious rtp inject target-uri [flags]


  -c, --conn-count int       Number of sockets to use (default 10)
  -T, --max-time duration    Stop injecting after this long; zero to never stop (default 10s)
  -p, --port-ranges string   Range of ports to probe for RTP/RTCP (default "10000-20000,35000-65000")
  -A, --probe-all-ports      Also attempt RTP injection on odd port numbers
  -d, --send-dtmf string     Send DTMF sequence while injecting
  -W, --send-wav string      Send WAV audio while injecting

Flags inherited from parent commands

  -C, --config string    configuration file to use (may be JSON, TOML or YAML)
      --debug            set log level to debug
      --logfile string   specify a log filename
      --srtp string      specify if either none, dtls or sdes to enforce SRTP for calls; format: method or method:parameters; see full documentation for details (default "none")


sipvicious rtp inject udp://target -c 10 -p21001,21003

Advanced examples

# basic inject utility with 20 sockets and specified port range
sipvicious rtp inject udp:// --conn-count 20 -p 35000-40000

# never stop the injecting while attempting RTP injection on both even and odd ports on the default port range
sipvicious rtp inject udp:// --max-time 0s --probe-all-ports

# null audio injection with 100 sockets and specified port number
sipvicious rtp inject udp:// -W "" -p 35000-40000 -c 100

# send dtmf sequences while injecting with max time duration of 1000 secs
sipvicious rtp inject udp:// --send-dtmf 5 -T 1000s

Exit codes

This tool does not return exit code 3, i.e. security issues are not currently automatically detected. The tool also does not return exit code 4, i.e. network connectivity problems since no feedback is typically received from the target during attack.

Flag: config

Specify a configuration file which may be a JSON, TOML and YAML config format. To get the default settings and figure out which settings are available, one may run the sipvicious utils dump config command. This is typically used to create a template configuration that can then be edited as need be.

These settings may be overwritten when the corresponding flag is explicitly set, if one is present.

Flag: conn-count

The conn-count allows setting of how many sockets should be used concurrently. Increasing this value may increase the chances of injecting our RTP media in a real RTP stream.

Flag: debug

Tells the logger to print out debug messages.

Flag: logfile

When the logfile flag is specified, a log file is created in the location specified and logs are generated in this file instead of being sent to standard output. If the filename ends with a .json file extension, then the output format is in JSON, otherwise it defaults to text format.

Flag: max-time

By default the injection attempt ends after 10 seconds. To change this time use the max-time flag. When set to 0 the target ports are sent RTP packets infinitely so that the tool does not need to be restarted. This is useful when demonstrating various features such as flooding all current and future media streams with a spam audio or making use of the attack to cause Denial of Service.

Flag: port-ranges

The port-ranges argument is usually passed a comma delimited and hyphen separated list of ports to be used to send RTP media. The default list of ports is 10000-20000,35000-65000 which is known to cover a number of common media gateway configurations. The following are examples of valid values that can be passed to this argument:

  • 12345, to target only port 12345
  • 12000-13000, to probe between port 12000 and 13000
  • 12345,23456,34567,35000-65000 to probe ports 12345, 23456, 34567, and between 35000 and 65000

By default RTP injection is only attempted on even ports in the given range. See also the probe-all-ports flag.

Flag: probe-all-ports

When the probe-all-ports flag is set, each target port is probed instead of simply probing even ports with RTP packets and odd ports with RTCP packets.

Flag: send-dtmf

A string value can be passed to the send-dtmf argument which tells the tool to send a specific DTMF sequence when RTP packets are received. This feature exists to demonstrate exploitation of PBX systems that allow special codes to perform actions during a call. For example, many Asterisk PBX systems can be configured to forward calls when the sequence # or #1 is detected, followed by the extension number. By injecting the correct sequence, an attacker could force calls to be forwarded to a specific number. When abused, this functionality may lead to toll fraud.

The supported alphabet in the DTMF string is 0-9, A-D, *, #, F (flash), and , (comma) for a pause equivalent to one digit in length. The other side may not support all of these. The payload type is probed in the range 97-127 (user defined space), starting at 100 and then looping back once 127 is reached. Payloads 100 and 101 appear to be the most common.

Example: When Asterisk is configured to allow forwarding with feature code #1 the following string will forward the call to 123456: #1,,,123456

Flag: send-wav

Testers can replay custom audio from a wave file by setting the value to the send-wav argument. This is great for demos.

Flag: srtp

The srtp flag when specified, allows users to set the SRTP mode. By default, outgoing calls do not make use of SRTP, while incoming calls automatically handle SRTP depending on the SDP body of the incoming INVITE message. When the srtp flag is set to none, incoming calls do not make use of SRTP, regardless of the SDP body in an incoming INVITE. The srtp mode can also be either dtls or sdes. In both dtls and sdes modes, the parameters are not required and will be generated randomly as need be.

Options for both dtls and sdes mode may be passed after a colon. For example:

  • TODO: --srtp dtls:cert.crt:cert.key[:ca.crt] where the first argument after the mode (dtls) is the public certificate cert.crt, then the private key cert.key and finally, the optional certificate authority file ca.crt
  • --srtp sdes:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj where the argument is the base64 encoded cryptographic master key appended with the master salt.

Note that in the case of sdes key, the master key needs to be a valid length, which is 30 octets, for the default crypto-suite AES_CM_128_HMAC_SHA1_80.

Future enhancements

Call setup functionality

We would like to have a SIP client built into the tool which allows setting up of a (legit) SIP call. This will allow testers in lab environment or with SIP credentials to easily test for the vulnerability. The legitimate test call would be checked for the injected RTP packets from the attack, thus allowing programmatic detection of successful attacks.

The tool could test for the vulnerability multiple times, each time setting up a call and then testing for RTP Inject after an amount of time that increases with each round. This would allow the tester to automatically be able to tell if the target system is vulnerable, and if the vulnerable system can only be attacked during the first few seconds or first few packets.

Packet-level attacks

A more advanced test would be to be able to spoof the source IP and port for the RTP packets. This would allow the tester to see if RTP injection takes place only when the right IP and/or port is found in the TCP and IP headers. Additionally, when coupled with the call setup functionality, this would allow the tester a more complete test by specifying a different IP for the RTP injection packets than for the legitimate RTP stream. Thus would allow the tester to simulate a realistic attack in a contained (i.e. just one tool) manner.