Microsoft forcing a ping??


Was locking down my system… as i just purchased win 7.

Blocking port 445…etc… Question is in regards to ICMP traffic… On my Belkin router i have ‘block all icmp’ traffic checked…etc.

Shields up… gives me ALL greens… and a perfect score… netbios is disabled…etc…

My question is with PING.EXE… it wanted to connect to which appears to be Microsoft. Does windows 7 just randomly ping microsoft servers? ( it was outgoing from my pc to the ip )… Any harm in just renaming Ping.exe to something else?.. Or just just block ping.exe completely?.. not a huge deal… i guess renaming would allow me to Use ping later… just by using the different name… just dont know if any other apps use it…

thanks much.

Decimal: 3475962453
ISP: Microsoft Corp
Organization: Microsoft Corp
Services: None detected
Type: Broadband

This seems to be a common function of Windows 7. I’m guessing ping is being called by svchost and there is an associated UDP out on port 123? If so, it’s related to ntp and seems to be a check performed, typically at boot, but also on occasion, when the system has been up for several days.

I do not believe that it is normal for Ping.exe to attempt to connect to much less Microsoft. However, there are at least 4 features I know of that would attempt talk out to Microsoft… One being already mentioned NTP (Network Time Protocol); however the connection out would not be a ping (echo request) going out to port 123 (as this would happen over UPD or TCP I forget which). Ping uses ICMP. The other is the connection Windows 7 using to figure out whether its online or not (I forget how this works but plenty on Google about it). The search function is the third which has been the case since atleast Windows 2000 if memory serves. The last reason your system would be phoning home to Microsoft would be your Windows Update Service (even when stopped it will continue to attempt to contact MS or at least did on my system). I would not rename PING.EXE for a permanent fix as that would only mask the symptoms of whatever is causing it. What you could try is temporarily renaming PING.EXE and seeing if any programs cry about it.

Thanks all…

Guess i’ll just let comodo catch it… and prompt me for it… will see how often it comes up ( im new to win 7 ).

What scared me were port 445 / system requests from random people across the globe… rofls… ( its closed up now :slight_smile: .

Thanks much.

NTP for time synchronisation uses UDP over port 123, this is not a time synchronisation as far as I have tested. If you’re on Windows 7 you can observer these connections for yourself. I did have a capture of this, I’ll post when I can find it.

he other is the connection Windows 7 using to figure out whether its online or not (I forget how this works but plenty on Google about it).

It’s the Network Location awareness service (NLASvc). This uses a few different addresses and varies according to location. In the past I though the ping was related to this service, but I’ve never found evidence of it. this is how it looks from my system:

The search function is the third which has been the case since atleast Windows 2000 if memory serves.
Can't say I've ever seen Windows search make use of ping, but one never knows.
The last reason your system would be phoning home to Microsoft would be your Windows Update Service (even when stopped it will continue to attempt to contact MS or at least did on my system).

From what I’ve seen these outbound connections come in pairs, a svchost generated ping request, followed directly by svchost sending a UDP packet to port 123, both to the same address. The address can vary between MS address blocks and those of large CDNs. Geography plays a role. Similar thread

Another possibility is the Cryptographic services provider, which is responsible for keeping the certificate root store up to date. As certificates are time sensitive, running a clock check would make sense.

The NTP traffic I am talking about is from a configuration on the system clock under Internet Time… it gets that information from “”. I did assume that is what you were talking about when you said port 123… If there is different traffic generating traffic to port 123 that would be interesting (Ive never noticed and would like to see the captures if you find them). I almost don’t want to believe that Microsoft would be sending non NTP traffic over UDP 123… but it wouldnt be the first time they broke RFC compliance… 88)

All the examples I was giving were for reasons why a system might arbitrarily contact Microsoft… I was not trying to imply that they would all use ping.exe and I am pretty sure that the Search function did not. Honestly, after Windows 2000 until Windows 7, I went to white listing with IP addresses and you guessed it… My system may have tried to phone home but it definitely was not able too (except for the few minutes each week to update).

But I did not even think about Cryptographic services provider as another reason.

When you were seeing svchost generated ping request… was it actually using the ‘ping.exe’ executable? If so Ive never noticed, but I havent taken time to explorer everything cooky that Windows 7 does.

yep was using the exe… .here’s a screeny of the log.

[attachment deleted by admin]

Hmm. It may be your Windows Live Service doing it since it is being blocked. Does the ping.exe show up in your logs if you all Windows Live to connect? Ive seen this happen with annoying persistent executables… I only want to let them connect on my terms and block it then they try going out through everything else under the sun.

It hasn’t done it again in about 8 hrs… so guess ill just leave it at that… Thanks for the help all…

I Did disable Windows Live ID Sign-in Assistant… ( about 3 hrs ago… )… as i dont need it running… not sure if that stopped it or not…

its Not a huge deal… it just came after i was seeing ‘system’ respoding to port 445 requests from like Zimbabwe ( no disrespect to people from Zimbabwe!.. :)… so after blocking 445… i later saw the ping.exe request… as was like… wth… is my machine infected or something :p… rofls…

Thanks all for the help… take care.

Highly likely caused by the blocking of the WLS, looks like it performs diagnostics on failure to connect.

well… just because im curious now… ill turn
Windows Live ID Sign-in Assistant

back on… and watch it…see it if tries to ping MS again…rofls… thanks all… appreciate the help and expertise!

That’s the best way to test! Let’s see if it returns.

Just had these on one of my PCs. My pings are always to a 64.4.. block, as is my NLASvc. Nothing installed on that box, just Windows 7 x86.

[attachment deleted by admin]

I’m not sure, but wonder if these pings to MS servers are not to check for updates for desktop Gadgets and system tray notifications as MS is using a polling pattern for the client/server content delivery and quoting MS

Polling means that the client checks with the service on a regular basis (for example, every 90 minutes) to see if there is new content.

Interesting idea but I always remove the Gadget service on all my PCs.

You’ll find if you ping either or manually the request will time out

I’ve found one of the causes, a scheduled task that will generate a ping on demand and matches the time-scale of the earlier log entries. Just two echo requests, no replies.

Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0x4d41 [correct]
    Identifier (BE): 1 (0x0001)
    Identifier (LE): 256 (0x0100)
    Sequence number (BE): 26 (0x001a)
    Sequence number (LE): 6656 (0x1a00)
    Data (32 bytes)

0000  61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70   abcdefghijklmnop
0010  71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69   qrstuvwabcdefghi
        Data: 6162636465666768696a6b6c6d6e6f707172737475767761...
        [Length: 32]

Nothing interesting, just saying hello :slight_smile:

[attachment deleted by admin]

It interesting to me because I am running Windows 7 x64 with Comodo in the strictess setting (alerting set to highest also) and I installed with “Do NOT show alerts that request security decisions” unchecked. In addition to this being a fresh install, with all but 4 vendors being removed from Trusted and very few allow rules. I have still yet to see ping.exe try to connect or anything try to connect on 123.

Just had a thought, depending on how you have Defense+ setup… you should have initially got warnings that “blahblahblah.exe was attempting to execute ping.exe” This would definitely tell you what was causing. Try checking your Defense+ logs since your firewall log will only show that ping.exe attempted to make the connection.

Apologies, I think there’s a slight misunderstanding. When this occurs ‘naturally’ there’s often two events back to back, A svchost UDP out on 123, immediately preceded and often followed by a ping to the same address. The ntp connection is raised by W32time but it’s not a time synchronisation in the conventional sense, as these events occur outside the standard Sunday morning time frame, the packets and address used are different and will vary based on geography. I also have my time synchronisation set to and not Microsoft.

Although I found a scheduled event that causes a ping on demand, if memory serves, the ‘naturally’ occurring events tend to have a different time frame and I’m still not sure what the cause of these are. The fact that time appears to be involved does suggest it’s a time sensitive event.

I don’t use HIPS or ‘real-time’ AV, just the firewall, set to Custom Policy with Alerts on Very high, all default settings removed.

Interestingly, I was just playing around with the scheduled event that generates the ping but I changed the time synchronisation source to, low and behold an ntp request and a ping.

Just for interest, turned on D+ and the sandbox, no alerts generated in safe mode but in paranoid mode ;D which pretty much explains everything…

[attachment deleted by admin]

Thats really interesting. From your log it looks like taskhost.exe is executing sdiagnhost.exe which in turn executes ping. And it looks like it has to do with certificates similar to what you said in a earlier post. More interesting is that these events are not happening on my system. Infact, as far as Comodo knows, sdiagnhost.exe has never even run.