Building malicious infrastructure is expensive and risky. You register a domain — it gets flagged. You stand up a server — it gets blacklisted. You buy an SSL certificate — it gets revoked. Every piece of custom infrastructure you build as an attacker leaves a trail and has a shelf life measured in days.
Attackers solved this problem. They stopped building their own infrastructure. They started borrowing ours.
The shift is structural, not tactical. Across eight different platforms in the last eighteen months, the same pattern appears: take a legitimate, widely trusted service that developers, designers, or business users depend on daily, and use it exactly as designed — to host files, send notifications, deliver invitations, or provide remote access. The platform's trust becomes the attack surface. The victim never lands on a suspicious domain. The email never comes from an unknown sender. The link never goes somewhere flagged by reputation tools. Everything looks clean because it is clean — the infrastructure is legitimate. Only the intent is not.
This analysis documents eight confirmed instances of what I'm calling Trusted Infrastructure Phishing — a framework that names what is actually happening across campaigns that are currently being treated as unrelated incidents. They are not unrelated. They are the same attack, executed across different platforms.
The Trust Tax: Organizations pay a trust tax every time they allow a third-party platform — a file host, a project management tool, a design platform, a remote access tool — into their environment. That trust is earned by the platform through years of legitimate use. Attackers borrow it for free. The tax is paid by defenders who cannot block the platform without breaking legitimate workflows, and by victims who have no way to distinguish a legitimate notification from a weaponized one.
These are not eight separate campaigns. They are eight instances of the same attack philosophy applied to different platforms at different layers of the attack chain. Some platforms are used to send the email. Some are used to host the phishing page. Some are used to stage the malware payload. Some are used as command and control infrastructure. The platform layer varies. The trust exploitation does not.
| Platform · Layer | How Trust Is Exploited | Confirmed Campaign | Detection |
|---|---|---|---|
| GitHub Payload staging · C2 |
Malware hosted in GitHub releases. Attackers create repos impersonating trusted brands. Domain reputation: trusted. HTTPS: valid. Content: malware. | kaswareteam org (17 repos, ScreenConnect delivery). Shapecluneedle/jubilant-engine (Vidar + SheetRAT). Kimsuky LNK delivery via raw.githubusercontent.com. | Partial |
| Azure Blob Storage Phishing page hosting |
HTML credential harvesting pages uploaded to public blob containers. Sits on blob.core.windows.net — a Microsoft domain with a Microsoft SSL certificate. Security tools see legitimate Microsoft infrastructure. | Ongoing campaigns impersonating Microsoft 365, OneDrive, Entra ID. Confirmed by Microsoft Threat Intelligence, Nopal Cyber, CYFIRMA (2025-2026). | Gap |
| Cloudflare Workers PhaaS infrastructure · Evasion |
EvilTokens PhaaS serves AES-GCM encrypted phishing pages via Cloudflare Workers. Keys rotate on every request, defeating sandbox replay. Cloudflare domain passes every perimeter control. | EvilTokens — M365 device code phishing, OAuth token theft. Confirmed by Sekoia TDR, Abnormal AI (2026). | Partial |
| Hugging Face Payload staging · Malware hosting |
Malicious model repos published on the AI community's primary hub. Trusted implicitly by developers loading models as part of normal workflow. 244K downloads of one malicious repo in 18 hours. | Open-OSS/privacy-filter typosquatting (May 2026). North Korea Lazarus Group payload staging. Android RAT via TrustBastion (Jan 2026). FaceHugger CVEs (Aug 2026). | Partial |
| Framer Phishing page hosting |
Credential harvesting pages built on Framer's free platform. Served from framer.com — SPF, DKIM, and DMARC all pass. Legitimate sending domain, malicious content. | Active campaigns using Framer-hosted phishing pages targeting Microsoft 365 credentials. Confirmed in Sublime Security telemetry (2026). | Partial |
| Figma Email delivery · Invite abuse |
Figma's invite notification system delivers phishing email from no-reply@email.figma.com. Passes SPF, DKIM, and DMARC. Invite links to a malicious Figma file. | Figma invite phishing targeting first-contact recipients. Figma plugin ecosystem abuse via CVE-2025-53967 (MCP RCE). Documented in field notes (2026). | Partial |
| Jira Service Management Email delivery |
Free Jira projects with phishing content in the welcome message. Invite Customers delivers email from Atlassian's own infrastructure. Passes every authentication check. | Documented by Cisco Talos (April 2026). Billing lure, invoice phishing, callback scam content delivered via Atlassian-signed email. | Partial |
| ScreenConnect C2 · Remote access |
Free *.screenconnect.com subdomains with no verification. Attackers register them as C2 infrastructure. Domain passes every reputation check — it's a legitimate enterprise platform. | TELEPUZ ClickFix campaign. SMOKE#SCREEN fake Adobe/Zoom updates. kaswareteam GitHub delivery. Multiple active subdomains confirmed via URLhaus (Aug 2026). | Partial |
These eight campaigns share three structural properties that explain why the technique works and why it is spreading. Each property is a feature of legitimate platform design that becomes a vulnerability when exploited.
Detection for Trusted Infrastructure Phishing cannot be domain-based. The domain is the problem — it's trusted. Detection has to be behavioral: who is sending the email, what is the relationship between sender and recipient, what signals inside the email suggest the platform is being abused rather than legitimately used.
For each platform in the taxonomy, I have either written a detection rule for Sublime Security's open-source ruleset or identified the gap. The common pattern across all eight: the existing rules are too narrow, catching only the most obvious abuse while missing the wider campaign.
GitHub: LNK/ZIP GitHub raw C2 rule — targets Kimsuky-specific delivery pattern via raw.githubusercontent.com
Cloudflare: Six rules covering Cloudflare Workers, tunnels, and service abuse
Firebase: Two rules covering Firebase sender abuse and redirect patterns
Azure Blob: One spam rule — new domains only, single non-org recipient
Framer, Figma, Jira, Hugging Face, ScreenConnect: Rules written and submitted or in pipeline
Azure Blob — body link: No rule for blob.core.windows.net links in email body from unsolicited senders with credential theft signals
AWS S3 — body link: S3 link in PDF attachment covered; email body link not covered
Firebase Storage: firebasestorage.googleapis.com not covered separately from Firebase sender rules
Cross-platform TIP detection: No rule that identifies the pattern across platforms — a rule that catches "trusted platform + first-contact sender + credential theft signal" regardless of which platform
The hardest gap to fill: A cross-platform TIP detection rule — one that catches the pattern regardless of which trusted platform is being abused — would require matching a large list of trusted hosting domains against first-contact sender and credential theft signals. The FP risk is high because legitimate use of these platforms is common. But the signal combination of trusted-platform-hosted link + first-contact sender + NLU credential theft intent is genuinely distinctive. This is the detection architecture that would close the gap across all eight platforms simultaneously.
| Action | Why | Priority |
|---|---|---|
| Build behavioral detection, not domain blocklists | Domain blocking cannot work when the domain is legitimate. Detection must be based on sender history, recipient relationship, and content signals — not whether the link goes to GitHub or Azure. | IMMEDIATE |
| Flag first-contact emails containing trusted-platform links | The combination of a first-contact sender and a link to a trusted hosting platform (GitHub releases, blob.core.windows.net, framer.com) with credential theft language is the core TIP signal. Flag for review rather than deliver silently. | IMMEDIATE |
| Audit your platform exposure — which trusted services does your organization use? | If your organization uses Figma, attackers can deliver phishing via Figma invites. If your developers use Hugging Face, attackers can deliver malware via model sharing. Map your trusted platform dependencies and apply appropriate controls for each. | HIGH |
| Train users on trusted-platform lures specifically | Standard security awareness training focuses on suspicious links and unknown senders. TIP attacks use trusted links and often known platforms. Training needs to cover "why does this Figma invite from someone I've never worked with contain a billing alert?" | HIGH |
| Use a password manager and treat failed auto-fill as a red flag | Password managers bind credentials to specific domains. A credential harvesting page hosted on blob.core.windows.net will not auto-fill Microsoft credentials — because the domain doesn't match login.microsoftonline.com. If your password manager doesn't offer to fill on a login page, stop and verify the URL. | HIGH |
| Report platform abuse directly to the platform | GitHub, Microsoft, Atlassian, Figma, and Framer all have abuse reporting mechanisms. A reported malicious repo or page gets taken down within hours in most cases. Reporting reduces the takedown window during which victims can be compromised. | MEDIUM |
This analysis synthesizes original research published across this portfolio between March and September 2026, including analyses of ScreenConnect RMM abuse, Hugging Face supply chain attacks, Figma platform abuse (Parts 1 and 2), Jira Service Management PaaP delivery, and kaswareteam GitHub infrastructure. Campaign data sourced from URLhaus and MalwareBazaar via ArgusX threat intelligence platform. Third-party sources include Microsoft Security Blog, Cisco Talos, Sekoia TDR, CYFIRMA, Nopal Cyber, HiddenLayer, and Bitdefender. The "Trusted Infrastructure Phishing" framework and "Trust Tax" framing represent the author's original analytical contribution. Detection rules referenced are available in Sublime Security's open-source ruleset and at the author's GitHub. This analysis represents independent research produced for educational purposes.
I'm a security researcher in Connecticut. Analysis is the part I love: tracing threat actor behavior, pulling apart supply chain attacks, and following evidence even when it lands on "unknown." I co-founded ArgusX, a live threat intelligence platform. Before security I spent 15 years designing enterprise software. I contribute detection rules to Sublime Security's open-source production ruleset. Security+ in progress. Everything here is independent work, shared as a contribution to the security community.