Image: (null) in some sysmon events

[absurd121]

In some "network connect" events of the sysmon log the "Image" value is not displayed. Instead the value (null) is displayed. For example, the pip was updated here:

Event SYSMONEVENT_NETWORK_CONNECT
        RuleName: -
        UtcTime: 2021-12-23 12:14:24.989
        ProcessGuid: {7c1402c1-681f-61c4-10b0-b52aec550000}
        ProcessId: 3095
        Image: /usr/libexec/platform-python3.6
        User: -
        Protocol: tcp
        Initiated: true
        SourceIsIpv6: false
        SourceIp: 10.0.3.21
        SourceHostname: -
        SourcePort: 46424
        SourcePortName: -
        DestinationIsIpv6: false
        DestinationIp: 152.19.134.198
        DestinationHostname: -
        DestinationPort: 443
        DestinationPortName: -
Event SYSMONEVENT_NETWORK_CONNECT
        RuleName: -
        UtcTime: 2021-12-23 12:14:25.208
        ProcessGuid: {7c1402c1-5ffd-61c4-0000-000000000000}
        ProcessId: 3090
        Image: (null)
        User: -
        Protocol: tcp
        Initiated: true
        SourceIsIpv6: false
        SourceIp: 10.0.3.21
        SourceHostname: -
        SourcePort: 34646
        SourcePortName: -
        DestinationIsIpv6: false
        DestinationIp: 151.101.84.223
        DestinationHostname: -
        DestinationPort: 443
        DestinationPortName: -

My system: CentOS Linux release 8.5.2111 Kernel: Linux 4.18.0-348.2.1.el8_5.x86_64

[mySYSMON]

I suspect it has something to do with this. https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/ What is the output of cat /etc/fstab | grep proc ?

Also see Then i dug around in /proc, and in the mountinfo files some processes have this:

/ /proc rw,nosuid,nodev,noexec,relatime shared:5 - proc proc rw,gid=26,hidepid=invisible while others have:

/ /proc rw,nosuid,nodev,noexec,relatime shared:286 - proc proc rw The processes that have hidepid enabled seem to always be run as root. Source: https://bbs.archlinux.org/viewtopic.php?id=262151

[mySYSMON]

Why can I list other users processes without root permission

Using ps -aux or top, I can list other users running processes, but I'm neither running as root nor making use of sudo, why?

Best Answer By default, you can always list other users processes in Linux.

To change that, you need to mount proc in /etc/fstab with hidepid=2

This functionality is supported from the kernel v3.2 onwards. It hides /proc and consequentially ps activity from all users except root.

Source https://itectec.com/unixlinux/linux-can-i-list-other-users-processes-without-root-permission/

[mySYSMON]

Good discussion about issue here: https://issueexplorer.com/issue/systemd/systemd/12955

[absurd121]

I suspect it has something to do with this. https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/ What is the output of cat /etc/fstab | grep proc ?

"cat /etc/fstab | grep proc" does not display anything I think this is not my case. Because when I run the "ps" command, I have access to the processes of all users, starting from PID 1, and to all the commands that started the processes. In addition, the sismon log displays pid of all processes.

[frkn4129]

@absurd121 I want to install sysmon on centos 8 . for centos 8 i did the following steps but Null values ​​are returned in /var/log/messages. How did you do? can you help me?

CentOS 8

1. Register Microsoft key and feed sudo rpm -Uvh https://packages.microsoft.com/config/centos/8/packages-microsoft-prod.rpm
2. Install SysmonForLinux sudo dnf install sysmonforlinux

[absurd121]

@frkn4129 Everything is correct, but after that the sismon service did not start. I had to manually install SysinternalsEBPF https://github.com/Sysinternals/SysinternalsEBPF :

Sysmon For Linux also depends on SysinternalsEBPF being installed: library libsysinternalsEBPF.so, header libsysinternalsEBPF.h, plus resource files in /opt/sysinternalsEBPF. These can be installed from the SysinternalsEBPF project or via the sysinternalsebpf DEB package from the packages.microsoft.com repository (see INSTALL.md).

[MarioHewardt]

Hi - Closing this issue as CentOS8 is EOL. If you see this issue in supported distros please feel free to reopen.