nvisosecurity/pycobalthoundpyCobaltHound is an Aggressor script extension for Cobalt Strike which aims to provide a deep integration between Cobalt Strike and Bloodhound.
pyCobaltHound is an Aggressor script extension for Cobalt Strike which aims to provide a deep integration between Cobalt Strike and Bloodhound.
pyCobaltHound strives to assists red team operators by:
BloodHound database to discover escalation paths opened up by newly collected credentials.To accomplish this, pyCobaltHound uses a set of built-in queries. Operators are also able to add/remove their own queries to fine tune pyCobaltHound's monitoring capabilities. This grants them the flexibility to adapt pyCobaltHound on the fly during engagements to account for engagement-specific targets (users, hosts etc..).
To install pyCobaltHound clone this repository. Do not forget to also clone the included submodule!
You can use the following command:
git clone https://github.com/NVISOsecurity/pyCobaltHound.git --recurse-submodulesEnsure that the following dependencies are correctly installed:
PyCobalt is a Python API for Cobalt Strike. It exposes many Aggressor functions to be used directly from Python.
Ensure that you have Python3+ installed. While PyCobalt may work on macOS and Windows as well, we have only really tested it on Linux.
There are two ways to use the PyCobalt Python library:
pyCobaltHound takes this approach, setting the search path from within the Python program using the variable sys.path variable.PyCobalt Python library. To do so, run python3 setup.py install. You will have to modify pycobalthound.py to ensure that it used the installed library instead of the one in the included repository.PyCobalt project will be maintained in the future. In fact, the latest update to the project was to incorporate the changes made in Cobalt Strike 4.2. Since pyCobaltHound only really uses basic Aggressor functions to interface with Cobalt Strike and its operator however this is not a big problem for pyCobaltHound.PyCobalt submodule used in this project is a fork done by us. We do not control the PyCobalt repository however.PyCobalt comes with some Script Console commands to manage the running Python scripts. When you reload your Aggressor script you should explicitly stop the Python scripts first. Otherwise they'll run forever doing nothing. During pyCobaltHound's development we noticed that this can also lead to undefined behavior.
Reloading pyCobaltHound can be done as follows:
aggressor> python-stop-all`
[pycobalt] Asking script to stop: /root/pycobalthound/pycobalthound.py
[pycobalt] Script process exited: /root/pycobalthound/pycobalthound.py
aggressor> reload example.cna`
[pycobalt] Executing script /root/pycobalthound/pycobalthound.py
For PyCobalt to work properly you can only call PyCobalt in one Aggressor script. Keep this in mind if you want to use pyCobaltHound together with other Aggressor scripts that use PyCobalt. Our approach is to have an Aggressor script with a calls to python() and include() for every PyCobalt based tool.
notify2 is - or was - a package to display desktop notifications on Linux. As we will see later pyCobaltHound supports a few ways of notifying the operator. notify2 is used on Linux to send notifications to the notification daemon over D-Bus.
To enable this, notify2 needs to be installed using:
pip install notify2
Using pyCobaltHound in Cobalt Strike is as simple as importing the pycobalthound.cna Aggressor script into your client. Once this is done you should see apyCobaltHound menu appear in your Cobalt Strike menubar.
pyCobaltHound's initial goal was to monitor Cobalt Strike's credential cache (View > Credentials) for new entries. It does this by reacting to the on_credentials event that Cobalt Strike fires when changed to the credential store are made.
When this event is fired, pyCobaltHound will:
Cobalt StrikeBloodHound databaseBloodHound database for each new entity using both built-in and custom queries.Since all of this takes place asynchronously from the main Cobalt Strike client this process should not block your UI so you can keep working while pyCobaltHound investigates away in the background.
pyCobaltHound uses seperate caches per teamserver to prevent issues when using multiple teamservers.
Sometimes there are situations where you would want to investigate specific users (or the entire credential store) again. This might be the case when you've uploaded new data into the BloodHound database.
Since pyCobaltHound should have investigated (and therefore cached) all entities in your credential store already it will not evaluate them against this new data without some operator intervention.
Two methods are available to operators to control which entities are cached.
In cases where you wish to remove a specific entity (or multiple) from the cache you can do so in the credential viewer (View > Credentials). Simply select your target(s) and click the remove from cache option under the pyCobaltHound menu entry.
In cases where you wish to remove all entities from the cache you can do so in pyCobaltHound's main menu (Cobalt Strike > pyCobaltHound > Wipe cache). This is most helpful when you want to reevaluate your entire credential store.
After removing your targets from the cache you can manually prompt pyCobaltHound to re-investigate the contents of the credential store. This follows exactly the same process as above.
pyCobaltHound contains functionality to interact with existing beacon sessions. This can be found in the beacon context menu. Note that these commands can be executed on a single beacon or a selections of beacons.
This functionality is especially useful when dealing with users and computers whose credentials have not been compromised (yet), but that are effectively under our control (e.g because we have a beacon running under their session token).