Using the Microsoft Outlook Auto-Complete feature for phishing

Years ago we have noticed strange behavior in some of our phishing engagements. In the phishing mails we were sending out, we usually added a “Reply-To” header. This allowed us to specify an email address where the replies on our phishing mail were sent to. Sometimes this is useful, because it allows us to retrieve information from the victim. It also gives the possibility to start communicating with the victim: as long as the victim believes he is communicating with the spoofed sender.

Huh, months later still retrieving sensitive information…

In some cases, strange behavior occurred during some of our engagements: we were getting company sensitive information, such as invoices, months after our phishing engagement was ended. Mails with sensitive information were sent to us continuously. Our first reaction: what is going on here?

After diving into this we quickly determined the issue. Whenever a victim replied to our phishing e-mail, our spoofed and faked email address was added to the victim Microsoft Auto-Complete list. The Auto-Complete list, is the list giving suggestions while composing an e-mail in Microsoft Outlook:

At that point of time we realized that this behavior can be quite an issue. If an attacker succeeds to get into the victims Auto-Complete list, this can be a sneaky way to exfiltrate company sensitive information or takeover the mail conversations. However, because it required the user to reply, we thought it was a functionality pretty hard to exploit and therefor left it at that time.

Starting to use the Microsoft products again a-lot!

Lately I started to use Microsoft products again, including the Microsoft Outlook 365 product on Mac OS X and Windows. During the usage of the products I noticed some behavior regarding the Auto-Complete list. Email addresses appeared in my Auto-Complete list; I was pretty sure I never contacted those email addresses myself nor replied to emails from those addresses.

This was a reason to investigate the behavior further: when are those email addresses added to the Auto-Complete list? It became clear that email addresses were added, just on retrieval of mails. This is pretty scary, as this would allow anyone sending you an email, to inject address into the Auto-Complete list.

After validating that it is possible to inject an address, multiple other questions popped up:

  • Which headers can be used to inject addresses into the Auto-Complete list?
  • What products are affected?
  • Is it possible to influence the order of the injected addresses? Getting above the real contact?

Due to the high number of products in the Microsoft suite using the Auto-Complete list, above questions had to be structured testing, as the behavior might be different per product. The following table contains the results of our the investigation:

From above list we can conclude that on most clients the behavior is the same. Usually all email addresses present in the From and the Cc header are automatically added to the Auto-Complete list. The only exception on this is the Mac OS X client, which does not add addresses in the Cc header, but does add email addresses present in the Reply-To header, which is pretty interesting because it this header is usually even harder to spot.

So, we can use the Cc (on OS X the Reply-To) to inject multiple addresses into the Auto-Complete list of a victim at once, by sending one email within the Cc all the spoofed addresses that we want to inject. This gives a malicious user the possibility to inject one or multiple look-a-like email addresses of known contacts by just sending one email to a victim. By trying to look-a-like the original contact email addresses as good as possible, it can be difficult to distinguish. One good trick to do this, is for example playing with capitals such as “l” and “I”, hard to spot differences: the domain and forsec.nI (capital i) almost looks the same in most email clients. It is even possible to buy the domain, to satisfy security checks such as SPF, DKIM and DMARC (disclaimer: please do not buy) ;-).

After injecting such an email, it’s waiting on the victim to craft an email to our fake address. To make our chances even bigger, I tried to influence the order of our injected address, with the main goal to get priority above the original address of our contact person. It became clear that Mac OS X is listening to this behavior and orders the list based on the recipient which sent the most emails to the victim (also Windows seemed to be partially doing this). This would mean: if we sent more emails to our victim than the original sender, we would overrule him and become the first suggestion of the Auto-Complete list. This increases our chance of receiving information.


What attack scenarios could be performed using this attack? The behavior can be for example used for social engineering attacks such as whaling. By impersonating a CEO and poisoning the Auto-Complete list of a CFO, the conversation can be possibly taken over. When the conversation is taken over, the CEO can request payments to the CFO to get financial benefit out of the attack.

Another idea would be to target multiple employees within an organization at ones. For example: target a lot of employee of a company at once by injecting a fake IT service desk email address through the Cc / Reply-To. Wait until some conversation can be taken over or confidential information is received. The goal might be to gain mailbox or network access.

Contacting Microsoft

I contacted Microsoft about the potential issue. At first, I was not sure is the finding would be marked as an issue or a feature. Adding the email addresses is a typical feature to increase the usability of Outlook, however such a feature has also effect on the security of the product. After contacting Microsoft, they confirmed they classify the functionality as a feature and not a bug:

“Our engineers have investigated this issue and determined that this behavior is working as intended, as this behavior is intended to cover cases when a user searches for or compose an email to someone you have never that you have never directly received mail from/someone not already in your contacts.”

It is understandable that Microsoft classifies this behavior as a feature and not as a bug. However, we think the feature should only be activated once an email is actually replied to instead of just adding email adresses on retrieval. Another idea would be to give the Outlook users the configuration option to only store the email addresses after replying.