BITS Downloading App updates from unknown endpoint

Copper Contributor



Our IDS started freaking out today because a large number of our endpoints started initiating BITS downloads to an unknown endpoint. My initial reaction was ransomware, but after further investigation it appears that these BITS downloads are updates for Windows Store Apps. I am making this post to confirm that these endpoints are actually indeed official Microsoft endpoints. The BITS requests I had seen were all for the Limelight Networks CDN (llnwd[.]net), which I have heard hosts content for a lot of MSPs, one of which being Microsoft.

Checking the logs, it appears that our workstations have never made BITS requests to this CDN. All previous BITS updates were carried out using official endpoints. 


The following are some examples of the domains seen in the BITS requests:

  • ic-c39e4900-0f7065-msftstoretlu19.s.loris.llnwd[.]net
  • ic-c39e4900-0d5ab5-msftstore19.s.loris.llnwd[.]net
  • ic-c39e4900-08b3f9-msftstore19.s.loris.llnwd[.]net
  • ic-c39e4900-0700f8-msftstore19.s.loris.llnwd[.]net


Although all my investigations point to these being official Microsoft endpoints, I am worried that a CDN is being used because a malicious actor could easily mangle the URLs to make them look like official Microsoft ones. 


Is this the correct place to confirm that the above sub-domains are official Microsoft, and if not where should I ask this question instead?



4 Replies

@Maximilian Demajo 


Hi - My IDS went off with the same alerts.  I'm still looking into the root cause - will check for Store apps across my network.  Thanks for starting this thread. Jason.

I found this - which appears to be a list of all the endpoints Windows 10 20H2  talks to ..


But if you read how they got this list, you realise Microsoft don't actually know all the endpoints they use - this was just someone in MS with a network scanner.




The following methodology was used to derive these network endpoints:

  1. Set up the latest version of Windows 10 on a test virtual machine using the default settings.
  2. Leave the device(s) running idle for a week ("idle" means a user is not interacting with the system/device).
  3. Use globally accepted network protocol analyzer/capturing tools and log all background egress traffic.
  4. Compile reports on traffic going to public IP addresses.
  5. The test virtual machine(s) was logged into using a local account, and was not joined to a domain or Azure Active Directory.
  6. All traffic was captured in our lab using a IPV4 network. Therefore, no IPV6 traffic is reported here.
  7. These tests were conducted in an approved Microsoft lab. It's possible your results may be different.
  8. These tests were conducted for one week, but if you capture traffic for longer you may have different results.




@JasonC2021 Thanks for checking this out. It appears that article does not contain any of the endpoints we are seeing, although it is dated. Unfortunate that they do not keep a complete list of contacted endpoints.


Have you noticed any further strange activity stemming from your devices since this started happening?


A bit worrying that I have not seen any further mention of these endpoints online

@Maximilian Demajo We are seeing IPS triggered due to a “virus” coming from one of these CDN’s. Only a certain number of devices, random, and they are blocked from download a 3D viewer app update that doesn’t appear listed on the apps page (that version). I’m concerned this is similar to a solarwinds style attack and can’t believe Microsoft would allow it. These should be pushed updates, everything is turned off for auto well anything and delivery opt. Is off as well.