sensor-tasking

What this skill does

# Sensor Tasking - Query and Command EDR Agents

This skill orchestrates sending tasks (commands) to EDR sensors and handling responses. It solves two key challenges of sensor tasking:

1. **Offline agents**: Sensors may be offline when you want to task them
2. **Response collection**: Some tasks generate data that needs to be collected

---

## LimaCharlie Integration

> **Prerequisites**: Run `/init-lc` to initialize LimaCharlie context.

### LimaCharlie CLI Access

All LimaCharlie operations use the `limacharlie` CLI directly:

```bash
limacharlie <noun> <verb> --oid <oid> --output yaml [flags]
```

For command help and discovery: `limacharlie <command> --ai-help`

### Critical Rules

| Rule | Wrong | Right |
|------|-------|-------|
| **CLI Access** | Call MCP tools or spawn api-executor | Use `Bash("limacharlie ...")` directly |
| **Output Format** | `--output json` | `--output yaml` (more token-efficient) |
| **Filter Output** | Pipe to jq/yq | Use `--filter JMESPATH` to select fields |
| **LCQL Queries** | Write query syntax manually | Use `limacharlie ai generate-query` first |
| **Timestamps** | Calculate epoch values | Use `date +%s` or `date -d '7 days ago' +%s` |
| **OID** | Use org name | Use UUID (call `limacharlie org list` if needed) |

---

## When to Use

Use this skill when the user wants to:
- **Live Response**: Query running processes, network connections, registry keys, services
- **Forensic Collection**: Collect memory maps, file listings, autoruns, packages
- **Fleet Operations**: Execute commands across many sensors (by tag, platform, etc.)
- **Incident Response**: Isolate hosts, kill processes, gather evidence
- **Data Collection at Scale**: Get OS versions, installed software, users across fleet

Example requests:
- "Get running processes from sensor X"
- "List all files in C:\Windows\Temp on compromised hosts"
- "Get OS version from all Windows servers when they come online"
- "Run a memory collection on all hosts tagged 'incident-response'"
- "Execute netstat on all online Linux servers"

## Core Concepts

### Challenge 1: Offline Agents

**Direct tasking** (`get_processes`, `dir_list`, etc.) only works for **online** sensors. If a sensor is offline, the task fails immediately.

**Reliable tasking** queues tasks for delivery when sensors come online. Tasks persist for a configurable TTL (default: 1 week).

| Approach | Use When | Pros | Cons |
|----------|----------|------|------|
| Direct Task | ≤5 online sensors, need immediate response | Fast, response inline | Fails if offline |
| Reliable Task | >5 sensors, offline sensors, or can wait | Guaranteed delivery | Response via telemetry |

### Challenge 2: Receiving Responses

| Method | Use When | How It Works |
|--------|----------|--------------|
| Inline Response | Direct tasking small numbers | Response returned directly from API |
| LCQL Query | Need to collect reliable task responses | Query for `routing/investigation_id` containing your `context` |
| D&R Rule | Need automated action on responses | Create rule matching `investigation_id`, with response actions |

## Decision Tree

```
START: User wants to task sensors
    |
    v
Are all targets online AND ≤5 sensors?
    |
    |--YES--> Use Direct Tasking (inline response, parallel execution)
    |
    |--NO--> Use Reliable Tasking (>5 sensors OR any offline)
              |
              v
       Do you need the response data?
              |
              |--NO (action-only like isolate)--> Create Reliable Task, done
              |
              |--YES--> Do you need automated handling?
                        |
                        |--NO--> Create Reliable Task, wait 2+ min, then LCQL query
                        |
                        |--YES--> 1. Create D&R rule with TTL FIRST
                                  2. THEN create Reliable Task
                                  (rule must exist before task to avoid missing responses)
```

## How to Use

### Step 1: Understand the Request

Parse the user's request to determine:
- **Target scope**: Single sensor, selector, all sensors?
- **Task type**: Data collection (needs response) or action (unidirectional)?
- **Urgency**: Need immediate response or can wait?
- **Response handling**: Inline, LCQL collection, or automated D&R?

### Step 2: Get Organization and Sensors

If you don't have the OID, get it first:

```bash
limacharlie org list --output yaml
```

Check sensor status if targeting specific sensors:

```bash
limacharlie sensor get --sid <sid> --oid <oid> --output yaml
```

> **CRITICAL: Filter to Taskable EDR Sensors**
>
> Before spawning executor agents or tasking sensors, you MUST verify sensors are **EDR agents** (not adapters or cloud sensors).
> Non-EDR sensors will fail with `UNSUPPORTED_FOR_PLATFORM`.
>
> **Taskable sensors require BOTH:**
> - **Platform**: `windows`, `linux`, `macos`, or `chrome`
> - **Architecture**: NOT `usp_adapter` (code 9)
>
> A sensor running on Linux platform but with `arch=usp_adapter` is an **adapter** (USP), not an EDR agent. These adapters forward logs but cannot execute commands.
>
> **Use combined selector when listing sensors:**
> ```bash
> limacharlie sensor list --selector "(plat==windows or plat==linux or plat==macos) and arch!=usp_adapter" --online --oid <oid> --output yaml
> ```
>
> **Or check sensor info** before tasking - verify both `platform` is in `["windows", "linux", "macos", "chrome"]` AND `arch` is not `9` / `usp_adapter`.

### Step 3A: Direct Tasking (≤5 Online Sensors)

For immediate data collection from a small number of online sensors (up to 5), use direct tasking functions with parallel execution.

**Available Direct Task Commands** (return response inline via `limacharlie task send --sid <sid> --task <command>`):

| Task Command | Description | Common Use |
|--------------|-------------|------------|
| `os_processes` | Running processes | Process investigation |
| `os_kill_process` | Kill a process | Incident response |
| `os_modules --pid [pid]` | Loaded modules | Malware analysis |
| `netstat` | Active connections | C2 hunting |
| `os_version` | OS details | Asset inventory |
| `os_users` | System users | Account enumeration |
| `os_services` | Windows services | Persistence check |
| `os_drivers` | Loaded drivers | Rootkit detection |
| `os_autoruns` | Persistence mechanisms | Malware persistence |
| `os_packages` | Installed packages | Software inventory |
| `reg_list [path]` | Registry values | Config/persistence |
| `dir_list [path]` | Directory listing | File investigation |
| `find_strings` | String search | Memory forensics |
| `yara_scan --pid [pid]` | YARA scan process | Malware detection |
| `yara_scan --filePath [path]` | YARA scan file | File analysis |
| `yara_scan --dirPath [path]` | YARA scan directory | Bulk scanning |

**Example - Get processes from a sensor:**

```bash
limacharlie task send --sid <sid> --task os_processes --oid <oid> --output yaml
```

### Step 3B: Reliable Tasking (>5 Sensors or Offline)

For more than 5 sensors, offline sensors, or fleet-wide operations, use reliable tasking.

> **IMPORTANT: Order of Operations**
>
> If you need automated response handling via D&R rules, you **MUST create the D&R rule FIRST**, before creating the reliable task. This ensures no responses are missed between task creation and rule deployment.
>
> Order: **D&R Rule → Reliable Task** (not the other way around)

**Create a reliable task:**

```bash
# reliable-send is per-sensor; first list matching sensors, then loop
limacharlie sensor list --selector 'plat==windows' --oid <oid> --filter '[].sid' --output yaml

for sid in <sid-list>; do
  limacharlie task reliable-send --sid $sid --command 'os_version' --investigation-id 'fleet-inventory-2024-01' --ttl 86400 --oid <oid> --output yaml
done
```

**Key Parameters:**
- `--sid`: Target sensor ID (reliable-send operates per-sensor)
- `--command`: The command to execute (e.g., `os_version`, `mem_map --pid 4`, `run --shell-comman