A complex Microsoft 365 credential harvesting campaign that uses Cloudflare's own security features to avoid detection and steal user login information without being noticed This article explores uses cloudflare security. . The campaign shows a worrying trend: hackers are using the same tools that are meant to protect websites to protect their own bad infrastructure.
Many people trust platforms like Cloudflare because they protect against bots, deliver content, and stop DDoS attacks. But these same features, like checks to make sure the user is a real person, IP filtering, and user-agent inspection, can make it harder for security researchers and automated scanning tools to find malicious sites quickly. Attackers in this campaign took advantage of that very blind spot. The campaign that Domaintools found was based on the domain securedsnmail[.
]com, which was the first place victims could go to.
A multi-layered gatekeeping system went to work as soon as a user got to the page, so there was no chance of credential theft. A Cloudflare human verification (Turnstile) check was the site's first line of defense. It quickly blocked automated crawlers.
But the attackers didn't stop there. The phishing page also used api.ipify[. ]org to get the visitor's IP address and then checked it against a hardcoded blocklist that included IP ranges from major security companies like Palo Alto Networks and FireEye, as well as cloud infrastructure from AWS and Google.
If a visitor's browser had a suspicious user-agent string, like those that belong to Googlebot, Bingbot, AhrefsBot, or Twitterbot, the page would change itself into a convincing fake "404 Not Found" error. This would stop security scanners from indexing or flagging the site. Anyone who passed these checks was then sent through a hidden credential harvesting script.
The main logic for stealing was hidden inside a custom virtual machine function (e_d007dc) that read an array of encoded instructions. This made static code analysis useless. If the gatekeeping logic saw a security tool in the middle of a session, the VM quietly sent the destination URL to a real domain, like Google.com, so that there would be no evidence of the crime.
The DomainTools report says that victims who passed all the checks were sent to the real phishing URL, which looked like a Microsoft 365 login page that was meant to steal credentials in real time. The URL was formatted like this: https[:]//office.suitetosecured[. ]com/KuPbXodA?b=cGjQKg4&auth={} Researchers found that all of the phishing sites found in this campaign had the same Cloudflare Turnstile sitekey: 0x4AAAAAACG6TJhrsuZdpjsN.
This key is a static identifier that is linked to a specific Cloudflare dashboard setup. This means that security teams may be able to use it to find new phishing infrastructure before it is used in active campaigns on platforms like Shodan, Censys, and URLScan. Namecheap registered all of the domains in the campaign, and they were all hosted on Cloudflare's IP infrastructure. The nameservers pointed to cloudflare.com.
Indicators of Compromise: securedsnmail[. ]com, securedreach[. ]com, wirelessmailsent[.
]com, suitecorporate[. ]com, and suitetosecured[.]com. This campaign makes it clear that service providers like Cloudflare need to improve their Know Your Customer (KYC) processes right away and create systems that stop their security features from being used against the wider security community. As attackers get better at using real platforms for bad things, proactive platform accountability becomes just as important as endpoint defenses.
Follow us on Facebook, Twitter, and LinkedIn for daily cybersecurity updates. Get in touch with us to have your stories featured.
