Fake technical interviews: developers turned into a gateway

I'm reviewing a repository someone sent me for a technical test.

So far, just another Tuesday for a developer.

You open the README, look at the structure, install what's needed, and run the project to understand what it does. It's exactly the kind of routine we've been doing for years without giving it much thought.

And that's precisely why the attack works.

Throughout 2026, several security companies have continued documenting a campaign known as Contagious Interview, linked by various researchers to actors associated with North Korea. The targets are developers and tech professionals who are contacted through fake hiring processes. Microsoft notes that the activity has existed at least since December 2022 and continues to appear in current environments.

The worrying part is no longer that someone sends you a suspicious executable.

Now they can send you work.

The attack looks like a real interview

The procedure has a huge advantage for the attacker: practically every action requested makes sense within a technical interview.

It can start with a recruiter on a professional network. Then come messages about experience, salary, or technologies.

There's a video call.

There's a project.

There's GitHub.

And finally there's a coding test.

In March 2026, Microsoft documented processes where candidates were directed to repositories hosted even on widely known services like GitHub, GitLab, or Bitbucket. Upon running the project, the victim ended up launching code controlled by the attacker.

Unit 42 also described a January 2026 case where attackers posed as personnel associated with Fireblocks. They conducted interviews via Google Meet and later asked the candidate to review a supposed project hosted on GitHub. The request included completely normal actions to set up a JavaScript project. The problem was that those actions triggered the malicious code.

That detail seems to me the most important one in this whole story.

You don't need to convince a developer to disable their antivirus or download a virus.exe.

You just need to tell them:

"Here's the challenge. Get it running and tell me what you'd improve."

That we do.

The repository can work perfectly

The evolution published by Elastic Security Labs in July 2026 makes it even more interesting.

On May 26, a fake job offer appeared within Elastic's own community Slack. Interested individuals were taken to private messages and received a challenge related to an e-commerce project.

The test worked.

But it was also set up to steal information.

Elastic found components associated with OTTERCOOKIE, including mechanisms to obtain browser credentials, files, clipboard information, and establish remote access.

The part that caught my attention the most was how they hid part of the code.

They used seemingly normal SVG files —flag images inside the project— to store fragments that could later be reassembled during execution.

Elastic also noted that, at the time of its analysis, that project was not being detected by antivirus vendors.

That breaks another fairly common assumption:

"If it were malware, Defender would detect it."

Not necessarily.

The README can lie too

Kudelski Security analyzed in June another repository related to these campaigns.

The project imitated a real company and had a structure convincing enough for a technical evaluation. Inside they found hidden code among normal project files and even VS Code-related configurations that could participate in the backdoor's execution.

There's something particularly effective about this.

When we review unknown software we usually look for exactly the opposite: a broken project, absurd names, obviously suspicious code, or strange instructions.

Here the attacker can spend time making everything look correct.

This already has scale

It doesn't seem like a small experiment either.

Socket reported in April 2026 that it had identified more than 1,700 malicious packages related to Contagious Interview.

And they weren't concentrated only in npm.

The activity appeared across several ecosystems used daily by developers: npm, PyPI, Go Modules, crates.io, and Packagist.

For those of us who work with several technologies this matters quite a bit.

The problem can no longer be summed up as "JavaScript developers need to be careful with npm."

The pattern is much broader.

Why attack developers?

Because our computers usually have quite useful things.

Private repositories.

Credentials.

Tokens.

Open sessions.

Access to cloud services.

Keys for publishing packages.

Client information.

And, in certain cases, access to a company's infrastructure.

Compromising a developer can be used to steal information directly, but also to reach a much bigger target.

A case documented in 2026 shows how serious this scenario can become. Unit 42 covers the attack against the lead maintainer of Axios: after a sophisticated interaction through a Slack set up to look legitimate, the attacker gained access to his npm account and ended up publishing compromised versions of the package.

At that point we're talking about supply chain.

In plain English: instead of attacking a thousand applications, you attack something those thousand applications use.

The signals I would check

I don't think the solution is to stop accepting technical tests.

I would change several habits, though.

• A company should be able to prove it actually exists and that the person contacting you works there.
• A repository received during a hiring process is still third-party code.
• A Google Meet video call or a conversation inside Slack doesn't by itself prove that the identity is legitimate.
• Being asked to install strange tools to continue an interview deserves scrutiny.
• An unknown project should be inspected before it's run.
• External assessments should be treated as potentially hostile software and kept separate from the environment where credentials, client repositories, or important access live.

I would also review the activity of the account delivering the project.

Unit 42 had previously flagged GitHub profiles with very little history, isolated repositories, and strange activity around projects used in this campaign.

None of these signals on its own proves that an attack exists.

Several together should raise alarms.

What I take away

For years we associated phishing with poorly written emails, odd domains, and attachments.

This attack follows a different logic.

It uses tools we know and tasks we all do every day.

A coding test builds trust precisely because it looks like real work.

That's why I think we developers need to start applying to received code the same distrust we learned years ago to apply to attachments.

GitHub is a platform.

Not a security certificate.

A simple rule for the next interview

If I get a technical test tomorrow from a company I don't know, I can review the code.

I can analyze the architecture.

I can do the assessment.

What I wouldn't do automatically anymore is turn my main computer into the environment where I find out whether the recruiter was who they said they were.

The campaign has been active for years and continued to evolve throughout 2026. Elastic found new techniques in July, and Unit 42 was still documenting in August how attackers are leveraging legitimate collaboration channels to make these operations more convincing.

That small change in habit can prevent a technical interview from turning into initial access to something much bigger.

Sources

Microsoft Security — Contagious Interview, March 2026. Microsoft Security research

Elastic Security Labs — new campaign with malware hidden in SVG, July 2026. Elastic Security Labs research

Kudelski Security — analysis of repository used in fake interviews, June 2026. Kudelski Security research

Socket — Contagious Interview expansion to five package ecosystems, April 2026. Socket research

Palo Alto Networks Unit 42 — analysis of collaboration channel abuse, August 2026. Unit 42 research