Canary token internals — how they work, how to deploy them, and how to detect them.

Canary token internals — how they work, how to deploy them, and how to detect them.

Redirect Token

A redirect canarytoken is a trackable URL that logs a visitor's information before forwarding them to a legitimate destination. When someone clicks the token URL, the canarytokens.com server records the request, including IP address, User-Agent, and timestamp, then issues an HTTP 302 redirect to the configured destination page.

In this walkthrough, we examine how redirect tokens work, deploy a practical example using a cloned login page, and review defensive techniques.

How the Redirect Mechanism Works

When a redirect canarytoken is created, the service generates a unique tracking URL (e.g., https://canarytokens.com/traffic/abc123/index.html). This URL does not host any content — it is a logging endpoint.

The flow operates as follows:

1. The token URL is embedded in a document, email, or web page
2. A visitor requests the token URL
3. The Canarytoken server logs the visitor's IP address, User-Agent, timestamp, and referrer
4. The server issues an HTTP 302 redirect to the configured destination (e.g., a legitimate login page)
5. The visitor's browser follows the redirect automatically, landing on the real page

The visitor sees only the final destination. There is no intermediate page, no warning, and no visible indication that the request was logged. The redirect happens so quickly that most users will not notice the brief URL change in the address bar. The entire exchange happens in a single HTTP request cycle, typically under 200 milliseconds.

This makes the redirect token distinct from other canary token types: it does not require the adversary to execute code or render an image. It requires only a single click.

Why Adversaries Often Miss Redirects

Redirect canarytokens are particularly effective because the logging happens during the HTTP redirect itself, a mechanism that is ubiquitous. Most adversaries will not inspect every URL before clicking, especially when the link appears to lead to a legitimate domain. The 302 redirect executes before the page renders, so there is no visible delay, no popup, and no intermediate warning page. While the address bar does briefly display the tracking URL, the transition happens quickly enough that most users do not notice it.

Furthermore, standard browser developer tools do not surface redirect logs in a way that would alert a casual adversary. Unless the adversary is actively monitoring HTTP response headers with a proxy or packet capture, the redirect is functionally silent.

Common Deployment Scenarios

Redirect tokens are commonly deployed in the following contexts:

• Phishing simulations: Embed the token URL in a simulated phishing email. When employees click, the security team is notified and the employee is redirected to the real training page.

• Document tracking: Place the token URL in sensitive documents (contracts, proposals, internal memos). If the document is forwarded or accessed by an unauthorized party, the click is logged.

• Honeypot web pages: Embed the token in a fake login portal or internal tool. Adversaries who discover the page and interact with it trigger the alert.

• Supply chain monitoring: Distribute documents containing tokens to vendors or partners. Unusual click patterns may indicate compromised credentials or unauthorized forwarding.

---

Practical Example: Cloned Login Landing Page with Redirect

To demonstrate how a redirect token can be embedded in a cloned web interface, we build a fictional corporate login landing page for Example Inc. The page contains a single Login button. When clicked, the token triggers.

In a real attack, an adversary would clone the target organization's actual login page and host it on a lookalike domain. For this demonstration, we build a self-contained template that illustrates the technique.

The Attack Flow

1. The visitor loads a page that looks like the Example Inc. login portal
2. The page presents a single Login button — no input fields, no forms to fill
3. The visitor clicks Login
4. The canarytoken triggers and sends a notification

The Template

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Example Inc. — Login</title>
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600&display=swap" rel="stylesheet">
  <style>
    *, *::before, *::after {
      margin: 0;
      padding: 0;
      box-sizing: border-box;
    }

    body {
      font-family: 'Inter', -apple-system, BlinkMacSystemFont, sans-serif;
      background: #f5f6fa;
      min-height: 100vh;
      display: flex;
      align-items: center;
      justify-content: center;
    }

    .login-card {
      background: #ffffff;
      border-radius: 12px;
      box-shadow: 0 2px 12px rgba(0, 0, 0, 0.08);
      padding: 48px 40px;
      width: 100%;
      max-width: 400px;
      text-align: center;
    }

    .logo {
      font-size: 28px;
      font-weight: 600;
      color: #1a1a2e;
      margin-bottom: 8px;
    }

    .logo span {
      color: #4361ee;
    }

    .tagline {
      font-size: 14px;
      color: #6b7280;
      margin-bottom: 32px;
    }

    .login-btn {
      display: inline-block;
      width: 100%;
      padding: 14px 24px;
      background: #4361ee;
      color: #ffffff;
      font-family: inherit;
      font-size: 16px;
      font-weight: 500;
      border: none;
      border-radius: 8px;
      cursor: pointer;
      transition: background 0.2s, transform 0.1s;
      text-decoration: none;
    }

    .login-btn:hover {
      background: #3a56d4;
    }

    .login-btn:active {
      transform: scale(0.98);
    }

    .footer {
      margin-top: 24px;
      font-size: 12px;
      color: #9ca3af;
    }

    .footer a {
      color: #6b7280;
      text-decoration: none;
    }

    .footer a:hover {
      text-decoration: underline;
    }
  </style>
</head>
<body>
  <div class="login-card">
    <div class="logo">Example<span>Inc.</span></div>
    <p class="tagline">Secure Employee Portal</p>
    <button class="login-btn" id="loginBtn">Login</button>
    <div class="footer">
      <a href="#">Privacy Policy</a> &middot; <a href="#">Help</a>
    </div>
  </div>

  <script>
       // Create at: https://www.canarytokens.org/nest
     // Enter an example URL for redirection, for example: https://login.example-inc.com/auth
    // Input the token in CANARY_TOKEN_URL = "yourtoken"
    const CANARY_TOKEN_URL = "http://canarytokens.com/traffic/kj6p78h1hcklgoe9g55d66yvg/index.html";

    document.getElementById("loginBtn").addEventListener("click", function () {
      window.location.href = CANARY_TOKEN_URL;
    });
  </script>
</body>
</html>

Walkthrough

Generate the token

Launch the webpage.

When clicking the login button the canary token gets triggered

Notification

Defensive Notes

Redirect canarytokens are difficult to detect through visual inspection alone. To reduce exposure:

• Hover over links before clicking — inspect the URL for unknown domains or unusual path structures
• Use browser extensions or enterprise proxy rules that log and review outbound redirects
• When reviewing shared documents, check for embedded hyperlinks that point to tracking services (e.g., canarytokens.com/traffic/...)
• Be aware that URL shorteners (e.g., bit.ly, tinyurl) can mask the true destination of a redirect token

For security teams: redirect tokens are most effective when placed in locations an adversary is likely to interact with — shared drives, internal wikis, exposed document repositories, or simulated phishing campaigns.

The complete hands-on exploration of Canary Token internals—including detailed deployment and detection is available on GitHub:https://github.com/HelixCipher/canary-tokens