Hello and welcome to the Wednesday, March 19th, 2025
edition of The Sands and it's Storm Center's Stormcast. My
name is Johannes Ulrich and today I'm recording from
Jacksonville, Florida. Xavier came across an interesting
piece of malware that he's sharing in today's diary. The
malware itself arrives as a zip archive, nothing really
that special about it. It's called hootsuite.zip.
Hootsuite, I'm not sure if they're still around. It was
sort of a front end for Twitter. They had some issues
when their API pricing changed. But either way, it's
probably a well enough known company where some people may
open that zip file. Also, the zip file itself, at least at
first, doesn't appear to include anything malicious.
There is a legitimate PDF reader. There is a PDF. Now,
where it gets interesting is once you are starting the PDF
reader, The reason the attacker is sending you that
PDF reader is because this PDF reader is vulnerable to DLL
side loading. If it loads a DLL file, a library, it will
prefer the file in the local directory over the one in the
system directory. And with that, it's easy to replace a
system library with a malicious one. That's exactly
what's happening here. This then invokes a bad file. That
bad file will install a complete Python environment
because, you know, who needs to save bandwidth these days?
So, complete Python environment is being
installed. And then a malicious Python script is
being executed. Don't ask me why they don't just do
PowerShell because PowerShell is maybe too messy for them.
But so is Python. I would have installed Perl just for good
old times sake. But anyway, the PDF reader is also much
larger than the original. But there doesn't appear to be any
additional malicious functionality here. Looks like
they're just added additional sort of garbage at the end
here to push it beyond 100 megabytes in size, which will
then prevent some anti-malware solutions from scanning it.
And one listener reached out over X to point out a little
omission in the Wall Alarm blog post about the Tomcat
vulnerability I talked about yesterday. I mentioned, and
that's from the Wall Alarm blog post, that in order to be
vulnerable, you need to use a file-based session manager.
But in addition, as DKX here points out, you also need to
configure the default servlet to be writable. Neither one of
these two configurations is a default configuration. So
someone would have to specifically configure Tomcat
with these two options to be vulnerable. I have no idea how
popular or common these particular configurations are.
And Portsmaker did release a detailed blog post showing how
to exploit the recent Ruby SAML vulnerability against
GitLab. I think that's an important blog post. It does
fill in some of the holes left in the original announcement.
The problem with these SAML vulnerabilities is that
they're fairly abstract and the risk isn't always easy to
gauge of the export actually being used and being used
against your particular site or your particular
application. I think a blog post like this actually
walking you through the exploit development and how it
works in a specific case like GitLab here certainly brings
home the message that these are real vulnerabilities that
are actually exploitable. And Trend Micro's third initiative
published a blog post with details regarding a Windows
shortcut exploit that's already being abused in
numerous advanced persistent threat campaigns. Actually,
the blog post goes over some of the APT campaigns that have
taken advantage of this particular vulnerability.
However, Microsoft at this point has no plans to actually
fix it. And the reason is that, well, the nature of this
vulnerability is a little bit tricky. So the problem here
are the good old shortcut files, the .LNK or link files
that are typically supposed to be used to basically just
provide a convenience link to a particular piece of
software. However, as part of the .LNK file, an attacker can
add arguments to the command they link to. And these
arguments then, if you're creating your links right,
will be able to execute arbitrary code. Now, a user
may inspect the .LNK file. Just right-click on it and you
can see the content on it. And you should see these command
line arguments. So the user should have a chance, even
though I consider it a small chance, of actually
discovering the malicious exploit. That's sort of where
the actual nature of the vulnerability comes in. By
using, well, interesting combinations of white space
characters, it's possible for an attacker to sufficiently
obscure the actual command line arguments. And basically
push them off the screen so a victim wouldn't actually see
anything wrong when they're inspecting this file. In the
end, it comes down to, in my opinion, that it's a user
downloading and executing a piece of software that, well,
they basically received from an unverified source. Not
really all that different from just downloading and executing
a .exe file. Not sure how much the file being a link file
contributes the likelihood of the exploit actually working.
And I think that's a little bit here what Microsoft is
thinking about. I don't know. It's probably also a hard one
to fix for Microsoft compared sort of to the impact it may
have for the security of the overall systems. It shouldn't
be too difficult for anti -malware and such to basically
check whether or not link files are using any of these
specific characters. And, yeah, the other problem still
remains where a user may just download and click and execute
a link file without first checking the parameters. And
then, of course, that particular vulnerability
wouldn't really matter. Well, and this is it for today. So,
thanks for listening and hope you like it. If you like it,
please leave a good review at your favorite podcast site if
it allows for reviews or click the five-star, whatever it is,
link. So, thanks and talk to you again tomorrow. Bye.
