process-events.md: Description of Process GUIDs is not right.

[hillu]

Looking at the Sysmon/Linux sources, GUIDs are constructed by concatenating the "machine id", the start time of the process (UNIX-style, seconds since 1970-1-1), and a "process start key" which is not defined in the userspace component (function GenerateUniqueId in sysmonCommon/eventsCommon.h):

	*(DWORD*) pResult = machineId;
	pResult += sizeof(DWORD);
	*(DWORD*) pResult = seconds;
	pResult += sizeof(DWORD);
	*(DWORD64*) pResult = ProcessStartKey;

The "process key" is taken from m_EventBody.m_ProcessCreateEvent.m_ProcessKey which for Linux is created in the eBPF code (set_ProcCreate_info in ebpfKern/sysmonProcCreate.c):

    // get the process key - this is the end of the text segment currently as it should be
    // a) randomised for a PIE executable; and
    // b) dependent on the amount of code in the process
    event->m_ProcessKey = (uint64_t)derefPtr(task, config->offsets.mm_end_code);

I'm still in the process of looking at Sysmon/Windows with a disassembler, so I can't yet speak to what happens there. However, from the logs I have looked at, I don't recognize the process id as part of the process GUID.

[darkoperator]

Matt Graebber I believe has it in a gist where he reversed the windows side of the creation

…

Sent from my iPhone

On Apr 26, 2022, at 4:48 PM, Hilko Bengen ***@***.***> wrote:  Looking at the Sysmon/Linux sources, GUIDs are constructed by concatenating the "machine id", the start time of the process (UNIX-style, seconds since 1970-1-1), and a "process start key" which is not defined in the userspace component (function GenerateUniqueId in sysmonCommon/eventsCommon.h): *(DWORD*) pResult = machineId; pResult += sizeof(DWORD); *(DWORD*) pResult = seconds; pResult += sizeof(DWORD); *(DWORD64*) pResult = ProcessStartKey; The "process key" is taken from m_EventBody.m_ProcessCreateEvent.m_ProcessKey which for Linux is created in the eBPF code (set_ProcCreate_info in ebpfKern/sysmonProcCreate.c): // get the process key - this is the end of the text segment currently as it should be // a) randomised for a PIE executable; and // b) dependent on the amount of code in the process event->m_ProcessKey = (uint64_t)derefPtr(task, config->offsets.mm_end_code); I'm still in the process of looking at Sysmon/Windows with a disassembler, so I can't yet speak to what happens there. However, from the logs I have looked at, I don't recognize the process id as part of the process GUID. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[hillu]

Matt Graebber I believe has it in a gist where he reversed the windows side of the creation

Right: https://gist.github.com/mattifestation/0102042160c9a60b2b847378c0ef70b4

And a more recent comment there mentions that PROCESS_TELEMETRY_ID_INFORMATION::ProcessStartKey is used for identifying the process as of Sysmon 13. I suppose that this is what the Linux eBPF code is modelled after.

[darkoperator]

Probably, seen some cases where a GUID collision has happened. Still not sure if the host share the same encryption GUID for the host

…

Sent from my iPhone

On Apr 26, 2022, at 6:07 PM, Hilko Bengen ***@***.***> wrote:  Matt Graebber I believe has it in a gist where he reversed the windows side of the creation Right: https://gist.github.com/mattifestation/0102042160c9a60b2b847378c0ef70b4 And a more recent comment there mentions that PROCESS_TELEMETRY_ID_INFORMATION::ProcessStartKey is used for identifying the process as of Sysmon 13. I suppose that this is what the Linux eBPF code is modelled after. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.