Hey there!

I was recently tasked with investigating large amounts of bandwidth being allocated to a few Microsoft domains. They were not being pesky, instead, they were noticed as having a lot of their content being served off of our HTTP object caches at remote sites.

The interesting domains that I was told about were:

• officecdn.microsoft.com
• *.tlu.dl.delivery.mp.microsoft.com

Combined, the domains were having an average of 6GB served from our cache every hour, at a remote site with around 1,000 users.

The cache log showed URLs like the following:

1
2
3
4
http://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60/Office/Data/16.0.8326.2096/stream.x86.en-us.dat
http://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60/Office/Data/MRO-E.cab
http://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60/Office/Data/v32\_16.0.8326.2076.cab
http://7.tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/6438c6f2-4888-4822-bc46-b67786fbfa1d?P1=1504224219&P2=301&P3=2&P4=DVe16MpJSOebZF9

The top file was generally the most frequently requested, and the one that was responsible for the majority of the data being served.

officecdn.microsoft.com

Doing a quick curl, we see that that file is roughly 1GB in size:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
09:17 xorcat@box ~ $ curl -I http://officecdn.microsoft.com.edgesuite.net/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60/Office/Data/16.0.8326.2096/stream.x86.x-none.dat
HTTP/1.1 200 OK
Content-Length: 1164510023
Content-Type: application/octet-stream
Last-Modified: Tue, 29 Aug 2017 09:37:21 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/7.5
Content-Disposition: attachment; filename=stream.x86.x-none.dat
X-Powered-By: ASP.NET
Date: Thu, 31 Aug 2017 23:18:05 GMT
X-CID: 2
Age: 3
Connection: keep-alive
Cache-Control: public, max-age=89854
Via: 1.1 akamai (ACE 6.11.1/6.11.0)

According to some brief Googling, the officecdn.microsoft.com host is used for what it appears to be: Microsoft Office.

Eric from Microsoft says:

Office update service runs as a scheduled task daily to check the Office 365 service, http://officecdn.microsoft.com/ for new updates. When the latest update is available, Office will schedule a time randomly over the next few days to download and install the update.

This only appears to be the case when Office is installed using “Click-to-Run”, the way it is generally installed in a non-managed environment.

So, it looks like the officecdn traffic is Office installations and updates which happen automatically, and are likely coming from the non-managed (BYO) machines on the network.

*.tlu.dl.delivery.mp.microsoft.com

Googling for this domain doesn’t give much solid information… You get a bunch of forum posts complaining about bandwidth hogging, and asking how to block the traffic:

markiejd asks:

Hi,

We have a site with a 100Mb link to the internet but some clients are swamping the connection going to http://tlu.dl.delivery.mp.microsoft.com/

I have checked that we are not sending out updates to anyone from the advanced tab of Windows update.

any ideas ?

And apparently, threatcrowd.org thinks the domain is malicious:

Hmmm. I think “the crowd” may have gotten this one wrong, but it still seems like it causes a bit of pain for some people.

Then I found this, an article from Kurt Mackie at MCP Mag, noting the tlu.dl domain as a server for Windows Updates as well as Microsoft Store installs and updates:

Organizations could have Windows Store applications installed. Windows Store apps typically will try to download updates at various times. They tap Microsoft’s URL known as “tlu.dl.delivery.mp.microsoft.com.”

Hang on, he also mentioned that there are some registry switches that, if enabled, will cause managed machines that should be getting updates from WSUS to reach out to Microsoft and get the updates from them:

Rasheed noted that the following registry values are intended for use with the Windows Update for Business service, but they will invoke the Microsoft Update service if used with WSUS or SCCM:

• DeferFeatureUpdate

• DeferFeatureUpdatePeriodInDays

• DeferQualityUpdate

• DeferQualityUpdatePeriodInDays

• PauseFeatureUpdate

• PauseQualityUpdate

• DeferUpgrade

• ExcludeWUDriversInQualityUpdate

WSUS or SCCM users wanting to regain control over Windows 10 client updates should verify that those Windows Update for Business values aren’t showing up in the Group Policy for Windows Update, Rasheed added.

Within that article, there is a link to a Microsoft Technet blog by Shadab Rasheed from Microsoft, which has quite a bit of interesting information, including:

Most of the customers may already have included the first two URLs but may not be aware of the 3rd URL, which is the CDN for Store App updates

This is referring to the above section, where the 3rd URL is *.tlu.dl.delivery.mp.microsoft.com

Based on that reading, it seems like Windows Updates should all originate from *.download.windowsupdate.com and, the more localised *.au.windowsupdate.com, unless of course the machines are correctly configured to use WSUS/SCCM.

Strange, I don’t seem to see *.windowsupdate.com in our cache logs though….

It looks like those domains are intended to bypass the proxy in our environment, as the proxy blocks both of these domains, and are (unusually for our environment) allowed to go direct through the firewall.

Unfortunately, the domains are not called out in our PAC file as go-directs, meaning that Windows is going to use the proxy for those requests, which will get blocked, meaning that non-SOE Windows machines will fail to get Windows updates at all while on the network (if their proxy is configured “correctly” or set to defaults).

There you go…

• officecdn.microsoft.com = Office365 installs and updates
• *.tlu.dl.delivery.mp.microsoft.com = Windows Store installs and updates

I’m always around on Twitter @XORcat, or on email at rzb@xor.cat.

Thanks!

XORcat