Ars Technica was recently used to serve second-stage malware in a campaign that used a never-before-seen attack chain to cleverly cover its tracks, researchers from security firm Mandiant reported Tuesday.
A benign image of a pizza was uploaded to a third-party website and was then linked with a URL pasted into the “about” page of a registered Ars user. Buried in that URL was a string of characters that appeared to be random—but were actually a payload. The campaign also targeted the video-sharing site Vimeo, where a benign video was uploaded and a malicious string was included in the video description. The string was generated using a technique known as Base 64 encoding. Base 64 converts text into a printable ASCII string format to represent binary data. Devices already infected with the first-stage malware used in the campaign automatically retrieved these strings and installed the second stage.
Not typically seen
“This is a different and novel way we’re seeing abuse that can be pretty hard to detect,” Mandiant researcher Yash Gupta said in an interview. “This is something in malware we have not typically seen. It’s pretty interesting for us and something we wanted to call out.”
The image posted on Ars appeared in the about profile of a user who created an account on November 23. An Ars representative said the photo, showing a pizza and captioned “I love pizza,” was removed by Ars staff on December 16 after being tipped off by email from an unknown party. The Ars profile used an embedded URL that pointed to the image, which was automatically populated into the about page. The malicious base 64 encoding appeared immediately following the legitimate part of the URL. The string didn’t generate any errors or prevent the page from loading.
Mandiant researchers said there were no consequences for people who may have viewed the image, either as displayed on the Ars page or on the website that hosted it. It’s also not clear that any Ars users visited the about page.
Loading comments...
If you don’t want to hardcode your C&C server directly, as that may eventually get found and block, you instead hardcode an interim location (with fallbacks) where you will hide the URL of the C&C server.
That interim location should be a URL that will raise no red flags from monitoring software, where an obscured URL can be entered such that the first stage can read it and, importantly, where it can be subsequently edited in the future, if the C&C URL is compromised.
I’ll bet if the third stage were to lose contact with the C&C server, it would fall back to looking back at those first stage pages for an updated URL.
It's right here btw: https://purepng.com/public/uploads/large/purepng.com-pizzafood-pizza-941524644327twewe.png
You can safely load it, download it, whatever. The malicious part was appended after the .png with a ? and a string. It was the URL itself that triggered the malware. In theory any way of putting a URL onto a page would work. As Dan noted, on Vimeo they put it in the video description.
That kind of string is used in legit ways all over the internet, so there's no way to realistically filter for it. But you have to have already been infected for it to do anything, so in that sense the problem is downstream. Someone had to load the malware in some way in the first place.
Just to quote the third party research for an unbiased take:
We didn't do anything wrong, in the sense that nothing actually malicious was ever on Ars.
I'm going to use a horrible analogy:
It's like the old spy craft of taking out a classified ad in a newspaper, and someone knows to check for such and such job listing, and the salary range is the address of the drop spot.
The newspaper might has facilitated bad actors, but not because they were running classified ads wrong. The ad only meant something to the right people.
In the same sense the URL was only meaningful to someone infected. So there's kinda nothing for us to stop? In theory we could try and dedicate resources to not allowing this specific kind of attack in the future, but there's almost no point.
The picture itself didn't contain any malware, the URL itself encodes the payload. One does not need to contact the webserver hosting the image at all to get the payload, only read the URL from the Ars Technica page.
The image hosting site itself is likely benign. Someone found (or possibly stood up) a site that simply discards garbage text after an image URL without returning an error. That allows them to use that image URL as a way to insert arbitrary data into any website allowing image embeds, without raising any suspicions. The URL functions normally to serve up an image if you follow it, and URLs frequently have tracking or session or resource identifier garbage tacked on as part of normal use. So now you have a way to retrieve arbitrary text from a benign webserver without anything suspicious ever showing up in a log. Worst case, if someone gets suspicious of the image URL, they can try requesting it and get the image normally, enough to quell most suspicions if the URL was flagged up for some reason.
Nobody random with malware from a USB drive will be able to view malicious URLs in that way anymore here.