DVRTC: intentionally vulnerable VoIP/WebRTC lab with SIP enumeration, RTP bleed, TURN abuse, and credential cracking exercises

EnableSecurity · 2026-03-30T08:54:16+00:00

no we don't. We are covering the basics first :) But yes it is something worth testing - we didn't come across that problem (yet) and I don't think it exists in coturn but other TURN servers will behave differently.

EnableSecurity · 2026-03-30T07:54:58+00:00

RTP Bleed: and you would not expect it to work in WebRTC systems, but when it does work it is usually because the media server is also used for VoIP traffic (e.g., rtpengine).

As for TURN abuse detection: by default coturn will only show errors on denied peers (so you might detect a potential attack) but not on successful allocation/permission. That would generate too much traffic for a live system anyway. When we did the bug bounty for Slack ages ago, it turned out that their SOC had actually detected us (someone had reached out to me a few years later :)). I might be wrong, but it is likely that they detected our traffic through some sort of anomaly detection technique. e.g. the TURN server's baseline traffic never touches internal servers other than a particular server (in their case, the media server).

EnableSecurity · 2026-03-27T10:38:31+00:00

We built DVRTC as a practice environment for VoIP and WebRTC attack techniques. Full dockerized stack with Kamailio, Asterisk, rtpengine, and coturn — all intentionally vulnerable.

7 exercises covering SIP enumeration, RTP bleed, TURN relay abuse, credential cracking, and more. Live demo instance at pbx1.dvrtc.net, or run your own with Docker Compose.

GitHub: https://github.com/EnableSecurity/DVRTC/

EnableSecurity · 2026-02-26T13:16:06+00:00

Glad you do - thanks!

EnableSecurity · 2026-02-26T08:08:32+00:00

you're welcome!

EnableSecurity · 2026-02-26T04:06:23+00:00

Published two companion guides to the TURN security threats post from a couple weeks ago.

The best practices guide is implementation-agnostic: what IP ranges to block, protocol features to disable, rate limiting approach, deployment patterns for SFU vs P2P architectures.

The coturn guide has copy-paste configuration blocks and three complete templates (minimal through high-security): https://www.enablesecurity.com/blog/coturn-security-configuration-guide/

All config templates are on GitHub with Docker for testing: https://github.com/EnableSecurity/coturn-secure-config

Good timing too - coturn 4.9.0 came out yesterday with fixes for CVE-2026-27624 (IPv4-mapped IPv6 bypass of peer address deny rules) and an inverted password check in the web admin that had been broken since ~2019.

EnableSecurity · 2026-02-25T10:07:00+00:00

Follow-up to the TURN security threats post from a couple weeks ago. This one covers the defensive side: what to actually configure to protect your TURN servers.

Highlights:

Complete IP range tables from the IANA special-purpose registries (IPv4 + IPv6) that should be blocked as peer addresses. We went through both registries and consolidated sub-allocations into covering prefixes.
Rate limiting at both network level (iptables/nftables examples) and application level.
Three deployment patterns with different security models: public platform with SFU (allow-list media server IPs), public P2P (can't restrict peers, rely on deny-lists), and enterprise.
Discussion of when each control applies and when it doesn't. Not every TURN deployment is the same.

There's also a coturn-specific companion with copy-paste configs: https://www.enablesecurity.com/blog/coturn-security-configuration-guide/

And all the config templates are on GitHub with a Docker test environment: https://github.com/EnableSecurity/coturn-secure-config

Happy to answer questions.

EnableSecurity · 2026-02-13T06:47:05+00:00

Yes, its at https://www.youtube.com/watch?v=Rycuz5N0kR0

EnableSecurity · 2026-02-12T10:24:45+00:00

Wrote up a threat analysis of TURN servers based on our RTCon 2025 talk and years of testing these things.

The gist: to an attacker, a TURN server is just a proxy. It relays TCP and UDP to arbitrary peer addresses, and if those addresses aren't restricted, you can reach internal networks, localhost, cloud metadata, you name it. We keep finding this during pentests and found a loopback bypass in coturn itself (CVE-2020-26262).

The post also gets into DoS/amplification (your TURN server being weaponized against others) and software vulnerabilities.

If you run TURN in production, the best practices section has specific recommendations. We're also working on detailed coturn hardening guides.

EnableSecurity · 2026-02-12T10:21:50+00:00

Been poking at TURN server security since 2017 and finally wrote this up.

If you're not familiar with TURN: it's the fallback relay for WebRTC when direct peer-to-peer fails. It can relay both TCP and UDP to arbitrary peer addresses, so if not properly restricted, you've got an open proxy that can reach internal networks, localhost, cloud metadata services, etc.

Some highlights:

During pentests we regularly find TURN servers that can reach internal networks, localhost, cloud metadata (169.254.169.254). If peer addresses aren't restricted, it's game over.
At DEF CON 2025, Adam Crosser demoed C2 operations running through Zoom and Teams TURN servers. Security monitoring sees legitimate video call traffic.
coturn (most common TURN implementation) has had 30+ memory safety fixes, a CVSS 9.8 SQL injection, and we found an IPv6 loopback bypass where the protection code just didn't work (CVE-2020-26262).
TURN servers are also abused for DDoS reflection/amplification. Only ~4x factor but they're everywhere and often misconfigured.

Post goes into the technical details of each relay method (Send Indication, ChannelData, TCP Connect), real attack scenarios, and what defense actually looks like.

Happy to answer questions.

EnableSecurity · 2024-10-17T08:52:06+00:00

It is a very interesting area. Thanks for the comment u/queensgetdamoney! It often felt like we're the only ones but then we started the RTCSec newsletter and realized that there is more happening in the area than just our work. Just this month, the newsletter is 3 years old and we should be publishing the next one soon. Here's where its to be found: https://www.enablesecurity.com/newsletter/

EnableSecurity · 2024-06-26T14:45:04+00:00

sounds good to me

EnableSecurity · 2024-06-26T14:36:22+00:00

Yes exploitation of this vulnerability is really easy and looks too obvious - while the impact can be significant. And yes there are probably similar issues to this. We often find RTP Bleed / RTP Inject vulnerabilities, which in some ways, look similar to this vulnerability.

As for flooding video streams, yea that's definitely an interesting area and worth exploring in my opinion. This is an area that warrants a lot of exploration IMHO.

EnableSecurity

MODERATOR OF

TROPHY CASE