Attackers are incentivized to cloak their attacks to avoid detection, keep attack chains alive longer, and make investigations more complicated.
One type of cloaking involves steganography, whereby an attacker embeds hidden data inside an otherwise innocuous file. For instance, an attacker might embed their malicious code inside an image file, not in an attempt to exploit a vulnerability in image parsers, but instead just as a convenient place to stash malicious data. That malware-laden image file may then be hosted anywhere that allows image uploads. There are plenty of such places on the public internet, because image file types are generally not considered dangerous.
In the recent Diamond Sleet attack, the attackers embedded the second stage of the attack as data inside of a PNG file and hosted that file on three unwitting web services, including the popular Imgur and GitHub services. The first stage of the attack code reaches out to one of three URLs, downloads the image, extracts the attack code, decrypts it, and runs the resulting malware.
When parsing the malicious PNG file, we see that the attackers got lazy– they shoved their data in the middle of the file after the end of its final IDAT chunk and before the IEND chunk.
In this case, the attackers didn’t bother formatting their attack as a valid PNG chunk; even though the malicious data is only 498,176 bytes long, the bytes 1518E13A at the front of the malicious content would suggest to a PNG parser to expect almost 354MB of data in the chunk.
But none of that matters to the attacker’s code — they don’t need to parse the file as if it were legitimate, they just grab the part of the file they care about and ignore the rest.
Developers of malicious browser extensions have been using this approach for years, because they learned from experience that the JavaScript files inside extension uploads get more scrutiny from browsers’ web stores’ security reviewers than the other files in the extension packages.
Defenders who want to detect hidden code can try to look for anything suspicious: malformed chunks, unknown chunk types, trailing data, and suspiciously inefficient files (e.g. much larger than the pixel count would suggest). But ultimately, there’s no way to guarantee that you’ll ever detect embedded messages.
A sufficiently motivated attacker could encrypt their malware and then encode it as legitimate pixel data (say, the “random” pixels of the stars in the sky) and there’s no way for a researcher to detect it without knowing the decryption routine. That said, finding an image’s URL inside a captured copy of the first stage or its network traffic is typically a pretty strong indication that there’s something malicious embedded in the file, because attackers tend not to bother downloading data they don’t need.
-Eric
text/plain 