Free tools Windows power users keep installed
One-click scans. No signup required.
A fake recruiter can turn a routine take-home test into a malware delivery route. In a campaign documented by Palo Alto Networks Unit 42, the Slow Pisces group contacted cryptocurrency developers through LinkedIn, sent a plausible job-description PDF, and then pointed candidates to coding challenges hosted in compromised GitHub repositories. The risk was conditional: some projects behaved normally, while code and infrastructure could deliver malware to selected targets.
How the fake coding-challenge approach worked
Unit 42 described a hiring-like sequence rather than an obvious malicious download:
- Recruiter contact: Actors posed as recruiters on LinkedIn and approached developers, particularly people working in cryptocurrency.
- A credible job pitch: They first sent a benign PDF job description, lending the exchange the appearance of a normal application process.
- A take-home assignment: The candidate was directed to a GitHub project presented as a coding challenge. The observed projects covered stock-market data, European soccer statistics, weather data, and cryptocurrency prices. Their code was adapted from open-source projects.
- Conditional execution: Project code and command-and-control infrastructure could behave differently depending on who accessed or ran the project. Unit 42 observed ordinary application data in some cases and malicious payloads delivered only to validated targets.
That conditional behavior matters: a project that appears to work, or looks like a reasonable programming exercise, is not proof that it is safe. Unit 42 said delivery could depend on factors such as IP address, location, time, and HTTP headers.
Can a GitHub coding challenge contain malware?
Yes. In this campaign, the repository was the wrapper for code that could reach attacker-controlled infrastructure and trigger a payload. The language and execution path varied with the target’s role; these are examples documented by Unit 42, not a complete list of fake recruiting techniques.
#1 Best Overall
| Observed target/project | Language and execution route | What Unit 42 established |
|---|---|---|
| Data-fetching project | Python; unsafe YAML deserialization through PyYAML’s yaml.load() behavior |
Most data sources in the example were legitimate, while one was attacker-controlled. The initial path avoided conspicuous direct use of Python eval or exec. Unit 42 noted that PyYAML documentation recommends yaml.safe_load() for untrusted input. |
| Cryptocurrency dashboard for a JavaScript-role target | JavaScript; an attacker-controlled URL passed through EJS rendering with an escapeFunction option |
The chain could execute supplied JavaScript, but Unit 42 did not recover the full JavaScript payload, so this route was only partially understood. |
| Other observed repositories | Python and JavaScript were common; two Java-based repositories were also observed | The projects were made to resemble ordinary data-oriented applications and were adapted from open-source code. |
The unsafe YAML example is a reminder that the danger can lie in how a project processes data, not just in a visibly suspicious command. Reviewing a repository’s source may help, but a plausible project or familiar open-source components alone do not establish that running it is safe.
What malware did the campaign deliver?
RN Loader
Unit 42 analyzed an RN Loader sample that sent basic machine and operating-system information over HTTPS and received commands. The report says later stages could be unknown or conditionally deployed; it does not establish that every target received the same stages or that every victim had persistence.
Rank #2
RN Stealer
The recovered macOS RN Stealer sample collected basic victim information, installed applications, home-directory contents, saved macOS credentials, SSH keys, and configuration files for AWS, Kubernetes, and Google Cloud. This is what the analyzed sample was capable of collecting, not a claim that every infected device had every item stolen.
Is this coding challenge from a real recruiter?
Do not decide based on a polished PDF, a convincing profile, or a project that runs correctly. Verify the person and the hiring process through a channel you find independently, such as the employer’s official careers site or a known company contact, rather than relying solely on links and contact details in the message. Treat an unexpected request to clone and run code as a reason to pause and ask for confirmation.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →- Check that the role exists on the employer’s official site and that the recruiter can be confirmed through an independently located company channel.
- Ask what the assignment requires you to install, execute, or connect to before running it.
- Be especially cautious if a task requires credentials, access to cloud configuration, SSH keys, or a personal or work account unrelated to the assignment.
- Do not run an unverified assessment on a device containing sensitive personal or corporate data.
What to do if you ran code from a fake interview
- Stop interacting with the project. Do not rerun it or follow further instructions from the suspected recruiter.
- Use a separate, trusted device to seek help. If a work device or corporate data may be involved, contact your organization’s security team promptly. Unit 42’s report identifies its Incident Response team as a contact for suspected compromise.
- Tell responders what happened. Preserve the repository URL, recruiter messages, job-description PDF, approximate run time, device and operating system, and any commands or permissions you granted. Avoid deleting potentially useful evidence unless your security team instructs you to.
- Protect exposed accounts from a clean device. If you entered or stored passwords, cloud credentials, SSH keys, or other secrets on the affected machine, tell the relevant security team or service owner so they can assess and revoke or replace them. Do not use the possibly compromised device to change important credentials.
- Follow incident-response guidance for the device. The appropriate containment and recovery steps depend on what ran and what information was present; the campaign report does not provide a one-size-fits-all cleanup procedure.
How employers can reduce risk in take-home assessments
Unit 42’s explicit mitigation is: “The most effective mitigation remains strict segregation of corporate and personal devices.” For employers, that means keeping unverified candidate code away from environments containing corporate accounts, production access, or sensitive data. For developers, it means not treating a routine interview assignment as a reason to run unknown code on a work machine or a personal device holding valuable secrets.
Unit 42 also reported sharing intelligence with LinkedIn and GitHub, after which the platforms removed malicious accounts and repositories. That is a historical takedown statement, not evidence that either platform is currently free of malicious recruiter accounts or repositories.
Rank #4
What is known about the campaign’s scale?
Unit 42 did not report a victim count or measured success rate for this coding-challenge operation. Its report cited more than $1 billion in cryptocurrency-sector theft in 2023 as a group-level figure, not losses caused by this specific campaign. It also summarized FBI attribution of a separate $308 million theft from a Japan-based cryptocurrency company in December 2024; that incident was not a measured impact of the fake interview delivery method.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
