Imagine if they used sites.google.com -- then it'd be even more convincing!then redirected to googleusercontent.com
Really surprising to see this. When @google.com can be weaponized, “trusted sender” checks aren’t enough. Detection has to focus on behavior and intent, not just infrastructure.
Thanks for your valuable information.TL;DR, courtesy of AI:
Scammers abused Google Cloud Application Integration by configuring an integration that uses the built-in “Send Email” task (which can send a custom subject/body to arbitrary recipients), so the phishing messages were legitimately generated by Google and arrived from Google’s real no-reply address. (Google Cloud Documentation)They made the emails resemble routine Google-style enterprise notifications (voicemail alerts, file-access/permission requests, etc.) to prompt victim's to click. (Check Point Blog)The embedded link started on a trusted Google Cloud URL (e.g., storage.cloud.google.com), then redirected to googleusercontent.com where a fake CAPTCHA/image check filtered out automated security scanners, before forwarding the user onward. (Check Point Blog)The final destination was an attacker-controlled site impersonating a Microsoft sign-in page to harvest their login details. (Check Point Blog)


