Podcast Detail

SANS Stormcast Tuesday, November 11th, 2025: 3CX Related Scans; Watchguard Default Password;

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9694.mp3

Podcast Logo
3CX Related Scans; Watchguard Default Password;
00:00

My Next Class

Application Security: Securing Web Apps, APIs, and MicroservicesDallasDec 1st - Dec 6th 2025
Network Monitoring and Threat Detection In-DepthOnline | Central European TimeDec 15th - Dec 20th 2025

… more classes


It isn’t always defaults: Scans for 3CX Usernames
Our honeypots detected scans for usernames that may be related to 3CX business phone systems
https://isc.sans.edu/diary/It%20isn%27t%20always%20defaults%3A%20Scans%20for%203CX%20usernames/32464


Watchguard Default Password Controversy
A CVE number was assigned to a default password commonly used in Watchguard products. This was a documented username and password that was recently removed in a firmware upgrade.
https://github.com/cyberbyte000/CVE-2025-59396/blob/main/CVE-2025-59396.txt
https://nvd.nist.gov/vuln/detail/CVE-2025-59396


JavaScript expr-eval Vulnerability
The JavaScript expr-eval library was vulnerable to a code execution issue.
https://www.kb.cert.org/vuls/id/263614

Podcast Transcript

 Hello and welcome to the Tuesday, November 11th, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Master's Degree Program in Information
 Security Engineering. Today's diary is about an odd username
 that I spotted in our honeypod logs. The username is ftp
 underscore 3CX. Now, the 3CX part likely refers to the
 maker of business phone systems 3CX. A couple of years
 ago, they sort of went through the news for being the victim
 of a big supply chain attack. But what we are seeing here is
 likely unrelated. I did, of course, do a quick search
 trying to figure out is this some kind of default username,
 maybe going with a default password. Doesn't look like
 it. And actually 3CX, their product does not really come
 with an FTP server. And our honeypod actually is looking
 for Telnet and SSH credentials. So we are
 actually not emulating FTP. I believe what's happening here
 is that if you're using these business phone systems from
 3CX, one of the options you have to create backups is FTP.
 And they're talking to documentation about setting up
 an FTP server that will receive these backups. So
 again, the product itself doesn't come with an FTP
 server. It's something that you're setting up separately.
 And they're offering a couple popular sort of FTP server
 options here and walking you through how to set them up
 correctly. But there are a couple issues here. First of
 all, that the username, well, people are likely going to use
 a username related to the product. There is a comment
 here to the diary by Stephen, who says, well, it's just
 human nature to use names like Stephen is using, for example,
 Veeam, like Veeamuser, Veeambackup and such. If
 you're using Veeam here for 3CX, why not using FTP
 underscore 3CX? The documentation actually uses
 3CX FTP user. So that's a variation of that particular
 username. Similar, the passwords that we are seeing
 being attempted for this user are also sort of 3CX related,
 likely preying on users that are essentially a little bit
 lazy in picking strong passwords. So this is not a
 case where a vendor would pick this weak password for you.
 This is users making that mistake. Very plausible
 explanation here that this is just human nature. What's a
 little bit bothering me or interesting to me is how do
 attackers pick those particular names? And I
 suspect that maybe they found usernames and passwords like
 this in other breaches that they came across and figured,
 hey, you know, we breached a couple of small business
 networks and such that ran the small business voice or IP
 system. And they all use the same usernames and passwords.
 Let's see, you know, who else does that? That's, I think,
 sort of where some of this may be coming from. Be careful
 with your username and passwords. Pick at least a
 random password. And actually, for a case like this, no user
 will actually ever really type these in. These are stored in
 some configuration files. It's not that wrong, really, to
 just use a random username as well here. And also make sure
 that, you know, yes, FTP, not a great protocol. But if
 you're using FTP for backups, that this user then does not
 have access via SSH and Telnet. So that way, if
 someone spots that password on the network, they're not able
 to actually log in and get a shell easily with that
 password. And we've got an interesting issue here around
 default usernames and passwords with WatchGuard
 Firebox devices. Now, the issue here is a default
 password for SSH. SSH is listening on port 4118. So not
 on port 22. And the default credentials are admin as
 username and password read -write. This was apparently
 assigned a CVE number 2025 -59396.
 However, WatchGuard does actually mention this
 configuration in their manual and suggests administrators to
 change it. Don't know. I like that. Don't know if I think
 this should be assigned a CVE number. NVD apparently doesn't
 think this is supposed to receive a CVE number because
 they ultimately rejected this particular CVE. Interesting
 converse around this. But in my opinion, there shouldn't be
 a default password select. Apparently, newer versions of
 WatchGuard Firebox firewalls do not contain or use this
 particular default set of credentials. So there is a
 patch for a vulnerability that never existed in some ways.
 But yes, definitely, if you're running WatchGuard, be aware
 of this issue and double check that your administrators
 changed this password or at least disabled access to the
 account. And then we got an interesting, vulnerable
 JavaScript library for a change, not an obviously
 malicious one. This is expr -eval. expr-eval is intended
 to be used to evaluate math expressions. Now, you could
 use the JavaScript eval function, but everybody knows
 eval is just one letter away from evil and is a function
 that should be avoided at all costs in any language, not
 just JavaScript. Because if you are executing strings,
 there's always a chance that some malicious command slips
 through. Well, that's what expr-eval is trying to avoid.
 They're trying to constrain the eval function to just
 mathematical operations where this is sometimes quite
 useful. But apparently, well, they didn't get it quite
 right. And this update now is fixing an issue where someone
 could slip through some commands. So definitely keep
 it updated. And if you're doing NPM, NPM will help you
 actually figure out if you are running this particular
 libraries on NPM audit. It should be able to detect a
 vulnerability and then also offer the ability to patch it.
 Well, and this is it for today. So thanks again for
 listening. Thanks for liking and subscribing to this
 podcast. As always, special thanks for leaving any good
 comments with your favorite podcast platform. Then that's
 it for today and talk to you again tomorrow. Bye.
 Bye.