Unwanted access

[templeben]

For the past few days, I've had email alerts about attempted calls to blocked countries (we lock down certain countires I know my users will never call).

On investigation, it seems someone has logged in to an extension and made about 100 calls over an 8 hour period overnight. Some have got throgh to countries we do call. I've changed the password on the account that was used, but on the second night, a different account was used. Our users use Office365 to login to 3CX and we leave the default 3cx password as is. I'm hoping I don't have to go thorugh all my extensions and change this if the default is not complex enough!! One of the accounts was a temp test account and I know the password was "Password12345!". We've now obviously reset all our test account passwords and wont be so lazy in future!!

Diagnosing how this happened seems to be really hard! I've searched throgh all the log files and finally found their IP address in the 3CX-tunnel log. We're on prem so I've blocked the network range on our firewall. IP whois said it was a home broadband pool of addresses. Second day, the IP range comes from different country and different ISP - again home broadband pool from a known ISP so I don't think NordVPN or the like are in use here.

I'm assuming they have just logged in to the 3CX web client and made calls as the logs say they calls were made from 127.0.0.1.

Anyone got any ideas what else I can do? The anti-hacking settings are all on the default. Nothing triggered the IP blacklist and failed auth protection is set to 2 attempts. Does 3CX log failed password attemtps? Just seems crazy I've got to sit here and wait for their next move!!! So frustrating I can't turn off non O365 logins which require 2FA.

We're on v18 debian update 9.

 

[SteveITS]

> home broadband

Probably, an infected PC being used as a relay.

See if this thread helps
Thread 'invalid CONSOLE login attempts not considered in IP blacklist ?'
https://www.3cx.com/community/threa...tempts-not-considered-in-ip-blacklist.119034/

Notably though “The anti-hacking module is for SIP attempts, not for web login.”

Does the office have IDS/Snort/Suricata in front of the server? That may help block attempts.

 

[templeben]

We have the admin console locked down to internal IPs. We do have IDS, but its not going to pick up what it thinks is legitimate web traffic. That link refers to the administrative console which I don't believe is currently being targetted.

So .. I just spotted my friend back on again. This time back on to the first extension that was compromised. I could see in the phones list that an app for andriod had logged in to this extension. I've changed the phone provisioning password now as I'm assuming they must have re-registeed with QR code.

Is there ANY log I can look at just to see how/what they are doing? I feel really blind - just waiting for more alerts about blocked countires. At least it seems quite a slow manual attack and we're not being used for multiple international calls at the same time.

 

[SteveITS]

The thread was more in reference to the anti-hacking settings not applying to web access.

If they set up an app, only changing the extension password won't disconnect them. Check the User and click the Regenerate button, and on the Regenerate Passwords dialog ensure "Regenerate provisioning file & QR Code for 3CX Apps" is checked, because it is not by default. (https://www.3cx.com/community/threads/outbound-call-hack.113999/)

If you set the Activity Log level to Medium that is a decent bump up in verbosity, and may help.

 

[templeben]

Thanks. I have my activity log on medium anyway. I did try verbose yesterday but with all my other 160 extensions it was just too chatty! I've regenerated everything as per your suggestion so hopefully that's killed it off for now.

Just really concerned I cannot look at any log to see if I'm still under some form of password brute force attack.

 

[SteveITS]

But you’re not seeing the events mentioned in that other thread?

Verbose is very verbose.

 

[imperator]

Don’t overlook the M365 side of this. If you use M365 for SSO there are very likely active/valid login sessions of the M365 accounts you have identified thus far. That’s important to realize if the M365 account was compromised, thus you’re still at risk. If a user’s home system was compromised you’re still at risk by the fact a valid M365 session token could have been leveraged and could still be useable - even without the M365 account itself being compromised by some malicious party knowing the password.

You should at the least revoke user access for those accounts in Azure / Entra to invalidate any active login sessions and unexpired tokens. This won’t reset the password or block the user from signing in again though. Personally, and to be extra safe, I would go further and reset the passwords for those accounts as well since you’re seemingly having a hard time tracking this down. You should follow either of those paths up with scrutinizing the activity log of the identified accounts in M365.

https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access

 

[templeben]

Thanks. I can rule out O365 on this occasion as both accounts in question have conditional access policies in place which prevent login from outside our trusted locations. I did also check O365 signin logs for any activity and there was nothing suspicious.

Since regenerating the accounts I've had no more logins as far as I'm aware. Nothing shows in the events log but then as far as I'm aware, this would only show password attempts on the admin console - not the user console.

Interestingly enough, last night I received an alert that an IP had been blacklisted and it came from the same ISP as my first breach. I can only assume they were attempting passwords and hit the hard coded 10 password limit. Hopefully this is the end of it - although I just wish I could review some logs to see who/what is still trying to access us! I really hope this gets addressed in v20!