Creating Tripwires

A step-by-step guide to creating tripwires from the dashboard for different detection scenarios.

The Create Page

From the dashboard, click the "Create Tripwire" button in the top-right corner to open the dedicated creation page.

Choosing a Tripwire Type

The create page displays all available tripwire types organized by category. Use the tabs to switch between categories or the search bar to find a specific type:

Protocol Honeypots

These tripwires generate fake service credentials that trigger alerts when someone attempts to connect:

Tripwire Documents

These tripwires are downloadable files that trigger alerts when opened:

Cloud Credentials

Generate fake cloud provider API keys that alert when used. Only AWS is available today (aws_session); Azure and GCP are not yet supported and are rejected by the API, CLI and MCP server:

QR Codes

QR codes for physical security that trigger when scanned:

Phishing Detection

Detect when your own site is cloned for a phishing campaign:

The token generates a ready-to-embed .js file. List your real hostnames in its EXPECTED_HOSTS array, then drop it into the pages attackers are most likely to clone — your login and password-reset pages. Any use of the clone raises an alert with the attacker's staging domain and the victim's source.

Redirect URLs

A link that records the visit and then sends the visitor on to a destination URL you choose, so whoever clicks it lands somewhere believable and never sees an error page:

• The destination must be an absolute http:// or https:// URL of at most 2,048 characters, with no username or password in it. Anything else is rejected with a 400 when you create or edit the tripwire.
• You can change the destination later with the CLI (tripwire update <id> --dest <url>), the MCP server, or the API (destination_url in a tripwire update). Links you already handed out keep working, because the destination is looked up on every visit rather than baked into the URL. A change takes up to a minute to reach every sink.
• The destination is only ever read from your tripwire, never from the request, so the tracking URL can't be abused as an open redirect. An unknown, deleted or expired link answers 404.
• The visit is recorded before the redirect is sent, so you're alerted even if the visitor never reaches the destination. The destination site doesn't receive the tracking URL as a referrer.

Self-hosted: the control server answers redirect URLs itself when the HTTP sink host (SINK_HOST) points at it, which is the default in the Terraform module. If you point SINK_HOST at the sink instead, the sink fetches the destination from the control server's /ingest/redirect/<id> endpoint using the same INGEST_TOKEN it already sends detections with. No extra configuration is needed, but the sink has to be a release that includes this lookup.

Technology Reference (API, CLI & MCP)

Every type on the create page is also creatable from the REST API (POST /tripwires), the CLI (tripwire create <technology>) and the MCP server (create_tripwire) using the same technology slug. The low-level type (dns, tcp or aws) is derived from the technology, so you only need to send technology:

curl -X POST https://api.gettripwires.com/tripwires \
  -H "Authorization: Bearer $TRIPWIRE_API_KEY" -H "Content-Type: application/json" \
  -d '{"name":"prod-db-replica","technology":"postgresql"}'

• Type is derived. If you also send type, it must match the technology’s type above; a conflicting value (e.g. "type":"tcp" with "technology":"docx") is rejected with 400.
• Aliases. The older slugs aws, qr / qrcode and http are still accepted and behave exactly like aws_session, qr_code and http_admin; the slug you send is the one stored and returned.
• Not yet supported. gcp, azure, oracle, rabbitmq, kafka, url and document are rejected with 400 “technology … is not yet supported”. An unrecognised slug returns 400 listing the valid values.
• Self-hosted installations can switch each category off in System Setup; creating a disabled category returns 403. Cloud credentials are off by default on self-host.

Naming Your Tripwire

After selecting a type, you'll be prompted to enter a name. Choose a descriptive name that helps you:

• Identify the purpose - Where will these credentials be planted?
• Remember the context - What system or environment does it represent?
• Recognize in alerts - When triggered, you'll want to know immediately what was accessed

Naming Best Practices

Creating the Tripwire

Click "Create Tripwire" to generate the tripwire. The system will:

1. Generate a unique hostname for your honeypot
2. Create randomized, realistic-looking credentials
3. Configure the detection endpoint
4. Activate monitoring immediately

After Creation

Once created, you'll be redirected to the tripwire details page where you can view and copy the generated credentials. See the Tripwire Details documentation for more information.