PHISHING CORPORATIONS
Lost in Translation?
How I managed to potentially trick software and humans by discovering and exploiting a weird bug in the Address Book component of Microsoft Office for Windows.
I recently discovered a vulnerability that affects the Address Book component of Microsoft Office for Windows that could allow anyone on the internet to spoof contact details of employees within an organization using an external look-alike Internationalized Domain Name (IDN).
This means if a company’s domain is “somecompany[.]com”, an attacker that registers an IDN such as “ѕomecompany[.]com” (xn--omecompany-l2i[.]com) could take advantage of this bug and send convincing phishing emails to employees within “somecompany.com” that used Microsoft Outlook for Windows.
How did I go about exploiting this bug?
I started researching about IDNs and their impact on everyday software a little while ago with this awesome tool shared by Simone Margaritelli on GitHub called ditto.
ditto allowed me to list out all available look-alike domain names that I could register. While I was looking for hosting infrastructure, I looked at options that I had on the table, 2 hosting providers clearly stood out:
- gandi.net
- domains.google
I chose domains.google for 2 main reasons:
- Registering domains on Google is easy. Google offers a 14-day trial for Google Workspace. This would allow me to run a 10-working day phishing campaign free of cost.
- I could use Google’s infrastructure to send my phishing emails.
After registering the domains on Google, I waited for a good whole month before I started using some of the domains.
I registered an email address that looked like my own organization email address and sent myself a test email to distinguish what factors in the email stood out as suspicious. What differed between my organization domain and the phishing domain was a Cyrillic “s” at the start of the domain name. To my surprise, out of all the applications and Operating Systems I tested against, Microsoft Outlook for Windows made my email seem quite legitimate. The only change I needed to make was the Sender name which can be easily done in Gmail settings.
A simple way to get the format of the Sender name is to simply wait for the major holiday period where people usually have automatic replies set for all emails within and external to the organization.
An email originating from my actual organization email would look like the screenshot below. Note that Address Book resolves the sender information as an actual contact with a display picture and contact details in the organization.
Using the IDN I registered earlier, I sent an email from Gmail and the email looked like the screenshot below. To my surprise, in this case as well, Address Book matched the IDN to my internal organization email contact details.
As you can see, not much stands out between the two emails apart from small details like the Sender label, the time, and minor text formatting. A first glance at these emails is not enough in this case.
Zooming into each of the email Contact details from above we can see that Microsoft Outlook recognizes the character difference. However, Address Book still resolves the contact information in both cases.
Searching for the phishing email address I used before in Address Book reveals my organization contact details in the search results as shown below.
Following is the message header for the phishing email. The Header of the message has the punycode representation of the IDN.
I decided to report this bug to Microsoft. Microsoft wrote back confirming that the bug exists however, they decided against fixing the vulnerability in the current version.
Microsoft stated in their email that, “In this case, while spoofing could occur, the sender’s identity cannot be trusted without a digital signature. The changes needed are likely to cause false positives and issues in other ways.”
I am yet to figure out what other features may be affected by IDNs within Microsoft Office for Windows. This vulnerability goes to show that sometimes software could also be tricked by “look-alike” domains just like the Humans that use it! 😆
How could one defend against such attacks?
- Labeling emails as external to the organization may be the first line of defense against this attack. This ensures that the recipient of the email knows when they receive external emails.
- Additionally, as Microsoft suggests, email signing could be employed to protect internal organization emails from spoofing attacks. Companies affected should employ the Trust Center feature to digitally sign emails by default.
THANKS FOR READING! Feel free to reach out if you find other cool stuff with IDNs!
UPDATE - Sept 7th 2021:
I forgot to mention this before in the article, replying to the phishing email that originates from the IDN does not reveal the punycode. The only significant difference in the case of an email reply is that the user’s profile picture does not show up. It still will not raise concerns since the contact card contains all other organizational information about the impersonated employee.
Additionally, since the bug affects Microsoft Office for Windows, the IDN email also displays the user’s Microsoft Teams presence (the green check bubble near the profile picture in previous emails) which adds a touch of authenticity as well.
Another Potential Mitigation:
Client side email rules would also work in this case. Employees can create a simple email rule to move all emails originating from external domains to another folder.
