SANS Stormcast Tuesday, July 21st, 2026: More Wordpress Details; HOLLOWGRAPH MSFT Calendar Abuse; Gitea 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/10016.mp3

previous

More Wordpress Details; HOLLOWGRAPH MSFT Calendar Abuse; Gitea 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, July 21st, 2026
 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
 Industrial Control System Security. Well, yesterday I
 mentioned the WordPress vulnerability that had an
 exploit available and yes, was already actively exploited.
 Today I took the time to set up a vulnerable WordPress
 instance and a reader also suggested or sent me some logs
 that they collected about an actual exploit attempt using
 this WP2 shell vulnerability. We now also got a CVE number
 for the vulnerability 2026-63030. The initial advisory
 didn't include that yet. And with WordPress extensions, we
 usually don't get the CVE numbers. But again, this is a
 vulnerability in WordPress core. And like I mentioned, I
 set up a vulnerable instance myself, just going through the
 standard install instructions of WordPress without loading
 any special extensions. The instance was vulnerable. So
 there's nothing you need to configure enable or such in
 order to be vulnerable. As soon as the REST API is
 exposed, you are vulnerable. Now, a couple things about the
 exploit attempts that we have seen. They often use a very
 obvious user agent. So that would be a first quick fix
 here to try to filter these user agents, like the one that
 I wrote up here used the actual CVE number as a user
 agent. You also have things like WP2 shell test. That's
 often used by the scanning scripts that are looking for
 vulnerable servers. The standard actions that I've
 seen observed so far really fall into kind of two
 categories. The first one is just basic reconnaissance,
 basically checking if a particular instance is
 vulnerable. There are a couple of different things that
 attackers are doing. Some basically just send a very
 small sort of request just to see if they get a response
 back from the REST APIs. Others are then actually doing
 some SQL injection. So they're actually looking for the
 vulnerability and just retrieving some data from the
 database to check whether or not you're vulnerable. Well,
 once the recon returns the system is vulnerable, the most
 common thing that I've seen so far is that the attacker then
 installs a simple web shell. Now, the individual that sent
 me the actual attempt that they captured, they later also
 saw that the attacker added an admin account. It's not
 actually clear at this point if they use the vulnerability
 for this, or if they use the web shell in order to add the
 admin account to the system. The web shell is located in
 the cache directory for WordPress. And it's a very
 common technique in WordPress. WordPress sets up this cache
 directory and well based on nature of the directory, the
 web server must have write access to this directory. Also
 PHP code inside the directory is executed. And with that,
 well, you pretty much get a fairly straightforward place
 to write a file by dumping data from the database and
 then executing it. A couple of things about sort of no
 configuration options as such that may make WordPress here
 less vulnerable. MySQL by default doesn't allow you to
 write data into random directories or write data sort
 of into files at all. Now, when you're setting up the
 MySQL user for WordPress, the instructions just tell you,
 hey, you know, give it all privileges. There may be some
 ways to sort of further constrain that MySQL also has
 some global settings that constrain what directories
 files can be written to. I haven't looked deep enough
 into whether or not WordPress or MySQL for WordPress
 actually has to write to the cache directory or whether
 that's only done by PHP itself. So that's sort of one
 of the options you have. Now, from an incident response
 point of view, definitely check for new accounts being
 added to MySQL and then check this cache directory for any
 web shells that may be left behind by an attacker. And
 that may give you a little bit more insight as to what the
 attacker attempted to accomplish. If you're then
 looking at like, you know, web logs and try to figure out
 what commands possibly were sent to the web shell. Also,
 from an incident response perspective, don't just delete
 the web shell. Don't just remove the accounts. Well, you
 don't know what else happened in particular. There are lots
 of different web shells and you may not really have
 sufficient logging in your system to figure out what an
 attacker did. So as always, you very much should attempt a
 complete rebuild of the system. The interesting part
 here is the database, you know, how much of that you
 retain from the from the system. Because again, you
 know, there may be some settings that may have been
 altered or such that then amount to a backdoor. And
 Group IB has an interesting write up about malware they're
 calling HoloGraph. This malware takes advantage of the
 Microsoft Graph API that's been used for various
 Microsoft cloud products in this case, in particular
 calendars. So essentially uses calendar messages in order to
 essentially remote control your systems. The goal, of
 course, here is to sort of, you know, basically be below
 the radar and fit in with all the other calendar and
 Microsoft 365 messages that you may have in your network.
 We all know that we're using the tools and with that, of
 course, it can get quite difficult to police and really
 find some good metrics of to observe these messages. Even
 if you have the capability to intercept the messages can be
 difficult to really identify malicious ones. In this
 particular case, actually, yes, you can monitor these
 graph library calls, but there's also a simpler way to
 detect the infection. And that's DNS. The malware does
 not just use the graph API. It also uses DNS as a covert
 channel, in particular to exchange key material. And
 with that specific patterns in the DNS host names that are
 being requested. So that may be a little bit simpler kind
 of to write rules for than to go after the graph API. Of
 course, depending on how your network is instrumented. Let
 me have a new wall of Gitea. Gitea is sort of a little bit
 of GitHub lite that you can self-host. It's not just a Git
 repository, but also provides some CI/CD integrations. So
 if you want to have something that basically can be
 integrated in your development pipeline and provide some of
 these sort of functionalities that we usually get from
 GitHub, but you're unhappy with GitHub and rather have
 something self-hosted, that's your solution. Lately, I've
 seen a couple of critical vulnerabilities in GitI. So,
 Fikir, it's worthwhile mentioning that. As always,
 keep this software up to date. And this is also software you
 probably don't want to expose to the world. Well, and this
 is it for today. So thanks for liking. Thanks for
 subscribing. Thanks for recommending this podcast. And
 talk to you again tomorrow. Bye.