Service platforms that provide protection and content delivery, like CloudFlare, have become a go-to for many web service hosts—including some malicious actors. These platforms offer inherent benefits like obfuscation, anti-bot, and anti-scanner tools. While excellent for defending legitimate customers, these very features can inadvertently shield malicious sites from proactive identification by security professionals and automated scanning services. This creates a challenging dynamic in the industry where a service provider's role in protecting its customer base competes with the broader community's need for effective security scanning.
This report details a recent Microsoft 365 credential harvesting campaign that leverages this dynamic to delay detection and risk profiling. The campaign implemented multiple anti-detection techniques including the use of CloudFlare human verification, hardcoded IP block lists, user agent checks, and multiple sites and redirects. This cluster highlights the need for service providers to consider taking on an even greater responsibility in knowing their customers and ensuring their defensive capabilities are not being abused to actively protect malicious actors.
Details
Gatekeeping and redirection paths
The site code contains a few layers of gatekeeping to ensure the visitor is a real target and not a security tool.
CloudFlare Human Verification: There's an initial CloudFlare human verification check and redirection.
Aggressive IP and User-Agent Filtering: The site code fetches details about the visitor's IP using https[:]//api.ipify[.]org/?format=json and checks it against a hardcoded blocklist. This list includes ranges belonging to major security companies (Palo Alto, FireEye) and cloud providers (AWS, Google), as well as search engine crawlers.
It also sniffs the visitor's browser for bot-like User-Agents. If a security scanner or bot is detected (e.g., Googlebot, Bingbot, AhrefsBot, or Twitterbot), the page replaces itself with a fake "404 Not Found" message to prevent the malicious site from being indexed or flagged.
User Agent Checks:
IP Checks:
The core credential theft logic is not written in standard JavaScript. Instead, it is executed by a custom VM function (e_d007dc) that interprets an array of encoded instructions. This prevents static analysis from identifying the data-stealing parameters or the Command & Control (C2) URLs.
The framework dynamically updates its destination. When the gatekeeping checks flag, it switches the URL in the VM to a legitimate domain like Google.com, neutralizing the malicious footprint for any subsequent analysis.
Obfuscated Credential Harvesting:
If the user passes these checks, an obfuscated script builds and redirects them to the credential harvesting URL built from an obfuscated script in the following format: `https[:]//office.suitetosecured[.]com/KuPbXodA?b=cGjQKg4&auth={}`, which it then designates an auth value that is presumably used to verify and track the user passing the gatekeeper to the next stage sites.
In reviewing the multiple phishing sites identified in this campaign, a commonality in the Cloudflare turnstile configuration was observed. The Cloudflare Turnstile sitekey (0x4AAAAAACG6TJhrsuZdpjsN) is a static identifier. Specifically, the “CG6TJhrsuZdpjsN” portion appears to be the unique identifier created when a Cloudflare user sets up the Turnstile widget in their CloudFlare dashboard. Security teams could possibly pivot on this key across telemetry sources (e.g. Shodan, Censys, URLScan) to identify newly registered phishing sites before they are utilized in campaigns.
Registration Commonalities
Nameserver: cloudflare.com
Registrar: NAMECHEAP INC
mx host: registrar-servers.com
IP ISP: CloudFlare Inc.
MX Domain:
- jellyfish[.]systems
- registrar-servers[.]com
Conclusion
The strategic abuse of legitimate content delivery and security platforms, such as CloudFlare, by malicious actors creates a considerable obstacle to proactive security scanning and detection. The Microsoft 365 credential harvesting campaign described in this report, which also employed multiple anti-detection mechanisms, shows how these defensive features can inadvertently shield malicious sites, delay their detection, and hinder informed risk assessments. To address this evolving dynamic, service providers should accept greater responsibility in knowing their customers and ensuring their platform's security capabilities are not leveraged to actively protect malicious campaigns.
