Solved Strange issues after PBX was hacked

Status
Not open for further replies.

GCIT

Joined
Aug 15, 2018
Messages
4
Reaction score
2
Recently, our SIP provider notified us of international calls that occurred overnight. We immediately locked down our extensions with stronger passwords and tighter PBX security per 3CX's online documentation.

We now do not see anyone using our extensions, but we do see constant attempts to authenticate from international IPs. I do not believe that anyone has any access to our extensions at this point. But, we are seeing strange issues with our incoming calls now. Sometimes when calls are coming in via our main line and are going to different departments via our IVR, 3CX does not show the actual caller ID information. Instead it shows the name of different employees from within our company, as if they are the ones calling. Also, sometimes, if someone within a department answers a call that has been routed to them, 3CX will show them on the line with two other employees within the company, when they are not, while also being on the line with the actual caller. Sometimes it will even show the recipient as the caller and the callee.

Additionally, it shows this same incorrect information within the 3CX call logs. When I check with our SIP provider, and view our call history, it shows as if our company is calling itself each time, which makes no sense to me. This was never the case before we had been hacked. I'm at a loss for what could be causing this, as little was changed outside of strengthening the extension passwords and changing the failed authentication protection attempts and the blacklist intervals.
 
Lock down your firewall to allow port 5060, 5061 TCP and 5060 UDP from and to your VOIP provider only.
 
Lock down your firewall to allow port 5060, 5061 TCP and 5060 UDP from and to your VOIP provider only.

I recently did exactly this and all dodgy authentication attempts stopped. I haven't had a single IP blacklisted since.

I would also do a run-through of every one of the settings in your installation to make sure it's what you expect, reset all extension passwords, change your tunnel password (if you're using an SBC), re-provision all of your endpoints and finally change the admin password.
 
I'm guessing this solution is out of reach if you have remote/stun users on their residential connection/dynamic IP.
 
I'm guessing this solution is out of reach if you have remote/stun users on their residential connection/dynamic IP.

Not at all. Just allow the traffic from those specific IP addresses as well. Most firewalls can allow for multiple IP sources. Just remember that if you get a call that the phone has suddenly "stopped working", there's likely been an IP refresh that you'll have to manage.
 
When one of these call happens, check the 3CX Activity Log. It will show where the call originates.
 
The logs show that it is coming from an internal extension when it is not. That's the issue. 3CX is not showing the correct caller ID on all calls, attributing some calls to internal extensions when it should not be.
 
Also, the information about locking down the ports is useful. That will be accomplished today.

But, the the issue that we need to resolve most urgently is the problem with the phantom calls and misattributed caller ID information. Has anyone experienced this in the past? I have no idea how changing the extension passwords would have caused this, and that is the only big step that was taken.
 
The logs show that it is coming from an internal extension when it is not.

It is one thing to be showing the caller ID of an internal extension, but does the log confirm that the call(s) originate from an internal IP assigned to that extension? If so, then it is not an external hack. It is one thing to be getting Direct SIP calls, or calls from an external extension that should not exist at a location (IP), and quite another if an internal set is somehow generating calls.
 
The fix for this was ridiculous. Somehow the user's mobile number was set to our main phone number and ring mobile simultaneously was enabled. When someone would call into any queue this user was in, it would immediately send them back to our main menu as it was dialing them back into the system, creating a loop. I have no idea why this was set this way or when it changed for that user. The issue is resolved.
 
When someone would call into any queue this user was in, it would immediately send them back to our main menu as it was dialing them back into the system, creating a loop. I have no idea why this was set this way or when it changed for that user.

If the user had their mobile call forwarded somewhere, then they should be aware of that. They should also be aware that calls to their 3CX extension also ring their mobile. It sounds like a reminder of what not to do, is in order.
 
Glad to see the issue has been resolved and thank you for updating the thread with your solution
 
Status
Not open for further replies.

Forum statistics

Threads
111,899
Messages
589,623
Members
164,765
Latest member
domi