CB Response: Alert Pointing to Different Process
Article ID: 289818
Updated On:
Products
Carbon Black EDR (formerly Cb Response)
Issue/Introduction
The alert shows process A but the process detail page shows process B.
Environment
- CB Response Console: All versions
- CB Response OSx sensor: 5.2.x and above
- CB Response Linux sensor: 5.2.x and above
Cause
Child process on OSx/Linux is different than in Windows.
Resolution
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.
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.
Feedback
Yes
No
Powered by
