When we think of zero-days, what comes to mind are usually RCEs or other high-impact vulnerabilities. Zero-days, however, come in all shapes and sizes and many of them are low impact, as is the vulnerability we’re going to discuss today. What is interesting about it, apart from it allowing a sender of an e-mail to include/change a link in an e-mail when it is forwarded by Outlook, is that I noticed it being exploited in a low-quality phishing e-mail by what appears to be a complete accident.
The e-mail in question was fairly simple – it used a Covid-19-related lure and when “View details” was clicked, it would direct the victim to a phishing site. All of the text at the bottom of the message was filled with links that lead to the same site. Or was it?
Originally, a colleague of mine @MartinHubinek simply forwarded me the message and this was really the case – the “View details” button and the entire text area following it were links, which pointed to the following phishing URL.
I commented on the laziness of this approach on the part of the attacker, to which my colleague replied that although it is weird, the original e-mail actually looked different, with only some parts of the footer text being links, which pointed to Google and not the phishing site. After I looked at the original message, I had to admit that he wasn’t joking.
I forwarded the original message to myself again and the resulting e-mail really looked different – the entire footer text became filled with links to the same phishing URL.
After that, I started experimenting with forwarding only parts the original HTML content of the phishing message to determine what was causing this behavior and the reason for it soon became clear. It turns out that Outlook (at least in versions 2016 and Outlook for Office 365 – I would expect other versions do the same, but I didn’t have the opportunity to check them) will incorrectly re-write any HREF, which contains an empty IMG tag, or an IMG tag with empty SRC attribute. Basically, Outlook will modify the HTML code in such a way that content, which follows the original link, will be enclosed in a tag which points to the same URL as the original A tag.
In the case of our phishing message, the strange behavior was caused by the fact that there was an IMG tag with empty SRC attribute within the A tag, which specified the link for the “View details” button.
This behavior of Outlook is quite unfortunate, since it basically allows for sender of a HTML-formatted e-mail to cause new links to appear/existing links to change in the message when it is forwarded by the original recipient. When I noticed the vulnerability, I informed Microsoft about it, but since it is only a low-severity issue, they decided not to patch it.
Although, based on its contents, it is almost certain that the authors of the original phishing message didn’t know about this behavior and their creation “exploited it” only by accident, it doesn’t mean that a malicious actor might not do so intentionally. For example, one can easily imagine a scenario, when an attacker or a red teamer might want to send an e-mail with a content similar to the following one.
If we open such an e-mail, the link would point to the Internet Storm Center website, so why shouldn’t we forward the e-mail? The ISC is indeed a great infosec resource, after all… 🙂
If we forward the message, however, the link will change to point to a (literal) untrusted network. Although I hope that it may be considered a good infosec resource as well, it definitely wasn’t the place to which we intended to direct our friends when we forwarded the e-mail.
If you want, you may try this out yourself by downloading an example EML file I prepared from https://untrustednetwork.net/files/ISC/2020/example.eml and forwarding it to your own address.
Will this technique became the “next big thing” in phishing because the underlying vulnerability is not patched? Hardly. Is it good to know about it? Definitely – it was, after all, already used in the wild, even though it was only by accident…
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.