Phishing is one of the tried-and-true methods that attackers have been heavily relying on since the early days of the internet, but it is far from a stagnant technique. Over the years, phishing has grown and shifted from crude impersonation tactics to complex multi-step attacks and advanced tactics. Attackers have even evolved to directly leverage trusted platforms, as demonstrated in a recent campaign abusing Google Cloud Application Integration. This campaign represents a broader trend where attackers operate inside legitimate ecosystems rather than attacking from the outside.
How the Campaign Worked
Attackers misused Google Cloud Application Integration capabilities to distribute phishing messages to their targets. Using the “Send Email” task, the threat actors sent almost 9,400 emails to more than 3,000 customers, all originating from the Google address noreply-application-integration@google.com. This tactic is a step up from spoofing email addresses, helping to bolster credibility and increase the chances of the messages being delivered to targets’ inboxes, opened, and trusted. The scale of these attacks is notable, as well as the diversity of the targets across regions and industries.
The phishing attacks utilized a link redirection technique to lead to eventual credential harvesting. The initial links in the phishing emails were hosted on a trusted cloud service and redirected to pages with fake CAPTCHA or image verification to filter out bots and scanners. After users got through this verification, they were directed to a spoofed Microsoft login page, where attackers captured their credentials.
Why Traditional Email Security Failed
Classic email security checks like SPF, DKIM, and DMARC usually help to verify that emails are from the sender they claim to come from, to protect users against spoofed domains and spam emails. These traditional measures failed to catch the Google Cloud campaign emails because they genuinely originated from a legitimate Google-owned domain, storage.cloud.google.com.
The usual trust signals worked exactly as they were designed to in letting these emails through without flagging them as suspicious or malicious. Unfortunately, they didn’t work in defenders’ favor this time, as attackers were able to leverage those very trust signals to evade detection.
The Automation Abuse Problem
This campaign is representative of a wider problem of attackers abusing automation tools for malicious ends. These tools have legitimate uses that many organizations benefit from. “IT and DevOps teams use application integration and other cloud automation services a lot to automate real business processes, like system notifications, permission requests, onboarding messages, and operational warnings, without any help from people,” according to Randolph Barr, Chief Information Security Officer at Cequence Security, a San Francisco, Calif.-based API security and bot management provider.
However, these tools can also be leveraged by threat actors for nefarious ends. Low-code and no-code automation tools, like Google Cloud Application Integration functions, are particularly attractive to attackers as they require less overhead investment of skills and expertise. These tools are flexible, easy to use, and come with the implicit trust that users place in legitimate infrastructure, a combination that creates a powerful abuse surface that many organizations are not monitoring closely.
What This Means for Enterprises
It is crucial for enterprises to look at incidents like this and take lessons away to improve security and avoid attacks in the future. This campaign has significant implications for security teams to consider, especially those that rely heavily on trust signals like domain reputation and infrastructure trust. These attacks highlight the growing need for advanced security measures like behavioral analysis, contextual inspection, and user-level risk assessment rather than depending entirely on binary trust decisions.
Experts emphasize the priorities that organizations should have in protecting against attacks like this campaign. “To reduce risk, companies should limit who can set up external emails, use least-privilege access to automation services, and keep track of and report workflow activities like any other API or non-human identity,” says Barr, stressing the responsibilities of security, IT, and DevOps teams to understand organizational use of automation tools and implement guardrails.
Rethinking Trust in Cloud-First Security Models
Moving forward, defenders must recalibrate assumptions about “trusted senders” and “safe platforms” to avoid falling victim to attacks like the Google Cloud campaign. Traditional security approaches and strategies have relied on measures like SPF, DKIM, and DMARC to flag and block suspicious and malicious emails. However, attackers have shown that their methods have moved beyond what these measures can handle.
In the face of modern attacks, trust becomes conditional, contextual, and continuously evaluated, rather than static. Decisions based on binary trust signals must be backed up by advanced security functions that go beyond traditional measures.
Lessons for Cloud Providers and Customers Alike
There is a shared responsibility in preventing attacks like this Google Cloud campaign. It is vital for cloud providers to implement better abuse detection and guardrails to block phishing attempts leveraging legitimate services. At the same time, customers must exercise caution and assume that even trust platforms can and will be misused.
