Trying to understand HTTP request containing base64 encoded part and email address

Question

I have public webserver serving static html pages and when analyzing error logs I found type of attempted GET that I don't understand.

They are formed like this and fail because request is too long:

/data=04|01|[email protected]|c2453b5a486d424d3cb508da0364a970|7c14dfa4c0fc47259f0476a443deb095|0|0|637826028838084502|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0=|1000&sdata=ZZ1oSGmGhS5

I found out that part starting with TWFpbGZsb3... is base64 encoded and decodes to Mailflow|{"V":"0.0.0000","P":"Win32","AN":"Mail","WT":2}.

These requests come from ips belonging to Azure datacenter.

Searching internet for this string shows several pages with nearly same or similar queries. What I find interesting is the part [email protected]. It is actually work email address of real person living in my country. But different name and organisation in each query. Persons or their organisations are not connected to my website in any way.

My webserver has no route starting with /data or anything else similar to to these queries. Email addresses of actual people caught my attention. Otherwise I would have considered these only as noise in the logs.

What might be meaning of these requests and why might they contain email addresses of actual people? Is it maybe an attempt to use exploit against some specific application?

Answer 1

These are parameters attached to URLs in Microsoft's Email protection service 'safelinks'. Normally these URLs take the form

https://<MS safelinks host>/?url=<original-url-reference>&data=<data-as-above>&<some-other-params>

Now what's meant to happen is that the safelinks service checks the URL in some way then redirects you to the unquoted version of url.

Why is this happening? Some theories:

• something is misconfigured at someone's mail server and email links are being rewritten to be sent to your server rather than the correct one
• something is horribly wrong both with DNS and clients' certificate validation and your web server is unwittingly impersonating safelinks.outlook.com
• some third-party service is poorly parsing links added to email and is following the URLs automatically but failing to strip out the safelinks data.