Trello Branding, Telegra.ph Relay, and a 15-Day-Old .sbs Domain Credential Page

A long-established U.S. school-district domain, name withheld, sent a message that passed every email authentication check. SPF passed on Google infrastructure. DKIM passed signed to the school district's own domain. DMARC passed. The message arrived looking like a legitimate communication from a known educational organization. It was not. The account sending it had been compromised.

The lure claimed to be a "protected" message, presented with Trello and Atlassian branding, and asked the recipient to click "View Encrypted Message" to authenticate and read the content. The button resolved to hxxps://telegra[.]ph/San-Luis-Valley-BOCES-06-04, a page on an anonymous public publishing platform, not a secure-message portal.

This is the anatomy of email account compromise as a delivery mechanism: the attacker does not need to build a sending domain or season a new mailbox. They take over an existing one with an established reputation and let that reputation do the authentication work.

The Telegra.ph Layer: Anonymous Hosting as a Scanning Buffer

Telegra.ph serves a specific function in this kill chain. It absorbs the first link that appears in the message body, presenting a URL that has no per-attacker reputation, cannot be trivially blocked without affecting legitimate content, and can be updated by the operator after the campaign launches.

The page itself was crafted to add legitimacy: it referenced "Trello Encryption" and "Authentication required," and included an IXL learning badge in the signature block to mimic the appearance of an educational-sector communication from a known source. None of these elements represent real services or real authentication. The page existed only to move the recipient one click closer to the actual credential collection site.

URL rewriting as a protective control rewrites links at delivery time and inspects the resolved destination. Against a Telegra.ph redirect with a JavaScript or server-side redirect to a third host, the protection depends on whether the scanner follows the full chain at the time of delivery. Attackers specifically use intermediary platforms to break this inspection: the Telegra.ph URL looks clean at scan time, and the downstream domain receives only human clicks.

MITRE ATT&CK T1566.001 covers spearphishing via link. T1078 (valid accounts) applies to the compromise and use of the school-district account. T1550.004 covers web session cookies, the likely post-harvest goal.

The Landing Domain: 15 Days Old, Cloudflare-Proxied, Gating Real Users

The Telegra.ph page's destination was hxxps://flux-vexz[.]sbs/bt79f93/. The .sbs TLD was registered just 15 days before this campaign. The domain carried no organizational identity, no legitimate registrant, and no prior reputation. Cloudflare fronted the infrastructure, which provides both hosting resilience and the ability to gate access by user-agent and referrer headers.

When automated scanners attempted to retrieve the landing page, the server returned HTTP 403. That is a deliberate defensive posture: the attacker blocks requests that look like security tooling while serving the credential-harvest page to actual recipients arriving through the redirect chain. A 403 from a 15-day-old .sbs domain behind Cloudflare is not a sign that nothing malicious is there. It is a sign that the attacker built in scanner evasion from the start.

See Your Risk: Calculate how many threats your SEG is missing

Why Passing Authentication Is the Wrong Reassurance

The school-district account at the center of this campaign was a legitimate Google Workspace mailbox. Google's infrastructure is listed in the domain's SPF record. DKIM signed the message with the school district's selector. DMARC aligned perfectly. Every authentication signal pointed toward a trusted sender.

That is precisely what credential harvesting campaigns targeting organizational email accounts look like after the attacker has gained access. Authentication passes are the reward for compromising a real account rather than building a new one. The phone number in the sender's signature block differed from the organization's publicly listed number, a discrepancy visible only to someone checking the sending account against known org details.

IRONSCALES flagged the message on behavioral signals: the instruction to authenticate through an external gateway rather than reply directly, the use of an anonymous public platform as the CTA destination, and the Telegra.ph content's mismatch with any real secure-message product. The combination of legitimate authenticated sender, social-engineering urgency, and a multi-hop redirect chain terminating at a days-old domain does not resolve to a legitimate communication pattern.

Organizations defending against account-compromise-based delivery need detection that operates independently of authentication verdicts. Behavioral anomalies like external-gateway redirect chains and domain-age signals on the final landing target are the signals that remain visible even when the sending account is fully authenticated.

Indicators of Compromise