Chain steps

Protocol steps

Protocol steps (HTTP, SMTP, IMAP, LDAP, DNS, SpamAssassin, Kerberos, SMB) are added by picking an existing probe from the probe picker dialog.

After selecting a probe, VirtuProbe copies its configuration into the chain step. The step name defaults to ProjectName / ProbeName. The original probe is not modified.

Each step can have extractors attached — see Extractors.

ITERATE

ITERATE is a container step that executes its child steps once for each item in a list. It supports two payload sources, optional rate control, and configurable stop conditions.

Static list

Define the values directly in the step editor — one value per line. This is the most common mode when the list is known upfront.

File

Read items from a text file on the server’s filesystem. Each non-blank line becomes one iteration item. Useful for large wordlists or credential files that would be impractical to paste inline.

The path is resolved relative to the server’s working directory, or you can use an absolute path.

Caution

The file is read by the server process at the time the chain runs. The file must be accessible from the server — in the desktop app this is the local machine; in a remote deployment it is the server host.

Configuration

Field	Description
Source	Inline list or File
Item variable name	The variable name injected for each item inside child steps
Values	(Inline only) Items to iterate, one per line
File path	(File only) Absolute or relative path to the wordlist on the server
Min delay (ms)	Minimum pause between iterations. 0 = no delay
Max delay (ms)	Maximum pause between iterations — actual delay is randomised between min and max
Max failures	Stop after this many failed iterations. Leave blank for unlimited
Stop on first success	When enabled, the loop continues past failed iterations and stops as soon as one iteration’s child steps all pass — the overall step result is success if a match is found, failure if the list is exhausted

The current item is injected as {{yourItemVarName}} into all child steps. Variables produced by child steps accumulate in the shared context; after the loop finishes, the last iteration’s values are visible to subsequent steps.

Credential spray example

Set Source to File, point it at /wordlists/passwords.txt, set Item variable name to password, enable Stop on first success, and add a delay range (e.g. 500–2000 ms) to avoid triggering lockouts. The chain stops as soon as an iteration produces a successful login and marks itself as passed.

Note

Default behaviour (no stop conditions set) is fail-fast: if any iteration’s children fail, the loop stops immediately. Stop on first success switches to continue-on-failure mode where individual iteration failures are expected and do not abort the loop.

CONDITION

CONDITION evaluates a Groovy boolean expression and executes one of two child step lists depending on the result. All {{variable}} placeholders in the expression are resolved before evaluation.

Field	Description
Expression	A Groovy expression that evaluates to a boolean, e.g. {{status}} == '200' or {{count}}.toInteger() > 0
Then branch	Steps to execute if the expression is true
Else branch	Steps to execute if the expression is false (can be empty)

The branch taken is shown in the execution results. Variables produced by the executed branch are available to subsequent steps.

Groovy expression examples

{{status}} == '200'
{{count}}.toInteger() > 0
{{flag}} == 'true'
{{body}}.contains('verified')

Note

If the expression cannot be evaluated (syntax error, exception), the condition is treated as false and the else branch runs.

PARALLEL

PARALLEL executes all child steps simultaneously using a thread pool. Each branch receives a snapshot of the current variable context; after all branches complete their extracted variables are merged back (last-writer-wins on name collision).

Add branches using Add Branch (opens the probe picker) or the Print button. Each branch is a single step — use a CHAIN_REF or ITERATE inside the branch if you need multi-step logic.

Note

PARALLEL is useful for independent requests you want to fan out — e.g. checking the same endpoint on three servers. It is not suitable for dependent steps; use multiple sequential steps for those.

CHAIN_REF

CHAIN_REF calls another chain as a sub-routine. Variable context does not flow automatically — you explicitly map values in and results out.

Input variables

Map variables from the parent context into the sub-chain. Each row is:

Column	Description
Child variable	The variable name the sub-chain will see
Value / expression	A literal value or a {{parentVarName}} reference resolved from the parent context

Output variables

Map variables from the sub-chain back to the parent context. Each row is:

Column	Description
Child variable	The variable name produced by the sub-chain
Parent variable name	The variable name to assign in the parent context

Example

A sub-chain that fetches an LDAP entry and extracts dn and mail:

Input vars:

Child variable	Value
filter	(uid={{username}})

Output vars:

Child variable	Parent variable name
dn	ldap_dn
mail	user_email

After the CHAIN_REF step, {{ldap_dn}} and {{user_email}} are available in the parent chain.

Note

If the referenced chain is not found or has no ID set, the step fails with an error and the parent chain stops execution.

PRINT

PRINT writes a line to the execution log. The template can contain any text mixed with {{variable}} references — all variables resolved so far in the chain are available.

Field	Description
Output template	Free-form text with {{variable}} placeholders, e.g. POST returned {{postId}} — title: {{postTitle}}

PRINT always succeeds and produces no extracted variables of its own. It is mainly useful for debugging a chain’s variable state mid-execution.

ASSERT

ASSERT checks that a variable’s value satisfies a condition. If the condition is false, the chain stops and the step is marked as failed.

Field	Description
Variable	Name of the variable to check (resolved from chain context)
Operator	Comparison operator
Expected	The value to compare against — supports {{variable}} references

Operators

Operator	Meaning
EQUALS	Exact string match
NOT_EQUALS	Not an exact string match
CONTAINS	Expected is a substring of actual
NOT_CONTAINS	Expected is not a substring of actual
MATCHES	Actual matches the regex in Expected
GT / LT	Numeric greater/less than
GTE / LTE	Numeric greater/less than or equal

Use ASSERT to enforce postconditions after a probe step — for example, checking that a status code variable equals "200" before proceeding to the next step.