CB Response: Alert Pointing to Different Process
search cancel

CB Response: Alert Pointing to Different Process


Article ID: 289818


Updated On:


Carbon Black EDR (formerly Cb Response)


The alert shows process A but the process detail page shows process B. 


  • CB Response Console: All versions
  • CB Response OSx sensor: 5.2.x and above
  • CB Response Linux sensor: 5.2.x and above


Child process on OSx/Linux is different than in Windows.


This is working by design.

Starting with 5.2.x sensors on OS X/Linux, posix process tracking has the following three types of events stored under the “childproc_complete” field in SOLR - the field that stores "general" child process activity. Each of these event types has different meanings.

1 – type 0: regular child process as we know it in Windows. A process forks (with a new PID) and then calls exec() and loads a new image. In the parent process events, this creates a child process event with PID number and started/ended events. A new SOLR document is created to track the activities of the child process separately. 
2 – type 1: a fork event. This pairs up with the type 0 child process event but denotes the time the parent process forked and the PID before exec() call and creation of the child process.
3 – type 2: posix_exec event: This is the same process with the same PID, loading a new image by calling exec(). In this case, a new SOLR document is NOT created. The process name, command_line etc changes from foo() to bar() and activities of bar() tracked under the same process unique_id as foo(). However, there is a new posix_exec() event in the event rows to donate the time foo() became bar() (along with associated name change). Any subsequent time a process calls exec() this is repeated, with process metadata being updated every time. 

Customer can track the progress of the process with the same unique_id over time, with changes to the process_name/command line that is paired with type 2 events under childproc_complete events.