Follow along as I recount a real-world toll fraud attack which targeted corporate VoIP infrastructure and unfortunately led to serious monetary damages. In this blog, I share my investigation process, some interesting findings, and lessons learned. This was my first exposure to Toll Fraud as a security professional and I enjoyed learning about this lesser-known attack surface.
What is a Toll Fraud Attack?
To put it simply, Toll fraud attacks involve hackers exploiting vulnerabilities or weak configurations in a telephony or VoIP system to route calls through the victim’s infrastructure, often to premium-rate numbers, or high-cost locations around the globe while generating revenue for the attacker at the victim's expense.
đź’ˇ
The image above was taken from a fantastic article written on Toll Fraud attacks. If you want an in-depth overview of Toll Fraud Attacks, be sure to check article
here.
To put this in more technical terms, I learned that these attacks typically can occur when hackers identify a weakness and/or a misconfiguration in an internet facing asset which exposes Port 5060 TCP/UDP or 5061 TCP/UDP. Many of these attacks start with simple SIP requests such as INVITE, REGISTER, OPTIONS, METHOD to observe how the SIP server responds. After attackers identify a viable victim SIP server to interact with, attackers can perform some of the following to further their access:
Extension brute forcing - Attacker try's to send SIP REGISTER requests to every possible extension to find valid extensions.
Password Guessing - With a list of valid extensions attackers can fuzz for known combinations of easily guessable/default user:pass combinations
Password Spraying - Trying a small list of common passwords against a large list of valid extensions
Denial-of-Service - Can be performed by sending large amounts of INVITE requests to the SIP server
VLAN Hopping - In an improperly configured network, it is possible for an attacker to jump from a VoIP network into the internal 'office' network.
Key Terms
Since the world of VoIP and SIP was brand new to me in this exercise, I bet it’s likely new to a lot of folks reading. To help, I’ve tried to highlight some of the basic terminology here for you:
SIP (Session Initiation Protocol): SIP is basically a communication protocol used for initiating, maintaining, and terminating voice and video calls, over the internet. SIP is a key component of VoIP systems.
VoIP (Voice over Internet Protocol): VoIP is a technology that allows voice communication to be delivered over the internet instead of traditional phone lines. Think about a product like Google Voice here.
SoftPhone - You might have heard of “softphones” before. A SoftPhone is just a software application that lets you make calls over the internet, likely from your computer. Think of something like Zoiper or Cisco Jabber
đź’ˇ
Above is an example of a SoftPhone application called Zoiper
PBX (Private Branch Exchange): A PBX (or PBX system) is essentially a private telephone network used within a company or organization. A PBX system manages internal and external calls, enabling features like voicemail, call forwarding, and conferencing. Modern PBX systems often use VoIP technologies, making them vulnerable to toll fraud if not secured properly.
Asterisk - Commonly referred to as an “Asterisk Server”, Asterisk itself is an open-source software framework often bundled or integrated into various telephony solutions. Some examples of PBX solutions include FreePBX, 3CX and Vicidial. For additional clarity - an Asterisk server runs PBX software (it can be configured to be a PBX), but not all PBX systems are Asterisk-based.
Analysis
With some background out of the way, lets dive into the analysis. I was provided a packet capture file which was collected as the security incident occurred. I did some research into some common SIP-focused exploitation tools, their use case, and ultimately routed my reading back into the types of attacks performed - which helped me understand what I was looking for within the Wireshark capture.
Call Flow 1
Opening our Wireshark capture, we started by simply filtering for SIP specific traffic - since that’s most likely where we would find information regarding authentication flow and recurring activity.
Above we can see various SIP requests, some 200 OK’s, some 403 forbidden’s and even some INVITE requests.
đź’ˇ
An INVITE request is sent by the client (often a softphone or VoIP application) to propose a communication session with another party (recipient).
There’s a lot going on in this capture file, so we first tried zeroing in on a specific conversation to get our bearings, lets take this specific SIP call flow for example
Above we can see one specific call (or rather attempted call that was placed). We see the conversation was initiated with an INVITE request, followed by both a Trying and Ringing packet. I’m no SIP expert, but I imagine this is quite literally what it looks like when a call is made. Ultimately we can see the call failed.
Was this an attacker making a call and failing? Or was this an employee making a standard business call and the user on the other end just didn’t pick up…lets look closer. By expanding the 503 Service Unavailable packets we can actually see the call was rejected based on data in the X-Asterisk-HangupCause header.
Cool cool, okay we can follow a call flow at least, but what in here can we look for that helps us find security issues? Well as we previously mentioned, SIP authentication uses extensions as usernames. And where there are usernames…there are passwords…and where there are passwords…well we can guess em!
Think of an extension like a phone number inside a company’s phone system. For example:
SIP authentication is how SIP/PBX servers (like Asterisk) verify that a user (or phone/softphone) is who they say they are before letting them make or receive calls. In the SIP INVITE packet below, we can see the username/extension making the call, extension 700.
In order to find the password that is being sent back and forth in these SIP conversations we need to look for a SIP REGISTER packet. Unfortunately there was no REGISTER packet in this call flow so two things likely happened here:
Either the SIP server doesn’t require authentication for this INVITE. (maybe the packet capture was started after authentication?)
Authentication may have already occurred during SIP registration, and the system considers extension 700 authenticated.
Lets take a look at another call flow
Call Flow 2
In this call flow we have a little more going on, we see the conversation is initiated by an INVITE once again, Lets take a look at the first INVITE request to see who is making the call.
Inside of the INVITE packet we see the user or extension 701 initiating this call. Looking back at the call flow, we see an INVITE, followed by a 401 Unauthorized.
The SIP server responds with a 401 Unauthorized message. This doesn’t yet mean the call is denied — it's actually part of a normal process called digest authentication. The server is essentially asking extension 701 to prove it has the correct credentials before continuing.
To do this, the server sends a unique code (called a nonce) that the client must use to create a hashed password response. We can see this information passed inside of the 401 Unauthorized packet.
Extension 701 acknowledges (as we can see by the ACK response in the call flow) the challenge and sends another INVITE request, this time including the Authorization header. The header contains the username, nonce, and a hashed version of the password. This is the client’s way of proving its identity.
Ultimately, as we look at the call flow above, we know that this call ends in a series of 403 Forbidden errors. While I wasn’t able to get to the root cause of why this specific call failed, a few possible reasons include:
Authentication Failure:
- Even though the client responded to the challenge, the server may be rejecting the hashed password due to incorrect credentials or a mismatch with what it expects.
Dial Plan Restrictions:
- The server may have rules in place that block calls to specific destinations, such as international or premium-rate numbers.
Blacklisting:
- The server could have blacklisted either the calling extension (701) or the destination number (**********0344).
Regardless, this is good information and brings us to the next step in our analysis. Extracting SIP Digest Authentication messages with SIPDump.
Identification of Weak Extension/User passwords Used for SIP Authentication
As we’ve already covered, In the world of VoIP and SIP, every user that requires access to telephony systems are likely assigned a SIP account which contains the extension (username), password and address of the SIP server.
Thinking critically here, we can already start to formulate a potential attack vector (looking at you password guessing/spraying). Say an attacker successfully identifies an exposed SIP sever, given the usage of usernames (AKA extensions) and passwords as an authentication mechanism, it could be possible for an attacker to find default/weak username and password configurations.
A common misconfiguration here involves SIP usernames configured with no password at all (null password) or configured to have the username and password match. Both of these examples are easily discoverable.
With the provided Wireshark packet capture file confirmed to have contained multiple call flows with multiple authentication attempts, I used the tool sipdump to extract SIP digest authentications that occurred during the attack. By extracting the Digest authentications that were captured in the Wireshark data, we were able to obtain the MD5 Password Hashes for various SIP users. (Look there’s that user 701 again).
đź’ˇ
Pictured above is the output from running SIPCrack. We can see columns indicating the IP address of the client, server, username AKA extension and the user’s password hashes.
With these MD5 hashes collected, we then used the tool sipcrack to crack these MD5 Password hashes. It was actually possible to extract the clear text password for three SIP users. The passwords were the same as their respective SIP user, thus indicating weak and/or default configurations were in use which could be abused by an attacker.
We could confirm at least a few SIP accounts were simply configured to have the username/extension match the password. With this singular finding, it’s a fair bet to make that this might’ve been evidence of a larger problem within this SIP environment. From here we could already start to formulate some remediation tasks specifically targeting username and password combinations configured within this SIP environment.
Moving on, I also investigated the some traffic I saw going back and forth to the web application I could only assume was used to interact with or manage the SIP/PBX environment as a whole. References to this now-defunct software (DragonSuite) can be seen below:
Looking even further, we managed to find some unencrypted authentication requests where a user was logging into the application. Since the traffic wasn’t encrypted, we were easily able to pluck out the hashed password.
Throwing this hash into our trusty friend John the Ripper we quickly see that this user had a password of 1234.
So at this point we found that there were most definitely weak configurations regarding SIP usernames and passwords, and we also found weak passwords in use to access the application used to manage the SIP/PBX environment. Food for thought.
Lessons Learned
While my findings here didn’t necessarily halt the active attacks or indicate a definite root cause, the data within Wireshark definitely indicated that there were security concerns within this PBX system that needed to be addressed. While yes, default username/password combos were identified - using a defunct PBX solution likely didn’t help the situation. Ultimately, this exercise not only brought awareness to how some PBX systems could be misconfigured but also gave me a new and interesting learning experience.
