Story
How to compromise your system with a job interview
1 report
1 website
1 discussion
Latest report
Overview
A phishing campaign impersonated a real company to send software engineers a TypeScript coding challenge through LinkedIn recruitment messages. The company named in the outreach was not involved and had publicly warned about the impersonation. Warning signs included a recruiter unaffiliated with the company, no introductory call, a personal Gmail address, an unexpected programming language, and code hosted on Bitbucket. The roughly 180-file project ran a loader when candidates used commands such as npm run dev or npm start. It contacted api.jsonbin.io to retrieve obfuscated JavaScript, which then contacted a command-and-control server at 147.189.174.138. The delivered modules included a remote-access trojan with shell access, SSH pivoting, screenshot capture, clipboard monitoring, and synthetic mouse and keyboard controls; a browser credential and cryptocurrency-wallet stealer; and a file grabber. The malware targeted environment variables, SSH and cloud credentials, .env files, private keys, browser profiles, wallet extensions, and user documents. It could access these files without administrator privileges because they are normally owned by the logged-in user. The malware also checked whether it was running in a virtual machine. Running untrusted coding tests in an isolated VM and restoring a snapshot afterward can limit exposure, although malware can still steal data accessible within that VM. Suspected victims should rotate credentials and keys, assess exposed secrets, and reinstall their operating system.
Summary from codedge.de.
Reports
One report so far. Additional coverage will appear here when it is linked to this story.
Community reactions
Each reaction summarizes sampled comments from the linked discussion.
Hacker News · codedge.de
Historical count: 15 · 15 saved in sample · Historical sample
Analysis ready
Read this discussion’s reaction
Based on 15 sampled comments from this thread. Analyzed 2026-08-21.
The AI-specific alarm centered on a coding-interview command-line tool accused of quietly installing components, inspecting running processes, and intercepting traffic from AI assistants. Commenters treated that behavior as a profound breach of the trust a candidate is asked to extend: an assessment tool should evaluate code, not gain visibility into prompts, tool calls, or the broader developer environment. The fact that this can happen without administrator privileges made the concern sharper, since valuable developer data often lives in ordinary user-accessible files and sessions. Most of the larger thread discussed recruiting scams and local-machine hygiene rather than AI itself, so there was little debate over AI model quality or the merits of AI-assisted interviewing. The relevant consensus was defensive: tools that touch AI workflows should be explicit about their network access, installed components, and data collection, especially when candidates are pressured to run them during a job search. Suggestions such as disposable virtual machines, separate machines, and outbound-firewall prompts were framed as practical containment, not as a reason to normalize intrusive assessment software. No one defended intercepting AI-tool requests as a legitimate feature of an interview platform.
- Concern: An interview CLI that silently monitors processes and captures AI-assistant traffic turns a coding exercise into potential surveillance of prompts, projects, and developer secrets.
- Concern: Candidates cannot safely treat a tool as harmless merely because it avoids administrator privileges; AI workflows and credentials are often exposed inside the normal user account.
- Concern: Job-search pressure makes intrusive AI-adjacent tooling especially dangerous, because applicants may run opaque software to avoid losing an opportunity.