From my reading, there can be multiple causes. For instance, after reading Cornelius's question: “Why is the System process listening on Port 443?”, I get the impression that at least these three different causes can lead to such a thing:
-
HTTP.SYS related to IIS (Microsoft's web server)
-
A network connection accepting an incoming VPN connection. (Possibly related to "Remote Access", part of RRAS which is "Routing and Remote Access"?)
-
Skype (see the hyperlink earlier in my answer, for pictures).
I'm guessing these have some common factors, such as using Microsoft code and probably using a low-level driver.
I would think there has to be a way to just check, instead of hunting. The TCP/IP stack has to know where to send the traffic, and we can check what the TCP/IP stack will do using the netstat command. Unfortunately, all the netstat command is giving us is the system-wide PID, which points us to a process named "System". I would think that, similarly, the "System" process must have a way to know which driver to send the traffic to. I have not yet found a way to just check that.
Meanwhile, I figured I'd point you to multiple possible causes I did find. Hopefully one of those will lead to you finding the answer you're seeking.
Note: The way I found this cause was by looking at some of the promising "Related" items that Superuser.com displays in the right frame. One of the basic rules of Stack Exchange is to try doing your own prior research. I suggest another good rule is that after you post a question, do check the section called "Related" in the right frame, because IMHO Stack Exchange does a pretty good job of frequently finding very on-topic questions.
On my Microsoft Windows system, PID 4 also belongs to the System process, so it does not appear that particular PID is very random.
The rest of this question just explains some things I checked on my system. It won't help you (Alexander Gelbukh) much because I can tell that you've already figured most or all of this out already. However, hopefully people reading that will be less inclined to blindly recommend netstat as a solution, since netstat's output is not a complete, sufficient solution (because we need to do more than just identify the process that the TCP/IP networking stack will send the traffic to).
I think there can be multiple reasons that netstat -b may say Can not obtain ownership information, including a lack of UAC elevation (at least on some versions of Microsoft Windows; on my Windows 10 I get different results when running un-elevated: netstat just immediately says The requested operation requires elevation. and gives two blank lines, and quits.)
I'm getting the same results as you: When I do run elevated, I cannot seem to see the results of PID 4.
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 996
RpcSs
[svchost.exe]
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
Can not obtain ownership information
TCP 0.0.0.0:8732 0.0.0.0:0 LISTENING 4
Can not obtain ownership information
(This says PID 996 is svchost.exe, but no info on PID 4.)
C:>tasklist /SVC | more
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
System Idle Process 0 Services 0 4 K
System 4 Services 0 4,828 K
C:\WINDOWS\system32>powershell "Get-NetTCPConnection -LocalPort 445 | Format-List"
LocalAddress : ::
LocalPort : 445
RemoteAddress : ::
RemotePort : 0
State : Listen
AppliedSetting :
OwningProcess : 4
CreationTime : 3/2/2017 9:56:19 PM
OffloadState : InHost
C:\WINDOWS\system32>