1

As title states,

Ive detected some MDNS queries from a googlecast address, which is strange since i don't have any googlecast apps or similar installed.

Additionally My PC is sending SSDP packets to 239.255.255.250 (subnet?) regarding 'M-Search: HTTP/1.1' strings to Chrome OS machine.

MDNS Packet : 192.168.1.65 224.0.0.251 MDNS 119 Standard query 0x000b PTR _674A0243._sub._googlecast._tcp.local, "QM" question PTR _8E6C866D._sub._googlecast._tcp.local, "QM" question PTR _googlecast._tcp.local, "QM" question

SSDP Packet: 192.168.1.67 239.255.255.250 SSDP 216 M-SEARCH * HTTP/1.1

Perhaps its good to mention that i noticed the specified 'User-agent' for these SSDP packets are stated as either 'Google Chrome' or 'Chrome OS'. Is this just a default function of Google chrome to include their DIAL tech.

0

The Chrome browser comes with a built in Chromecast plugin to allow tab or screen sharing if a Chromecast compatible is on your local network (e.g. Android TV or Chromecast devices).

It will search for devices regularly so it can present a list of target devices.

1
  • Thanks hard, so im guessing it will keep querying for compatible devices on my network? What explains the SSDP transmission though? Im guessing thats due to my computer using chrome?
    – N S
    Mar 3 '20 at 8:09
1

You're observing two different things that are independent form each other.

  • The SSDP traffic is just a general "poll" for devices that matches the search. 239.255.255.250 is a multicast address that is defined in the UPnP standard. SSDP is just the UPnP discovery mechanism that somebody though should have its own name. Only "subscribers" to 239.255.255.250 will actually receive these messages (the OS network stack filters multicast messages), but as with all multicast packets, the packets themselves are sent to all network devices. Any number of software running on your computer can be the source of the M-SEARCH, some OS'es like Windows will even send these themselves as a part of the built-in "network discovery".
  • mDNS with DNS-SD is an alternative system for doing pretty much the same thing as SSDP. It's also called Bonjour among other things, and it too uses multicast to let network devices discover each other. DNS-SD adds the ability to announce "services" over mDNS or regular unicast DNS. _googlecast._tcp.local is one such "service" that is used by ChromeCasts, Android TVs, Google Home, the Chrome browser and all other things in the "Google ecosystem" that can take part in their "cast" system. I'm not fluid in mDNS, but it seems to me like this is also a "poll" looking for peripherals that support this "service". I assume that Chrome OS also take part in this, so it might be that for example a Chrome browser running on another OS and Chrome OS will "keep in though" using this system.
-2

)

I have only just seen this post. Ok about 2 years ago I had similar dealings with this address coming out of my machine.

So this is just a GoogleCast/ChromeCast ??

From my own computer and research im not so sure at all.

Everything on my machine was upto date at the time, so you wouldnt expect to be seeing any unknown applications running from the system, but there was and quite a few.

For me ipv4 is a 1 to 1 connection and ipv6 is a multicast unicast connection. So i thought i would disable ipv6 from the Local area network, router and all apps and all firewall permissions that seem to be default using multicast. Also I removed any services for ipv6, translation, tunneling, basically as much as i knew i could without screwing the system up.
I thought that should take care of it, but checking again after, it was still running.

So now i tracked it down to a Windows svchost, with a PID process number of 4. How can this be embedded into my operating system like this? So more digging and without any ipv6 running i managed to pin point the remote connection addresses far easier.

Just from information within the resource monitor it now looks like this is actually some form of Windows 'Speed Test' More research would suggest these bogus and bullshit svchosts are actually Windows Speed tests, Remote Speed tests, Internet Speed tests. All cleverly installed and placed into the Windows Task Schedular and nicely hidden from a normal user.

Lets get down to the useful information which I managed to translate myself. You may find interesting.

Local addresse on my comp:

239.255.255.255 svchost PID=4 + PID=2584 224.0.0.252

These were connecting to multiple remote addresses. I did my research here. Speed test? Yeah right.

Speed test addresses looks like this,

  1. 239.255.255.255 = 1e100.net - Google
  2. 239.255.255.255 = 104.40.210.32 - Akamai Tech (Steam)
  3. 239.255.255.255 = 93.184.221.240 - Verizon Edgecast Netblk
  4. 239.255.255.255 = 88.221.42.227 - Akamai Tech
  5. 239.255.255.255 = 34.98.75.36 - Amazon Key logging?
  6. 224.0.0.254 = 13.227.171.38 - cloudfront.net (Amazon)
  7. 224.0.0.252 = 99.84.8.129 - cloudfront.net (Amazon)

Type = Remote Speed Tests - Ports 443 + 49000 range

  1. 52.183.47.176 = Microsoft Azure
  2. 151.139.128.14 = Highwinds Network Group
  3. 173.222.210.65 = Akamai Technologies (steam i think)

Ipv6 converted addresses found attacking my machine,

  1. 0:0:0:ffff%1 = 191.232.139.2 = Microsoft Azure
  2. 0:0:0:ffff%2 = 40.112.91.29 = Microsoft Azure
  3. 0:0:0:ffff%3 = 52.156.194.135 = Microsoft Azure
  4. ::/64 = 152.199.19.161 = Verizon Business
  5. :: = 204.79.197.200 = Microsoft?

Back in the day, you had to enable things to make them work. Nowadays everything is on by default. Privacy? There basically isnt any these days.

Anyways good luck and for anyone else readin this I hope this information helps you out some.

Plugz

1
  • You've got a lot of stuff wrong, starting with the IPv4 and IPv6 misinterpretation. svchost processes are not hidden in any way, and their intent is far from just speed testing. Sep 3 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.