Hackers Impersonate Linux Leader on Slack to Target Dev

Open source developers face a growing and sophisticated threat. Unlike attacks that rely on complex exploits or hidden vulnerabilities, this particular danger exploits a far simpler, yet potent, vector: trust.

A social engineering campaign is actively targeting developers through Slack, where an attacker poses as a respected Linux Foundation community leader to trick victims into downloading malware.

The attack was first brought to public attention on April 7, 2026, through a high-severity advisory posted to the OpenSSF Siren mailing list by Christopher “CRob” Robinson, Chief Technology Officer and Chief Security Architect at the Open Source Security Foundation (OpenSSF).

The campaign focused on the Slack workspace of the TODO Group — a Linux Foundation working group for open source program office (OSPO) practitioners — as well as related open source communities.

Attackers carefully built a fake identity of a well-known Linux Foundation leader and used that persona to send direct messages containing a phishing link hosted on Google Sites, a platform many developers recognize and consider safe.

The link was deliberately crafted to appear legitimate, making it far harder for even security-aware developers to catch something was wrong.

Socket.dev analysts and a Socket engineer were among the first to examine the attack and document its technical behavior.

Their investigation confirmed this was not a basic phishing attempt — it was a calculated, multi-stage operation built to exploit the deep trust that naturally exists within close-knit open source communities.

The attacker’s pitch was carefully crafted. Posing as the Linux Foundation leader, the threat actor described an exclusive private AI tool that could analyze open source project dynamics and predict which code contributions would get merged before any reviewer ever looked at them.

The message emphasized exclusivity, telling targets the team was “only sharing this with a few people for now.” Along with the phishing link, the attacker included a fake email address and an access key to make the fake workspace flow look real.

Once a victim clicked the link, a fraudulent authentication flow collected their email address and a verification code.

After credentials were stolen, the phishing site directed victims to install what it called a “Google certificate” — which was, in reality, a malicious root certificate.

Once installed, it allows the attacker to silently intercept encrypted web traffic passing between the victim’s device and any website they visit. This set the stage for the most damaging part of the attack, which then diverged into different paths depending on the victim’s operating system.

Inside the Infection Mechanism

The platform-specific behavior of this attack reveals just how precisely it was engineered. On macOS, once the malicious root certificate was installed, a script automatically downloaded and executed a binary named gapi from a remote IP address (2.26.97.61).

Running this binary gives the attacker potential full control over the compromised device — including the ability to access files, steal further credentials, and issue additional commands remotely.

On Windows, victims were prompted to install the malicious certificate through a browser trust dialog. Once accepted, it enabled the same encrypted traffic interception.

Across both platforms, the complete attack followed four clear stages: impersonation, phishing, credential harvesting, and malware delivery — each step building on the last to push deeper into the victim’s environment.

OpenSSF’s advisory includes several important recommendations for developers active in open source Slack communities.

Always verify identities out of band — never trust a Slack message based on a display name or profile photo alone, and confirm unusual requests through a separate, known communication channel before taking any action.

Never install a root certificate from a link sent through a chat message or email; legitimate services simply do not request this from users.

Treat any such prompt as suspicious unless your organization’s IT team has explicitly directed it. Finally, enable multi-factor authentication (MFA) on all developer and collaboration accounts.

MFA will not prevent impersonation, but it meaningfully limits the damage if credentials are stolen.

Indicators of Compromise (IoCs):-

• Phishing URL: https://sites.google.com/view/workspace-business/join
• Fake email address: [email protected]
• Access key: CDRX-NM71E8T
• Remote C2 IP: 2.26.97.61
• Malicious macOS binary: gapi

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.