Toll fraud: SipPhreak

While performing a routine check on one of our honeypots, a new, particularly large program file caught our attention: a 17MB PE (Portable Executable) file.

After analysis, we identified the file as being the complete distribution of PHP 5.3.5 for Windows bundled with a malicious PHP script. ESET detects this threat as PHP/SipPhreak.A.

The script acts like an ancient SMTP open relay scanner, but with a twist: it targets open or vulnerable SIP devices instead of mail servers. (Wikipedia defines the Session Initiation Protocol (SIP) as ‘an IETF-defined signalling protocol, widely used for controlling multimedia communication sessions such as voice and video calls over Internet Protocol.’)

This paper gives an overview of the malware’s infection vector and its installation procedure, followed by an analysis of the malicious script itself. Finally, an overview of the malware’s activity during the observation period will be presented.

The SipPhreak installer was collected from a machine infected with Win32/Peerfrag. We were able to determine that it was dropped by a secondary infection of the Win32/Restamdos trojan. Figure 1 shows the infection path.

Figure 1. SipPhreak infection source.

It is interesting to note that the Restamdos and SipPhreak command and control servers (C&C) and the SipPhreak installer location are all hosted on the same IP address located in Moldavia.

Figure 2. Source of the SipPhreak infection.

The SipPhreak installer is a self-extracting archive (SFX). These files are compressed archives that extract their content when executed. They are commonly used as legitimate software installers.

In the case of SipPhreak, the archive contains the entire original distribution of PHP 5.3.5 for Windows and two additional files: an unused batch file (start.bat) and the malicious PHP script (bc.php). The archive content is shown in Figure 3.

Figure 3. Content of SipPhreak’s self-extracting archive.

Interestingly, the author did not seem to care very much about the size of his malware. Several unused libraries, PHP modules and even documentation text files were left in the archive, contributing to its large size.

When executed, the SipPhreak SFX silently extracts its content to C:\windows\bc2. Once the extraction is complete, a pre-configured post-extraction command launches the malicious PHP script. Figure 4 shows the command used to start bc.php.

Figure 4. Auto-starting the PHP script after extraction.

Unsurprisingly, the code inside bc.php is obfuscated. All variables and function names are one letter long, and no new lines or indentations are present. A quick look at Figure 5 should be enough to convince you that the only thing you can expect from trying to understand this code (as-is) is a headache.

Figure 5. Obfuscated PHP code.

The first step towards getting a readable script was to use some sort of PHP formatter tool. We used a free online tool called PHP Formatter, which successfully added the missing indentation and new lines. But even when formatted correctly, the code was not exactly clear. We had to read through it and follow the control flow, changing the variable and function names to meaningful ones and adding comments along the way. We ended up with fully documented PHP source code (see Figure 6) and were finally able to discover all the malware functionalities.

Figure 6. Cleaned up source code.

The most interesting part of the code is the main loop, where the script waits for commands from the C&C. Figure 7 describes the five different commands available.

Figure 7. SipPhreak commands.

We can see that the malware is quite powerful: the ‘!’ and ‘~’ commands literally provide a backdoor functionality. However, during our observation period neither of these commands were used. The command most commonly observed was the ‘R’ command, used to perform a SIP scan on a range of IP addresses. The variety of parameters available for this command makes it quite flexible.

An example of a typical ‘R’ command sent by the C&C is shown below:

R 60 44207066xxxx 00,011 55 0 0 asterisk

An explanation of each parameter used is given in Figure 8.

Figure 8. ‘R’ command syntax.

Figure 9 shows the scan algorithm. In essence, every target IP is sent one INVITE per country code/phone number combination.

Figure 9. Scan algorithm.

Looking at the clean version of the PHP script also allowed us to analyse the quality of the source code. We would say that it is above average quality for malware code, with clearly separated functions, decent error handling and no debugging leftovers.

However, despite well-conceived source code, the script’s execution is not as stealthy as one would expect. The SIP scans are not throttled, meaning that the script can easily saturate the system resources by issuing hundreds of SIP requests every minute.

Once initialized, the malware first contacts its C&C to receive orders. With the exception of a few ‘$’ commands to customize the OPTIONS payload, all the commands received during our observation period were ‘R’ commands, issued to scan one or more IP address ranges (see Figure 7 for a description). Over time, the command was issued with quite a wide variety of country codes and phone numbers.

Figure 10. Country codes sent by the C&C.

Figure 11. Phone numbers sent by the C&C.

Researching these phone numbers yielded very few hits on Google. One of the few numbers we found was in a recent forum post by an unhappy PennyTel user who reported that his account had been compromised. At first he saw incoming probing with the phone number 44207347xxxx, followed by real communications established with various countries:

‘Last week, I had my account hacked. The attack started with some calls to UK number 44207347xxxx. A simple search on Google shows this number is associated with probing of asterisk type of VoIP systems. After the probing, some real calls were made to destinations such as El Salvador, Ghana, Haiti and Nepal.’ [1]

During the observation period we saw the C&C trying to scan approximately 4,000,000 IP addresses, with very few duplicates. As shown in Figure 12, the vast majority of these IP addresses were located in Germany.

Figure 12. Proportion of IPs scanned, by country.

During our investigation we intercepted traffic from infected hosts to the C&C server. Along with the IP, the specific SIP response code and the device’s User Agent string are reported. Figure 13 shows that one specific type of device, AVMFritz, was clearly prevalent.

Figure 13. Proportion of valid devices, by UserAgent string.

It is likely that this malware operation is the initial step in a broader toll fraud scheme. The idea is to find poorly configured SIP gateways that allow an attacker to connect to their SIP sites and then translate the calls to the PSTN network. The attacker can then initiate costly overseas calls or even call his own premium numbers (collecting the money directly), all at the expense of the device owner. The Australian Honeynet Project has published interesting studies in this area at HTCC2010 [3] and the Honeynet Workshop 2011 [4].

VoIP toll fraud is likely to become more popular as businesses continue to convert their telephone infrastructure to VoIP solutions. Way too often, we see news reports of incidents that cost small and medium businesses enormous amounts of money after switching to Internet telephony.

The hackers target any kind of organization, from a small charity in Flintshire in the UK that was hit for a few thousand pounds [5], to the Canadian law firm Martin & Hillyer, which received a $207,000 bill from Bell Canada for long-distance calls to Sierra Leone that its staff had never made [6].

In addition to toll fraud, organizations are also vulnerable to a range of targeted threats including industrial espionage, intellectual property theft and eavesdropping – all of which can result in far greater damage than toll fraud. Unsecured VoIP infrastructures can allow an attacker to gain full access to phone conversations, voicemails and more. Imagine the consequences if the attacker was your closest competitor.

It is imperative that businesses and individuals properly secure their VoIP infrastructures. If they do not have the expertise to do so internally, they should hire an external firm so as to avoid becoming another victim.