An investigation into phishing activity over the past months has surfaced a decisive structural evolution in how threat actors operate. The campaigns analysed no longer resemble the phishing most organizations trained their defenses to stop. There are no spoofed domains, no suspicious sender addresses, and in the most advanced cases, traditional indicators such as files, URLs, or network artifacts may be absent or significantly reduced. What replaced those classic indicators is something more difficult to confront: attackers conducting phishing operations entirely from infrastructure that organizations trust by design.
The platforms being weaponized are the same ones employees use everyday: cloud storage buckets, productivity suites, email workflow tools, OAuth authentication endpoints, and calendar APIs. Adversaries have realized that the fastest path past enterprise defenses is not to break through them, but to send mail from the inside. When an email originates from a legitimate Google or Microsoft system, passes every authentication check, resolves to a valid TLS-certified domain, and links to a page hosted on a whitelisted cloud service, every layer of the traditional security stack sees routine traffic.
The consequences are significant. Across the campaigns investigated, multi-factor authentication was bypassed without the attacker ever touching a password. In several cases, victim organizations had no anomalous event in their SIEM at the time of initial compromise, the attacker’s access token looked identical to the legitimate user’s. The first evidence of intrusion was discovered during post-incident review, sometimes weeks after the initial access event.
This report details the full attack chain observed, documents the case studies that define this threat category, maps the behavioural indicators that provide the only reliable detection surface, and provides actionable mitigations stratified by role.
Trusted Infrastructure Phishing (TIP) refers to a class of adversarial campaign in which every operational phase, covering delivery, hosting, execution, authentication, and persistence, is conducted through legitimate, enterprise-trusted cloud infrastructure rather than attacker-controlled systems. In TIP campaigns, malicious intent produces no infrastructure anomaly. The attack is indistinguishable from normal operations at the network layer because it is normal operations at the network layer.
TIP is not a single technique. It is an operational doctrine, a deliberate architectural choice to conduct the entire attack lifecycle within the bounds of what defenders have already sanctioned. Where traditional phishing required building malicious infrastructure and hoping it would evade detection, TIP inverts that model entirely: the infrastructure is already trusted, already authenticated, and already permitted.
The five stages of the TIP kill chain are delivery via provider-owned sending infrastructure, payload hosting on legitimate cloud storage, execution within browser memory using native platform APIs, credential and token theft through legitimate authentication flows, and persistent presence through the victim’s own licensed services.
To understand why TIP has emerged as the dominant phishing model, it is necessary to trace the conditions that made it viable.
Malware-based phishing, covering the delivery of executable payloads, macro-enabled documents, or exploit-bearing attachments, declined in effectiveness as endpoint detection matured and email filtering improved. In response, threat actors deprioritized malware delivery in favour of credential harvesting and token theft, which require no malicious file and leave a substantially smaller forensic footprint.
In parallel, the widespread enterprise adoption of cloud productivity platforms, including Microsoft 365, Google Workspace, and their associated ecosystems, created a new and largely undefended attack surface. Organizations invested heavily in securing their endpoints and email gateways. They invested comparatively little in governing the OAuth application permissions, device code authentication flows, and cloud storage access controls that those platforms introduced. Threat actors identified and exploited that gap.
The result is TIP: a generation of phishing campaigns that achieve initial access, credential theft, and persistent presence entirely through the abuse of cloud services that organizations have explicitly trusted, licensed, and integrated into their operations. This is not phishing that has evolved to evade defenses. It is phishing that evolved to become indistinguishable from normal operations, and that distinction is what makes it structurally different from everything that preceded it.
The attack chain above reflects the five-stage model reconstructed across multiple campaigns. Each stage is addressed below with the specific behaviours and techniques our investigation identified.
The entry point is no longer a suspicious email. In the campaigns analysed, threat actors are using legitimate cloud workflow automation tools to dispatch phishing emails directly from provider-owned infrastructure. Because these messages are genuinely sent by the cloud vendor’s own mail systems, they pass SPF, DKIM, DMARC, and composite authentication checks without modification. Traditional email security gateways, which evaluate messages based on sender reputation and authentication results, have no mechanism to flag them.
The lure content observed was tightly tailored. Attackers impersonated internal operational notifications, task assignments, document-sharing requests, payment alerts, and policy acknowledgment requests, creating a plausible pretext for urgency without triggering the stylistic cues that security awareness training teaches employees to recognize. Volume varied widely: some campaigns targeted thousands of organizations simultaneously, while others were narrow and highly targeted, indicating both commodity and advanced threat actor involvement in this technique.
In a related variant, attackers created legitimate form infrastructure to trigger automated platform notifications to victims’ inboxes. No malicious code is involved in the delivery step; the entire notification pipeline is the platform’s own.
Once the lure is delivered, the victim is directed to a phishing page hosted on legitimate cloud object storage. TIP campaigns at this stage use Azure Blob Storage containers, SharePoint file-sharing links, and OneDrive-hosted HTML documents as phishing stages.
The hosting choice is deliberate. These services carry wildcard certificates covering the entire provider domain, meaning the browser displays a valid padlock and a trusted hostname. Web proxies and secure email gateways that perform URL reputation analysis against known malicious domains find nothing actionable; the domain is Microsoft’s own. Allowlists built into enterprise proxy configurations frequently permit these destinations without inspection.
The page retrieved at this stage is typically a convincing replica of a legitimate login interface, complete with corporate branding appropriate to the target’s industry. In more sophisticated variants, the page performs victim fingerprinting and renders its phishing content only for traffic arriving from target geographies or expected browser environments, presenting a blank page or benign redirect to automated scanners.
In one variant investigated, the redirect chain itself was layered: a legitimate form submission service resolved to a Blob-hosted redirect, which resolved to the credential harvesting page. Each hop independently resolved to a trusted domain, making automated chain analysis difficult.
The most technically advanced technique encountered removes the hosted phishing page from the equation entirely. Rather than serving a credential-harvesting page from a cloud storage bucket, this method constructs the phishing page dynamically inside the victim’s browser using native JavaScript Blob APIs.
The kill chain proceeds as follows: the victim receives a lure email containing a link to an apparently benign intermediary, a document preview service, a shortened URL, or a QR code embedded in a PDF attachment. Following the link chain loads a minimal JavaScript loader. The loader uses standard browser APIs to Base64-decode a bundled HTML payload, instantiate it as a Blob object, and force the browser to navigate to a generated blob:https:// URL. The phishing page then renders entirely in the victim’s browser memory.
The defensive implications are significant. Because the phishing page never transits the network as an HTTP response, URL reputation engines have nothing to analyze. The blob: URL exists only in browser memory for the duration of the session. No file is written to disk. No proxy log entry captures the phishing page request. The only artifact is the initial request to load the JavaScript loader, which may itself be hosted on a reputable intermediary. This technique effectively defeats every network-layer and file-based detection control currently deployed in most enterprise environments.
In campaigns that do not use in-memory delivery, the objective is typically not the victim’s password; it is their OAuth access token. This stage reflects the abuse of cloud identity ecosystems at their authentication layer, targeting the token infrastructure that underpins modern cloud access rather than the credentials that protect it. Our investigation identified two techniques in active use.
The first is adversary-in-the-middle proxying. A reverse proxy is positioned between the victim and the legitimate authentication endpoint, relaying the full authentication flow in real time. The victim completes a genuine MFA-verified sign-in. The proxy captures the resulting session cookie and replays it to access the victim’s cloud environment. From the identity provider’s perspective, the sign-in was legitimate because it was.
The second technique abuses the OAuth 2.0 Device Authorization Grant flow, a mechanism originally designed for input-constrained devices. The attacker initiates the flow to generate a device code, then distributes a lure directing the victim to the legitimate provider portal to enter it. The victim’s authentication at that portal issues a valid access and refresh token directly to the attacker’s registered application. The resulting token grants persistent access to email, files, calendar, and administrative functions in many cases for the full refresh token lifetime, which can extend beyond ninety days. Neither technique requires knowledge of the victim’s password. Neither is addressed by MFA. In both cases, the initial access event in identity logs is a routine successful authentication.
Once access is established, the actors tracked did not pivot to external infrastructure. They remained within the victim’s cloud environment, using licensed services as their operational platform, a behaviour that reflects the systemic abuse of enterprise cloud ecosystems as post-compromise infrastructure. In multiple cases, the attacker created inbox rules within minutes of obtaining access, forwarding rules, silent deletion rules, and keyword-triggered folder routing, establishing persistence without touching any endpoint or generating any file-based alert.
In more advanced operations, the compromised cloud tenancy was repurposed as phishing infrastructure against the victim’s own business network, hosting lures in SharePoint, sending messages from the victim’s identity to supply chain partners, and laundering subsequent campaigns through established trust relationships. Nation-state actors in our dataset went further, establishing covert command-and-control channels through legitimate SaaS calendar APIs, embedding operational instructions inside routine API calls that are structurally indistinguishable from normal application behavior at the network layer.
During our tracking of this campaign, the analysed phishing operation executed lure delivery entirely through a major cloud provider’s legitimate workflow integration service. The attacker did not compromise the provider; they registered a free-tier account and configured it to dispatch phishing emails through the provider’s own outbound mail infrastructure. Every resulting message originated from a genuine provider address and passed all authentication checks. This reflects the abuse of enterprise cloud ecosystems at the delivery layer; the platform itself was the weapon.
The lure impersonated an internal task notification, a format that enterprise users are conditioned to act on without scrutiny. Thousands of organizations were targeted. The manufacturing sector bore the highest concentration of targeting, consistent with patterns observed across multiple campaigns where operational data is a priority objective.
Key findings: No pre-delivery indicator was actionable. The sending domain was legitimate. The sending IP was the provider’s. Detection was only possible through behavioural analysis of post-click activity.
Detection implication: Standard email filtering and domain reputation controls provide no coverage for this technique. Detection must be anchored in post-delivery behavioural signals, link, click telemetry, subsequent authentication events, and redirect chain analysis.
BlobPhish represents TIP at its most technically advanced. This is a campaign in which the phishing payload exists only in browser memory and produces no network-layer artifact. The campaign impersonates high-value brands across productivity suites, banking institutions, brokerage platforms, and payment processors, targeting Microsoft 365 users and selected cryptocurrency platforms. Its defining characteristic is the complete absence of a detectable phishing page on any network-accessible server, a technique that leverages trusted cloud browser capabilities as execution infrastructure.
Victims receive a lure via email or QR code in a PDF attachment. The resulting link chain loads a JavaScript loader that instantiates the phishing page as a browser Blob object, rendering it entirely in local memory. The identified victims are across North America, Western Europe, Asia-Pacific, and the Middle East across finance, manufacturing, government, transportation, and telecommunications sectors.
Key findings: This campaign carries no network-layer signature. In advanced variants, traditional indicators such as URLs, files, or proxy log entries are absent because the phishing payload never transits the network.
Detection implication: Network-layer and URL reputation controls provide no coverage. Detection requires browser memory telemetry, endpoint behavioural monitoring, or correlation of blob:https:// navigation events with subsequent cloud authentication attempts.
This campaign illustrates TIP targeting technology, manufacturing, and financial services organizations across North America. The campaign abuses the OAuth 2.0 Device Authorization Grant flow, a mechanism embedded in Microsoft’s own cloud identity ecosystem to obtain persistent access tokens without credential theft and without engaging MFA. This technique reflects the systemic abuse of cloud authentication infrastructure rather than an attack against it.
The attacker generates a device code and distributes a lure directing the victim to Microsoft’s legitimate authentication portal to enter it. The victim, interacting with a familiar Microsoft interface, unknowingly authorizes the token issuance. The attacker captures the resulting tokens, which provide full access to email, calendar, Teams, SharePoint, and OneDrive, often for the full refresh token lifetime. In the intrusions tracked, attackers conducted methodical, low-volume reconnaissance over extended dwell periods. In most cases, victim organizations became aware of compromise through behavioural anomaly detection weeks after initial access was established. Over 340 organizations were confirmed to be affected in campaigns of this type in early 2026 alone.
Key findings: MFA provided no protection. The initial access event in identity logs was a routine successful authentication. Dwell periods measured in weeks before detection were common.
Detection implication: Perimeter and authentication-layer controls provide no coverage. Detection requires monitoring Entra ID sign-in logs specifically for device code authentication events from unrecognized geographies or device identities.
This campaign is attributed with moderate confidence to a state-sponsored threat group targeting government organizations globally. The campaign combined spear-phishing delivery through a compromised government website with a post-access command-and-control architecture that embeds operator instructions inside legitimate consumer calendar API calls, reflecting the abuse of enterprise cloud ecosystems as persistent operational infrastructure.
The malware framework uses calendar event objects as the communication channel between the implant and the operator. From the network’s perspective, the implant’s traffic is structurally identical to a user’s calendar application, making routine API calls. There is no dedicated C2 domain, no atypical destination IP, and no traffic pattern that deviates from baseline SaaS application behaviour. This case represents the current ceiling of cloud-native abuse: not deploying an attack through cloud platforms but embedding permanent operational infrastructure inside the target’s own sanctioned network activity.
Key findings: C2 traffic was indistinguishable from legitimate SaaS application behavior at the network layer. Standard network monitoring and threat intelligence feeds had no signal to act on.
Detection implication: Network-layer C2 detection is ineffective against this technique. Detection requires behavioural baseline profiling of SaaS API call patterns, specifically calendar and note-taking services, with alerting on deviations in call timing, frequency, and off-hours activity.
Our team identified an active phishing campaign impersonating a major consumer finance institution with an established retail lending and payment services presence across Southeast Asia. The threat actor constructed a lookalike domain formatted as a branded subdomain under a generic registrar-owned parent; a deliberate construction designed to appear contextually plausible to the target user base without triggering obvious typosquatting heuristics against the institution’s primary domain.
What distinguished this campaign from commodity financial phishing was not just the infrastructure stack, but the operational discipline behind it: real-time monitoring, automated interaction workflows, and deliberate geographic targeting. This was a managed operation, not a one-time deployment.
Infrastructure Architecture
The attack infrastructure was constructed in three distinct tiers, each chosen for the evasion properties it contributed to the overall chain, as mapped in the diagram below.
As illustrated in Figure 1, each tier was selected for the specific evasion properties it contributed to the overall chain.
The outermost layer was Cloudflare, positioned as the phishing frontend’s protective perimeter. By routing the lookalike domain through Cloudflare’s reverse proxy, the attacker ensured that any DNS or IP lookup returned Cloudflare-owned address space, high-reputation infrastructure shared with millions of legitimate sites. Threat intelligence enrichment on the domain produced no actionable results. The true origin of the campaign was fully concealed.
Traffic passing through Cloudflare was forwarded to Azure Front Door, Microsoft’s globally distributed application delivery service. We identified two Azure Front Door edge nodes active in this campaign: 13.107.246.38 and 13.107.213.38. Both belong to Microsoft’s production infrastructure and appear on every major enterprise allowlist. Their presence in the redirect chain meant that any network control evaluating traffic by destination reputation had no basis for intervention.
The backend processing environment was a containerized deployment hosted on Azure Container Apps, resolving to 20.44.241.109, a Singapore-region Azure node. This environment hosted three functional components: a Grafana monitoring dashboard providing live campaign telemetry, an automation workflow tooling managing the interaction pipeline, and the chatbot engine driving victim engagement in real time.
Key observations: The full infrastructure chain: Cloudflare → Azure Front Door → Azure Container Apps, meant that at every network inspection point, traffic resolved to a major legitimate cloud provider. This reflects the systemic abuse of enterprise cloud ecosystems as the complete attack stack, with no attacker-controlled infrastructure in the chain.
Interactive phishing mechanism
The credential harvesting mechanism departed meaningfully from the static form model that most phishing detection tooling is built to identify. Rather than presenting a replica login page, the campaign deployed a chatbot interface designed to simulate the institution’s customer support function, leveraging trusted cloud services as the interaction delivery mechanism.
The chatbot engaged victims in structured, scripted conversation flows that replicated the cadence and vocabulary of a legitimate financial services support interaction. Users were guided through a progressive series of prompts, each collecting a discrete piece of information while maintaining the appearance of a routine service enquiry. No single interaction event resembled a credential submission; the complete harvest is only apparent when the transcript is read end to end.
The chatbot’s response logic branched based on user input, mimicking an adaptive support agent. This served two purposes: increasing plausibility for the victim, and complicating sandbox-based analysis since the system’s behavior varied depending on analyst engagement patterns.
Operational insight: Beyond credential capture, the conversational format harvested behavioural data on what account information victims volunteered unprompted, and how they responded under simulated service pressure. This secondary data layer has downstream value for more targeted follow-on social engineering.
Backend exposure and operational findings
The most consequential finding of our investigation was the discovery of a publicly accessible backend interface associated with the containerized environment at 20.44.241.109. The interface carried no authentication controls, no token, no basic auth, and no IP restriction, making its full contents accessible to any external requester who identified the endpoint path.
The exposed data included complete chatbot conversation transcripts, session identifiers, and timestamped interaction logs. Examining the corpus revealed two consistent markers of deliberate geographic targeting. First, all date values were expressed using the Buddhist Era calendar system, a convention used exclusively in Thailand. Second, the language of all victim-side inputs was Thai throughout the entire sample examined. These two signals together confirm targeted deployment against the institution’s Thai user segment specifically, with the interaction flow fully localized for that audience.
The Grafana dashboard within the same environment provided real-time campaign telemetry session volumes, interaction rates, and active victim counts updated continuously. The attacker was managing this operation with the discipline of a professional service delivery platform.
Key observation: The attacker demonstrated clear competence in cloud architecture selection and evasion layering, then left the campaign’s full operational internals exposed without any access control. This inconsistency, sophisticated frontend, unprotected backend, is a pattern we have observed in campaigns where infrastructure was deployed under time pressure or by a different individual than the original architect.
Detection implication: Every network-layer indicator in this campaign pointed to legitimate cloud providers. The only actionable detection surfaces were the lookalike domain registration pattern, the abnormal subdomain construction, and post-click authentication anomalies. The unauthenticated backend provided complete operational visibility that would otherwise have been unavailable in campaigns where this exposure does not exist; defenders face significantly narrower detection options.
The fundamental detection challenge in cloud-native phishing is that static IOCs, IPs, domains, and file hashes have very short useful lifespans in this threat category. Attackers rotate infrastructure rapidly, and in the case of in-memory payloads, no external IOCs exist at all.
| Type | Indicator | Remarks |
| URL Pattern | blob:https://* in browser navigation events | Monitor |
| Redirect Chain | forms.office.com → *.blob.core.windows.net | Monitor |
| OAuth Endpoint | POST /oauth2/v2.0/token with grant_type=device_code | Monitor |
| HTTP Request | POST /_layouts/15/ToolPane.aspx?DisplayMode=Edit from external IP | Block |
| IP Address | 107.191.58.76 | Block |
| IP Address | 104.238.159.149 | Block |
| IP Address | 96.9.125.147 | Block |
| IP Address | 20.44.241.109 | Block |
| IP Address | 13.107.246.38 | Monitor |
| IP Address | 13.107.213.38 | Monitor |
| Tactic | ID | Technique |
| Resource Development | T1583.004 | Acquire Infrastructure: Server |
| Resource Development | T1584 | Compromise Infrastructure |
| Initial Access | T1566.001 | Phishing: Spear phishing Attachment |
| Initial Access | T1566.002 | Phishing: Spear phishing Link |
| Execution | T1059.007 | Command and Scripting Interpreter: JavaScript |
| Stealth | T1027 | Obfuscated Files or Information |
| Stealth | T1078.004 | Valid Accounts: Cloud Accounts |
| Defense Impairment (new — TA0112) | T1556 | Modify Authentication Process |
| Credential Access | T1528 | Steal Application Access Token |
| Credential Access | T1557 | Adversary-in-the-Middle |
| Collection | T1114.003 | Email Collection: Email Forwarding Rule |
| Collection | T1119 | Automated Collection |
| Command and Control | T1102 | Web Service |
| Exfiltration | T1567 | Exfiltration Over Web Service |
The campaigns documented in this report share a single defining characteristic: they are Trusted Infrastructure Phishing attacks conducted entirely within cloud ecosystems that organizations have already sanctioned, trusted, and integrated into daily operations. The infrastructure is legitimate. The authentication flows are real. The indicators, where they exist, belong to providers whose traffic is whitelisted by default. In advanced TIP variants, traditional forensic artifacts may be significantly reduced or absent.
What TIP reveals is a structural gap in how most organizations have positioned their defenses. Investment has concentrated on the perimeter: email filtering, domain reputation, and endpoint detection. Meanwhile, the cloud identity layer, the OAuth consent ecosystem, and the behavioural patterns of post-authentication activity have received comparatively little attention. The campaigns in this report exploited that gap with operational consistency and, in several cases, with sophistication that exceeded what defenders were instrumented to detect.
Addressing TIP does not require new tooling in most cases. It requires architectural decisions: migrating to phishing-resistant authentication, governing OAuth application permissions, and building detection logic that operates on identity and behavioural telemetry rather than network signatures. These decisions are available now. The organizations that make them will be meaningfully better positioned against the next iteration of TIP than those that do not.
Strategic Recommendations
Operational Recommendations
Tactical Recommendations
