In April 2026, attackers infiltrated the Slack workspace of the TODO Group — a Linux Foundation working group for open source program office practitioners — and impersonated a respected community leader to deliver malware to developers. No zero-day was used. No exotic exploit chain. Just trust, a Google Sites link, and a fake AI tool pitch. This campaign is a textbook example of why open source communities are increasingly high-value targets: they are built on trust, operate informally across collaboration platforms, and often lack the enterprise security controls that would flag such behavior.
If you maintain open source packages, contribute to foundation working groups, or manage a developer community on Slack or Discord, this attack chain directly applies to your threat model. This post breaks down exactly how the attack worked, maps it to known adversary techniques, and gives you concrete steps to reduce exposure.
How Threat Actors Exploit Developer Trust in Collaboration Platforms
Open source communities run on informal trust. A message from a known leader in a Slack DM carries weight — developers are unlikely to demand email verification before clicking a link sent by someone with the right display name and profile photo. Attackers understand this dynamic, and they exploit it deliberately.
This campaign mirrors MITRE ATT&CK technique T1566.002 (Spearphishing Link) combined with T1036 (Masquerading) — impersonating a trusted identity to lower the victim's guard before delivering a malicious payload. The social engineering component was unusually refined: the attacker crafted a persona around an exclusive, invitation-only AI tool that could predict code merge outcomes, framing the message as a privilege, not a request. The message explicitly stated the team was "only sharing this with a few people for now" — a classic scarcity trigger that encourages the target to act without pausing to verify.
Why Google Sites Was Chosen as the Phishing Host
The phishing link pointed to https://sites.google.com/view/workspace-business/join — a Google Sites page. This is not accidental. Attackers regularly abuse legitimate platforms (Google Sites, Notion, GitHub Pages) because the parent domain passes most URL reputation checks. A link to sites.google.com will not trigger a Slack warning or a corporate proxy block the way a suspicious lookalike domain might. Security tools that filter on domain reputation rather than full URL analysis are systematically blind to this technique.
Important: Never evaluate a URL's trustworthiness based solely on the root domain. A Google Sites URL can host a fully functional phishing kit. Train your developers and security teams to treat any URL — regardless of the parent platform — that requests credentials or certificate installation as suspicious.
The Four-Stage Attack Chain: Impersonation to Full System Compromise
The attack followed a precise sequence, with each stage enabling the next.
| Stage | Technique | MITRE ATT&CK ID | Outcome |
|---|---|---|---|
| Impersonation | Fake Slack persona of Linux Foundation leader | T1036 – Masquerading | Victim trusts the message |
| Phishing | Google Sites link with fake workspace UI | T1566.002 – Spearphishing Link | Credentials harvested |
| Certificate Install | Malicious root certificate disguised as "Google certificate" | T1553.004 – Install Root Certificate | Encrypted traffic intercepted |
| Malware Delivery | Platform-specific payload (gapi binary on macOS) | T1105 – Ingress Tool Transfer | Full device compromise |
Stage 3: The Root Certificate Is the Real Payload
Most phishing write-ups focus on credential theft. This campaign went further. After harvesting the victim's email and verification code, the phishing site instructed victims to install a "Google certificate" — framed as a routine access requirement. In reality, this was a malicious root certificate that, once installed, enables the attacker to perform a machine-in-the-middle (MitM) attack against all HTTPS traffic from that device.
This is significant. Credentials can be reset. A trusted root certificate installed on a developer workstation gives the attacker the ability to intercept Git operations, package registry authentication, CI/CD API calls, and any other encrypted communication — silently and persistently.
Stage 4: Platform-Specific Malware Execution
On macOS, a script automatically downloaded and executed a binary named gapi from the remote IP 2.26.97.61. This technique — downloading a binary from a remote C2 immediately after initial access — maps directly to T1105 (Ingress Tool Transfer). On Windows, the certificate installation followed the same flow via a browser trust dialog. Both paths achieve the same result: persistent access to a developer machine with potential reach into upstream repositories and internal tooling.
Why Open Source Ecosystems Are Structurally Vulnerable to These Attacks
Consider what a compromised open source developer's workstation actually represents. It likely holds SSH keys to repositories with millions of downstream users, API tokens for package registries like PyPI or npm, and credentials for CI/CD pipelines that automatically publish signed releases. The threat is not just to the individual — it's to the software supply chain.
The 2020 SolarWinds compromise and the 2024 XZ Utils backdoor (CVE-2024-3094) demonstrated that attackers are willing to invest significant time targeting individuals with repository access. Impersonating a Linux Foundation leader in a Slack workspace is operationally simpler than the XZ Utils campaign, which involved an attacker maintaining a fake contributor persona for two years. The barrier to this kind of attack is low. The potential impact is not.
Pro Tip: Map your open source contributors and maintainers against your threat model. If a developer has the ability to publish packages used by your production environment, treat their workstation and credentials with the same sensitivity as an internal privileged account. Apply CIS Control 5 (Account Management) and CIS Control 6 (Access Control Management) accordingly.
Detection and Response: What SOC Teams Should Be Looking For
If you operate a SOC and have visibility into developer endpoints, the following indicators and behavioral patterns are relevant.
| Detection Vector | What to Look For | Tool/Data Source |
|---|---|---|
| Network | Outbound connections to 2.26.97.61 | Firewall logs, SIEM |
| Endpoint | Execution of unsigned binary named gapi on macOS | EDR (CrowdStrike, SentinelOne) |
| Certificate Store | New root certificate added outside of MDM/GPO | Endpoint visibility, osquery |
| Browser | Requests to sites.google.com/view/workspace-business | Proxy logs |
| Email/Chat | Messages from cra@nmail.biz or containing access key CDRX-NM71E8T | DLP, Slack audit logs |
Indicators of Compromise (IoCs)
Immediately search for these across your environment:
- Phishing URL:
https://sites.google.com/view/workspace-business/join - Fake contact email:
cra@nmail.biz - Access key used in lure:
CDRX-NM71E8T - C2 IP address:
2.26.97.61 - Malicious macOS binary:
gapi
If you find the root certificate in any device's trust store and cannot verify its origin through your MDM system, treat the device as fully compromised and initiate your IR playbook accordingly.
Hardening Developer Environments Against Social Engineering and Supply Chain Attacks
Preventing this class of attack requires layering technical controls with behavioral ones. Neither alone is sufficient.
Identity Verification Protocols for Developer Communities
The OpenSSF advisory issued by CRob Robinson makes a practical recommendation that organizations should formalize: always verify identity out of band before acting on any request received through a chat platform. If a colleague sends you a DM on Slack asking you to install something, confirm it via a phone call or a second platform before proceeding. This is not paranoia — it is basic operational security.
For community managers and foundation working group leads, establish a clear policy: official tooling, certificates, and access invitations will never be distributed through direct messages. Publish this policy visibly in your community workspace.
Root Certificate Management as a Security Control
Organizations should enforce root certificate management through MDM (for macOS) and Group Policy (for Windows). No certificate should be installable on a managed device without organizational approval. This directly counters the technique used in this campaign and maps to NIST SP 800-53 control SC-12 (Cryptographic Key Establishment and Management).
| Security Control | Implementation | Risk Reduced |
|---|---|---|
| MDM-enforced certificate policy | Jamf (macOS), Intune (Windows) | Prevents rogue root certificate installation |
| MFA on all developer accounts | TOTP, hardware key (FIDO2) | Limits credential theft impact |
| Slack audit log monitoring | Slack Enterprise Grid or SIEM integration | Detects unusual DM patterns |
| Out-of-band identity verification | Documented in community policy | Defeats impersonation |
| EDR on developer endpoints | CrowdStrike, SentinelOne | Detects binary execution post-compromise |
Key Takeaways
- Verify identity before acting — A matching Slack display name and profile photo is trivially easy to fake. Confirm unusual requests through a second channel before clicking any link or installing anything.
- Treat root certificate installation requests as a red flag — Legitimate services do not ask users to install root certificates via a chat link. This is an automatic indicator of compromise or attempted compromise.
- Extend privileged access policies to developer accounts — Maintainers with repository push access or package publishing rights carry supply chain risk equivalent to internal privileged users.
- Search your environment for the listed IoCs now — Do not wait for an incident report. Check firewall logs, endpoint certificate stores, and proxy logs for the indicators above.
- Enable and review Slack audit logs — If you use Slack for developer communities, audit log visibility into DM activity is a detection capability gap most organizations have not addressed.
- Implement out-of-band verification as policy — Open source working groups and internal developer communities should have a documented, published verification procedure for any unusual requests.
Conclusion
This campaign does not require sophisticated infrastructure or novel exploit techniques to succeed. It requires only that developers trust a familiar name in a familiar platform — and that is precisely why it works. Open source communities run on informal trust, and attackers have recognized that this trust is exploitable at scale with minimal operational cost.
The supply chain implications extend well beyond the individual victim. A compromised developer workstation with active access to public repositories is an entry point into software that runs in millions of production environments. Organizations that consume open source dependencies should treat maintainer compromise as a legitimate threat scenario in their risk models, not an edge case.
Start with the IoCs above. Then audit root certificate stores on developer endpoints, review your Slack security configuration, and formalize your community's identity verification protocol. The controls exist — the question is whether they are implemented before the next impersonation campaign lands in your developers' DMs.
Frequently Asked Questions
Q: How did attackers gain access to the TODO Group Slack workspace to send these messages? The investigation did not confirm a compromise of the Slack workspace itself. Slack allows users to send direct messages across workspaces in some configurations, and attackers may have used a separately created account with a spoofed display name and profile photo to impersonate the Linux Foundation leader. Slack's identity model relies on display names, not cryptographic verification — which is why display name spoofing is viable.
Q: Would MFA have prevented this attack?
MFA would have limited the damage from credential theft but would not have prevented the root certificate installation or malware execution. If a victim installed the malicious certificate and executed the gapi binary before realizing the attack, their credentials being MFA-protected does not prevent the attacker from intercepting session tokens and authenticated traffic in real time. MFA is a necessary control — it is not sufficient on its own here.
Q: Why did the attacker target open source developers specifically rather than corporate employees? Open source maintainers often have privileges that corporate employees do not — specifically, the ability to publish code to public package registries without enterprise security tooling monitoring their endpoint or network activity. From an attacker's perspective, compromising a maintainer with npm or PyPI publish access is potentially more valuable than compromising a corporate endpoint that sits behind a DLP system and EDR.
Q: How do I check if my macOS device has the malicious root certificate installed?
Open Keychain Access, navigate to System Roots or System, and search for any certificate you do not recognize or that was added recently without an MDM push. You can also run security find-certificate -a -p | openssl x509 -noout -subject from the terminal to enumerate all installed certificates. If you find an unrecognized root certificate, treat the device as compromised and engage your incident response process.
Q: Does this attack fall under any compliance reporting obligations? Potentially, yes. If a compromised developer had access to systems storing personal data, the credential theft and traffic interception could trigger breach notification requirements under GDPR (Article 33), HIPAA (if health data was accessible), or PCI DSS (if payment system credentials were in scope). Organizations should involve legal and compliance teams early in the incident response process to assess notification obligations.
Enjoyed this article?
Subscribe for more cybersecurity insights.