Sensor commands are commands that can be sent to the sensor (through the backend as an intermediary) to do various things.
These commands may rely on various collectors that may or may not be currently enabled on the sensor and have been marked as such.

Below is a high level listing of available commands and their purpose. Commands are sent like a command line interface
and may have positional or optional parameters. To get exact usage, either do a GET to the REST interface's /tasks
endpoint or issue the RPC get_help to the c2/taskingproxy category.

When issuing a task, the expected answer from the REST interface is an empty ({}) 200 OK. This because responses
from the sensor to a task may come right away or may trickle in over time (like in the case of the Yara scanning). To
prevent the REST interface from blocking for very long times, the responses to the tasks are simply sent as part
of the normal data flow from the sensor as response events. This means you can find the responses through the data in the
Output you have configured.

To assist in finding the responses more easily, the investigation_id mechanism was created. When issuing a task, you can include
an investigation_id, which is simply an arbitrary string you define, and that ID will be included in all related responses from
the sensor (routing/investigation_id). Note that Outputs also support the inv_id parameter that allows you to create
an Output that will only receive data related to an investigation ID.

A common scheme is to set an investigation ID in all tasks sent during an interactive session and
to create an Output with this specific ID for the duration of the session. That way you can find all the
responses from your session in one place.

The investigation ID used for routing through Outputs only applies to the value of investigation ID that is before the first
instance of a / (slash) character. This allows you to overload an investigation ID by adding values after it, like:

my-inv-id
my-inv-id/task1
my-inv-id/task2

All the above will be routed to an Output set to receive the my-inv-id investigation ID.

An investigation ID beginning with a __ (double underscore) will also tell the Output system to ignore
that specific event from being forwarded to an Output. This can be useful, for example, while building a Service that
may fetch files, or dump bits of memory that are not useful to retain in the long term outside the service. This scheme
does not apply to the CLOUD_NOTIFICATION event for auditing reasons.

When you issue a task, you will see CLOUD_NOTIFICATION events coming back from your
sensor. Those events are simply "receipts" from your sensor to let you know they have
received a task and the contents of that task.

usage: dir_list [-h] [-d DEPTH] rootDir fileExp
positional arguments:
rootDir the root directory where to begin the listing from
fileExp a file name expression supporting basic wildcards like
* and ?
optional arguments:
-h, --help show this help message and exit
-d DEPTH, --depth DEPTH
optional maximum depth of the listing, defaults to a
single level

Display the map of memory pages from a process including size, access rights, etc.

Platforms: Windows, Linux, MacOS

Due to recent changes in MacOS, may be less reliable on that platform.

usage: mem_map [-h] [-p PID] [-a PROCESSATOM]
optional arguments:
-h, --help show this help message and exit
-p PID, --pid PID pid of the process to get the map from
-a PROCESSATOM, --processatom PROCESSATOM
the atom of the target proces

Due to recent changes in MacOS, may be less reliable on that platform.

usage: mem_strings [-h] [-p PID] [-a PROCESSATOM]
optional arguments:
-h, --help show this help message and exit
-p PID, --pid PID pid of the process to get the strings from
-a PROCESSATOM, --processatom PROCESSATOM
the atom of the target process

Turn on or off the high performance mode on a sensor. This mode is designed for very high performance servers requiring high
IO throughput. This mode reduces the accuracy of certain events which in turn reduces impact on the system. This mode is not
useful for the vast majority of hosts. If you are considering its usage, get in touch with the team at LimaCharlie.io.

Platforms: Windows

usage: set_performance_mode [-h] [--is-enabled]
optional arguments:
-h, --help show this help message and exit
--is-enabled if specified, the high performance mode is enabled, otherwise
disabled

The special command restart can be used to tell the LimaCharlie agent to re-initialize. This is usually only useful when
dealing with cloned sensor IDs in combination with the remote deletion of the identity file on disk.

usage: doc_cache_get [-h] [-f FILE_PATTERN] [-s HASHSTR]
optional arguments:
-h, --help show this help message and exit
-f FILE_PATTERN, --file_pattern FILE_PATTERN
a pattern to match on the file path and name of the
document, simple wildcards ? and * are supported
-s HASHSTR, --hash HASHSTR
hash of the document to get

Tells the sensor to stop all network connectivity on the host except LC comms to the backend. So it's network isolation, great to stop lateral movement.

Note that you should never upgrade a sensor version while the network is isolated through this mechanism. Doing so may result in the agent not re-gaining
connectivity to the cloud, requiring a reboot to undo.

This command primitive is NOT persistent, meaning a sensor you segregate from the network using this command alone, upon reboot will rejoin the network.
To achieve isolation from the network in a persistent way, see the isolate network and rejoin networkD&R rule actions.

Platforms: Windows, MacOS, Chrome

usage: segregate_network [-h]
optional arguments:
-h, --help show this help message and exit

Note on usage scenarios for the --is-ignore-cert flag: If the sensor is deployed
on a host where built-in root CAs are not up to date or present at all, it may be
necessary to use the --is-ignore-cert flag to allow the logs to be pushed to the
cloud.

Unlike the main sensor transport (which uses a pinned certificate), the
Artifact Collection feature uses Google infrastructure and their public SSL certificates.

This may sometimes come up in unexpected ways. For example fresh Windows Server installations
do not have the root CAs for google.com enabled by default.

usage: run [-h] [--payload-name NAME] [--arguments ARGUMENTS]
[--shell-command SHELLCMD] [--timeout TIMEOUT] [--is-ignore-cert]
optional arguments:
-h, --help show this help message and exit
--payload-name NAME name of the payload to run
--arguments ARGUMENTS
arguments to run the payload with
--shell-command SHELLCMD
shell command to run
--timeout TIMEOUT number of seconds to wait for payload termination
--is-ignore-cert if specified, the sensor will ignore SSL cert mismatch
while upload the log

Note on usage scenarios for the --is-ignore-cert flag: If the sensor is deployed
on a host where built-in root CAs are not up to date or present at all, it may be
necessary to use the --is-ignore-cert flag to allow sensor to pull the payload to
execute from the cloud.

Unlike the main sensor transport (which uses a pinned certificate), the
Payloads feature uses Google infrastructure and their public SSL certificates.

This may sometimes come up in unexpected ways. For example fresh Windows Server installations
do not have the root CAs for google.com enabled by default.