Strange Hotmail Activity On WIN 7

WIN 7 x64 SP1, Comodo v5 .1383

Ever since I installed, I have observed a connection to a Hotmail IP range connection at boot time. Now I don’t use Hotmail. I assumed this was normal MS dialing home baloney.

Sometime later, I noticed Comodo firewall auto-generate an allow application rule for ping.exe for all ICMP outbound. Never saw anything like that before so I changed the rule from Allow to Ask.

Rule sat dormant for a long time. Recently, I saw a block action on this rule. I must have been away from my PC when the Ask alert was generated. so Comodo blocked it. Low and behold, it was an ICMP 8,0 request to a Hotmail IP range.

Anyone know if this is normal WIN 7 OS activity?

[attachment deleted by admin]

Yes, I believe it is normal. The Hotmail activity is probably W7 (maybe Live ID related) trying to put your unread email count (if there is one) on the Login screen and the PING is probably either the same email activity (trying to make sure the connection is OK) or one of W7’s periodic tasks trying to test the same for wired/wireless connections (they’re small VBS scripts).

Check W7’s Task Manager, if you’ve not seen it before it will be quite an eye-opener… it’s very extensive and there are lots of W7 related tasks than run for many reasons (some scheduled & others on events, etc).

I just checked my global rules. I have a rule allowing all ICMP outbound. It appears Comodo ignored that and generated generated the application rule. Don’t know what it did that.

Then there is the Hotmail issue. Like I stated previously I don’t have a Hotmail account. I can buy the boot dial-out to Hotmail which I have observed using TCPView. Don’t know why it would dial out randomly at any other time?

Are you’re saying Hotmail based on a reverse DNS lookup of the IP address or because of something else? Also, when you say “dial out” do you mean an outgoing connection or are you talking about Dial-Up Networking (DUN)?

PS Check the Microsoft - Windows sections with the Task Scheduler. It’s fairly likely that you’ll find your culprit in there (somewhere).

Personally, I don’t see any ICMPv4 activity related to this address, or any other address during boot, so your ‘Ping’ event may be caused by something else. However, running a dumpcap during boot, on my system, shows these events to be NCSI/NLA (Network Status Connectivity Indicator/Network Location Awareness) related, although I wasn’t aware this service used that address range. The normal behaviour for NLA is controlled by svchost and the parameters found at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet

Which is a request to www.msftncsi.com, but if you look at the trace below, you can see the URI request towards the bottom.

Windows 7 does include Windows Mail, but I was under the impression it needed to be activated before it could be used.

Frame 17: 151 bytes on wire (1208 bits), 151 bytes captured (1208 bits)
    Arrival Time: Aug  4, 2011 11:48:05.349613000 *
    Epoch Time: 1312418885.349613000 seconds
    [Time delta from previous captured frame: 0.085516000 seconds]
    [Time delta from previous displayed frame: 0.105531000 seconds]
    [Time since reference or first frame: 0.490467000 seconds]
    Frame Number: 17
    Frame Length: 151 bytes (1208 bits)
    Capture Length: 151 bytes (1208 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:tcp:http]
    [Coloring Rule Name: Checksum Errors]
    [Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1 || sctp.checksum_bad==1 || mstp.checksum_bad==1]
Ethernet II, Src: CadmusCo_fe:33:5f (08:00:27:fe:33:5f), Dst: AsustekC_*:*:* (e0:cb:4e:*:*:*)
    Destination: AsustekC_*:*:* (e0:cb:4e:*:*:*)
        Address: AsustekC_*:*:* (e0:cb:4e:*:*:*)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: CadmusCo_fe:33:5f (08:00:27:fe:33:5f)
        Address: CadmusCo_fe:33:5f (08:00:27:fe:33:5f)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.1.202 (192.168.1.202), Dst: 64.4.18.90 (64.4.18.90)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 137
    Identification: 0x0031 (49)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0xe56d (maybe caused by "IP checksum offload"?)]
        [Good: False]
        [Bad: True]
            [Expert Info (Error/Checksum): Bad checksum]
                [Message: Bad checksum]
                [Severity level: Error]
                [Group: Checksum]
    Source: 192.168.1.202 (192.168.1.202)
    Destination: 64.4.18.90 (64.4.18.90)
Transmission Control Protocol, Src Port: 49158 (49158), Dst Port: http (80), Seq: 1, Ack: 1, Len: 97
    Source port: 49158 (49158)
    Destination port: http (80)
    [Stream index: 2]
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 98    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgement: Set
        .... .... 1... = Push: Set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
    Window size value: 256
    [Calculated window size: 65536]
    [Window size scaling factor: 256]
    Checksum: 0x154c [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    [SEQ/ACK analysis]
        [Bytes in flight: 97]
Hypertext Transfer Protocol
    GET /ncsi.txt HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): GET /ncsi.txt HTTP/1.1\r\n]
            [Message: GET /ncsi.txt HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: GET
        Request URI: /ncsi.txt
        Request Version: HTTP/1.1
    Connection: Close\r\n
    User-Agent: Microsoft NCSI\r\n
    Host: www.msftncsi.com\r\n
    \r\n
    [Full request URI: http://www.msftncsi.com/ncsi.txt]

0000  e0 cb 4e a8 6e f3 08 00 27 fe 33 5f 08 00 45 00   ..N.n...'.3_..E.
0010  00 89 00 31 40 00 80 06 00 00 c0 a8 01 ca 40 04   ...1[at].........[at].
0020  12 5a c0 06 00 50 3e b5 8e a3 7a 62 7e 03 50 18   .Z...P>...zb~.P.
0030  01 00 15 4c 00 00 47 45 54 20 2f 6e 63 73 69 2e   ...L..GET /ncsi.
0040  74 78 74 20 48 54 54 50 2f 31 2e 31 0d 0a 43 6f   txt HTTP/1.1..Co
0050  6e 6e 65 63 74 69 6f 6e 3a 20 43 6c 6f 73 65 0d   nnection: Close.
0060  0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 4d 69 63   .User-Agent: Mic
0070  72 6f 73 6f 66 74 20 4e 43 53 49 0d 0a 48 6f 73   rosoft NCSI..Hos
0080  74 3a 20 77 77 77 2e 6d 73 66 74 6e 63 73 69 2e   t: www.msftncsi.
0090  63 6f 6d 0d 0a 0d 0a                              com....

Which is a request to www.msftncsi.com, but if you look at the trace below, you can see the URI request towards the bottom.

Thanks Radagast for the detail work on that boot Hotmail url connect event. I figured it was “benign.”

As far as I can determine, Windows Mail is not active or activated.

I have used a few firewalls and Comodo’s starting with ver. 3 and I have never seen a system triggered application outbound rule generated for ping.exe. I have seen a rule created for ping.exe when I manually executed the ping command. Note that I did not executed a ping command at the times shown in the firewall log screen shot. Something within WIN 7 generated those ping commands. Also the pings are generated randomly it appears.

I do know one thing for sure about WIN 7 - it should be remaned “Microsoft Spyware.” The more I learn about it, they more intrusive I see it is.

I changed some of my global ICMP rules and will wait and see what falls out.

I was purposely blocking ICMP outbound destination unreachable for everything except to router. I always viewed that as a security risk to inbound port probing but WIN 7 might require it to “dial home” for God knows what.

I also added an allow inbound ICMP echo reply prior to any outbound ICMP rules. This in reality might be the issue. I suspect WIN 7 was generating an outbound echo reply and wasn’t receiving a reply and attempted to re-test connectiviry by internally generating another echo request hence the generation of the Comodo application outbound ICMP echo request rule.

I can’t really see why you’d want to configure any outbound ICMP rules for the firewall, other than application rules for ping and tracert, especially not echo reply. The only Global ICMP rules the majority should consider, are inbound for destination unreachable, time exceeded and fragmentation needed.

I have attached the ICMP rules I created. These are one for one copies of NIS 2011 global ICMP rules. In fact, I have made my Comodo global rules equal to those given for NIS2011. A few of them are shown.

I have never been infected in close to a year using NIS 2011. I have been infected twice already since May using Comdo’s firewall and Defense+. One time was so severe, I had to restore from an image backup. I am not taking any more chances with Comodo’s default rules.

I have not added NIS 2011 IPv6 ICMP rules yet since they are extensive and I am not using IPv6 for Interent access since my ISP does not support it yet.

[attachment deleted by admin]

You have a number of Global rules in there that make little sense:

  1. Allow DHCP Broadcast.

Providing you have an Application rule for svchost that allows a limited broadcast out over UDP to port 67, you don’t need this rule. If you haven’t changed the defaults, this is already happening.

  1. Allow ICMP OUT ANY is pretty pointless. If there’s unsolicited outbound ICMP traffic originating from your PC, you should find out why.

  2. Both of your NetBIOS rules fail to include support for NetBIOS Session service (TCP over port 139) which is the single most exploited NetBIOS port.

  3. ICMP Echo Request IN is not needed, even in a LAN environment, unless you’re constantly ‘pinging’ other devices on your LAN.

  4. Windows file sharing is NetBIOS and direct hosting over TCP/UDP ports 137-139 and 445. What do your Windows file sharing rules do?

  5. Win 2000 SMB? SMB (Service Message Block) is used in Windows and Samba file sharing (NetBIOS and Direct hosting. What is this rule for?

As I said elsewhere, it’s pointless copying rules from another firewall, as they work differently and you’re not doing yourself any favours. In CIS there are specific guidelines about the way the rules work, which can be simply defined as:

Application rules allow control of individual processes, typically for outbound traffic
Global rules allow control of ports and protocols, typically for inbound traffic

Whilst it’s quite easy to deviate from this behaviour, it’s worth adopting it’s structure. If you want help defining rules, please ask.

You have a number of Global rules in there that make little sense:

The rules all make perfect sense to me. NetBIOS rule is for ports 137-138, the Windows File Sharing rule is for port 139, Win 2000 SMB is for port 445, etc. Wording shown is Norton’s and I used it to cross-ref to the NIS 2011 rules. Yes, I could create application rules for system and svchost.exe to cover the above but global rules are more secure. Note that these rules all apply for the most part to inbound UDP activity which is not stateful and does have a way to enter a PC. I have seen it do so multiple times over the years.

As far as the DHCP rule see: Comodo Forum. I need this for my router. It will not assign/renew DHCP address without it.

I am happy with them and that’s all that counts.

Thanks for you concern though.