"Microsoft Clairty" Isn't Microsoft Clarity: Deobfuscating a Typosquatted Ad Fraud Script

A browser extension is injecting obfuscated JavaScript from msclairty[.]com, a typosquatted domain impersonating Microsoft Clarity. The script deletes Google Analytics cookies, stuffs affiliate cookies with the value pub=twsc, injects hidden iframes to discounthero[.]org, and hijacks the Fetch API. No security tool flags this domain. This is the first public documentation of msclairty[.]com.

What is msclairty[.]com?

msclairty[.]com is a typosquatted domain designed to impersonate Microsoft Clarity (msclarity[.]com / clarity[.]ms), the popular analytics and heatmap tool from Microsoft. The letters "i" and "r" in "clarity" are transposed to "clairty", making it subtle enough to pass a quick glance in a network log or script tag.

The domain is not serving analytics. It is delivering an obfuscated JavaScript payload that performs affiliate cookie stuffing, tracking cookie deletion, and Fetch API hijacking inside the visitor's browser.

How was this script discovered?

Over the last 48 hours, we started observing network requests to msclairty[.]com across multiple unrelated websites in our telemetry. The first request we recorded was on March 2, 2026 at 21:17 UTC, with traffic ramping sharply through the morning of March 3. The traffic is not coming from a compromised script tag in page source. It is being injected by a browser extension. We have not yet identified the specific extension responsible, but the injection pattern is consistent across every affected site: same obfuscated payload, same domain, same behavior, regardless of the site's own script inventory.

The common denominator is the end user's browser, not the site's codebase.

We observed the script affecting sites across multiple unrelated industries, including transportation, SaaS platforms, sports management, and government payment portals. The affected visitors span multiple Chrome versions (132, 138, and 145) and originate from US-based IP addresses on the East and West coasts. Every affected site loads the identical event.js campaign identifier and receives the same payload hash, confirming this is a single coordinated campaign running through one browser extension.

The campaign IDs rotate daily. On March 2, the loader URL was event.js?id=dHRcSiYkDj4&date=2026-03-02. On March 3, a new campaign ID appeared: event.js?id=XGp2NSkTRVs&date=2026-03-03. The date= parameter matches the date of each campaign rotation. This means the infrastructure is actively maintained and deploying fresh campaign identifiers on a daily cadence.

Every affected user shares the same fingerprint. Across all requests in our telemetry, the browser profile is identical: Windows 10 x64, desktop Google Chrome, no mobile. There is not a single request from Firefox, Safari, Edge, Brave, macOS, Linux, Android, or iOS. This is a Chrome-only extension. The sec-ch-ua client hints confirm real Chrome (not Chromium forks that report differently), and sec-ch-ua-mobile: ?0 confirms desktop on every request. We observed only 5 unique visitor IPs across all affected sites, all on US residential connections.

The full attack follows a two-stage loading pattern where the server makes per-request targeting decisions about which payload to deliver.

Stage 1: Loader script (event.js)

hxxps://msclairty[.]com/event.js?id=dHRcSiYkDj4&date=2026-03-02
hxxps://msclairty[.]com/event.js?id=XGp2NSkTRVs&date=2026-03-03

The event.js loader is 8,599 bytes. The id= parameter is a campaign identifier that rotates daily. On March 2 the campaign ID was dHRcSiYkDj4. On March 3 it changed to XGp2NSkTRVs. The date= parameter matches the date of each rotation. The first loader we captured was last modified on March 2, 2026 at 09:58:50 GMT.

We deobfuscated the loader and it does the following:

1. Console hijacking. Overwrites all 7 console methods (log, warn, info, error, exception, table, trace) immediately on load, before any payload runs.
2. Anti-iframe check. Compares window.self to window.top and exits if the loader is running inside an iframe. It only executes in the top-level browsing context.
3. Dedup cookie check. Reads the __tr_luptv cookie using a getCookie() helper. If the cookie already exists, the loader exits. This is the same cookie the payloads set after firing. It serves double duty: attacker attribution for commission fraud and a "don't run twice" guard that prevents repeat execution across page loads.
4. Server-side targeting request. Sends a POST to msclairty[.]com with Content-Type: application/x-www-form-urlencoded containing four parameters: url (the current page URL), referrer (document.referrer), unique_id (the campaign ID from the id= parameter), and ext: 'twsc' (the attacker's affiliate identifier, hardcoded). The server responds with JSON containing a data field (the Base64-encoded filename for the payload) and a type field (which ?type= variant to load).
5. Dynamic payload injection. Constructs the Stage 2 URL by concatenating the server's response: https://msclairty[.]com/js/ + response.data + .js?type= + response.type, creates a <script> element, sets its src to this URL, and appends it to document.head.
6. SPA navigation hooks. Monkey-patches history.pushState and history.replaceState to dispatch custom locationchange events. Listens for popstate. On every client-side navigation in a single-page application, the loader re-runs the Info() function with the new URL, giving the server another chance to deliver a payload. A 500ms debounce (wait_nw semaphore) prevents rapid re-execution on fast route changes.

The server decides the attack, not the script. The loader sends the page URL and referrer, and the server responds with both the encoded payload filename and the ?type= value. This means different sites, different pages, or different referrers can receive different payload variants. A product page might get type=1 (silent cookie stuffing) while a checkout page might get type=5 (forced redirect). The targeting logic is entirely server-side and invisible to client-side analysis.

Stage 2: Obfuscated payload

hxxps://msclairty[.]com/js/[Base64-encoded-blob].js?type=[1-5]

The payload weighs in at 10,007 bytes. The Base64-like filename is generated server-side based on the page URL and referrer sent by the loader. The ?type= parameter, also chosen by the server, selects which of the five attack variants gets executed. The function inside each payload is named to match its variant (type1(), type2(), type8(), type9(), type11()).

Which security tools flag msclairty[.]com?

None of them. We checked every major threat intelligence platform and security tool available. As of publication, not a single one flags msclairty[.]com as malicious:

• VirusTotal: 0 out of 90+ engine detections
• urlscan.io: no scan results, no community submissions
• Google Safe Browsing: not flagged
• SecurityTrails: no DNS history, no WHOIS enrichment
• ANY.RUN: no sandbox submissions for this domain
• Hybrid Analysis / Falcon Sandbox: no results
• PhishTank: not listed
• OpenPhish: not listed
• MalwareBazaar: no samples
• ThreatFox (abuse.ch): no IOC entries
• Cloudflare Radar: no data

This is zero coverage across every major platform. This post is the first public documentation of this domain being used for malicious purposes.

How cside detected this script

cside autonomously detected this script through runtime behavioral analysis. No threat feed flagged the domain. No scanner returned the payload. No signature matched. The detection was based entirely on what the script did inside the browser: deleting tracking cookies, injecting a hidden iframe, hijacking the Fetch API, and suppressing the console.

Browser extension scripts are beyond your control as a website owner. You cannot prevent an extension from injecting code into your pages. But it helps to know that the abuse is taking place. The script deletes the legitimate RedTrack attribution cookie (rtkclickid-store) and replaces it with the attacker's own affiliate token pub=twsc through the discounthero[.]org redirect chain. If you use RedTrack for affiliate conversion tracking or depend on accurate traffic attribution, this kind of fraud is actively stealing commission from your legitimate affiliates and you would never see it without client-side visibility.

Use cside to understand how your application behaves in the browser. Detect signals of fraud by visitors, AI agents, and client-side dependencies.

cside has shared this intelligence with Microsoft so they can pursue a takedown of msclairty[.]com for malicious typosquatting of their Clarity brand. We have also reached out to RedTrack, as their rtkclickid-store attribution cookie is being explicitly targeted for deletion in this attack and the affiliate token pub=twsc is being used to override legitimate RedTrack click attribution with fraudulent commission claims.

Start for free or book a demo to talk to our team.

Why do AI tools and scanners get a 403 from msclairty[.]com?

The server behind msclairty[.]com runs on an Express (Node.js) backend fronted by Cloudflare. Response headers include x-powered-by: Express, cf-cache-status, and access-control-allow-origin: *. The payload is cached by Cloudflare with a max-age of 14400 seconds (4 hours).

Despite being on Cloudflare, the server actively blocks automated analysis. When AI-powered tools like ChatGPT, Claude, and Perplexity attempt to fetch content from the domain, the server returns a 403 Forbidden response. The same happens with automated security scanners and any request originating from datacenter IP ranges.

This is deliberate filtering based on IP address ranges, user-agent strings, or other request fingerprinting. The server only delivers the malicious JavaScript payload when the request appears to come from a real browser with the correct referrer, user-agent, and headers. Datacenter IPs, known bot user-agents, and AI tool request signatures are all blocked.

This anti-research behavior also explains why VirusTotal, urlscan.io, and other scanning platforms return clean results or no results at all. They never receive the real payload.

What do the request headers reveal about the msclairty[.]com extension?

Every request in our telemetry shares an identical browser fingerprint: Windows 10 x64, desktop Google Chrome, sec-ch-ua-mobile: ?0. There is not a single request from Firefox, Safari, Edge, Brave, or any mobile browser. No macOS, Linux, Android, or iOS.

This is significant. If the extension were available on the broader Chromium ecosystem, we would expect to see Edge or Brave user-agents in the mix, since both support Chrome Web Store extensions. The fact that every request reports "Google Chrome" in the sec-ch-ua client hints and standard Chrome user-agent strings suggests this is either a Chrome-only extension or has only been installed by Chrome users so far.

Three Chrome versions appear in the data: 132, 138, and 145. Chrome 132 was released in January 2025 and is now outdated. Chrome 138 and 145 are more recent. The spread across versions rules out a version-specific exploit and is consistent with a voluntarily installed extension that persists across Chrome updates.

Other notable header patterns:

The sec-fetch-storage-access header appears with values active and none on the initial script loads (sec-fetch-dest: script). This indicates the extension interacts with the Storage Access API, which governs cross-site cookie access. This is consistent with an extension that needs cross-site storage to operate its cookie-stuffing mechanism.

All POST requests use content-type: application/json with varying content-length values ranging from 604 to 10,246 bytes. These are the event.js beacons sending data back to msclairty[.]com. The varying payload sizes suggest the script is exfiltrating different amounts of page or session data depending on the browsing context.

The dnt: 1 (Do Not Track) header is present on requests from Chrome 145 and Chrome 138 users but absent from Chrome 132. This is a user preference, not an extension behavior, but it confirms these are real end users with individually configured browsers.

When was the msclairty[.]com domain registered?

The SSL certificate for msclairty[.]com was issued on February 20, 2026 at 20:14:54 UTC. That is just 10 days before we first observed live traffic from this domain on March 2. This is a freshly registered domain, purpose-built for this campaign.

WHOIS registration details are hidden behind a privacy service. No historical DNS records exist for this domain in SecurityTrails or passive DNS databases.

What does the msclairty[.]com script actually do?

After deobfuscation, the script performs six distinct actions. None of them have anything to do with analytics or heatmaps.

Step 1: DevTools detection

The script checks whether browser developer tools are open before executing anything. It compares window.outerWidth - window.innerWidth and window.outerHeight - window.innerHeight against a 120-pixel threshold. It also checks for Firebug and window.chrome.isInitialized.

If any check indicates that someone is inspecting the page, the script exits immediately. It only runs for real users, never for developers or security researchers.

Step 2: Console hijacking

The script overwrites seven native console methods: log, warn, info, error, exception, table, and trace. All seven are replaced with empty no-op functions. This prevents any warnings or debug output from appearing if someone opens DevTools after the script has loaded.

A separate console.clear() call fires on a 3-second timer to wipe anything that might have been logged before the overwrite took effect.

Step 3: Tracking cookie deletion

The script deletes the following cookies at both the path level and the root domain level:

• _ga (Google Analytics client ID)
• _gid (Google Analytics session ID)
• rtkclickid-store (RedTrack affiliate click attribution)

This is the most important behavior to understand. By deleting the RedTrack rtkclickid-store cookie, the script wipes the legitimate affiliate click attribution for that visitor. By also deleting Google Analytics cookies, it removes any evidence of how the user actually arrived at the site. The visitor's real traffic source disappears entirely. This clears the way for the attacker's own affiliate token (pub=twsc) to become the sole attribution source.

Step 4: Hidden iframe injection and affiliate cookie stuffing

A 1x1 pixel hidden iframe is injected into the page body. The iframe loads the following URL:

hxxps://discounthero[.]org/us/s/red_u_plain.php?t=direct&s=287&d=[target]&pub=twsc

The iframe uses referrerpolicy="noreferrer" to suppress the referrer header.

Here is what each URL parameter means:

• t=direct: traffic type marker
• s=287: campaign identifier
• d=[target]: the site being defrauded (the value changes per victim site)
• pub=twsc: the attacker's affiliate publisher ID

The value pub=twsc is the affiliate account that receives the fraudulent commission. This is the core of the attack. The hidden iframe silently loads a redirect chain through discounthero[.]org that drops an affiliate cookie in the user's browser. If the user later visits the target site and makes a purchase, the attacker behind pub=twsc earns a commission they never generated. The cookie deletion in step 3 ensures no competing attribution exists.

After 20 seconds, the iframe is removed from the DOM. No visual trace remains on the page.

Step 5: Fetch API hijacking

Inside the injected iframe, the script monkey-patches window.fetch. Any fetch request containing nivtrck[.]com (encoded as bml2dHJjay5jb20= in Base64) is silently blocked with a rejected Promise.

This prevents a competing tracking service from recording the real traffic source. The attacker does not just want credit for the visit. They actively block other trackers from capturing any attribution data that would conflict with their fraudulent cookie.

Step 6: Referrer suppression and attacker tracking cookie

A <meta name="referrer" content="no-referrer"> tag is injected into the page's <head>, suppressing referrer headers on all outbound navigations. This hides the fraud from downstream analytics on the target site.

The script also sets its own tracking cookie:

__tr_luptv = [current timestamp minus 300000 milliseconds]

The cookie value is Date.now() - 300000 (current time minus 5 minutes), set on both the root path and the site's root domain. This backdated timestamp likely signals to the discounthero[.]org redirect chain that the visitor has already been tagged and should not be processed again.

How is the msclairty[.]com script obfuscated?

The code uses a standard but effective obfuscation stack that defeats most static analysis tools:

• A rotated string array containing approximately 95 Base64-encoded entries
• A decoder function that translates array indices to readable strings at runtime
• Proxy objects that wrap function calls and string references behind randomized property names
• An IIFE shuffle loop that rotates the array until a checksum matches, ensuring the decoder produces correct values

The obfuscated code looks like random noise. No static analysis tool, signature scanner, or regex-based detection will identify malicious behavior from the raw source. You have to execute the decoder to see what the script actually does.

What is discounthero[.]org?

discounthero[.]org is the affiliate fraud redirect endpoint used in this attack. Unlike msclairty[.]com, this domain has an established presence across multiple threat intelligence platforms:

• Hosted on AWS infrastructure at IP 3.68.5.1 (AS16509, AMAZON-02), geolocated to Germany
• Classified as an adware distributor by Gridinsoft
• Flagged as malicious in ANY.RUN sandbox analyses with Tycoon 2FA phishing indicators
• Appeared in Falcon Sandbox analysis reports alongside known ad fraud domains
• Reported by users in multiple browser forums as a source of malvertising redirects, including incidents on the Daz3D community forums
• Uses the red_u_plain.php redirect endpoint with per-campaign parameters (s=, d=, pub=, t=)
• Redirect chain flows through gracylifestyle[.]com (Cloudflare) to d33old9jdtt77h.cloudfront.net (Amazon CloudFront)

What is nivtrck[.]com?

nivtrck[.]com is the tracking domain that the script actively blocks through Fetch API hijacking. This domain has zero public documentation across all threat intelligence platforms, sandbox reports, and WHOIS history databases. It may be a legitimate tracking service whose attribution the attacker wants to suppress, or it may belong to a competing fraud operation.

Indicators of compromise (IOCs) for msclairty[.]com

Why does this attack bypass traditional security tools?

This attack bypasses traditional security tools for two reasons: the injection vector and the evasion techniques.

The script is injected by a browser extension, not embedded in the site's source code. This means Content Security Policy headers will not block it. Tag audits will not find it. Subresource Integrity checks do not apply. Server-side security tools have no visibility into what a browser extension injects into the page at runtime.

On top of that, the server behind msclairty[.]com filters requests aggressively. Security scanners, AI-powered research tools, and any request from a datacenter IP or known bot user-agent receives a 403 Forbidden response. Even if a scanner somehow retrieved the real payload, the obfuscated source contains no recognizable signatures or known malicious patterns that static analysis would flag.

The script also evades manual research. It detects open DevTools and exits. It overwrites all console methods. It removes the iframe from the DOM after 20 seconds. It wipes the console after 3 seconds.

The loader adds another layer: it hooks history.pushState, history.replaceState, and popstate to re-trigger on every client-side navigation in single-page applications. Each route change sends the new URL to the server for fresh targeting. And because the server decides which payload variant to deliver based on the page URL and referrer, static analysis of a single captured payload cannot reveal the full range of attacks the infrastructure is capable of.

How do you detect affiliate cookie stuffing attacks like this?

Blocklist-based detection does not work against this type of attack. The domain is too new for any threat feed to have indexed it. The obfuscation defeats static analysis. The server blocks automated scanners and AI tools with 403 responses.

The only reliable detection method is runtime behavioral analysis: monitoring what scripts actually do inside the browser rather than analyzing their source code or checking their domain against a blocklist. Cookie deletion, hidden iframe injection, Fetch API hijacking, and console suppression are all observable behaviors that are clearly malicious regardless of what the source code looks like or where the script was loaded from.

This is what real-time client-side security monitoring is built for.

What does the ?type= parameter mean?

The URL takes a ?type= query parameter that selects which attack payload the server returns. We have confirmed five variants. Each one escalates in aggression. All five share the same evasion core: DevTools detection (exits if open, 150px threshold), console hijacking (7 methods overwritten), cookie deletion (_ga, _gid, rtkclickid-store at path and root domain level), attacker attribution cookie (__tr_luptv = Date.now() - 300000), referrer suppression via meta tag, and the same affiliate target (discounthero[.]org with pub=twsc and s=287).

The ?type= parameter value (1 through 5) is sequential, but the internal function names are not. This mismatch reveals the true scale of the infrastructure.

?type=1 (function type1()) -- Silent affiliate cookie stuffing

Injects a hidden 1x1 iframe to discounthero[.]org with pub=twsc. The iframe loads the affiliate redirect chain, drops the attacker's cookie, and self-destructs after 20 seconds. The Fetch API is hijacked to block requests to nivtrck[.]com. The visitor sees nothing.

?type=2 (function type2()) -- Cookie stuffing + content injection

Does everything type=1 does. Then it fetches a second URL from a server-side template variable {{link2}}, creates a second hidden 0x0 iframe, writes the fetched HTML into it using contentWindow.document.write(), and spoofs the iframe URL with history.replaceState. The second iframe self-destructs after 15 seconds. The {{link2}} placeholder is filled server-side per target and could deliver phishing overlays, ad injection, or page manipulation.

?type=3 (function type8()) -- Click hijacking (piggyback)

No iframe. Installs a click event listener on document.body. When a visitor clicks any <a> tag with an href starting with "http", the script calls preventDefault(), then redirects the browser to the original URL with the discounthero[.]org affiliate redirect appended as a query parameter. The user still reaches their intended destination, but the navigation passes through the attacker's redirect chain on the way.

?type=4 (function type9()) -- Click hijacking (direct redirect)

Same click interception as type=3, but the redirect direction is reversed. Instead of appending the affiliate URL to the original destination, it sends the user directly to discounthero[.]org with the original URL encoded as a parameter using encodeURIComponent(). The user visibly navigates through the attacker's infrastructure first, then gets forwarded to their intended destination after the affiliate cookie is dropped.

?type=5 (function type11()) -- Auto-redirect (no click required)

The most aggressive variant. No iframe. No click interception. After a 400-millisecond delay, the script forcibly redirects the entire page using window.location.search. The user is automatically navigated away from the page they were viewing to the discounthero[.]org affiliate chain. No interaction required. The 400ms delay is just long enough for the cookie deletion and __tr_luptv cookie to be set before the redirect fires.

The function names are non-sequential. The ?type= parameter runs from 1 to 5, but the functions are named type1, type2, type8, type9, and type11. Values above 5 return blank responses. The gaps in function numbering (type3 through type7, type10) likely reflect retired or deprecated variants from earlier iterations of this infrastructure. Five active payload types, escalating from silent to forcible.