Podcast Detail

SANS Stormcast Wednesday, December 17th, 2025: Beyond RC4; Forticloud SSO Vuln Exploited; FortiGate SSO Exploited;

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/9742.mp3

Podcast Logo
Beyond RC4; Forticloud SSO Vuln Exploited; FortiGate SSO Exploited;
00:00

Beyond RC4 for Windows authentication
Microsoft outlined its transition plan to move away from RC4 for authentication and published guidance and tools to facilitate this change.
https://www.microsoft.com/en-us/windows-server/blog/2025/12/03/beyond-rc4-for-windows-authentication


FortiCloud SSO Login Vuln Exploited
Arctic Wolf observed exploit attempts against vulnerable FortiGate appliances.
https://arcticwolf.com/resources/blog/arctic-wolf-observes-malicious-sso-logins-following-disclosure-cve-2025-59718-cve-2025-59719/

FrePBX Vulnerability
Horizon3.ai identified three distinct vulnerabilities in FreePBX. In particular, the authentication by-pass issue should be of concern, but default FreePBX installs do not use the vulnerable web authentication feature.
https://horizon3.ai/attack-research/the-freepbx-rabbit-hole-cve-2025-66039-and-others/

Podcast Transcript

 Hello and welcome to the Wednesday, December 17th, 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 Graduate Certificate Program in
 Cybersecurity Leadership. I want to start today's podcast
 not sort of with breaking news, but with an issue that
 has come up beginning of the month and is something that
 you probably should address early next year. So now is the
 time kind of to get ready and get organized to get this
 worked out. And that's Microsoft discontinuing RC4
 for all the occasion. Hopefully for your
 organization, this will be really a non-event. And the
 last version of Windows that did require RC4 was Windows
 Server 2003, if I remember correctly. So hopefully you
 don't have 20 plus year old systems around. But we all
 know it's easier said than done. And yes, sometimes these
 legacy systems are hanging around. So what Microsoft did
 in order to support this transition is that they came
 up with an extensive blog or website here beyond RC4 for
 Windows authentication that goes over some of the steps
 that you can take in order to make sure that you won't be
 affected once RC4 will at least by default be disabled
 for authentication with Active Directory. Now that turnover
 will be mid next year. So again, you still have some
 time. And what they did now to get ready for it was to enable
 additional logging in the security events that basically
 log what authentication mechanisms are used and what
 are available. If you do have one of the newers like AS and
 such available and you still use RC4, well, in this case,
 it may just be as easy as changing the particular user's
 password, which again, may not necessarily be easy. They also
 do provide PowerShell scripts to search your logs for any
 accounts that may need to be updated and set up an email
 address that you can use in case you're running into any
 devices or such that just won't work with RC4. If you do
 run into this situation, you can't really get this resolved
 by mid next year. There is an option to still manually
 enable RC4. So it's not that you're sort of left out in the
 cold here, but it's definitely something that you should
 address. And it's probably going to point you to a bunch
 of devices that you probably should have retired a long
 time ago. And well, this may be sort of the last push it
 takes to actually make that happen. So like I said, not
 breaking news, but something that you definitely should
 tackle. And beginning next year is probably when you sort
 of should have a plan ready and figure out how much this
 affects you. And last week I mentioned that Fortinet did
 publish a single sign-on authentication bypass
 vulnerability in its FortiGate devices. This affects any
 device that is using the FortiCloud single sign-on in
 order to authenticate. Arctic Wolf now says that they have
 seen active exploit attempts against this vulnerability. So
 you must get your systems up to date. Now, if you can't get
 them up to date, again, there is a workaround. You basically
 just disable the cloud-based single sign-on feature and use
 local authentication. And then you should be good here. They
 also point out that as part of these exploit attempts,
 attackers were then reading configuration files. As
 always, and we have seen this many times before, if a
 compromise like this happens, you must change all local
 credentials stored on the device. This may include any
 seats for multi-factor authentication. Not sure if
 that applies here in this particular case, but that's
 something that has sort of caused problems for people
 where then later they were compromised even though they
 had multi-factor authentication enabled. But
 the seats were not changed and as a result, the attacker was
 able to replicate the two -factor authentication tokens.
 And Horizon 3 published a blog post with details regarding
 three different newly discovered vulnerability in
 FreePBX. A couple months ago, we sort of had this fire trail
 where we hadn't already exploited vulnerability being
 patched in FreePBX. This research sort of evolved out
 of looking into this earlier vulnerability. So three
 vulnerabilities. Two of them are SQL injection
 vulnerabilities that could lead in the worst case to
 arbitrary code execution vulnerability. Similar to the
 prior exploit, the way this is exploited to actually achieve
 remote code execution is by actually using the SQL
 injection to add data to a ground job table that's being
 maintained in SQL and then is being used to periodically via
 cron launch various scripts. And if the attacker can add a
 script to that table, they have arbitrary code execution.
 Now, the newer version of the SQL injection vulnerabilities
 does require authentication. However, that's where the
 third and in some ways most critical vulnerability comes
 in. There is an authentication bypass vulnerability that can
 then be leveraged with these other vulnerabilities to gain
 unauthenticated full code execution. Well, the only good
 thing about this vulnerability is it's not exploitable in the
 default configuration. You need to send your
 authentication type to web server, which is not the way
 it's usually configured, but at that point, if you are
 vulnerable, it's exploitable by just sending a specific
 header. And with that, you essentially bypass
 authentication. So definitely get this patched. And even the
 authenticated vulnerabilities could be an issue depending on
 who you have authenticating to your free PBX server. Well,
 and this is it for today. So thanks for listening and talk
 to you again tomorrow. Bye. Bye.