Local RDP sessions call Microsoft?

[SamirD]

I noticed this in resource manager under network when looking at the network activity when connecting via rdp to a system in an ipsec vpn wan (point-to-point ipsec tunnel and system is on the other end of tunnel)--mstsc and lsass seem to briefly connect to microsoft or some other network that's probably also connecting to microsoft.

Just now when I tore down and reconnected to the system I'm typing on now:
Image PID Address Send (B/sec) Receive (B/sec) Total (B/sec)
lsass.exe 560 vip0x008.map2.ssl.hwcdn.net 30 5,240 5,270

This IP resolves to StackPath LLC. Other IPs I've noticed today are 23.59.155.80 and 13.107.4.50.

Just curious what this is all about since these connections are essentially being initiated and connected to within two different subnets on a LAN with no domains, AD, etc.

Any ideas welcome.

 

[Eulogy]

23.59.155.80 isn't a MSFT IP, and StackPath LLC isn't MSFT (if it was, it'd be in Azure, not RackSpace). That looks like it's Akamai, who own that entire AS.

13.107.4.50 is MSFT though.

hwcdn.net is typically MS update, but not 100% exclusive to that. More like 99.9%.

So off the cuff of my sleeve would be some sort of update check for the MSFT connection. For the other, I'm not sure what it'd be doing, but I don't think it's related.
Are these on the origin or the destination of the RDP connection? Have you wiresharked to see if you can get anything useful from the packets?

 

[SamirD]

23.59.155.80 isn't a MSFT IP, and StackPath LLC isn't MSFT (if it was, it'd be in Azure, not RackSpace). That looks like it's Akamai, who own that entire AS.

13.107.4.50 is MSFT though.

hwcdn.net is typically MS update, but not 100% exclusive to that. More like 99.9%.

So off the cuff of my sleeve would be some sort of update check for the MSFT connection. For the other, I'm not sure what it'd be doing, but I don't think it's related.
Are these on the origin or the destination of the RDP connection? Have you wiresharked to see if you can get anything useful from the packets?

Thank you for the detailed reply! I forgot about this thread until I was watching one of my workstations RDPing in and saw this in the resource manager:
Image Address Send (B/sec) Receive (B/sec) Total (B/sec)
lsass.exe https-69-164-31-128.yxx.llnw.net 32 4,707 4,739

I don't know what it would be looking to update though as these are xp embedded thin clients so they shouldn't even be looking for updates. And they have write protect enabled so they don't download anything and are basically toasters that 'just work'.

These are on the origin RDP connection--thin client connecting to another thin client with rdp server enabled across an IPsec vpn tunnel, so different subnets, but on the same network.

I haven't tried wiresharking yet. Inspecting packets on the origin should be the place to start, right?