EDR: Why SIEM raw Event Presents Two Processes in One process_guid
search cancel

EDR: Why SIEM raw Event Presents Two Processes in One process_guid

book

Article ID: 290087

calendar_today

Updated On:

Products

Carbon Black EDR (formerly Cb Response)

Issue/Introduction

Why SIEM raw event presents two different processes in one process_guid?

For example:
 
{"path":"/usr/libexec/xpcproxy","pid":48010,"process_guid":"00028561-0000-bb8a-01d6-b778a4ec5764","sensor_id":***217,"timestamp":1605023184,"type":"ingress.event.procstart","username":"root"}

{"path":"/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mdworker_shared","pid":48010,"process_guid":"00028561-0000-bb8a-01d6-b778a4ec5764","sensor_id":***217,"timestamp":1605023184,"type":"ingress.event.procstart","username":"****"}

Environment

EDR: All versions

Resolution

 If a process exec's into another process after a previous exec (e.g. an exec->exec rather than a fork->exec) the sensor overwrites the metadata including the path, process_name, cmdline, and md5. This is why the path for the process changed from xpcproxy to mdworker_shared.

There will only be one path in an API or console because xpcproxy exec's into mdworker_shared immediately and not in a subsequent segment of the doc. The event forwarder however will generate an event for the original process start (1st exec) and another for the 2nd exec.