A Bolster investigation identified a Microsoft 365–themed credential-harvesting page hosted on a Replit subdomain. In a captured browser session, the page transmitted form data through Telegram’s Bot API, and the API response indicated that a formatted login record was delivered to a private chat. The finding illustrates how attackers can combine widely available app hosting with third-party messaging infrastructure to collect stolen credentials without operating a conventional collection server.
A related URLScan search returned 481 scans in the displayed 30-day window, all marked malicious by the scanning service. That number represents search results—not 481 independently confirmed unique phishing sites or evidence that one actor controlled every page.
What researchers observed
The examined page displayed Microsoft 365 branding and an email-and-password sign-in flow on a replit.app subdomain. The browser showed a dangerous-site warning. After the password step, the page displayed “Sign in attempt timeout, please try again.” The message could encourage a second submission, but the available capture does not establish that repeat credential collection occurred.
The browser network panel recorded a request to api.telegram.org using the Bot API sendMessage method. The response returned HTTP 200 and a JSON payload indicating delivery to a private chat. The message contained labeled fields for email, password and client IP. The IP field appeared as “undefined,” suggesting that particular enrichment field did not populate.
This is the strongest evidence in the investigation: the captured page was not merely imitating Microsoft branding; it was observed forwarding credential-form data to an external messaging destination.
A broader pattern of Microsoft-themed hosted pages
Researchers also searched URLScan using the query domain:replit.app AND visible.brandname.keyword:"Microsoft". The displayed 30-day results included 481 scans, each labeled malicious in the interface. Results featured recurring Microsoft, Outlook and OneDrive-themed page titles and similar visual templates across multiple Replit-hosted URLs.
Examples of observed titles included “Security verification – Microsoft account,” “Sign in to your account,” and “Continue to Outlook.” Some hostnames repeated in the underlying inventory, so scan totals should not be treated as unique-site totals. Similar branding and hosting patterns are useful leads for investigation, but they do not, by themselves, establish a single coordinated campaign.
How the attack works
- Brand impersonation: A hosted page imitates a familiar Microsoft 365 sign-in experience. The original delivery channel for the lure was not captured.
- Credential entry: The page prompts for an email address and password, then displays a timeout-style message.
- Telegram relay: In the captured instance, the page sends a Bot API request containing a structured login record.
- Operator access: The API response indicates delivery to a private chat. The operator’s identity and any subsequent account access were not established.
Why this matters for defenders
A phishing page does not need a lookalike registered domain or dedicated attacker-controlled server to be effective. App-hosting subdomains can provide ready-made HTTPS hosting, while a messaging API can serve as a collection endpoint. That separates the visible lure from the destination receiving captured data and complicates investigations focused only on domain registration or traditional web servers.
Replit hosting is not evidence that the page was generated by AI. The available artifacts do not show the development workflow or establish that Replit knowingly facilitated the abuse. The broader security issue is misuse of accessible deployment and messaging services, regardless of whether the page was hand-coded or AI-assisted.
Recommended defensive actions
- Monitor for Microsoft-themed login pages hosted outside authorized Microsoft and organizational domains. Validate suspicious pages before classifying them as malicious.
- Correlate suspicious hosted pages using page templates, titles, scan history, and network behavior; deduplicate repeated scans and URLs before reporting counts.
- Investigate unexpected Telegram Bot API calls originating from credential-entry pages. Telegram traffic alone is not proof of phishing; context matters.
- Report validated impersonation URLs to the hosting provider and relevant brand or browser abuse channels. Include timestamps, scan identifiers and appropriately redacted evidence.
- If real account credentials were exposed, follow incident-response procedures: reset passwords, revoke sessions, review sign-in activity and assess MFA coverage. Do not test captured credentials against live accounts.
Research methodology and limitations
This analysis is based on the screenshots and inventory excerpts supplied with the investigation, including browser/network evidence and a URLScan search-results view. The raw HAR, page source, JavaScript bundle, full URL export and independent reproduction were not included. A separately mentioned Lovable-hosted dataset and approximate count were not substantiated by the supplied artifacts and are excluded from the findings. ClickFix-like activity mentioned in field notes is likewise excluded because a connection to this captured incident was not documented.
The Telegram relay is supported for one captured instance. The broader scan results support a recurring pattern of hosted Microsoft-themed pages, not attribution to a single operator or confirmation of AI-generated code. All exposed bot tokens and credential-like values should remain restricted and redacted from publication.
The takeaway
The important shift is not a new phishing trick but a leaner infrastructure model: recognizable brand impersonation on an accessible hosted page, with credential data routed to a messaging service. Security teams need visibility into both the impersonating page and its outbound behavior—and a process to validate, correlate and remove abusive deployments quickly.
