IMPORTANT ANNOUNCEMENT: On May 6, 2024, Carbon Black User eXchange (UeX) and Case Management will move to a new platform!
The Community will be in read-only mode starting April 19th, 7:00 AM PDT. Check out the blog post!
You will still be able to use the case portal to create and interact with your support cases until the transition, view more information here!

EDR: How to Determine if a Binary has been Received by the Server and Scanned by Yara

EDR: How to Determine if a Binary has been Received by the Server and Scanned by Yara

Environment

  • EDR: 7.x and Higher
  • Yara: 2.x

Objective

To determine whether a specific hash value has been uploaded to the EDR server and whether Yara has already scanned it. 

Resolution

Querying PGSQL
A record of all collected hashes is stored on the primary server pgsql db in the storefiles table. 
To see a specific record :
  1. On the primary server, run:
# psql -d cb -p 5002 -c "select * from storefiles where md5hash='\x<hash>';"
where <hash> is the lower-case value of the md5sum being queried. 
example: md5hash='\x22ea17f020dc46f8bb4270cb31358acc ';"
The '\x' is generally required.
  1. Run: 
# psql -d cb -p 5002 -c "select * from binary_status where md5hash='\x<hash>'
where <hash> is the lower-case value of the md5sum being queried. 
example: md5hash='\x22ea17f020dc46f8bb4270cb31358acc ';"
The '\x' is generally required.

Querying YARA
To determine if Yara has seen a specific hash before, query the SQL lite file from the primary server:
  1. Run:
# sqlite3 /var/cb/data/cb-yara-connector/feed_db/binary.db
  1. Run the query:
sqlite> select * from binarydetonationresult where md5='<hash>';
where <hash> is the lower-case value of the md5sum being queried. 
example: md5='22ea17f020dc46f8bb4270cb31358acc ';"

 

Additional Notes

  • The Yara connector uses the postgres storefiles table to confirm if the physical binary is still local and which node it exists on (clustered) in order to do the scan
    • When sharing hashes, these are deleted locally and are not available for scanning if the binary was already seen before the connector and/or rule was implemented
    • Manually deleting the binaries from /var/cb/data/cbmodules can cause errors on lookup, instead rely on the 'binary_purge' job that is enabled by default. 
  • The Yara connector creates a feed report that is binary based IOC. Non-query based IOC's hit at ingress of data, this means that you will not get alerted on by the first hit as the Yara connector scans the binary file after ingress. CB-42584 was created to enhance the connector to alert on the first seen. 
  • \x is required for the pgsql query.
  • \x is not needed in the Yara sqlite db.  

Related Content


Labels (1)
Tags (2)
Was this article helpful? Yes No
100% helpful (1/1)
Article Information
Author:
Creation Date:
‎04-22-2024
Views:
53