Process information missing from network connection events

Question

I'm verifying my Sysmon-configuration file with test scripts inspired by Atomic Red Team.

When testing my NetworkConnect-rules (Event ID 3), one of my scripts are using wget from GnuWin32.
Checking the result I saw that the event logged doesn't contain any process information:

Network connection detected:
RuleName: <-=redacted=->
UtcTime: 2021-06-01 09:07:50.839
ProcessGuid: {00000000-0000-0000-0000-000000000000}
ProcessId: 14928
Image: <unknown process>
User: -
Protocol: tcp
Initiated: true
SourceIsIpv6: false
SourceIp: <-=redacted=->
SourceHostname: -
SourcePort: 8163
SourcePortName: -
DestinationIsIpv6: false
DestinationIp: 20.49.223.105
DestinationHostname: -
DestinationPort: 443
DestinationPortName: -

Information for Image and ProcessGuid are also missing in my certutil.exe test case.

Most of my logged EID 3 events do contain process information though. So it's not always missing.

Searching for information online I found this page saying this problem was fixed in Sysmon v11.10.
However, I'm running the most current version (v13.20).

Continuing searching, I found this page which describes the "reasons" for missing process information:

You would see a NULL parent GUID if either we never saw the process create for the parent process or the
parent process terminated before we logged the creation of the child process. To prevent the latter case we
don't purge cache records immediately but instead keep them around for a period of time before we remove
them permanently.

As far as I understand it, none of these cases applies.

I also read somewhere (sorry, I forget where so no link this time) that the reason could be a very short lived process.
So I added a call to "sleep 10" in my test script. Unfortunately, this result was the same.

Anyone else seeing this? Any ideas for the cause?

Answer 1

Hhmm, interesting. I've done some more analysis and have found logged events where the Image is reported as <unknown process>
but where the ProcessGuid field contains a valid GUID.

Even more interesting, If I then search for all the events with this GUID I sometimes find events (even other NetworkConnect events)
where this Image field has valid information.

So it seems that Sysmon only sometimes is unable to log the Image information!?

Answer 2

This issue seems to still be there in version 13.34, tested and reproducible on my Windows 11 Pro machine.
In another thread on the old forums, some people observed this behavior primarily on short-lived processes. This seems to be true for my situation as well. I can consistently reproduce this by executing curl in a cmd shell (not powershell): "curl -i https://learn.microsoft.com".

This results in the following event log entry:

Network connection detected:  
RuleName: -  
UtcTime: 2022-07-05 16:38:33.512  
ProcessGuid: {00000000-0000-0000-0000-000000000000}  
ProcessId: 11600  
Image: <unknown process>  
User: -  
Protocol: tcp  
Initiated: true  
SourceIsIpv6: false  
SourceIp: ####redacted####  
SourceHostname: ####redacted####  
SourcePort: 52552  
SourcePortName: -  
DestinationIsIpv6: false  
DestinationIp: 104.89.4.197  
DestinationHostname: a104-89-4-197.deploy.static.akamaitechnologies.com  
DestinationPort: 443  
DestinationPortName: https  

BTW, I could not reproduce this on a Windows 10 Pro VM.
What bothers me most is that because the process can't be identified, "image"-based rules in Sysmon's config aren't working properly and connections aren't logged.
For now I'm working around this by adding the following rules for inclusion:

<ProcessGuid name="ProcessGuidFallback" condition="is">{00000000-0000-0000-0000-000000000000}</ProcessGuid>  
<Image name="UnknownProcessFallback" condition="is">&lt;unknown process&gt;</Image>  

That way, I still can't see which process and which user initiated the connection, but at least it's being logged at all.

If there is anything else I can provide to help hunt this bug down, please let me know.

Answer 3

Addendum:
Interestingly, processes that Sysmon cannot identify can still be captured by Sysinternals ProcessMonitor. Using ProcessMonitor with an appropriate filter ("Operation" "is" "TCP Connect"), I could reliably identify those executables whose image path and user data Sysmon sometimes didn't catch.

Also, I wrote a small .NET test dummy application in an attempt to further investigate this issue. This application doesn't do much: connect (TCP) + disconnect + sleep + terminate.
If there is no delay (sleep) before the application terminates, Sysmon logs neither the process image, process GUID, nor the user name. If the dummy application waits for about 1.5 seconds after connecting, Sysmon often gets the user name and process GUID, but still not the process image. With a sleep time of about 2.5 seconds and higher, Sysmon captures all the data reliably, on my machine at least.
There wasn't much difference between connect + disconnect + sleep + terminate vs. connect + sleep + disconnect + terminate.
Sleeping before doing the TCP connect didn't help at all (sleep + connect + disconnect + terminate). Sysmon never got the user name or the process image in those cases.

However, in all these cases, ProcessMonitor caught the process and all related information.

Answer 4

In my case after investigation it turned to be sysinternals process for profiling the system. Sysmon