Recorded Login

Recorded login allows a scan to run using an authenticated session with your app. This simulates the behaviour of an attacker setting up an account before performing reconnaissance. See Recorded Login for detailed setup instructions.

Recorded Login Secrets

When used with internal scanning it is usually desirable to keep credentials within the user’s infrastructure. For example, account passwords, API keys, and one-time-password secrets are stored in a secret store in the user’s infrastructure. The recorded login file is modified to tell the scanner where the secrets are stored. At run time the secrets are read from the secret store and injected into the recorded login file.

For TOTP-based MFA you supply an otpauth_url seed and the scanner generates valid one-time codes during the login replay.

Supported Secret Stores

1. Kubernetes Secrets
2. Hashicorp Vault

Contact sales if you have other requirements.

Setup Recorded Login

When making the recording, login to the application as you normally would (i.e. enter real passwords, API keys and TOTP codes). When completed, the recorded login (.trail) file will contain the credentials you entered. These need to be replaced with instructions on how to extract the same credentials from your chosen secret store. The process is different for TOTP codes and other credentials.

Once the credentials have been removed from the recorded login file it can be uploaded in the Detectify UI.

Standard Credentials

Locate the section in your login file (.trail) where the credential is stored and replace it with the secret reference for your chosen secret store. This will be in the commands section of the recorded login file.

Recorded action:

{
    "type": "UserAction",
    "version": "1.0",
    "command": "input",
    "selectors": [
        ["css=body > form > input[type=\"text\"]:nth-child(1)"]
    ],
    "values": [
        "my-secret-password"
    ]
}

Replace with:

{
    "type": "UserAction",
    "version": "1.0",
    "command": "input",
    "selectors": [
        ["css=#id-of-password-input"]
    ],
    "values": [
        "secret={backend=hashicorp_vault, path=recorded-login/credentials, key=password}"
    ]
}

TOTP/MFA Codes

For TOTP codes there are two steps:

1. Add a new setLocalMFAWithVault command to the recorded login file. This tells the scanner where the TOTP secret is stored.
2. Replace the command where the TOTP code was entered with a multiFactorAuthSingleField (or multiFactorAuthSplitFields) command. This tells the scanner to generate a fresh code at replay time.

Recorded action:

{
    "type": "UserAction",
    "version": "1.0",
    "command": "input",
    "selectors": [
        ["css=#id-of-mfa-input"]
    ],
    "values": [
        "123456"
    ]
}

Replace with:

{
    "type": "UserAction",
    "version": "1.0",
    "command": "setLocalMFAWithVault",
    "values": [
        "secret={backend=hashicorp_vault, path=recorded-login/mfa, key=otpauth_url}"
    ]
},
{
    "type": "ExternalInput",
    "version": "2.0",
    "command": "multiFactorAuthSingleField",
    "selectors": [
        ["css=#id-of-mfa-input"]
    ],
    "values": []
}

In some applications the TOTP code is entered one digit per field. In this case there will be multiple input commands in the recorded login file. Replace them all with a single multiFactorAuthSplitFields command listing each field’s selector. See Recorded Login for a detailed example.

Secret Reference Syntax

When providing the location of a secret in the recorded login file, use the following syntax:

secret={backend=<backend>, <backend_specific_args>}

The supported backends are:

Kubernetes Secret Store Arguments

Example Secret:

apiVersion: v1
kind: Secret
metadata:
  name: recorded-login-password
  namespace: scanner
stringData:
  username: admin
  password: t0p-Secret

Reference in the recording file:

"values": ["secret={backend=kubernetes, name=recorded-login-password, key=password}"]

Hashicorp Vault Store Arguments

How path, mount and key map to the Vault location

Given a secret reference:

secret={backend=hashicorp_vault, mount=secret, path=recorded-login/credentials, key=password}

The scanner constructs the Vault API read path based on the KV engine version configured in the Helm chart (hashicorp_vault.kvVersion):

In both cases, key (password) selects a single field from the secret’s data map.

You provide only the logical path — do not include /data/ in the path argument.

Writing the secret to Vault (KV v2):

vault kv put secret/recorded-login/credentials \
  username="testuser@example.com" \
  password="s3cret"

Reference in the recording file:

"values": ["secret={backend=hashicorp_vault, path=recorded-login/credentials, key=password}"]

If mount is omitted, it defaults to the value of hashicorp_vault.kvMount in your Helm values (default: secret).

Storing TOTP Secrets

Regardless of the secret store, TOTP secrets must be stored as an otpauth URL:

otpauth://totp/Example?secret=JBSWY3DPEHPK3PXP&digits=6

Configuring Secret Stores

Kubernetes

Access

By default, the scanner has access to secrets in the Kubernetes cluster it is deployed in. No additional configuration is required.

Configuration

The following environment variable can be set in the scanner-worker-config ConfigMap:

Managing Secrets

The scan scheduler API can be used to create and manage Kubernetes Secrets in the scanner namespace. See Scanner API for details.

Hashicorp Vault

Access

To enable HashiCorp Vault as a secret backend, set HASHICORP_VAULT_ENABLED to true in the scanner-worker-config ConfigMap.

The scan-worker authenticates to Vault using its Kubernetes ServiceAccount JWT via the Kubernetes auth method . See HashiCorp Vault Integration for full setup instructions including policy and role configuration.

Configuration

The following environment variables can be set in the scanner-worker-config ConfigMap: