Imbutus
← Documentation

Lists

Lists are the universal data container: one ordered, reusable set of items that any workflow can work through — targets to scan, pages to test, hosts to watch — with optional properties on every item.

BETA

What a list is

A named list lives on your Kali machine and every run that names it reuses it (guest or signed-in), so you define a scope once and keep using it. Items keep their order, and each item can carry its own properties — a label, an expected auth level, a severity, anything you want to attach to it.

The two shapes

  1. TARGET list — bare hosts (a.com, b.com). Attach it where each item is its own scan: recon:domain --list <name|id>.
  2. PAGE list — URLs or paths inside ONE host (https://a.com/x, /cart). Attach it to one web target: recon:web <origin> --list <name|id>.
  3. Path-only items are resolved against the run's target, so /cart works with recon:web https://a.com --list <name|id>.

Managing lists from chat

  1. Ask in plain language — 'create a list checkout-pages and add /cart, /checkout, /pay'.
  2. The assistant uses one tool (list_manage): create, add items with properties, read a list back, delete it.
  3. Attach it to any run with --list <name|id>; items are processed in order, and a list works for both guest and signed-in runs.
create a target list:  "make a list mydomains: a.com, b.com"
attach as targets:      recon:domain --list mydomains
create a page list:     "list checkout-pages = /cart, /checkout, /pay"
attach as pages:        recon:web https://a.com --list checkout-pages
                          recon:web https://a.com --list checkout-pages --sign-in

Validation

  • The shape is checked before a scan starts: a page list is refused as a target list, a list spanning several hosts is refused as the pages of one target, and a list for host A is refused on a run for host B.
  • Adding items that would break a list's declared kind is refused too, so a target list cannot quietly turn into a page list.
  • The refusal says which of the two you meant — answer it and the run continues. Nothing is silently rewritten.

Managing lists on the machine page

Every list also has a panel on its Kali machine page (Virtual Machines → your machine → Lists): create a list, add items one by one, change each item's status (pending / running / done / failed / skipped), open a list to see its progress, delete an item or the whole list, and Process a list to launch a run over it. That is the same store the assistant writes to, so a list you make in chat appears there and vice versa — and either its NAME or its ID can be used to refer to it. The search and recon workflows save the lists they build through the same writer, so a list they produce appears here too — with its items, its count, and a Process button.

Lists belong to the machine they were created on: they live in that machine's findings database, are shared by every run on it, and travel with the machine's export/import (the whole database is exported and imported, so lists and their items come along).

The container is generic on purpose: items already accept arbitrary properties, so 'targets' and 'urls' are the shapes supported today, not the limit of the concept.