The link looked legitimate because, technically, it was.
During a recent investigation, Bolster researchers analyzed a suspicious email containing a sign-in URL hosted on login.microsoftonline.com — exactly the kind of domain users and security controls are conditioned to trust.
But following that link revealed something very different.
Six hops later, we uncovered a credential-harvesting campaign that used Microsoft OAuth as its entry point, a free cloud container as a redirector, blockchain-based storage to host its phishing kit, anti-analysis techniques to evade inspection, and a Cloudflare Worker to relay stolen credentials into Telegram.
The attacker did not need to host the attack on a conventional server of their own.
Instead, nearly every stage of the chain abused legitimate infrastructure.
It started with a legitimate Microsoft URL
The reported URL pointed to Microsoft’s OAuth /authorize endpoint at login.microsoftonline.com.
Two details immediately stood out.
First, the OAuth state parameter contained the victim’s email address in cleartext rather than a random anti-CSRF value.
Second, the request did not specify a redirect_uri.
That omission was important.
Microsoft Entra ID uses the client_id to identify the application requesting authentication. When no redirect_uriis supplied, Entra ID can return the user to a reply URL stored in that application’s registration.
The client_id in this campaign did not correspond to a known Microsoft first-party application. Our investigation found that its configured reply path led into the attack chain.
The request also included prompt=none, allowing the authentication request to proceed without presenting an interactive Microsoft sign-in screen. Depending on the user’s session state, Microsoft returns either an authorization result or an error — while echoing the state value back in the response.
The result is important from a phishing perspective:
The URL the victim clicks really is a Microsoft URL.
Microsoft’s infrastructure then provides the first redirect into the attack chain.
Hop 2: A cloud container becomes the redirector
The application’s reply URL did not point directly to the phishing page.
Instead, it led to a Northflank container:
p01–auth–2g99z9lh4n8s.code.run
The service was appropriately — if unsubtly — named auth.
The container returned another HTTP 302 redirect and carried the victim’s email address forward as an e= parameter.
Its function appears deliberately simple: act as a disposable layer between the Microsoft application registration and the phishing infrastructure.
That separation adds resilience. If a downstream phishing destination is disrupted, the operator can potentially change the redirect while leaving the original Microsoft URL used in phishing emails unchanged.
Hop 3: The phishing page isn’t on a traditional web server
The next destination initially looked like an unusually long phishing hostname.
Its HTTP headers told a different story.
The x-ar-io-* and x-arweave-* headers identified the site as a gateway into Arweave, a decentralized storage network.
That changed how we understood the infrastructure.
The long subdomain wasn’t simply a victim identifier. It represented the underlying Arweave data item, served through a gateway.
And unlike a traditional phishing page hosted on a conventional web server, content written to Arweave is designed to be permanent.
Removing one gateway does not remove the underlying data. Another gateway can potentially retrieve the same content.
This creates a very different takedown problem.
The blockchain gave us a durable pivot
The Arweave metadata also exposed the wallet associated with the upload:
oEBPXN3aJPagbIO8GQ90aNb5j5fh_Swl16CD8wkeUZ4
Examining activity associated with that wallet revealed multiple data items and what appeared to be an active development cycle.
During one 35-minute period, for example, versions of the loader grew from 436 bytes to 485 bytes and then 750 bytes. Earlier, larger versions were also present.
Because those versions were associated with the same uploader wallet, the wallet provides a more durable way to connect campaign infrastructure than any individual hostname.
This is one of the more interesting defensive implications of the campaign: when infrastructure becomes disposable, the useful indicator may no longer be the domain.
Hop 4 and 5: A loader designed to resist analysis
The first Arweave-hosted component was remarkably small.
Its job was to retrieve the victim’s email address from the URL and inject a second JavaScript file — also stored on Arweave, but accessible through another gateway.
The second-stage script was substantially more sophisticated.
Bolster researchers analyzed the approximately 142 KB script statically in an offline environment. It containedseveral layers intended to obscure its behavior and frustrate analysis.
The script used string obfuscation, XOR-encoding meaningful strings until runtime.
It implemented integrity checks, computing hashes over the embedded payload and abandoning execution if the content had been modified.
It also included an anti-analysis gate that compared the browser’s outer and inner window dimensions — a heuristic commonly used to infer whether developer tools are open. If the check failed, the page displayed a generic “Connection Error” instead of continuing.
Finally, the actual phishing page was hidden inside an RC4-encrypted, Base64-encoded payload.
Decrypting that payload offline exposed an approximately 100 KB credential-harvesting page.
The phishing page brands itself to each victim
The decrypted page revealed another important feature: it wasn’t built specifically to impersonate Microsoft.
It was a generic phishing kit designed to turn itself into the victim’s company.
Given an email address, the page extracts the company’s domain and uses external services to retrieve branding and imagery associated with that organization. It then creates a personalized sign-in experience, including the company’s logo, a blurred screenshot of its real website, a company-specific page title, and the victim’s pre-populated email address.
The screenshot on page 5 of the research shows the result: a polished, generic “Welcome Back” login experience that can be dynamically adapted rather than requiring the attacker to build a separate phishing site for every target.
That makes the kit scalable.
One underlying payload can impersonate many different organizations simply by changing the email address supplied to it.
Where the stolen credentials go
Credentials entered into the page are POSTed to a Cloudflare Worker:
tg8.internalwave.workers.dev
using the /send and /edit endpoints.
The Worker then relays the captured information into Telegram.
Putting the Worker between the phishing page and Telegram prevents the Telegram bot token from being exposed directly in the client-side code.
The campaign also appears designed for interactive monitoring. The first credential capture creates a Telegram message, while subsequent victim activity updates it. Messages use the prefix:
-ESBR RESULT-
The kit even sends a separate notification when it believes the page is being analyzed.
The whole attack chain
This is where I would absolutely keep the attack-flow graphic currently on page 6. It’s probably thestrongest visual in the entire piece.
I would introduce it with something like:
Put together, the campaign creates a six-stage chain in which almost every component is hosted on infrastructure the attacker does not directly operate.
The graphic makes what is otherwise a fairly complicated investigation understandable in about five seconds.
Why traditional defenses struggle with this attack
The individual techniques aren’t necessarily novel. What’s more interesting is how the operator combines them.
The initial clickable hostname is Microsoft’s.
The first redirect runs through legitimate Microsoft infrastructure.
The next layer uses a cloud application platform.
The phishing content is stored on decentralized infrastructure and can be accessed through multiple gateways.
The payload attempts to detect analysis before displaying its real content.
The phishing page dynamically impersonates the victim’s organization.
And stolen credentials are relayed through another legitimate cloud service before reaching Telegram.
That means a defensive strategy centered primarily on identifying and blocking a malicious domain has less to work with.
In this campaign, the domain is increasingly disposable. The behavior connecting the services is the stronger signal.
What defenders should look for
Security teams investigating similar activity should look beyond the visible hostname and correlate the infrastructure and parameters across the full redirect chain.
For this campaign, useful hunting pivots include the Entra application client_id, Northflank forwarder, Arweavetransaction IDs, uploader wallet, Cloudflare Worker, and static artifacts associated with the phishing kit.
I would then retain the existing IOC table from pages 6–7 essentially intact. It is valuable to the intended threat-research/SOC audience and gives readers something directly actionable.
Trusting the domain is no longer enough
This campaign started with a URL most users — and many security systems — would consider safe:
login.microsoftonline.com
But the Microsoft URL was only the front door.
Behind it was a chain of legitimate services that ultimately delivered an encrypted credential harvester, personalized the phishing experience to the victim’s organization, resisted automated analysis, and relayed captured credentials to the attacker.
That’s the larger lesson from this investigation.
Attackers don’t necessarily need to build malicious infrastructure anymore. They can assemble an attack from trusted infrastructure that already exists.
For defenders, that means reputation alone is increasingly insufficient. Detection has to account for how trusted services are being connected and used, not simply whether each individual hostname has a good reputation.
