Fake Slack Job Posts Push Trojan Coding Tests

How the attack worked

The operation began with a job lure posted in a community Slack's #jobs channel, offering a developer role focused on upgrading an e-commerce platform with a modern stack. Interested developers who responded were moved from the public channel into direct messages, where they were instructed to complete a coding assessment as part of the hiring process. This assessment took the form of a repository that looked like a normal, functional software project.

The repository was not what it appeared to be. Malicious payload fragments were hidden as Base64 text inside HTML comments across SVG flag images stored in an assets directory. A JavaScript file, serverValidation.js, reassembled these fragments into a multi-stage payload aligned with the OTTERCOOKIE malware family. Because the visible code ran perfectly fine, developers had no obvious reason to suspect anything was wrong while the hidden code executed in the background.

Why it succeeded

The lure exploited normal hiring workflows that developers encounter regularly: an unsolicited job offer, a move to private messaging to discuss details, and a request to complete a coding assessment. Each step mirrors legitimate recruiting practices, which lowered suspicion. The malicious repository's outward functionality reinforced the illusion of legitimacy, since running the project produced no visible errors or warning signs.

Hiding payload fragments inside image files rather than in obviously executable code also helped the operation evade casual review and some automated scanning, since SVG assets are not typically treated as a place to look for malicious logic.

What to watch for

• Unsolicited job offers posted in community Slack workspaces, especially ones that quickly push toward direct messages
• Coding assessments or take-home projects that require executing unfamiliar code locally, particularly outside a sandbox
• Repositories that appear to run correctly but include unusual asset files, embedded scripts, or components unrelated to the stated project scope
• Any request to run code as a precondition for continuing a hiring conversation

Building resistance

Organizations should treat this pattern as a reminder that developers are high-value targets because their systems and credentials can open the door to broader supply chain compromise. Useful steps include independently verifying recruiters and companies before engaging, reviewing unfamiliar repositories in isolated or sandboxed environments before execution, and training engineering teams to treat any workflow that moves from a public channel to private messages, especially one involving code execution, as worth extra scrutiny. Building this awareness into onboarding and ongoing security training for developers can reduce the chance that a single compromised individual becomes an entry point for a larger incident.

How did attackers reach developers in this campaign?

Attackers posted job lures in a Slack community's #jobs channel, then moved interested developers into direct messages to continue the recruiting pretext.

What made the malicious coding assessment hard to detect?

The malicious payload was split into Base64 fragments hidden inside HTML comments within SVG flag images, then reassembled by a JavaScript file, so the repository ran normally while malicious code triggered silently in the background.

What data was the malware designed to steal?

The operation focused on stealing browser credentials, crypto wallet data, and files, plus enabling remote access and clipboard theft.

Why are developers a preferred target for this kind of attack?

Compromising a single developer can provide the initial access needed to enable broader supply chain attacks against downstream organizations.