Podcast Detail

SANS Stormcast Monday, April 28th: Image Steganography; SAP Netweaver 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/9426.mp3

Podcast Logo
Image Steganography; SAP Netweaver Exploited
00:00

Example of a Payload Delivered Through Steganography
Xavier and Didier published two diaries this weekend, building on each other. First, Xavier showed an example of an image being used to smuggle an executable past network defenses, and second, Didier showed how to use his tools to extract the binary.
https://isc.sans.edu/diary/Example%20of%20a%20Payload%20Delivered%20Through%20Steganography/31892

SAP Netweaver Exploited CVE-2025-31324 
An arbitrary file upload vulnerability in SAP’s Netweaver product is actively exploited to upload webshells. Reliaquest discovered the issue. Reliaquest reports that they saw it being abused to upload the Brute Ratel C2 framework. Users of Netweaver must turn off the developmentserver alias and disable visual composer, and the application was deprecated for about 10 years. SAP has released an emergency update for the issue.
https://reliaquest.com/blog/threat-spotlight-reliaquest-uncovers-vulnerability-behind-sap-netweaver-compromise/
https://onapsis.com/blog/active-exploitation-of-sap-vulnerability-cve-2025-31324/

Any.Run Reports False Positive Uploads
Due to false positives caused by MS Defender XDR flagging Adobe Acrobat Cloud links as malicious, many users of Any.Run’s free tier uploaded confidential documents to Any.Run. Anyrun blocked these uploads for now but reminded users to be cautious about what documents are being uploaded.
https://x.com/anyrun_app/status/1915429758516560190

Podcast Transcript

 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.