UCM 6204 Hacked Analog Ports Outbound International Calls


Last month, there were several long distance calls we caught on our phone bill to Jamaica and DR. Luckily, the charges were not outrageous. But looking in the CDR, I see lots of entries like this:

trunk_1 200014142639500 VIDEOCONFERENCE[trunk_1] 2020-02-11 19:09:09 0:00:00 0:00:00

I have since locked web access to 2 workstations, and changed the admin password. So I will check the logs tomorrow to see if these entries persist.

I’d like figure out how these outbound calls are being made, and how the UCM was exploited in order to prevent future intrusions. I can’t find anything in the UCM referencing trunk_1. Also VIDEOCONFERENCE[trunk_1].

UCM has version firmware.


Hello Mr. Ken,

My client also experienced this a month ago because my client wanted to connect their gswave to their ucm (UCM6104) using port forwarding. Previously I had warned this to them because I had seen in the grandstream forum (before I joined this forum) and I saw the writings of Mr. Larry (Mr.@lpneblett) about the dangers of using port forwarding and it turns out what Mr. Larry (Mr.@lpneblett) said was absolutely true, but my client didn’t believe me. After my client’s ucm got hacked, I immediately told them to delete the port forwarding setting on their router (my client use mikrotik router). Until now my client cannot use their own gswave when they use cellular (4G).
Maybe you can communicate with Mr. Larry (Mr.@lpneblett) or someone else in this forum to solve your problem
Good luck Sir


Update firmware and set firewall on UCM


Hello Mr.Russell,
I also encountered this problem at the same time as you and we found out this could be stopped by input the correct pattern number in the inbound. The request is send from various IP targeted any system with “.” in the inbound to accept any syntax, you should try it to see if it help.


Tiennk has it correct - There is a newer version of firmware that specifically address the hack you reference. Please go to the firmware page and review the release notes and update as needed to get to the final version.

tin542211, the post mentions analog ports and it is not possible to change the inbound pattern to other than what it is as a default. FXO ports only react to the ring and do not care what the number looks like.


You should also make use of fail2Ban and could go ahead and whitelist IP-extension registration. Make sure you delete unused extension and have maximum registration to an extension is set properly. I have been a victim of this sometime back.


you first need to update the fw, but even more important to create the rules in ACL on the firewall.


@lpneblett, Exactly, these outgoing calls are using the FXO ports.
I’ll update the firmware today.
The UCM sits behind a router with a firewall which only has the 5060 port forwarded to it. Is there more firewall configuration beyond that?
I did disable the forward by pointing it at a non existent IP address, but these calls are still occurring, so I suspect they are not originating from the internet.
@Kzioliver, Fail2Ban has been turned on. As for “whitelist IP-extension registration” I can’t find anything that explains what that means. What will that accomplish? If I can find the settings, I can research what they do.

I greatly appreciate the suggestions for tightening the security for the UCM. However the question still remains. How are these calls being made?
I’ve went through every trunk, extension, and ring group looking for this trunk_1 and cannot locate it. I still don’t understand how and where these calls originate from.


I can only say that several have had the issue and that it was addressed by GS in their firmware release. As to how, the cause, etc., that was not made known and I suspect it was withheld so as to not reveal the details which might attract the attention of others who would possibly like to understand so that they too could see if they might be able to work around the fix or test the security more so.

Vid_conf and trunk1 are symptoms of the attack as logged in the CDR, but have nothing to do with what is visible from within the UCM Web GUI. It is a vulnerability that white-listing or F2B will not prevent.


This kind of attack happened when one of my colleagues, using GSWave, accepted a call from a random international “…bot”. From CDR, most calls originated from his extension and other extensions that existed in the UCM but had not been registered to any phone.

I whitelisted extensions,
Stopped Port Forwarding, you could try OpenVPN and advise I’m too scared to try:roll_eyes:
Stopped using GSwave,
Generated new passwords for extensions
While I may not be able to point out what exactly solved the problem, I didn’t experience it since, maybe someone found my PBX boring and discovered greener pastures… I don’t remember upgrading the firmware Immediately, but I shared that CDR file with a support guy, about 1000+ calls in 3mins!!
@DocuSystems to respond to your question,


as long as you continue to use remote extensions without VPN or ACL will be so.


Thank you.
Just wanted to update this.
I updated the firmware to .19, then .20. When I checked the CDR, I don’t see anymore new entries corresponding to the trunk_1 calls. I’ll check again tomorrow.
I just discovered that outbound calls to the FXO ports (1&2) aren’t working after the update. What changed in the firmware that would break outbound calls?
The message is “the number you have dialed is incorrect”. I’ve tried to dial local (7 digit) with area code (10 digit) and with 1 (11 digit). I haven’t changed my outbound routes. This is maddening. Trying to fix one thing and break another.


Create a new rule and put at the top of the list and try.


@lpneblett, thank you for helping!
I put a rule just for a local number _xxxxxxx, and set to National privilege, and set to my FXO trunk, and moved it to the top of the list.
Same result.
The CDR is essentially useless for troubleshooting this type of thing.


I would replace this with your local area code eg Australia Victoria has 035, 036, 038, 039 so I would place a rule that would encompass all of those by _03[5,6,8,9]xxxxxxx and also _[5,6,8,9]xxxxxxx <-- privilege set to local
That will work to make a call out on the trunk providing the trunk is in the route under the rules.


To dial using a regular handset, local calls are xxx-xxxx. I took the FXO1 port and connected a regular handset to it and dialed a number that way and it works. If I have a rule set up with _xxxxxxx wouldn’t it just push that same dialing pattern out to the FXO port?
My thinking is the rules were working before the firmware upgrade, so why would that change?
Just trying to understand what broke it.
I only have one area code here (US) so I changed it to _434xxxxxxx, dialed that way and it went through. So I tried to set it to _xxxxxxx and prepend the 434. result: “The number you have dialed is incorrect”. I’m absolutely certain this message is from the UCM, not my local phone company. What changed to not allow 7 digit dialing anymore?


do you need to dial 434 before dialling a local number ?
If not, what is the number range(s) start for local calls?


never mind - @lpneblett is lurking and will answer you… :wink:


If the dial string 434XXXXXXX worked, then assuming the UCM sent all 10 digits, then the provider apparently accepts same. While somewhat unusual, it could be that they will accept both the local area code in addition to the local exchange and number strings. Using the same analog handset, you should be able to dial the same exact number (10 digits and see if such is the case. What about long distance (1), does that work?

Out of curiosity what is the phone make and model and firmware version being used to dial such?
What you can do is to take a network capture at the UCM. This will show the messaging between the phone and the UCM so we can see that the dial string from the phone itself is correct.


There are several phones in play here which cannot dial out through the FXO ports. GXP2170 and DP-750 with DP-720 handsets. I also have a GXV-3370 on the system using SIP trunks to dial out with the FXO ports as the failover. The GXV-3370 dials out just fine, which I thought was unusual, possibly because it was using the SIP trunk.
I did get this one figured out, though. Since the “incorrect number” message was definitely coming from the UCM, not the analog provider, I looked harder at the dialing strings I was using for the SIP trunk. They were _NXXXXXX, _NxxNxxNxxx, etc. instead of _XXXXXXX, _XXXXXXXXXX. After I edited the dialing strings in the outbound routes to _NXXXXXX, etc. everything works as before.
I believe that the fix for the security problem I was having was to force dialing strings to be specified as numbers so that other characters would be rejected. It would have been nice if Grandstream had released this information in the firmware updates I applied as I had read through the Release Note trying to see if anything about dialing strings had been changed.
Thanks to all that chimed in on this, especially you, @lpneblett! Hopefully this post will help someone else.