An end user recently received an email that looked completely legitimate on the surface. It invited them to join a Trello board and appeared to come from a known sender within their own company. The email passed every major email authentication check. But the board itself contained a malicious link.
This is an example of platform abuse, where attackers use legitimate cloud services to deliver harmful content. In this case, the attacker used Trello’s built-in sharing tools to bypass traditional email filtering, giving the message all the traits of a safe email—without being safe at all.
How the Attack Was Orchestrated
This attack followed a clear and intentional flow:
- The email itself is the delivery mechanism. The attacker used Trello’s legitimate “invite by email” feature to send the message. It originated from a trusted source and passed all authentication checks, making it appear safe to recipients and filtering systems.
- The Trello board link is the trigger. Within the email was a link to a real Trello board hosted on Atlassian infrastructure. The user was prompted to click this link to view what appeared to be a legitimate board shared by a colleague.
- The content on the board is the payload. Once the user accessed the board, they were exposed to malicious content—such as phishing links, credential traps, or redirects to external malware-hosting sites. The board itself acted as the container for the payload, shielded by the trusted domain and delivery path.
This structure allowed the attacker to bypass traditional defenses. The email looked real, the link was hosted on a known platform, and the malicious content wasn’t delivered until the user followed the link and engaged with the board.
How the Email Reached the Inbox
The attacker created a valid Trello board and used Trello’s “invite by email” feature. The target received an email that was genuinely sent by Trello through Amazon’s infrastructure. There was no spoofing, no lookalike domains, and no suspicious attachment. The email contained a link to a legitimate Trello board—the payload was within the board content itself.
The organization uses a third-party inline security gateway (Avanan/Checkpoint) in addition to Microsoft 365 filtering. This message was scanned and passed by both systems, showing no signs of threat during transit.
Here are the actual email authentication results taken from the header, with personal details redacted:
Received-SPF: Pass (protection.outlook.com: domain of
atlassian-bounces.trello.com designates 76.223.147.234 as permitted sender)
receiver=protection.outlook.com; client-ip=76.223.147.234;SPF Passed
Received-SPF: Pass (protection.outlook.com: domain of
atlassian-bounces.trello.com designates 76.223.147.234 as permitted sender)
receiver=protection.outlook.com; client-ip=76.223.147.234;This means Microsoft’s filtering systems recognized the message as coming from a server that Trello explicitly allows to send email. The IP (76.223.147.234) belongs to Amazon SES, a known mail service provider used by Atlassian.
DKIM Signed and Validated
DKIM-Signature: ... d=trello.com; ...
DKIM-Signature: ... d=amazonses.com; ...Two valid DKIM signatures were included—one from trello.com and one from amazonses.com. These digital signatures prove that the message headers were not altered after leaving Trello’s servers.
DMARC: Passed
Authentication-Results:
spf=pass smtp.mailfrom=atlassian-bounces.trello.com;
dkim=pass header.d=trello.com;
dmarc=pass action=none header.from=trello.com;DMARC passing confirms that both SPF and DKIM were valid and aligned with Trello’s domain policy. This tells mail servers that the message is authentic and should be trusted.
Headers Match Legitimate Atlassian Campaigns
From: Trello Invitation <[email protected]>
Return-Path: <[email protected]>
X-Atlassian-Mail-Transaction-Id: ecfe3981-xxxx-xxxx-xxxx-b57621c2a259
X-Msys-Api: {"campaign_id":"invite_board_modernized_PP","template":"invite_board_modernized"}This header data confirms the message was created using Trello’s own systems. It includes internal campaign tracking IDs used by Atlassian’s notification system.
Why This Works
Email filters saw this message as authentic because:
- It used a trusted domain (
trello.com) - It was sent through a trusted service (Amazon SES)
- It had no malware attachments or suspicious links in the body
- It passed SPF, DKIM, and DMARC—all standard email security checks
The danger wasn’t in the email itself—it was in the content embedded on the Trello board. Once users clicked the invite and landed on the board, they were exposed to a malicious payload hosted within a legitimate application.
What Businesses Can Do
- Don’t Trust a Message Just Because It’s Authenticated – SPF, DKIM, and DMARC confirm who sent the email—not whether the contents are safe. Security filters need to go beyond header checks.
- Use Browser Sandboxing or Isolation for Shared Links – If your business receives a lot of invites from external cloud platforms, consider browser isolation for URLs in tools like Trello, Notion, and Google Drive.
- Train Staff on Platform Abuse – Educate users that trusted tools like Trello can be used maliciously. Encourage them to verify unexpected invites—even if they appear to come from inside the company.
- Block or Monitor Unapproved Collaboration Tools – If your organization doesn’t use Trello, consider blocking its domains or setting alerts on invites.
- Report Abuse to the Provider – Platforms like Trello have abuse reporting processes. This helps prevent further exploitation by terminating malicious boards or user accounts.
Final Note
This wasn’t a failure of the tools in place—those tools worked as designed. The problem is that attackers are adapting faster than our detection systems. Just because security systems approve an email doesn’t mean the content is safe. Employees remain the final line of defense.
Security awareness training is essential. It needs to keep pace with how attackers operate—not just their tools, but their methods. Email filters and firewalls are useful, but they can’t assess context the way people can. Attackers take advantage of trust in familiar platforms, which means employees must stay alert and informed to recognize when something isn’t right.