Skip to main content

Active Countermeasures

Most Surface Security features observe and alert. Active Countermeasures go one step further: they proactively disrupt phishing kits and plant tripwires that reveal credential theft in progress. All of them run inside the browser extension on your enrolled endpoints, and all of them are off by default.

Because these features change how the browser presents itself to websites and plant synthetic artifacts in the browser, they are gated behind a master switch and every change requires the administrator to re-enter their password. This page explains what each countermeasure does, how to configure it on Settings > Active Countermeasures, and what to consider before enabling each one.

How it works​

The page contains a master switch and three individual countermeasures:

ControlWhat it does
Enable Active CountermeasuresMaster toggle. When disabled, no countermeasures are active regardless of individual settings.
Curl User-Agent SpoofingPresents a non-browser identity (curl/8.11.1) to untrusted sites, causing phishing kits that fingerprint browsers to refuse to serve their payload.
Shadow State MeshPlants coordinated decoy authentication artifacts on risky sites to detect credential harvesters.
Canary CookiesPlants fake cookies tied to Thinkst Canarytokens domains, so stolen-and-replayed cookies trigger an external alert.

Settings are delivered to enrolled browser extensions at the next policy sync (typically within about a minute). Each individual countermeasure card shows an Active badge when both the master toggle and that feature are enabled. When the master toggle is off, the individual cards are dimmed and cannot be changed.

Every save on this page prompts a password confirmation dialog: "Saving active countermeasures settings requires you to re-enter your password." After a successful save, a "Settings saved successfully." banner appears.

Screenshot

[SCREENSHOT PLACEHOLDER: The Active Countermeasures settings page showing the Enable Active Countermeasures master toggle at the top and the three countermeasure cards below, with the master toggle enabled and Active badges visible]

Using the page​

Navigate to Settings > Active Countermeasures in the admin dashboard.

  1. Turn on Enable Active Countermeasures and confirm with your password. This unlocks the individual cards but does not activate anything by itself.
  2. Toggle the individual countermeasures you want, confirming each change with your password.
  3. Wait for the next policy sync for the change to reach endpoints.

Curl User-Agent Spoofing​

Modern phishing kits and adversary-in-the-middle (AITM) proxies fingerprint incoming traffic. Requests that do not look like a real browser — security scanners, sandboxes, crawlers — are rejected or served a harmless decoy page, so the kit stays hidden from analysis. Curl User-Agent Spoofing turns this evasion technique against the attacker: on non-trusted sites, the extension rewrites the browser's User-Agent header to curl/8.11.1. The phishing kit sees what looks like a command-line tool, assumes it is being scanned, and refuses to serve the phishing page. The attack breaks before your user ever sees it.

As described on the card, the extension:

  1. Identifies trusted sites from your learned origins and allowed domains.
  2. Sends HTTP requests to all other sites with a curl user-agent header.
  3. Relies on the phishing kit's own browser check to reject the request and break the attack.

Trusted sites — origins your organization has learned through normal use, domains on your allowed list, and the Surface Security server itself — are excluded and always receive the normal browser user-agent. The rewrite applies to page and embedded-frame navigations on everything else.

Screenshot

[SCREENSHOT PLACEHOLDER: The Curl User-Agent Spoofing card with the toggle enabled, showing the Active badge and the three-step "How it works" explanation]

Shadow State Mesh​

Shadow State Mesh plants coordinated decoy authentication artifacts — a fake session cookie, decoy storage keys, a hidden form field, and a JavaScript marker — on risky or unlearned sites. Legitimate software rarely touches more than one of these surfaces; credential harvesters sweep them all. When decoys are accessed in a correlated pattern, or a decoy value is seen leaving the page toward a third party, Surface Security raises a confidence-scored alert — often before any real credential is compromised.

The card lists the detection signals:

  • Reads of decoy cookie/storage/DOM/JS artifacts before meaningful interaction
  • Cookie tampering and targeted reads of decoy storage keys
  • Outbound exfiltration or replay of any decoy token to controlled sinks
  • Cross-surface correlation within a short execution window

Shadow State Mesh has its own detailed guide covering the scoring model, alert tiers, deduplication, and the threat scenarios it catches. See Shadow State Mesh for the full deep dive. Alerts it raises appear in the standard alerts feed alongside other detections (see Alerts).

Canary Cookies​

Canary Cookies address a threat the other countermeasures do not: cookie theft that happens outside the browser. Infostealer malware routinely dumps the entire browser cookie jar from disk and ships it to an attacker, who replays the cookies to hijack sessions. A canary cookie is a tripwire in that jar — a fake cookie scoped to a domain you registered through the free Thinkst Canarytokens service. The extension plants it directly through the browser's cookie store without ever navigating to the canary domain, so it sits dormant. If an attacker steals the cookie jar and replays it (visiting or probing the domains found in it), the canary domain is contacted, and Thinkst Canarytokens fires an alert to the contact address you configured when creating the token.

The card includes an info banner titled How Canary Cookies Work that summarizes this flow and links to the Canarytokens site.

To create a canary cookie:

  1. Create a canary token at canarytokens.org/nest and note the unique canary domain it gives you (for example abc123.canarytokens.com).
  2. On the Canary Cookies card, click Add Cookie. The New Canary Cookie form appears with four fields:
    • Label — a friendly name, for example "Fake Session Cookie".
    • Domain — the canary domain from step 1. If you paste a full URL, the page extracts the hostname automatically.
    • Cookie Name — a plausible name an attacker would target, for example session or auth_token.
    • Cookie Value — the fake value. Use the JWT button to generate a realistic fake JSON Web Token, or Random for a random 16-character string.
  3. Click Create.
  4. Make sure the Canary Cookies toggle and the master toggle are both enabled.

Configured cookies appear in the Configured Canary Cookies table with columns Label, Domain, Cookie Name, Enabled, and Actions. Each row has:

  • An Enabled toggle to pause a single cookie without deleting it.
  • An edit action that opens the Edit Canary Cookie form. The Cookie Value field shows "(leave blank to keep current)" — the stored value is never displayed back, so leave it empty to keep it or enter a new one to rotate it.
  • A delete action that requires a second Confirm click.

When a cookie's value changes (or a cookie is deleted and recreated), extensions re-plant it on the next sync. Planted cookies are marked secure, are readable by page scripts (deliberately, so harvesters can find them), and expire after one year.

A few practical tips for convincing canaries:

  • Use cookie names attackers grep for: session, auth_token, access_token, or names mimicking your real SSO provider.
  • The JWT generator produces a structurally valid (but cryptographically fake) token with realistic claims — a much more tempting target than a random string.
  • Create two or three canaries on separate token domains so a single false trigger is distinguishable from a full cookie-jar dump.
Screenshot

[SCREENSHOT PLACEHOLDER: The Canary Cookies card with the New Canary Cookie form open, showing the Label, Domain, Cookie Name, and Cookie Value fields with the JWT and Random generator buttons]

Screenshot

[SCREENSHOT PLACEHOLDER: The Configured Canary Cookies table with two or three cookies listed, showing the per-cookie Enabled toggles and the edit/delete actions]

Safety and impact considerations​

Active countermeasures interact with live traffic, so weigh each one before enabling.

Curl User-Agent Spoofing​

  • Highest potential for side effects of the three. Any site that is not learned, allowed, or the Surface server receives the curl user-agent — including legitimate sites your organization simply has not visited often enough to learn yet.
  • Legitimate sites that block non-browser clients, or bot-protection services that challenge unusual user-agents, may block or degrade the experience on those unlearned sites. Users will see this as "the site does not load."
  • Impact shrinks over time as learned origins accumulate. Enable it after your deployment has run in production long enough to build a solid learned-origin baseline, and pre-populate your allowed domains list with business-critical sites first.
  • Best fit: organizations at elevated phishing risk that have completed a learning period and accept occasional friction on unfamiliar sites in exchange for breaking phishing kits pre-emptively.

Shadow State Mesh​

  • Low functional risk. Decoys use reserved names that legitimate applications do not use, and nothing existing on the page is modified. Trusted and allowed domains are excluded entirely.
  • The main consideration is alert volume: single decoy touches are logged but never alert, and correlation plus deduplication keep noise low, but expect some medium-severity alerts from aggressive-but-benign scripts when first enabled. Review these and extend your allowed domains list where appropriate.
  • Best fit: broadly safe to enable for most organizations; it is detection-only and does not alter site behavior.

Canary Cookies​

  • No effect on browsing. Cookies are planted silently on domains users never visit; they do not change how any site behaves.
  • Alerting for triggered canaries happens through Thinkst Canarytokens (the email or webhook you configured when creating the token), not in the Surface Security alerts feed. Make sure the token's contact address is monitored by your security team.
  • A planted canary cookie signals cookie theft — typically an infostealer on the endpoint — which warrants immediate session revocation and endpoint investigation for the affected user.
  • Best fit: any organization concerned about infostealer malware and session hijacking. This is a passive tripwire with essentially no downside beyond the small setup effort.

Contoso's security team wants early warning if any employee's browser cookies are stolen by an infostealer.

  1. An administrator creates a canary token at canarytokens.org/nest, choosing an alert email of soc@contoso.com, and receives the canary domain k7f2mq.canarytokens.com.
  2. In Settings > Active Countermeasures, they enable Enable Active Countermeasures, confirm their password, then click Add Cookie on the Canary Cookies card.
  3. They enter Label Fake Okta Session, Domain k7f2mq.canarytokens.com, Cookie Name session, click JWT to generate a convincing fake token value, and click Create.
  4. They enable the Canary Cookies toggle and confirm their password. Within a minute, every enrolled browser silently plants the fake session cookie.
  5. Three weeks later, an employee runs a trojanized installer. The infostealer dumps the browser's cookie database and uploads it. When the attacker's tooling replays the stolen cookies, the canary domain is contacted and Thinkst emails soc@contoso.com with the trigger details.
  6. The SOC revokes all of that employee's sessions, forces a password reset, and isolates the endpoint — before the attacker uses any real session cookie of value.

Troubleshooting​

A legitimate site stopped working after enabling Curl User-Agent Spoofing. The site is receiving the curl user-agent because it is not yet trusted. Add it to your allowed domains list; the exclusion reaches extensions at the next policy sync. Frequently used sites also become excluded automatically as learned origins build up.

I toggled a feature but endpoints are not picking it up. Check that the master Enable Active Countermeasures toggle is on — individual settings have no effect without it. Then allow for the policy sync interval. Also verify the change actually saved: every toggle requires password re-authentication, and canceling the dialog discards the change.

I edited a canary cookie but the old cookie is still in browsers. Extensions plant the updated cookie on the next sync. Changing the value (or deleting and recreating the entry) triggers re-planting; browsers do not proactively remove the previously planted cookie, but the canary domain remains yours, so a replay of either value still fires the alert.

Why is the cookie value hidden when editing? The stored value is write-only in the dashboard. Leave the field blank to keep the current value, or enter a new one to rotate it.

For the detections these countermeasures complement, see Phishing Detection.