Cloud-hosted phishing turns trusted infrastructure into an attack path

At a glance

What this is: Aryaka describes a cloud-based phishing campaign that uses Google Cloud Storage-hosted redirectors and fraudulent sites to bypass trust heuristics and email filters.

Why it matters: It matters because IAM, email security, and fraud teams need to treat trusted cloud infrastructure, domain authentication, and user trust as a combined attack surface rather than separate controls.

Context

Phishing has moved beyond suspicious domains and crude impersonation. Attackers increasingly borrow trusted cloud services, browser redirects, and analytics tooling to make malicious journeys look normal, which weakens controls that rely on domain reputation alone.

In this campaign, the security gap is not just email filtering but the trust model behind it. When a message can look legitimate, resolve through a reputable cloud service, and carry user data into a fake reward flow, the attack is working across identity verification, web trust, and cloud governance at once.

Key questions

Q: How should security teams respond when phishing infrastructure is hosted by legitimate providers?

A: Treat the provider relationship as part of the response path. Capture evidence, preserve timestamps, escalate through the provider’s abuse process, and coordinate legal or brand-protection teams when the abuse is persistent. The goal is to remove the criminal’s operational access, not only block the lure locally.

Q: Why can SPF pass while a phishing email is still dangerous?

A: SPF only confirms that a sending server is authorised for a domain. It does not prove that the message is genuine, that the brand is trusted, or that the linked destination is safe. If DKIM is absent and DMARC is weak, attackers can still deliver convincing impersonation emails that reach users and bypass confidence controls.

Q: What are the signs that cloud-hosted phishing is bypassing your controls?

A: Look for messages that use familiar branding, link through cloud storage or other reputable services, and rely on redirects or CAPTCHA before the final destination appears. If user reports show legitimacy cues but downstream pages ask for deposits, rewards registration, or data capture, your filtering and trust logic are not keeping pace.

Q: How do cloud-based phishing campaigns change the role of email security teams?

A: They force email security teams to work with cloud operations, identity teams, and fraud responders rather than only tuning mail filters. The goal is to detect when trusted infrastructure is being used to carry users into scam flows, then remove the content, revoke trust, and stop the campaign from iterating.

Technical breakdown

How cloud-hosted redirectors defeat link filtering

A redirector is an intermediate page that sends the browser onward to the final payload or scam site. When attackers host that redirector in a trusted cloud service, the URL looks less suspicious than an obvious malware domain and can survive basic reputation checks. Static scanners often inspect the first hop, but the real malicious destination only appears after the browser executes the page’s script. That means defenders are forced to analyse behaviour, not just URL strings. The security problem is not only hosting, but the abuse of a legitimate delivery layer to hide intent until runtime. See the Cloud Misconfiguration Guide.

Practical implication: Inspect redirect behaviour and browser-executed scripts, not only the visible URL or first-hop domain.

Why SPF alone does not prove message legitimacy

SPF only checks whether a sending server is allowed to send mail for a domain. It does not authenticate message content, and it does not confirm that the visible brand in the email matches a trustworthy sender relationship. If DKIM is absent and DMARC policy is weak, a message can still arrive in inboxes with enough legitimacy cues to bypass user suspicion and some automated controls. That is why email authentication must be treated as a layered trust model, not a single gate. Authentication without policy enforcement leaves room for impersonation at the delivery edge. See the Email Security Guide.

Practical implication: Tighten DMARC enforcement and require alignment between visible brand, authenticated sender, and policy outcome.

How legitimate cloud infrastructure becomes part of the fraud chain

Cloud hosting changes the economics of phishing. Attackers no longer need to operate suspicious infrastructure that is easy to blacklist; they can place pages, redirects, and tracking components inside reputable services and exploit the trust those services already carry. In this case, Google Cloud Storage is not the root vulnerability. The real issue is that defenders and users often extend inherited trust to the platform itself, even when the content hosted there is hostile. That weakens perimeter-style assumptions and pushes detection toward content analysis, user-behaviour signals, and rapid takedown coordination. See the Google Cloud Security Guide.

Practical implication: Treat trusted cloud platforms as potential abuse vectors and monitor them for malicious content patterns, not just traffic anomalies.

Threat narrative

Attacker objective: The attacker wants victims to click through to fraudulent reward or bonus portals, submit data, and ultimately enable financially motivated scams at scale.

1. Entry occurs through a phishing email that impersonates trusted Google-related services and uses wording designed to look routine.
2. Credential or trust abuse follows when the message passes SPF checks and leads users to a GCS-hosted redirector that hides the final destination.
3. Escalation occurs as the redirect chain adds CAPTCHA and fake reward pages that collect browser and user data while reinforcing legitimacy.
4. Impact is financial fraud and broader compromise of user trust, aided by legitimate cloud infrastructure and analytics that help attackers optimise the campaign.

Breaches seen in the wild

• Mailchimp breach 2022: Attackers socially engineered Mailchimp staff, used a support tool to export 102 customer lists and exposed customer API keys for phishing.
• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trusted cloud infrastructure has become an extension of the phishing kill chain: this campaign shows that defenders can no longer treat cloud platforms as neutral transit layers. When malicious content is hosted inside a reputable service, inherited trust becomes part of the attacker’s delivery strategy. The operational lesson is that reputation-based controls must be paired with behavioural inspection and rapid abuse response.

Email authentication is being used as a permission slip, not a guarantee: SPF success can create false confidence when DKIM is absent and DMARC enforcement is weak. The governance gap is that many programmes still read authentication as proof of legitimacy rather than one signal inside a broader trust decision. Practitioners should treat sender authentication as necessary but not sufficient, especially where brand impersonation is the objective.

Cloud phishing now blends identity, web trust, and fraud operations: the campaign is not only an email problem or a web problem. It is a trust-exploitation workflow that starts in the inbox, continues through browser redirects, and ends in a monetisation path built on user deception. That makes it relevant to Google Workspace security governance as much as to mail filtering and fraud detection.

Browser telemetry has become part of the attacker’s optimisation loop: the use of analytics platforms to collect user and browser data shows how phishing campaigns now adapt in near real time. That matters because detection must move beyond static indicators and account for how attackers tune lures, redirects, and targeting based on victim behaviour. Organisations should expect adaptive phishing, not fixed templates.

Cloud abuse reporting must be treated as a governance function, not an afterthought: the report’s coordinated disclosure to the cloud provider and detection team shows the right operating model, but it also exposes a recurring weakness in many programmes. Abuse of trusted infrastructure is only contained when security, legal, email, and cloud operations can act together quickly. Practitioners should formalise that response path before the next campaign lands.

Read next: Cloud Misconfiguration Guide

What this signals

Trusted-host phishing is now a governance problem, not just an email problem: when the delivery path runs through reputable cloud infrastructure, the control failure is broader than sender filtering. Organisations need a programme that correlates mail authentication, web redirection, cloud abuse monitoring, and fraud reporting so that trust decisions are made from multiple signals, not a single domain check.

Cloud-hosted lures reduce the value of static blacklists: once the malicious page sits inside an otherwise trusted platform, the blocklist model becomes reactive and brittle. The better response is to treat hosted content, redirect chains, and user-facing brand cues as dynamic risk indicators that must be evaluated continuously at the point of click.

For practitioners

• Harden DMARC beyond pass/fail Move from permissive or monitoring-only policy toward enforcement, and verify that DKIM alignment is required for high-risk business domains.
• Inspect redirect chains, not just domains Review email and web controls so that JavaScript redirects, multi-hop links, and CAPTCHA-gated destinations are analysed before users reach the final page.
• Treat trusted cloud hosts as abuse surfaces Create detections for phishing content hosted on cloud storage and other reputable platforms, then build escalation paths for fast takedown and provider notification.
• Strengthen user reporting for brand impersonation Tune mail reporting workflows so staff can flag messages that imitate Google-branded services, even when the sender looks technically authenticated.

Key takeaways

• The campaign shows how phishing can hide inside reputable cloud infrastructure, which weakens controls that still depend on domain reputation and familiar branding.
• Email authentication alone is not enough when SPF passes, DKIM is missing, and DMARC policy remains weak or unenforced.
• Practitioners need layered detection that joins mail, web, cloud-abuse, and fraud signals so trusted platforms do not become blind spots.

Related NHI Mgmt Group resources: Cloud Misconfiguration Guide · Email Security Guide · Google Workspace Security Guide · Phishing Incident Response Playbook

Key terms

• Cloud-Hosted Phishing: Phishing that uses legitimate cloud services to host redirectors, landing pages, or supporting infrastructure. The abuse works because the service itself appears trustworthy, which can bypass reputation-based filtering and lower user suspicion even when the content is malicious.
• Email Authentication: Email authentication is the set of controls that help recipients verify whether a message really came from a domain. SPF, DKIM, and DMARC reduce spoofing and impersonation, but they work best when combined with domain lifecycle management and user awareness.
• Redirect chain: A redirect chain is a sequence of intermediate links that forwards the victim from an initial lure to the final malicious page. Attackers use it to hide the destination, defeat static URL analysis, and exploit trusted services that are less likely to be blocked early.
• Cloud Abuse: Cloud abuse is the misuse of legitimate cloud credentials or resources for unauthorized activity such as mining, data exfiltration, or covert automation. Unlike a direct exploit, it often relies on valid access and blends into normal operations. That makes detection harder and containment more urgent.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.