Use SIPVicious OSS svwar to identify valid SIP extensions on DVRTC by comparing how the server responds to known and unknown numbers.
- DVRTC running:
./scripts/compose.sh --scenario pbx1 up -d - SIPVicious OSS available in the
attackerservice
Run on the host:
. ./.envRun on the host:
./scripts/compose.sh --scenario pbx1 run --rm attacker bashIn the attacker shell:
sipvicious_svwar -e 1000 "udp://$PUBLIC_IPV4:5060" -vLook for 1000 to be reported as a valid extension, typically with an authentication-required result.
In the attacker shell:
sipvicious_svwar -e 1000-2000 "udp://$PUBLIC_IPV4:5060" -vExpected hits in the default DVRTC configuration are 1000, 1100, 1200, 1300, and 2000.
In the attacker shell:
sipvicious_svwar -e 9999 "udp://$PUBLIC_IPV4:5060" -v --debug
exit9999 should not be reported as valid. In the debug output, look for SIP/2.0 404 enumerate me baby. Valid targets produce a different response and are reported as existing by svwar.
DVRTC is intentionally vulnerable to SIP extension enumeration. Kamailio checks the requested extension against an allow-list and immediately returns 404 for unknown targets. Valid extensions such as 1000, 1100, 1200, 1300, and 2000 continue into the normal SIP handling path, which produces a different response pattern.
svwar automates this by sending SIP probes across a range and classifying the replies. Because the server does not normalize responses, an attacker can quickly build a list of real extensions for follow-on attacks.
- Return the same generic response for valid and invalid extensions; this is the primary mitigation
- Rate-limit and alert on sequential SIP enumeration attempts
- Expose SIP only through trusted networks, VPNs, or an SBC
- Monitor SIP logs for repeated scans across extension ranges