SANS Stormcast Tuesday, April 14th, 2026: EncystPHP Webshell; CPUID Compromise; OpenAI Mac Cert Issue; Axios Vulnerability

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

previous

EncystPHP Webshell; CPUID Compromise; OpenAI Mac Cert Issue; Axios Vulnerability

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Tuesday, April 14th, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Stockheim, Germany. And this episode is brought to you by
 the SANS.edu Graduate Certificate Program in
 Cybersecurity Leadership. Today I wrote about scans for
 an Encyst web shell that we observed. These are often done
 as a follow-up to then scans for FreePBX vulnerabilities,
 but also, well, just as parasitic scans looking for
 already installed web shells. Fortinet wrote about these
 particular web shells back in January, but we have just seen
 sort of another scan for them. Fortinet also observed them
 being used against free PBX systems. So if you're running
 free PBX, you may want to take a look at some of the
 indicators of compromise or such for this particular web
 shell. Now, what makes it a little bit more tricky to
 detect is that it replaces existing files. So you won't
 really see necessarily new files that are doing a good
 job in sort of fitting in on the system. They are, however,
 at least the scans that I've seen adding a number of
 additional accounts to the system. So if you're just
 checking your /etc/password file, you may see these
 specific accounts with their preset passwords defined as a
 part of the attack. This particular web shell does use
 a password. Now the password parameter is called MD5, but
 it's not an MD5 hash necessarily that's being sent
 here. In the example I've seen it had the format of an MD5
 hash, but the string is just compared in the web shell. So
 they could basically use any string, but yes, the password
 is then in the source code. So if anybody would see some of
 these scans like I did, and then download the particular
 web shell this attacker is trying to deploy, well, you
 would have access to the password. So it's not that
 unlikely that attackers are looking for again, pre
 -existing web shells sort of in a parasitic fashion. Well,
 then we have sadly another major website compromise. This
 time the website of CPUID was compromised and Trojan copies
 of their very popular tools like Perfmon and such were
 offered via links on their site. According to a post to X
 that was done by one of the developers of CPUID. The
 website actually itself was not compromised in the sense
 that the file integrity did not change, but the attacker
 was able to inject links to the malicious versions of the
 tools. There's also a good write-up by Kaspersky on their
 secure list site about this incident. They analyzed the
 malware and essentially the malware itself was, well,
 first of all, a valid copy. of the respective tool that you
 would have downloaded from the actual site. But then they
 added a malicious DLL that was side loaded into the tool. And
 as a result, it would then execute the malicious code.
 Sadly, the CPUID.com website, as far as I can tell, has so
 far really nothing on their site noting this incident.
 Also nothing on the official CPUID X account. The only
 reason I sort of mention the post on X was that, well, it
 got sort of verified by Kaspersky, VXUnderground and a
 couple of others have verified that yes, indeed malicious
 code was distributed via the CPUID website. So if you have
 downloaded any of their tools over the last few days, then
 please double check that you didn't get infected by this
 malware. And as a result of the Axios HTTP client library
 compromise, OpenAI now has to re-release its macOS
 applications. The problem here is that GitHub workflow that
 OpenAI uses to build these macOS applications used a
 compromised copy of the Axios HTTP client library. As a
 result, any secrets that workflow touched may have been
 at risk and, well, one of the secrets here was the secret
 key used to sign these applications. So as a result,
 they're rolling certificates and now you must download the
 new applications signed with the new secret key and
 certificate because, well, the old one will be revoked. And
 sticking with the Axios library here for another
 story, there's also a new vulnerability in that library
 that you may want to address. And this one is kind of an
 interesting vulnerability. It allows basically to inject
 headers, which can then particularly in cloud
 environments, which of course are often used for this kind
 of application. It can be used to basically steal metadata
 service data from your cloud virtual machine. And that of
 course can then lead to a full system compromise, which is
 why this is rated as a full 10 on the CVSS scale. Overall,
 this is something that there are workarounds available and
 they go over these workarounds in the advisory. Essentially,
 you have to make sure that any headers you're setting don't
 sort of have this HTTP response splitting pattern
 with new lines embedded in the header value. That's kind of
 what sort of triggers this particular vulnerability.
 Interesting vulnerability, I find definitely even if you're
 not using Axios, but you are sort of creating HTTP
 requests, dealing with HTTP requests, maybe worth just
 looking at the advisory. Well, and this is it for today.
 Thanks for listening. Thanks for liking and subscribing.
 And always thanks for recommending this podcast to
 others and leaving good reviews and talk to you again
 tomorrow. Bye.
 Bye.