Automatically restrict hunts

[bob1503]

In order to prevent (critical) hunts on OT related hosts we need to make sure that these hosts are always excluded from any hunt. As far as we understand this could be accomplished by modifying System.Hunt.Creation, which is ran whenever a new hunt is created. However, we might need a little help with the VQL syntax: how could we actually overwrite "include_labels" or "exclude_labels" of a hunt that was just created?

[scudette]

Note that hunts are just a convenient - you can emulate a hunt by running a query like

SELECT collect_client(client_id=client_id, ....) 
FROM clients()

will schedule a collection on all clients known to the system.

Are you asking about this from a security point of view or just to prevent an accident?

[bob1503]

In general we assume that each of our Velociraptor users knows what they're doing. Still, due to internal regulation we would need some kind of "fail safe" mechanism that prevents an analyst from accidently running "heavy" artifacts on critical hosts. I get your point that there is more than just one way to do that. How would you restrict it in terms of running a hunt?

[scudette]

So it seems that you are most concerned about running certain collections on an endpoint, not so much on a hunt (which is just collecting the same thing from many hosts at the same time).

Currently the ACL model does not have per-client granularity. If a user has the COLLECT_CLIENT permission they can collect any artifact on any client. We have a couple of mechanisms to control this:

1. The lockdown feature prevents all collections unless the system is in IR mode (i.e. the lockdown flag is removed). This is suitable for deployments which dont use Velociraptor daily but only in critical investigations.
2. We now have the concept of Basic collections which are simpler collections which should be safe to run everywhere. Rather than give users the COLLECT_CLIENT permission which allows users to collect anything, they can have the COLLECT_BASIC permission which only allows them to collect those same artifacts.

[bob1503]

Regarding the COLLECT_BASIC permission: which artifacts fall in this category? (Sorry, but I couldn't find it in the docs.)

[scudette]

It is up to you which artifacts are considered basic - the intention is that you create a set of "Basic" artifacts which will start more powerful artifacts perhaps after doing some sanitazation of user input etc.

You use this VQL function to designate an artifact as "Basic":
https://docs.velociraptor.app/vql_reference/misc/artifact_set_metadata/

[scudette]

Another way to segment a Velociraptor deployment is by using orgs - if you have a set of very sensitive endpoints you can create a totally separate org for them and provide only some users with access to that org. Users have different roles/permissions in different orgs so you can have most of the SOC have access to the rest of the network but the restricted org can have a limited set of users (while everyone else can be read only or not access at all or whatever).

[bob1503]

We are currently evaluating this option, but allow me to get back to my initial question regarding System.Hunt.Creation: the idea was to use this artifact to modify newly created hunts by automatically setting either include_labels or exclude_labels. However, as far as we understand hunt() always creates a new hunt and hunt_update() doesn't allow to modify include_labels or exclude_labels, is this correct?

[scudette]

That is correct - the hunt is created with the initial label include/exclude configurations. But labels are dynamic so if you assign a client one of the included labels after the hunt is created then it will be scheduled on it immediately.

This is normally how this feature is used - the labels represent e.g. compromised hosts or ones in scope, then analysts can assign labels to include them in the hunt. As you can see here https://docs.velociraptor.app/vql_reference/server/label/ a user only requires the LABEL_CLIENT permission to label a client, but that can trigger a larger workflow.

[bob1503]

Thank you for your fast replies. We'll discuss the options internally.