Author: Mike Manzotti – Senior Consultant
Introduction
As part of a red team assessment, I discovered a bug affecting the latest version of Microsoft Outlook for Microsoft 365 (which was version 16.0.13801.20240 32 bit and 64-bit at the time of the discovery). The vulnerability allows an attacker to spoof an arbitrary victim’s email address in a way that Outlook fetches and displays valid Active Directory details and the image of the impersonated user. When the victim receives the phishing email and sees a valid picture, the trust and validity of the phishing significantly increases giving an attacker more chances to successfully carry out a social engineering attack.
A proof of concept video is provided at the end of the article.
Although Microsoft acknowledged the vulnerability and communicated to us that they are not going to release a fix, I have discovered that the latest version of Microsoft Outlook for Microsoft 365 (which at the time of the writing was 16.0.14228.20216) is no longer vulnerable.
Technical Details
Following the reconnaissance phase, I quickly discovered that the target of the red team assessment is using Microsoft Office 365. With that information, I started to brainstorming ideas in order to execute a spear phishing attack. My intent was to impersonate someone within the organisation to steal credentials.
Since I could not actually spoof any valid email addresses because of the SPF records and SPAM protections (Exchange Online Protection), I decided to buy a punycode domain which was close enough to the target domain.
In short, a punycode domain contains a combination of ASCII characters which represents Unicode characters. To distinguish a traditional domain from a punycode domain, the latter has the prefix “xn--” to indicate the following characters are representing a Unicode string.
For the purpose of this blog post I refer to “onmicrosoft.com” as the target domain, since I had to replicate the attack for Microsoft, otherwise they would have not acknowledged my vulnerability. All the accounts displayed on this blog article are fake.
For this reason, I decided to buy the punycode domain “onmìcrosoft.com” which was available. Note that the domain includes the Unicode character “ì”. The ASCII representation of the onmìcrosoft.com is “xn--onmcrosoft-b8a.com”. When the punycode domain is used for example in the URL, the browser displays the Unicode character as shown below:
After experimenting for a while with Phemail, I discovered that I could send a phishing email which impersonates a valid Azure AD account ([email protected]) and displays valid image and Active Directory details, despite the fact the domain was not the target domain “onmicrosoft.com”, but instead the punycode one “onmìcrosoft.com”.
In other words, the phishing email targets the user [email protected]ìcrosoft.com, however, valid Active Directory details and image of [email protected]icrosoft.com are displayed as if the email was coming from a trusted source, as shown in the screenshot below:
After a bit of testing, I realised that this was possible because Microsoft Outlook for Microsoft 365 does not correctly validate addresses in the Multipurpose Internet Mail Extensions (MIME) from header. In fact, when you send an HTML email you can specify the SMTP “mail from” address, and the Mime “from” address.
This is because the MIME headers are encapsulated into the SMTP protocol. MIME is used for extending simple text messages, for example when sending HTML emails. This can be visualised in the following image:
Using the verbose option in Phmail it is possible to see the raw content of the email:
$ ./phemail.py -v -e targets.txt -f "test <[email protected]>" -F "[email protected]" -s "Test" -b body.txt -g username:password SMTP server: smtp.sendgrid.net send: 'mail FROM:<[email protected]> size=882\r\n' reply: '250 Sender address accepted\r\n' reply: retcode (250); Msg: Sender address accepted send: 'rcpt TO:<[email protected]>\r\n' reply: '250 Recipient address accepted\r\n' reply: retcode (250); Msg: Recipient address accepted send: 'data\r\n' reply: '354 Continue\r\n' reply: retcode (354); Msg: Continue data: (354, 'Continue') send: 'Content-Type: multipart/related;\r\n boundary="===============1484143720950262401=="\r\nMIME-Version: 1.0\r\nmail from: test <[email protected]>\r\nfrom: [email protected]\r\nsubject: This is a Test\r\nreply-to: \r\nto: [email protected]\r\n\r\nThis is a multi-part message in MIME format.\r\n--===============1484143720950262401==\r\nContent-Type: multipart/alternative;\r\n boundary="===============4769694584102690015=="\r\nMIME-Version: 1.0\r\n\r\n--===============4769694584102690015==\r\nContent-Type: text/plain; charset="us-ascii"\r\nMIME-Version: 1.0\r\nContent-Transfer-Encoding: 7bit\r\n\r\nThis is the alternative plain text message.\r\n--===============4769694584102690015==\r\nContent-Type: text/html; charset="us-ascii"\r\nMIME-Version: 1.0\r\nContent-Transfer-Encoding: 7bit\r\n\r\n<html>\r\n<body>\r\nThis is a test email.\r\n</body>\r\n<html>\r\n\r\n--===============4769694584102690015==--\r\n\r\n--===============1484143720950262401==--\r\n.\r\n' reply: '250 Ok: queued as 0mJ0q82oTL6110Zl_BCOVA\r\n' reply: retcode (250); Msg: Ok: queued as 0mJ0q82oTL6110Zl_BCOVA data: (250, 'Ok: queued as 0mJ0q82oTL6110Zl_BCOVA') Sent to [email protected]
Since Microsoft Outlook for Microsoft 365 does not correctly validate or verify the punycode domain, this attack can be abused to impersonate any valid contact in the target organisation.
This vulnerability was affecting the latest version of Microsoft Outlook for Microsoft 365 MSO at time of the discovery, which was version 16.0.13801.20240 32 bit and 64-bit.
It is worth noting that this attack fails, if the phishing email is displayed on a web browser accessing Outlook Web Access (OWA).
Proof of Concept Video
Below there is a proof of concept video. In the video I impersonate Nestor Wilke with the punycode domain “[email protected]” and I target “[email protected]”. Also, the video shows that I was the owner of “onmìcrosoft.com” and no special DNS settings were configured on the system.
Timeline
2021-03-11: Initial report sent to Microsoft.
2021-03-12: The vulnerability was rejected. Microsoft response: “It appears the email alias you are spoofing is within your own company, we would need proof on how you can do this to someone else’s account.”
2021-03-15: A second report was sent to Microsoft.
2021-04-14: Microsoft acknowledged the vulnerability.
2021-05-11: Requested an update. Microsoft response: “This is still being mapped out. Fixes usually take about 3-4 months as they test variations, compatibility, and regressions“.
2021-08-13: Requested an update. Microsoft response: “We’ve finished going over your case, but in this instance it was decided that we will not be fixing this vulnerability in the current version and are closing this case. In this case, while spoofing could occur, the senders identity cannot be trusted without a digital signature. The changes needed are likely to cause false positives and issues in other ways.“
2021-08-24: Discovered that the latest version of Microsoft Outlook (16.0.14228.20216) is no longer vulnerable, and requested a clarification to Microsoft if a specific fix was issued.
2021-09-01: Microsoft was unable to confirm.
2021-09-02: Vulnerability was disclosed to the public.