Using Carbon Black Rest API for behavior monitoring and process management

This blog post comes from Dwolla’s Information Security Team. As part of our continuing mission to practice iterative security, we believe in the value of sharing new lessons and best practices that we learn along the way. In this post, our Information Security Analyst walks through a new process he created for better security monitoring.

Background

As a part of our continuous security monitoring practice, Dwolla’s Information Security Team tracks and generates alerts based on an endpoint’s behavior in a number of interesting ways.

For example, if an endpoint user is normally asleep at 11:00pm, but one day we observe a sudden authentication through VPN at 2:00 AM, it would be an abnormal behavior for that user and would generate an event.

Another example related to the topic would be if an endpoint user working on the HR team is running the process like ‘git’, ‘python’ or ‘powershell’. This would cause concern because this is a process that he or she doesn’t need to do and doesn’t normally do; therefore, it would also be considered abnormal behavior and cause for concern.

Below, we will demonstrate how to analyze processes as we correlate behavioral-based events to gain confidence in the authenticity of associated processes and improve security monitoring for Dwolla’s team.

Problem Description

Carbon Black is a robust tool that can be used to collect process information from endpoints. In addition to its threat intelligence feeds and alerts, it has a powerful Rest API.

I wrote an internal tool to detect the abnormal processes running in endpoints, like the examples I described above. Further, to reduce the false positive rate in certain situations, it would be better for us to know if a process is cryptographically signed or not.

This signature is a simple but powerful indicator to provide insight into if a process is “malicious” or not. While the signature isn’t a perfect indicator as some advanced exploitation techniques such as DLL Injection can rely on the pedigree of the parent process, it is very helpful when analyzing large amounts of process information.

During my analysis, I found that if the Carbon Black Process and Binary Search API is used directly, you cannot grab the signing information from the response. The following is an example json response for the process searching result.

u'results': [{u'childproc_count': 0, 
     u'cmdline': u'/usr/bin/git rev-list --left-right master...origin/master', 
     u'comms_ip': -1062698981, u'crossproc_count': 0, 
     u'current_segment': 0, 
     u'emet_config': u'', 
     u'emet_count': 0, 
     u'filemod_count': 0, 
     u'filtering_known_dlls': False, 
     u'group': u'MAC Devices Group', 
     u'host_type': u'workstation', 
     u'hostname': u'host001', 
     u'id': u'-8377683872379532238', 
     u'interface_ip': 0, 
     u'last_update': u'2017-06-23T14:26:19.601Z', 
     u'modload_count': 0, u'netconn_count': 0, 
     u'os_type': u'osx', u'parent_md5': u'000000000000000000000000000000', 
     u'parent_name': u'Code Helper', 
     u'parent_pid': 75463, 
     u'parent_unique_id': u'53f564bf-ce84-ce9d-0000-000000000001', 
     u'path': u'/usr/bin/git', u'process_md5': u'82a7bf2b1f51f1988be571b8176aa545', 
     u'process_name': u'git', u'process_pid': -1, 
     u'processblock_count': 0, 
     u'regmod_count': 0, 
     u'segment_id': 1, 
     u'sensor_id': 31, 
     u'start': u'2017-06-23T14:26:19.601Z', 
     u'terminated': True, 
     u'unique_id': u'8bbc7ce7-aa4c-8c32-0000-000000000001', 
     u'username': u'user001'}]

Solutions

After doing additional research, I found that while I can’t get the signing information from the Rest API directly, it does exist in the backend.

With this information, I started to test using other keywords for searching queries to see if there is any difference in the result, but unfortunately, I still found nothing related to signing information.

After reading more of the query documentation, I found you can search for signing information with query strings like: digsig_publisher, digsig_issues, digsig_subject, digsig_prog_name, digsig_result, digsig_sign_time.

However, this query string won’t inform you if a specific process is signed or not; it could only be used to in searching queries as one of the requirements. Essentially, those “searching queries” can only be used to filter the signed process; you won’t be able to grab signing information from the actual response, but you will be able to track if the process is signed on the queries provided.

I started to use joint searching queries to grab some signing information about a specific process. This time the new method works and after trying some of the joint searching queries, I found if I use process_md5 and digsig_prog_name together, I can get the result I want.

The search query would become:

'q=process_md5%3A' + <process_md5> + '%20digsig_prog_name%3A' + <process_name> + '&rows=1&start=0&sort='

If the process is not signed, I would get nothing in result, because you can’t get the signed process name with a not signed process md5. On the other hand, if there is any result in the json response, we can say it’s signed.

For not signed process, the response you would get is like the following:

{u'elapsed': 0.00925898551940918, 
     u'facets': {}, 
     u'filtered': {}, 
     u'highlights': [], 
     u'results': [], 
     u'start': 0, 
     u'tagged_pids': {}, 
     u'terms': [u'process_md5:3d485deffe2f74d0c15f1cb23086f936', 
     u'digsig_prog_name:git'], 
     u'total_results': 0}

For signed processes, you would still receive the similar result with detailed information like what was shown earlier in the blog post.

No single tool is a solution for comprehensive security monitoring — a variety of data sources and activity are required to get a full picture of behaviors, threats, and countermeasures.

The Carbon Black API is a rich source of information which can enhance the value of abnormal behavior alerts when queried and integrated into automation and investigative activities. Cryptographic signing of processes is a common practice with modern operating systems and the use of this feature can help reduce noise and speed analysis efforts.

At Dwolla, security is never done. We take an interactive approach to improvement, and we’ll continue to share new InfoSec and security monitoring insights as we learn.

Interested in joining our team? Visit the careers page now.

Originally published by Chen Cao at www.dwolla.com on September 14, 2017.