Microsoft Threat Intelligence has documented a macOS ClickFix campaign that has evolved from openly serving malicious commands to using server-side browser fingerprinting. Previously, the attack chain was visible to any visitor, but now it profiles each request and only reveals the lure to genuine macOS browsers. This shift disrupts the detection workflows your security stack relies on.
What Changed
The campaign used over 250 domains with a recognizable naming pattern (filecopperbasket, filevelvettractor, applefilevault). Initially, visiting a domain would return the complete attack: paste-to-Terminal instructions, clipboard-write logic, obfuscated shell command, and staging URL, all visible in the HTML source. Scanners that didn't execute JavaScript could recover the entire chain from passive data.
Now, these domains return a 2.5 KB JavaScript profiling routine. To crawlers and automated scanners, the site appears blank or parked. Sandbox environments that fail fingerprinting checks receive benign decoy pages, such as fake VPN landing pages or browser extension sites. Only requests with a genuine macOS browser fingerprint receive the ClickFix lure, distributing MacSync or Atomic Stealer (AMOS).
Since this decision happens server-side on a per-request basis, the same URL can return different content to different requests. An apparently benign response doesn't mean the domain is safe.
Key Findings
The fingerprinting gate collects six categories of signals. It profiles browser identity (navigator platform, user agent, vendor, plugins), display characteristics (screen size, color depth, window dimensions, pixel ratio), page context (document title, referrer, URL), and console object enumeration. These values merge into a single fingerprint object submitted to the server for evaluation.
WebGL-derived GPU signals distinguish real Apple hardware from virtualized environments. The gate uses the WebGL browser graphics API to retrieve graphics-processing details. These signals help identify software-rendered, emulated, or sandboxed environments before the server decides whether to return the lure.
Environmental and behavioral checks identify uncommon execution contexts. The gate records timezone offset (unusual values suggest hosted infrastructure or sandboxes), checks whether the page runs inside an iframe (common in crawlers and analysis tools), and probes for touch-input support (uncommon on desktop macOS, useful for identifying emulated environments).
Anti-analysis techniques detect browser instrumentation. A toString() counter increases when developer consoles are open or when headless tools serialize console output. A prototype-tamper probe repurposes the canPlayType() video-format check to identify environments where standard browser methods have been modified, common in automation frameworks.
The cloaking limits visibility for multiple detection layers. Passive DNS collection, URL scanners, threat-intelligence feeds that rely on crawling, and sandboxes that don't replicate genuine macOS browser fingerprints all receive decoy content or blank pages. Your existing detection workflows may classify these domains as benign while they continue serving malware to real users.
What This Means for Your Team
If you're implementing ISO/IEC 27001 Annex A 8.16 (monitoring activities) or SOC 2 CC7.2 (system monitoring), verify your controls can detect threats that actively evade automated analysis. The fingerprinting gate doesn't just bypass a single tool; it breaks the assumption that scanning a URL reveals what users see.
For SOC 2 Type II audits, demonstrate that your threat-detection controls remain effective when adversaries cloak their infrastructure. If your evidence shows only automated scanner results, your auditor will ask how you validate that those scans represent actual user experience. For ISO/IEC 27001 clause 8.2 (information security risk assessment), document how your risk-treatment plan addresses detection gaps created by server-side cloaking.
This campaign also challenges your incident-response evidence collection under ISO/IEC 27001 Annex A 5.24 (information security incident management planning and preparation). If you're investigating a suspected compromise and your URL analysis returns benign content, you can't conclude the domain is safe. You need forensic artifacts from the actual victim endpoint, not just scanner output.
Action Items by Priority
Immediate: Update your threat-hunting queries to include domain-pattern pivots. Search for domains containing "file" combined with dictionary-style words (filecopperbasket, filevelvettractor) and domains placing "file" in the middle or end (applefilevault, bananafastfile). Treat the naming pattern as a clustering signal, not a complete signature. The stronger indicator is the combination of dictionary-style domains, shared infrastructure behavior, and conditional content delivery.
This week: Verify your macOS endpoint-detection coverage captures Terminal execution chains. ClickFix attacks start from user-run Terminal commands, avoiding parts of the normal macOS application trust path (quarantine handling, code-signing evaluation, notarization checks). Your EDR must log shell command execution, not just downloaded application launches. Test whether your current configuration would capture a curl one-liner retrieving remotely hosted content.
This month: Document your detection-validation methodology for your next audit. Update your SOC 2 or ISO/IEC 27001 control documentation to explain how you verify that automated scanners accurately represent user-facing threats. Include manual validation steps, threat-intelligence correlation, and endpoint telemetry review. Your auditor needs evidence that you've considered detection gaps created by server-side cloaking.
This quarter: Assess whether your risk-treatment plan addresses adaptive adversary behavior. Review your scenario-based risk assessment under ISO/IEC 27001 clause 6.1.2. If your threat scenarios assume static infrastructure that reveals itself to automated analysis, update them to include adversaries who profile your detection tools before deciding what content to serve. Your risk register should reflect the possibility that domains classified as benign during scanning may still be serving malware to real users.
