Hello and welcome to the Monday, April 28th, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich and today I'm recording from
Jacksonville, Florida. Well, this weekend we had two
interesting diaries that sort of played on each other.
First, Xavier talked about a piece of malware that encoded
an executable as part of an image. This technique, usually
called steganography, does essentially adjust the value
of individual pixels in order to encode the particular
binary that's supposed to be either exfiltrated or in this
case infiltrated. So it's more here about bypassing network
defenses. The initial download malware is actually encoded
using Unicode characters. Very common, as Xavier points out,
in order to make reverse analysis a little bit more
difficult. But then the real interesting part is the
steganography part where the attacker sort of extracts the
binary from individual pixel values. Often, lately, I've
seen steganography being used to refer to where an attacker
just appends data to an image. In my opinion, that isn't
really sort of what steganography is all about
because the data is still clearly readable.
Steganography usually just means making these sort of
subtle adjustments to existing files in order to hide that
there is any additional data present. And then the second
diary this week was from Didier. Didier, of course,
famous for his Python scripts that analyze malware. And
Didier is walking us through how these tools can be used to
analyze a piece of malware like this that hides data in
an image. The first tool that Didier is using is his PNG
dump tool. PNG is a compressed file format. So, in order to
get the raw pixel data that you need here to extract the
actual hidden data, you need to first decompress the image.
And, well, that's exactly what Didier's tool does. And then
you can use additional tools to look at the output binary
data to then extract the individual pixel values that
matter in this particular case. Of course, every sort of
steganography tool uses slightly different techniques
here. And you need to adapt the post-processing to match
whatever steganography tool is being used. There's also
sort of no generic way to figure out if an image does
contain additional data. If an attacker uses a standard tool,
then, yes, there are tools that will figure out that one
of those standard tools are being used. But, again, they
could make small variations to these standard tools. And then
any alteration like this goes undetected if you don't know
what the original image looked like. Well, and then we have a
critical and somewhat messy, sadly, security issue around
SAP's NetWeaver. Sort of started, at least to become
public, with a blog post by ReliaQuest. ReliaQuest did
basically state that, yes, there is a vulnerability in
SAP's NetWeaver and it's actively being exploited. Now,
this was initially sort of published as a Sereday, as an
unpatched vulnerability, and rightfully so, because there
wasn't really sort of a patch necessarily available for this
issue. The problem itself here comes from the NetWeaver
Visual Composer, which is actually a tool that has been
deprecated about 10 years ago, but apparently is still
enabled. There is a file upload endpoint here being
exploited. And this file upload endpoint can be used to
upload arbitrary files without authentication, which, of
course, may include web shells. And then these web
shells can be used to gain full access to the system. So
the CVE associated with this vulnerability has a CVSS score
of a perfect 10. Now, where it gets a little bit messy is
sort of the SAP response. First of all, I don't have
access to the SAP security advisory. I've only seen it
being quoted. It's only available to customers.
Apparently, on April 8th, SAP did release an advisory
regarding this issue. And late last week, they did publish
then also a patch for it. As far as the advisory goes or
what you can do other than patching, well, you can
disable the vulnerable components. And that appears
to be a wise decision. In this case, again, this tool has no
longer been supported for quite a while. But the SAP
disputes that this vulnerability is already being
exploited. ReliQuest stated they have seen exploitation.
Also, Onapsis, a company that deals with ERP security,
stated they have seen exploitation of this
particular vulnerability. And according to some press
reports, watchTowr also reported seeing at least
exploit attempts for this vulnerability. Given that the
vulnerability is now public, it's not terribly difficult to
exploit. Definitely do expect exploitation of it. Do treat
unpatched, exposed system as compromised. And late last
week, Any.Run, a company that automatically analyzes
malware, published on various social media channels that
they had some issues with false positives in MS Defender
XDR. Now, it wasn't actually Any.Run that had the problems.
It was their customers. Any.Run does run malware in containers
in virtual machines and then automatically creates reports
as to the behavior of whatever software you uploaded. The
problem is if you're using Any.Run's free tier, which many
users are using, then these reports are public. And due to
this false positive issue in MS Defender XDR, they received
a large number of basically false positives. So valid
documents with, in part, confidential data. Like I
said, this is not just an Any.Run issue. I've seen
similar things with VirusTotal. In VirusTotal,
it's a little bit different. You usually don't sort of get
a lot of details about the documents. But if you do have
paid access to VirusTotal, you usually can download any
document other users have uploaded. So whenever you are
uploading documents to a system like this, in
particular free systems, assume that they will become
public. And do not just blindly upload anything that
you think that might be malicious. I've seen some
organizations that upload like all attachments to VirusTotal.
Seen lots and lots of interesting documents being
uploaded there. So be careful if it's likely malware. If it
has no personal critical information in there, then
yeah, sure, it's okay to upload it. But be careful
about this. Again, there's a good reminder here what may
happen. Well, and that's it for today. Thanks again for
listening. Thanks for subscribing and liking this
podcast. And yeah, talk to you again tomorrow. Bye.
