security_wiki:quick_guide_to_carbon_black [Owlbear Consulting

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{ :security_wiki:bit9-plus-carbon-black-tagline.png?nolink&150|}}
===*Crash Course in Carbon Black*===

This document provides an introduction to the Carbon Black user interface and will demonstrate a little bit of the workflow and, most importantly, some things to look for.

NOTE: _Carbon Black strongly prefers *Chrome*!  It works with Firefox, but not well. It will not work with IE at all._

====Introduction====

<u>What Carbon Black Is</u><br />
From their [[https://www.bit9.com/solutions/carbon-black/]], _Carbon Black sensors collect 6 things:<br />
      1) A record of all execution (this includes EXE, DLL, SYS, and any other executable)<br />
      2) A record of all filesystem modifications<br />
      3) A record of all registry modifications<br />
      4) A record of all network connections<br />
      5) A copy of every unique binary<br />
      6) (Most importantly) The relationship among these events_

The Carbon Black server stores these events and makes them searchable through the Administrative Console.

At the most basic level, Carbon Black is a process monitor.  It simply watches for processes to be started, then captures all related activity (filesystem and registry reads/writes, network communications, spawned child processes, etc).  As such, if an executable file has not run or been accessed by another file or process, Carbon Black will have no knowledge of it.

One of the nice features of Carbon Black is that, in addition to the metadata it collects, it will retain a copy of every unique binary that has run across the enterprise.  So if someone is infected via a dropper and the resulting malware attempts to cloak itself, you will have copies of every file that was involved in the process, including the dropper and any intermediate files, along with every detail of what actions they took on the host.

<b><u>Changes in Version 5</u></b><br />
Version 5 adds the capability to conduct incident response on any endpoint with a Carbon Black sensor installed.  There are 2 options that can be used together or separately:
   * *Endpoint Isolation* - The ability to instruct an endpoint to only communicate with the Carbon Black server, all other network activity is blocked (ARP, DNS and DHCP services continue to run as they are required for communication with the server).
   * *Live Response* - Open a command interface to directly access any endpoint with a sensor installed.

<br />

<u>What Carbon Black Is <i>Not</i></u><br />
      <b>System Scanner</b> – Cb does not actively scan files, filesystems, or processes; it simply captures process activity and reports certain details about the files that spawned them and how they interacted with the filesystem.<br />
      <b>Data Logger</b> – Cb does not capture email, IM, keystrokes, screenshots, data files, pcaps, or any communications information, with the exception of destination IP and domain, if applicable<br />
      <b>Deep Forensics Tool</b> – Process object information like handles (open files, mutexes/semaphores, events, etc), threads, memory sections, and sockets are not available from within Carbon Black

====Brass Taxes====
=====Overview=====

Carbon Black provides a simple, intuitive interface that allows analysts to quickly identify and drill down into process information that could indicate a potential compromise or other suspicious activity.  The UI is broken into the following major sections:

<b><u>DETECT</u></b><br />

<b>Dashboard</b><br />
The Dashboard is new in version 5.  It displays overview information about alerts found on hosts including the number of hosts, the number of unresolved alerts and the average age of unresolved alerts.  You can sort hosts, users and unresolved alerts by time or severity.

<b>Threat Intelligence</b><br />
The Threat Intelligence page displays information about Alliance Partner and custom intelligence feeds.  You can also access information about process and binary matches found by each feed, and configure feed behavior (if permissions allow).

<b>Triage Alerts</b><br />
Triage Alerts is a listing of watchlist hits and IOCs defined by feeds.  The criteria (status, username, hostname, etc.) can be used to search for specific events.  The events displayed are sorted by severity by default.

<b>Watchlists</b><br />
Watchlists are only minimally useful in the current configuration.  The idea is that when you detect a compromise, you can add the details of the event to a watchlist and alert on future hits. Alerts can be received via SIEM and/or email.  Carbon Black supplies a very basic list, but the intent is to add as you go.

<br />

<b><u>RESPOND</u></b><br />

<b>Process Search</b><br />
Process Search is the best place to go if you want to review process information across the enterprise.  Here you can review executed processes from the entire sensor network in near real-time, or you can refine your query all the way down to detailed process activity on a single host in a specific time frame.

<b>Binary Search</b><br />
The Binary Search is essentially the same interface as Process Search, but focuses on executable files.  This allows you to view the database information from a different angle.  This search makes it easy to identify suspicious binaries and drill into them for further details.

<b>Go Live</b><br />
Go Live.

<b>Investigations</b><br />
The Investigations menu is where you can store and pick up previous investigations, which are essentially a timeline of tagged events.  Adding events to an investigation provides a complete picture of what happened in a single screen (once you have identified and added all related events).  Think of it as a chronological cork board that you can add or remove events from.

<br />

<b><u>OTHER</u></b>

<b>Notifications</b><br />
The Notifications drop-down will display acknowledgement of system changes, like when a new watchlist or user is created.  They will clear themselves out after you view them or log out of the UI.

<b>Administration</b><br />
The Administration menu contains a server dashboard, sensor inventory, user management, and system configuration settings.  This section is only available to Global Administrators.

====Get Started====

When you log in you are presented with the Carbon Black landing page (you can ignore the instructions for the sensor).  One thing worth mentioning at this point is that there are multiple ways to look at any one piece of evidence in Carbon Black.  As such, there is no right or wrong way to come to a conclusion. As you gain experience with the tool you will develop your own style of workflow, so investigate however it's most comfortable for you.

The next few sections will describe the key parts of the user interface and what they mean.  Since it's listed first, we'll start with the *Detect* tab; hover your cursor over the Detect menu item at the top and click the first option, Dashboard:

{{ :security_wiki:02a_Detect-Dashboard.jpg?nolink}}

<br />


#DashBoard
=====Dashboard=====

The first thing you'll notice about the dashboard is that we're not making use of Carbon Black's alert/resolution mechanism.  This may change at some point in the future, but at the time of this writing the Dashboard is useful for general trending, such as top 10 lists and a graphical display of alert trends over time.  If you want to view specific alerts you can hit the *Alerts* button at the top right or drill in from one of the tables.  Here is what the Dashboard looks like:

{{ :security_wiki:03a_Dashboard.jpg?nolink&857|}}


   1 *Overview* - The numbers at the top are online hosts and alerting statistics, with a graphical depiction of alerts over a 30 day period just below.
   1 *Top 10 Users & Hosts* - Self-explanatory; sorted by time by default.
   1 *Top 10 Alerts* - Self-explanatory; sorted by time by default.
   1 *Statistics & "Leaderboard"* - These are primarily beta features and aren't used at this time (June, 2015).
#ThreatIntelligence
=====Threat Intelligence=====

#TriageAlerts
=====Triage Alerts=====

#WatchlistManagement
====Watchlists====
=====Adding Watchlists=====

A *Watchlist* is a pre-defined query that is able to alert either via email or syslog when the criteria are met.  As you might expect, there are two types of watchlists: process-based and file-based.  The type depends on where you construct the query, Process Search or Binary Search.  Once you are happy with the query you've constructed, you can turn it into a Watchlist by clicking the Actions button in the top-right of the screen and selecting "Add Watchlist":

<img alt="" src="%ATTACHURLPATH%/Actions_AddWatchlist.jpg" />

At this point you'll be asked to name the watchlist, you can also enable email notifications when the watchlist fires (you can change this at any time):

<img alt="" src="%ATTACHURLPATH%/Actions_AddWatchlistConf.jpg" />

After you've made your selections click "Save Changes" and your new watchlist will appear on the Search &gt; Watchlists page.
=====Deleting Watchlists=====

You can also delete watchlists by navigating to Search &gt; Watchlists and selecting the one you want to delete (on the left), then click the Delete button in the top-right:

<img alt="" src="%ATTACHURLPATH%/DeleteWatchlist-sm.jpg" /><br />

You will be presented with a confirmation dialog, make sure you have the correct watchlist selected before permanently removing it from the list!
====="Editing" Watchlists=====

The word Editing is in air bunnies because that's not really what we're going to do here.  The reality is that once a Watchlist has been created you can only change its name or delete it.  If you wish to "edit" an existing watchlist while maintaining the existing watchlist name use the following process:<br /><br />
The short version:
   1 Change existing watchlist name
   1 Make new watchlist with updated query and give it the old name
   1 Delete old watchlist
The TL;DR version:
   1 Highlight the watchlist to edit on the left side of the page.
   1 Click the pencil icon just to the right of the watchlist name, this will allow you to edit it.
   1 Change the name to something easily identifiable (e.g. add "-old" to the end).
   1 Hit Enter to make the change.
   1 Next click the Search button in the top-right corner. This takes you to a Process Search that will have the original watchlist query in the Search box at the top of the page.
   1 Edit your query as appropriate and select Actions &gt; Add Watchlist.
   1 Name the watchlist the same as the original that you wanted to edit.
   1 Once the new watchlist is in place and confirmed to be working properly you can delete the old one.
   1 Because we've created a new watchlist rather than edit an existing one, the SOC will need to subscribe to the new watchlist (as appropriate).

Why not just create a new watchlist?  The reason is because ArcSight will be configured to identify watchlists by name in order to bubble them up to the main channel.  This is the only way to separate out the "noisy" watchlists like Autoruns and Newly Loaded Modules (which would probably DDoS the main channel) from alerts that we actually want to know about.  This is a clunky way to go about Watchlist management, hopefully Bit9/Cb will allow editing of existing watchlists in the future.

=====Subscribing to Watchlists=====

To subscribe/unsubscribe to a watchlist, simply check the box to the right of the pencil icon.

====Final Note====

One last word about watchlists, any CB user can create or delete them.  Be aware that when you create a watchlist and subscribe to it you will be the <u>only</u> one that will receive email alerts.  This is great for testing queries and refining watchlists before having others subscribe to the alerts.  For the SOC (or anyone else) to receive alerts they would have to manually subscribe to it by logging in to their account and ticking the checkbox.

====Process Search====

Most queries of the Carbon Black database will start with the Process Search interface.  Carbon Black designed the UI to be an interactive sort and filter.  You begin with a view of everything in the Carbon Black database and every item you click on will filter the data displayed on the rest of the page.  For example, if you click on a process under Process Name and that exact same process is running on 3 systems, only those 3 hosts will be displayed in the “Hostname” metadata column.

Here is the main Process Search interface:

<img alt="" height="580" src="%ATTACHURLPATH%/02_Search-ProcSearch.jpg" width="892" />

      1) *Primary Search* – where manual queries can be constructed, can be as simple as a file name<br />
      2) *Add Criteria* – Point & Click interface for query construction; global filter<br />
      3) *Reset search terms* – Resets the entire query<br />
      4) *Grouped Metadata* – Key details about running processes, clicking toggles filter on/off<br />
         - If an MD5 is selected (click or mouse-over) a detail pane appears in the results region<br />
      5) *Time Filters* – allows filtering on temporal data, clicking toggles filter on/off<br />
      6) *Related Events* – These are the results of the current query/filter, which can be sorted on

<u><b>Notes on Syntax</b></u><br />
If you construct queries manually, which is often helpful, here are some tips that will make that task easier:
   * Terms without fields are expanded to search all default fields
      * For a listing of default fields see the [[%ATTACHURL%/Carbon_Black_v4.2_-_Query_Overview.pdf][Query Overview]] document
   * Searches are (generally) case-insensitive
   * *Terms are whitespace delimited*, so use double-quotes when required. (e.g, <font face="Courier New" size="2"> filemod:"c:\program files" </font>)
      * Whitespace is the only delimiter, using commas, semicolons, etc. _will_ cause problems with your search
   * Full boolean support with AND, OR and -
      * Multiple terms are AND’ed if not otherwise specified
   * Nested boolean support with parenthesis. (e.g. <font face="Courier New" size="2"> (foo or bar) baz </font> )
   * Force phrase searches with double-quotes: <font face="Courier New" size="2"> "foo\bar" </font>
   * Terms can be limited to a single field with <font face="Courier New" size="2">field:term</font>-style syntax, (e.g. <font face="Courier New" size="2"> process_name:svchost.exe </font> )

For details on the Carbon Black query language, please see the [[%ATTACHURL%/Carbon_Black_v4.2_-_Query_Overview.pdf][Carbon Black Query Overview]] document, or...

=====example of building a query...=====

Let's take the Watchlist "Non-System Filemods to System32" and refine it.  The goal of this watchlist is to detect processes that make changes to the C:\Windows\System32 directory.  This occurs legitimately on a regular basis, so this incredibly noisy watchlist needs a lot of tuning before it can be useful.  Here is the query for the stock watchlist:

      <b><font color="DarkGreen" face="Courier New" size="2">-path:"c:\windows" filemod:"c:\windows\system32"</font></b>

Notice the '-' in front of *path*, this is because it is normal for processes that start in the C:\Windows directory to write to System32 so we want to exclude those hits from the results.  The second part says "return any process that modifies a file in C:\Windows\System32\".  Between these parameters we have weeded out a bunch of database hits that aren't of interest to us, but if you take a look at the results you'll find a number of other things that need to be excluded from the query.  Most of the legitimate processes are easy to spot, program updates run from C:\Program Files, updates to Adobe Flash Player and Malwarebytes scans to name a few.  So how do we refine this?

One thing that seems suspicious from the results is when a process that runs from C:\Users\<user>\appdata\local and modifies the System 32 directory, so let's exclude all other potential paths and zoom in on that directory path.  Then our query becomes:

      <b><font color="DarkGreen" face="Courier New" size="2">-path:"c:\windows" filemod:"c:\windows\system32" %BLUE%path:"c:\users"%ENDCOLOR%</font></b>

Now we're getting somewhere, but there are still a lot of obviously legitimate processes making it through our filter.  In most cases signed processes can be trusted, so let's exclude anything that has a legitimate digital signature (again using a '-' before the parameter):

      <b><font color="DarkGreen" face="Courier New" size="2">-path:"c:\windows" filemod:"c:\windows\system32" %BLUE%path:"c:\users" -digsig_result:"Signed"%ENDCOLOR%</font></b>

Now we're really getting somewhere.  In my case I'm still seeing a lot of Malwarebytes-related processes as well as another process called "Infinst.exe".  The latter turned out to be legitimate despite its many variations and the lack of a digital signature (it installs drivers for Intel chipsets when required and is often associated with starting games from a popular gaming service; looking at you Gaben...  :) ) Now the query becomes:

      <b><font color="DarkGreen" face="Courier New" size="2">-path:"c:\windows" filemod:"c:\windows\system32" %BLUE%path:"c:\users" -digsig_result:"Signed" -process_name:mbam* -process_name:infinst.exe%ENDCOLOR%</font></b>

At the time of this writing the original watchlist had nearly 50,000 hits.  After making these small tweaks to the query the number of results dropped from ~50,000 to 30 (yes, _thirty_) processes to investigate.  Many of these are also legitimate - EnCase setup running from C:\Users\administrator for example - but the it's better to have too much than too little.  Once the legit hits are removed we're down to a handful of processes that are truly worthy of further investigation.


Once you have found something interesting to drill in to, you can click the process name or the ‘&gt;’ to the right of the result to navigate to the Process Analysis page:

<img alt="" height="628" src="%ATTACHURLPATH%/03-ProcessAnalysis.jpg" width="831" />

      1) *Process Visualization* – shows all parent, sibling, and child processes<br />
      2) *Grouped Metadata* – all metadata that relates to the process being examined<br />
      3) *Detailed Metadata* – shows details, history, and frequency of the process currently highlighted<br />
      4) *Timeline* – Sortable chronological history of records specific to the highlighted process<br />

The entire Process Analysis view is dynamic and will change depending on what you have highlighted.  Data in this view responds to both clicks and mouse-overs, so it’s worth clicking and hovering around to become familiar with the information and how you can manipulate it.  There is a wealth of information here.

Just to show an example of a fairly busy process, have a look at the execution list that the Wajam toolbar creates:

<img alt="" src="%ATTACHURLPATH%/ProcTreeExample_wajam.jpg" />

====Binary Search====

The Binary Search interface is nearly identical to the Process Search interface, but the data available to query all revolves around the PE files in the Carbon Black database:

<img alt="" height="624" src="%ATTACHURLPATH%/04-BinarySearch.jpg" width="883" />

      1) *Primary Search* – same as Process Search; manual query, criteria query, and reset<br />
      2) *Grouped Metadata* – Metadata filters having to do with binary file information<br />
      3) *Time & Alliance* – Time filtering and Carbon Black Alliance information<br />
      4) *Related Metadata* – Query results<br />
<br />

When you’ve narrowed it down to files you’re interested in you can drill into each binary individually:

<img alt="" src="%ATTACHURLPATH%/04a-BinarySearchResult.jpg" />

<br />

You can also click on the View link which opens a browser tab with Virus Total results.  This functionality is only available if there are hits on Virus Total.

Just to the right of the View link is an icon to show whether or not the binary has any Watchlist hits; green for one or more hits, grey for no hits.  If green, you can mouse-over the icon to see how many Watchlist items were matched.

The Binary Analysis interface looks like this:

<img alt="" height="606" src="%ATTACHURLPATH%/05-BinaryDetail.jpg" width="880" />

      1) Key file details<br />
      2) Investigative tools:<br />
         a. Watchlist hit(s)<br />
         b. File Writers – Search that identifies the parent process(es) that wrote this file<br />
         c. Related Processes – Search on all processes that have a relationship to this binary<br />
         d. Carbon Black’s version of [[http://lmgtfy.com/][LMGTFY]]<br />
      3) Frequency data and partner information (currently only Virus Total, iSight Partners coming soon)<br />
      4) File metadata, operating system, and listing of other hosts that have run this exact binary

This page provides comprehensive details on a file, it’s frequency on the network, and other valuable information.  The investigative tools are incredibly useful and should always be drilled in to.  This is also the only part of the interface where you can download the file for detailed analysis.  Unless you know what you are doing I do not recommend this feature!

====Investigations====

WIP

Do feel free to create/delete your own investigations too see how it works.  This is a powerful feature of Carbon Black that should not be overlooked.  Based on experimentation it seems pretty straightforward: you just create an Investigation (or select the investigation you have already been working on) and tag the interesting events from the Process Analysis results.  When you go to the Investigations menu and select your investigation from the drop-down, the tagged events show up in the data fields below.

NOTE:  <i>At the time of this writing (June '14) the sorting feature is somewhat broken; it appears to sort on day of week rather than actual date/time.  It still groups events on the same day properly, just pay attention to the datetime of the event after sorting.</i>

===Summary===

WIP

<br /><br />
#HuntingBasics
===*APPENDIX A: Stuff to Look For*===

Now that we have an idea of how to navigate the interface, we need some things to look for.  Much of this information comes from the experience of repeatedly seeing what is normal, and therefore being able to easily identify things that are not normal.  This is by no means a comprehensive list, but will provide a starting point.

<b><u>Process Name</u></b><br />
The name of the process or executable itself can provide valuable information.  If you are familiar with what processes are normally running on Windows hosts you should be able to easily identify processes that warrant further investigation.

A good place to look for suspicious processes is at or near the bottom of the Process Name metadata in the Process Search interface.  It’s unlikely that there will be thousands of instances of malware across all the hosts, so focus on processes that have low number of instances, especially if on a low number of hosts as well, and research anything that looks suspicious, or that you’re not familiar with.

<b><u>Full Path</u></b><br />
Malware will sometimes camouflage itself as a legitimate process name, but it will run from a different location from the legit process.  These are easy to identify in Carbon Black by iterating through common Windows processes and looking for any that run from non-standard locations.

For example, if you select svchost.exe from the Process Name metadata in the Process Search, you should ONLY see “C:\Windows\System32\svchost.exe” in the Process Path field.  In this case, the parent process should be “services.exe”.  If one or both of these conditions are not true it is time to go down the rabbit hole.

<b><u>Parent Process</u></b><br />
Similar to paths, parents of legitimate processes are always the same.  Anything that strays from the standard convention should be investigated further.

For example, many user applications have a parent process of “Explorer.exe”, which is the user shell.  So if you see a process named “svchost.exe” with “Explorer.exe” as its parent, that is clearly suspicious.  Another example is that the average user doesn’t use “cmd.exe” very often, so strange processes spawned this way also deserve further vetting.  Pay particular attention to the parameters that are passed.

Understanding of the parent processes is also helpful since it allows you to determine where in the system boot hierarchy something was loaded.  A process that has a parent of “Services.exe” could have been spawned at boot time (and possibly have a persistence mechanism), where a process parented by “Explorer.exe” is likely a user process that would have started sometime after logon.

<b><u>Searching Binaries</u></b><br />
The most useful functionality in the Binary Search page is when you already know the name of the file you’re looking for.  For example, if Spectrum picks up a successful download of a known malicious file, you can search in Carbon Black to see if the file executed, what systems it has been executed on, and everything that happened thereafter.

If you’re on a recon mission, probably the best place to start is filtering on the digital signature type.  Malware is almost never signed and can throw some other red flags depending on its behavior.  Scrolling through Publisher, Company Name, and Product Name can also yield some interesting information. How about unsigned versions of kernel32.dll?  Binaries with scores at VirusTotal, binaries with explicit distrust, check for binaries that are run from strange file paths... Get creative!

Once the field of suspects is narrowed down you can sort, filter, and drill down on anything interesting in the Binary Analysis interface.

<b><u>A note about digital signatures</u></b><br />
Most of us think about digital signatures in two basic forms, signed and unsigned.  However, there are a total of 8:
   * Signed
   * Unsigned
   * Expired
   * Explicit Distrust
   * Invalid Chain
   * Bad Signature
   * Untrusted Root
   * Invalid Signature
This matters because it affects how we construct our queries.  If you want to see unsigned binaries you would use "<font color="blue" face="Courier New" size="2">digsig_result:unsigned</font>".  However, if you want to see binaries that are not signed - the remaining 7 - you would use "<font color="blue" face="Courier New" size="2">-digsig_result:signed</font>".  By adding the "-" before digsig_result and changing "unsigned" to "signed" we're telling Carbon Black to exclude all signed binaries, but show us everything else.

<br /><br />
#SampleQueries
===*APPENDIX B: Sample Queries*===

The default Watchlists that come bundled with Carbon Black are a start, but they cast such a wide net that they tend to be very noisy; not exactly useful for monitoring.  The purpose of this section is to provide some ideas on how to refine queries, in this case based on a few variants of the out-of-the-box Watchlists.  The sample queries below are intended to be a starting point, and to demonstrate a couple of tips/tricks you can use to make your results more meaningful.  There is plenty of room for improvement!

<b><u>Refining the built-in .cn/.ru watchlist query:</u></b><br />

Original query:<br />
<font color="blue" face="Courier New" size="2">
domain:.ru or domain:.cn
</font>

Refined query:<br />
<font color="blue" face="Courier New" size="2">
(domain:.su or domain:.ru or domain:.xn--p1ai) -process_name:chrome.exe -process_name:"Google Chrome" -process_name:firefox.exe -process_name:waterfox.exe -process_name:"Firefox" -process_name:iexplore.exe -process_name:opera.exe
</font>
   * This excludes common browsers from the results so you can focus on other apps that are phoning home
   * Add "<font color="blue" face="Courier New" size="2">-digsig_result:signed</font>" to exclude signed binaries
   * "<font color="blue" face="Courier New" size="2">.xn--p1ai</font>" is a punycode version of ".ru"
   * Replace "<font color="blue" face="Courier New" size="2">(domain:.su or domain:.ru or domain:.xn--p1ai)</font>" with "<font color="blue" face="Courier New" size="2">domain:.cn</font>" to switch offenders
      * Don't forget about other countries! Pull up a [[https://www.google.com/maps][map]] and try neighboring countries, you can find country tld's [[http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains][here]].

<b><u>VirusTotal Grey Area (4-9 hits), refined:</u></b><br />

Original query:<br />
<font color="blue" face="Courier New" size="2">
alliance_score_virustotal:[4 TO 9]
</font>

Refined query:<br />
<font color="blue" face="Courier New" size="2">
alliance_score_virustotal:[4 TO 9]  -path:*ask.com* -path:*askpartnernetwork* -digsig_result:signed
</font>
   * Excludes ask.com crap and signed binaries from the results

<b><u>Non-system Filemods to system32, refined:</u></b><br />

Original query:<br />
<font color="blue" face="Courier New" size="2">
-path:c:\windows\*
</font>

Refined query:<br />
<font color="blue" face="Courier New" size="2">
filemod:c:\windows\system32\* -path:c:\windows* -path:c:\program\ files\* -path:c:\program\ files\ \(x86\)\* -path:c:\users\administrator\* -path:c:\users\snei-admins\* -path:c:\programdata\sony\ corporation\* -path:c:\workspace\cassandra\* -path:c:\cygwin64\* -digsig_result:"Signed" -process_name:mbam* -process_name:_iu14d2n.tmp -process_name:infinst.exe -process_name:omtsreco.exe -path:c:\oraclexe\* -path:c:\dell\* -path:c:\acer\* -path:c:\programdata\dell\*
</font>
   * Note that "<font color="blue" face="Courier New" size="2">-path:c:\program\ files\ \(x86\)\*</font>" can also be represented as "<font color="blue" face="Courier New" size="2">-path:"c:\program files (x86)\*"</font>"

<b><u>Same as previous, but for 64-bit architectures:</u></b><br />

Original query:<br />
<font color="blue" face="Courier New" size="2">
-path:c:\windows\*
</font>

Refined query:<br />
<font color="blue" face="Courier New" size="2">
filemod:c:\windows\syswow64\ -path:c:\windows\* -path:c:\program\ files\* -path:c:\program\ files\ \(x86\)\* -path:c:\users\administrator\* -path:c:\users\snei-admins\* -path:c:\oracle\* -digsig_result:"Signed" -process_name:_iu14d2n.tmp  -process_name:omtsreco.exe -process_name:oradim.exe -process_name:httpd.exe -process_name:testapp.exe  -process_name:flashplayerinstaller.exe
</font>

<b><u>Search multiple Watchlists for certain criteria:</u></b><br />

<font color="blue" face="Courier New" size="2">
(watchlist_1:* or  watchlist_3:* or watchlist_8:*) -digsig_result:signed
</font>
   * This query will return any binaries that are not signed (unsigned, expired, broken chain, etc.) from the "Non-System Filemods to system32", "Netconns to .cn or .ru" and "Autoruns" Watchlists
   * To find the Watchlist ID, simply navigate to *Detect &gt; Watchlists*, highlight the Watchlist of interest, and look at the URL in your browser, the Watchlist ID is here:
<img alt="" height="430" src="%ATTACHURLPATH%/WatchlistID.jpg" width="532" />

<br /><br />
#KnownIssues
===*APPENDIX C: Known Issues*===

   * Email alerts for Watchlists are broken in v5.0
   * Live Response is non-functional in v5.0
   * Mac sensors do not appear to collect much data (needs verification)
   * Linux sensors are broken; 0% success rate for installs on 4 sample Linux OS's

<br /><br />
#VendorDocs
===*APPENDIX D: Vendor Documentation*===

   * [[%ATTACHURL%/Carbon_Black_v5.0_-_User_Guide.pdf][User Interface Guide]]

<br /><br /><br /><br />Don't Panic.