I may be asking a really stupid question, but Defense+ keeps blocking wininit.exe (the one in the system32 folder, not that I have any others :P). A Malwarebytes search gave 0 results, so I guess I am completely trojan free. So, is my wininit.exe acting normally? Here is a print of the log.
Edit: That was the only time I got so many intrusions from it.
Wininit EXE is a core process that is present in each Vista session. Wininit EXE’s job is to start some of the main Vista background services (programs) like Service Central Manager (SCM), the Local Security Authority Subsystem (LSASS) and the Local Session Manager (LSM.EXE). Wininit EXE is a critical Windows Vista background program that should never be stopped through the Vista Task Manager system.
If you block it in CIS you’re just begging for trouble. Either add it manually to D+ rules, or next time the pop-up alert shows up, click ‘allow’ + ‘remember this’
Your logs show that wininit.exe try to access \Device\Afd\Endpoint which is a part of the Windows Socket defining a network programming interface. An application accessing the network needs to access windows socket.
In principle, Defense + has default rules for Windows files. Then either Defense + blocked what is a abnormal behavior from wininit either you changed sth in the default rules of Windows System Applications either an application tries to access internet using wininit. Try to identify which application you were using when the blocking occurs. I’m under win XP and don’t have wininit.exe which is part of Vista and 7, then I can’t check if there is a rule specific for wininit.
Boris
Those intrusions usually appear when I plug my network cable back in ( do not ask why I unplug it in the first place). And I really doubt I have any security problems since I tend to take real good care of my PC’s safety. I just want to know what wininit.exe is trying to do exactly.
Its legiit behavior for Vista. If it was hijacked, CIS would intercept it as unrecognized and probably sandbox it. If it was corrupted CIS AV would intercept it as malicious.
You said you’re clean per Malwarebytes - I’m guessing you’ve been running CIS for a while too - so there really shouldn’t be any reason to question any functioning of your system. The only thing you need to question is any new stuff you install.
I’d create a rule for it as I explained. Make sure that all the ‘access right name’ are set to ‘ask’. Then it’ll generate alerts for any new access right it needs.
CIS allows in the its default rules all that is necessary to let windows runs flawlessly.
wininit.exe replaces in vista and 7 the winlogon.exe of XP.
wininit.exe should be in the Windows Systems Applications rule in Defense +, if you haven’t changed this rule. If it isn’t there, add a rule for wininit.exe and give it the predefined rule Window System Application. This will allow this file to run normally.
I have another question. Look at this image. Those other ips are also from my network, but I have printer sharing and all that turned off. Is it normal? ???
As you have a Teredo multicast in the list I can guess which svchost instance this is and as the connections all share the same PID, you’ll probably find this of help as it’s likely the same situation.
Well, I reinstalled my Windows and the connections seem to have disappeared. Anyway, I disabled ipv6 transitions using your instructions on the other topic and so far, so good. And, just to get it clear, were those IPs my neighbors, so to speak, and we all used the same Teredo Client? Sorry for being such a total newb. ;D
Tunnelling ipv6 over ipv4 can use a variety of mechanisms, Teredo being just one. In cases where a publicly routable ip address is used, a 6to4 tunnel could have been used. Regardless, when ipv6 is enabled and a valid tunnel exists, various ancillary services will come into play to provide the necessary communication between ipv4/ipv6 clients.
Looking at the image you’ve posted, it would appear the source address and port are the same (65032) but the destination addresses and ports are different. Are you running a p2p client?
I don’t think so. I once had Utorrent but it was uninstalled at the time of the screenshot. Other programs that were using the Internet I think were Peerblock and maybe Samsung Kies. I also had Hamachi installed but at the time of the process, its processes were killed. So, yeah, just wondering why my computer was communicating with computers near me (like, in the same city).
To identify exactly what was happening, we’d need to identify which of the individual processes, hosted by svchost, was being used in the connections. If my assumption is correct, then unless you re-enable tunnelling we’ve lost the opportunity. However, I’m certain it would have been the iphlpsvc (IP Helper service) process. Essentially, when tunnelling is being used, this service occasionally checks the tunnel availability and these are the connections you’re seeing.
If you’re interested, the following is a capture of the data transmitted by the iphlpsvc, when using an active Teredo tunnel:
No. Time Source Destination Protocol Info
1104 78.153831 192.168.1.141 178.190.27.138 UDP Source port: 55854 Destination port: 54430
Frame 1104: 110 bytes on wire (880 bits), 110 bytes captured (880 bits)
Arrival Time: Jun 1, 2011 17:50:12.347088000 ***
Epoch Time: 1306911012.347088000 seconds
[Time delta from previous captured frame: 0.000119000 seconds]
[Time delta from previous displayed frame: 1.131467000 seconds]
[Time since reference or first frame: 78.153831000 seconds]
Frame Number: 1104
Frame Length: 110 bytes (880 bits)
Capture Length: 110 bytes (880 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ip:udp:data]
[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 || mstp.checksum_bad==1]
Ethernet II, Src: CadmusCo_ff:b7:63 (08:00:27:ff:b7:63), Dst: AsustekC_a8:6e:f3 (e0:cb:4e:a8:6e:f3)
Destination: AsustekC_a8:6e:f3 (e0:cb:4e:a8:6e:f3)
Source: CadmusCo_ff:b7:63 (08:00:27:ff:b7:63)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.1.141 (192.168.1.141), Dst: 178.190.27.138 (178.190.27.138)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 96
Identification: 0x38c4 (14532)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (17)
Header checksum: 0x0000 [incorrect, should be 0x714b]
[Good: False]
[Bad: True]
[Expert Info (Error/Checksum): Bad checksum]
[Message: Bad checksum]
[Severity level: Error]
[Group: Checksum]
Source: 192.168.1.141 (192.168.1.141)
Destination: 178.190.27.138 (178.190.27.138)
User Datagram Protocol, Src Port: 55854 (55854), Dst Port: 54430 (54430)
Source port: 55854 (55854)
Destination port: 54430 (54430)
Length: 76
Checksum: 0x90db [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Data (68 bytes)
0000 60 00 00 00 00 1c 06 80 20 01 00 00 5e f5 79 fd `....... ...^.y.
0010 04 d5 25 d1 92 81 e5 b7 20 01 00 00 5e f5 79 fd ..%..... ...^.y.
0020 34 92 2b 61 4d 41 e4 75 c0 a7 b2 82 df 85 49 34 4.+aMA.u......I4
0030 00 00 00 00 70 02 20 00 a1 b9 00 00 02 04 04 c4 ....p. .........
0040 01 01 04 02 ....
Data: 60000000001c0680200100005ef579fd04d525d19281e5b7...
[Length: 68]
A similar packet is received in response. As you can see, it’s not very interesting 
Thank you. You have been very helpful. I learned something I haven’t even heard about before these 2 days, thanks to you. Also, sorry for seeming paranoid, I just want to keep my PC security as high as possible, though I tend to exaggerate, as seen in this topic. 