Shipping Memcyco-class canary + SDK protection at self-serve price: an architecture walkthrough

Memcyco raised $37M in January 2026 to commercialize a great piece of anti-phishing engineering: a JavaScript snippet embedded on the legitimate site that attackers unwittingly copy when cloning, which then fires telemetry when real victims land on the clone. Combined with a decoy-credential swap and real-time Red Alert overlay, it's the most technically interesting thing in the brand-protection category.

We ship a version of that at OpenBait. Same core idea. 1/20th of the price. This post walks through how — the architecture, the honest trade-offs, and what we deliberately chose not to build.

The core mechanic, in one sentence

Put a tamper-resistant JavaScript tag on your legitimate site's HTML. When an attacker scrapes or clones that HTML, the tag travels with it. When a victim lands on the fake domain, the tag executes in their browser, notices it's running on the wrong origin, and sends a signal home.

This is the Memcyco pattern. It's also the OpenBait pattern. The mechanic is not proprietary — it's the natural way to build a canary for cloned websites. What differs between implementations is:

1. How you make the tag hard to remove
2. What signal you collect and how you correlate it
3. What you do with the signal (warn users? warn you? auto-trigger takedown?)
4. How you price the resulting platform

Part 1 — Making the tag tamper-resistant

The naïve implementation

Drop a <script src="https://canary.openbait.com/probe.js"> on every page. Done. Next question?

No, not done. Attackers routinely delete external scripts when cloning sites. A wget or curl mirror will pull the HTML but not execute JS; a browser-based Save As will try but the external URL would break cross-origin anyway. An attacker who runs a quick "rewrite links" pass gets rid of the tag in one sed line.

The slightly less naïve implementation

Inline the tag. <script>…full probe code…</script> inside the HTML. Now the tag travels with the HTML when cloned.

This mostly works. But:

• Anyone who reads the HTML and recognizes the pattern can strip it.
• The probe code is statically analyzable in the clone.
• CSP headers on the original site may need adjustment.

Our implementation (high level)

• Inline, obfuscated probe script. We inline a minimal bootstrap that fetches the real probe logic from the clone side. The bootstrap is small enough to be easy to inline cleanly, but not so distinctive that a generic "remove canary" regex works on it.
• Domain assertion at runtime. The probe reads window.location.hostname and compares it against an allowlist baked into the bootstrap at deploy time. If the hostname doesn't match, the probe is in a clone context and fires.
• CSP compatibility via nonce injection. We emit the bootstrap with the customer's CSP nonce when their site uses strict CSP. This is a common pain point with canary JS — without nonce integration you force the customer to add 'unsafe-inline' to their script-src, which many security teams won't accept.
• Integrity hash for the fetched main probe. The bootstrap verifies the SRI hash of the main probe before executing, so an in-the-middle attacker modifying the probe itself can't weaponize it.

We are not claiming this is unbreakable. A motivated attacker can and will strip the probe, especially one familiar with the canary-token mechanic. What the obfuscation + SRI + inline bootstrap does is move the expected cost of defeating the canary from a 10-second sed command to a 30-minute review and rewrite pass — enough friction that most automated cloning tools and low-effort attackers still miss it.

What Memcyco does that we don't

Memcyco's canary implementation is described publicly as PoSA (Proof of Source Authenticity) — a per-user watermark rendered on the legitimate site that proves authenticity to individual users, plus device fingerprinting (their "Device DNA") that persists across sessions. The per-user watermark is a meaningfully different layer: it makes the page itself self-verifying from the user's side, not just from our side.

We don't ship per-user watermarking. At mid-market price point we decided it isn't worth the deployment complexity (every page load needs a server-side nonce; every user needs to be trained to look for the watermark). For financial institutions with dedicated fraud teams this is a reasonable feature. For a mid-market SaaS company, the canary signal home + user-side SDK warning is sufficient coverage at 1/20th the cost.

Part 2 — Signal collection and correlation

When the probe fires on a clone, we need to get a signal back to OpenBait without tipping off the attacker.

The signal

• Page URL the probe is running on (the phishing domain)
• Referrer (where the user came from — often the email campaign or ad origin)
• Rough geolocation (based on Cloudflare Edge; no IP stored)
• User agent fingerprint (not persistent identification; just browser/device class)
• Timestamp
• Optional: hashed DOM signature (helps us detect which parts of the site were cloned)

The transport

• POST to a neutral-looking beacon endpoint. Not canary.openbait.com — that's too obvious. The endpoint uses a generic-sounding path and rotates across several CDN-fronted subdomains.
• Retry with backoff, since victim browsers on clone pages often have flaky connectivity (attackers sometimes use sketchy hosting).
• Payload signed by a key the bootstrap carries, so the backend can filter out replayed / forged beacons.

Correlation

Every beacon gets bucketed by (customer brand, phishing domain, day). We care about two primary analytics questions:

1. Is this domain a real clone, or a reflection of our own site being cached somewhere? We cross-reference the phishing domain against a deny-list of legitimate reflections (archive.org, Google cache, preview services) and against a heuristic (too-few beacons + too-many origins = probably a reflection, not a phishing campaign).
2. How many real victims have landed on this clone? Each unique victim probe fires a beacon; we dedup by hashed device fingerprint within a 24-hour window.

We deliberately don't store cross-device user identity. Memcyco's Device DNA is persistent identification across sessions — this is part of what lets them do per-user ATO defense. We chose not to build that. It adds legal / privacy complexity that we judged not worth it for our ICP.

Part 3 — User-side SDK (the warning layer)

Separate from the canary, we ship an opt-in JavaScript SDK that customers embed on their legitimate site. When a user lands on the legitimate site having just been referred from a known phishing domain, the SDK shows an in-page warning.

Why this is different from the canary

• The canary is the signal from clones to us.
• The SDK is the signal on the legitimate site, warning users after they've been phished.

The Memcyco equivalent is their "Red Alert" overlay — but it fires on the clone, not on the legitimate site. Both approaches are reasonable. Ours has the advantage of running in a trusted execution context (the legitimate site); theirs has the advantage of warning users who never make it back to the legitimate site.

Implementation

• The SDK ships as a small JS snippet customers drop on login / payment / high-risk pages.
• On each page load, it checks the document.referrer against a blocklist we maintain (our own canary detections + upstream Phishing / Safe Browsing feeds).
• If the referrer is flagged, the SDK renders a warning modal: "It looks like you arrived here from a fraudulent site. If you entered credentials there, change your password now."
• The SDK is opt-in per customer (not a network-wide include) and uses a subresource-integrity-verified bundle.
• Zero cross-site user tracking. We don't identify users, just check the referrer hash against our blocklist.

Known failure modes

This is an honest section.

• Attackers who rewrite document.referrer to a benign value defeat the detection. Browser privacy policies (Chrome's Referrer Policy changes) already limit what referrer info we see, so this is already partial coverage.
• Users arriving via URL typed into a new tab have no referrer. Our SDK can't catch them.
• Users who encountered the clone but never made it to the legitimate site never hit our SDK. The canary handles that case (fires telemetry when they land on the clone), but the user doesn't get a warning unless the customer operates their own notification channel.

What Memcyco does that we don't, here

Memcyco's Red Alert fires on the clone itself, so users see a warning in the attack context even if they never reach the legitimate site. Their decoy credential swap — when a user enters stolen credentials, Memcyco intercepts the form submission and replaces it with a traceable fake — adds adversarial disruption we don't implement.

Both are real features that justify Memcyco's enterprise price point. We chose the simpler warning layer because:

1. The clone-side warning requires the canary to still be intact (sufficiently savvy attackers strip it).
2. Decoy credential swap raises regulatory flags (you are inserting forged data into a third-party form — legal opinion required per deployment).
3. The simpler mechanism covers the common case (users who came back to the legitimate site) for a tenth of the engineering complexity.

Part 4 — What this architecture deliberately doesn't do

Being explicit about our trade-offs:

Part 5 — Pricing the thing

Memcyco's AWS Marketplace listing shows Silver at $48K/year, Gold at $66K/year. Their typical enterprise contracts are reported in the $100K–$500K ACV range.

OpenBait's Business tier is $299/month ($3,588/year), or approximately 1/20th of Memcyco's enterprise floor. What makes that possible:

1. Self-serve signup — no field sales overhead at the $3K–$12K ACV tier
2. Simpler feature set — we deliberately skip per-user watermarking and decoy credential swap, which are the hardest parts of Memcyco's stack to maintain
3. Mid-market-appropriate SLAs — 48-hour response, not real-time fraud team escalation
4. Bundled with proactive scanning — our detection pipeline catches clones before the canary is needed in many cases, which reduces the criticality of any single component being perfect

The wedge is: if you're a mid-market company that wants Memcyco-class canary and SDK protection but doesn't have an enterprise fraud team and doesn't want to sign a $100K/year contract, we're built for that gap.

Part 6 — How to evaluate

If you're considering canary + SDK protection for your brand, here's what to actually test:

1. Deploy the canary on a single marketing page or a staging environment. Clone it yourself with wget or an HTML scraper. Confirm the canary fires telemetry.
2. Check CSP compatibility. Any canary that forces 'unsafe-inline' in your script-src is a non-starter for SOC 2 / ISMS 审查.
3. Ask about referrer-based SDK detection coverage on modern browsers. Chrome / Safari privacy defaults eliminate the referrer in many cross-origin cases; confirm the vendor's approach to this.
4. Ask about what happens when the canary is stripped. Any vendor that promises 100% detection is not being honest. The real question is: what's the cost curve for an attacker to defeat it?
5. Evaluate the backend analytics. A canary that fires but doesn't give you a usable dashboard is just noise.

OpenBait's free tier includes canary tokens and the base SDK. If you want to test this architecture in production on your own domain, sign up takes about five minutes. No sales call required.

---

Related

• OpenBait vs Memcyco — mid-market price, comparable tech
• A practitioner's guide to typosquat detection — 5 methods
• Stopping phishing without waiting for the registrar — browser blocklist reporting