How North Korean Hackers Compromise Developers Using a “Coding Assignment” Trap

Today’s post breaks down a developer-focused attack: how fake job offers and GitHub “assignments” quietly trigger malware through VS Code automation—turning a normal interview step into a compromise!

Here’s a cyberattack that starts like a career opportunity.

And ends like a breach.

A recruiter messages you.

A “coding assignment” is shared.

You open it in VS Code.

And that’s it. You’re compromised.

This is part of a campaign used by nation-state threat actors to target developers in IT companies.

The pattern is not new.

But the execution is getting smarter.

Because this time… you don’t even have to run anything.

You just have to open the folder.

Let’s break down how this works.

---

Attack Flow:

1. It typically begins on LinkedIn. The attacker approaches the victim like a recruiter with a job opportunity, builds some trust over a few messages, and then shares a GitHub repository link as part of a technical coding assignment. This step is intentional: developers are comfortable with GitHub links, and the entire interaction feels routine.
   

2. The victim clones the repository and opens it in Visual Studio Code. At that moment, VS Code often displays a warning asking whether the user wants to trust the folder or open it in Restricted Mode. Most developers click “Trust,” because trusted mode enables normal functionality: tasks, extensions, automation, and integrations. Restricted mode is seen as inconvenient. In this attack, that single click is the pivot.
   

3. Now comes the key trick: the moment the project folder is opened, the repository triggers execution automatically — even though the victim didn’t click “run.” This happens because the project includes a malicious configuration that abuses VS Code’s built-in automation features. Specifically, it contains a VS Code Task configured with “runOn: folderOpen”, meaning the task is triggered as soon as the folder opens.
   

4. This is the part that surprises people. We tend to assume that “opening a repo” is the same as “reading files.” But modern IDEs are no longer passive text editors. They’re execution environments. They run tasks, load workspace settings, activate extensions, and automate routines that developers run hundreds of times a day.
   

5. Once the task triggers, it silently reaches out to an attacker-controlled server and downloads a payload. This can happen in the background without any obvious warning because the command that performs the download is just another system call. To the OS and even to endpoint tooling, it may look like normal developer activity: VS Code running commands as part of a project workflow.
   

6. The downloaded payload then executes using Node.js, which is another reason this technique is so effective. Developer machines already have Node installed. They already run npm scripts and JavaScript tooling constantly. So the attacker doesn’t need to drop a heavy binary or ask the user to install anything. They simply use the existing runtime that’s already trusted in the environment.
   

7. The first stage typically performs lightweight profiling. It gathers system details to confirm whether the victim is the intended target and to fingerprint the machine for tracking. This can include details like OS version, hostname, and other device characteristics. At this stage, the attacker isn’t trying to cause a loud disruption. They’re trying to validate: “Is this an actual developer machine inside a real company environment?”
   

8. Once validated, a second stage is pulled down. This stage is usually more heavily obfuscated and designed to do real damage. It can fetch additional JavaScript modules, execute remote instructions, and begin collection. From here, capabilities often include keylogging, screenshot capture, searching for sensitive files, and extracting browser credentials.
   

9. For a developer endpoint, this becomes extremely high impact, because developer machines often have access to the most valuable parts of a company: source code, build pipelines, internal documentation, API tokens, cloud credentials, and session cookies that effectively act like “password equivalents.”
   

---

Key Insights:

1. We often assume that “opening code” in an IDE is safe. Because we think nothing is being “executed”. This attack cleverly abuses that assumption. It flips a very common developer habit into an entry point.
   

2. Many developers don’t realize how powerful IDE automation features (such as VS Code Tasks) are. These are meant to automate routine work: build, test, run. But automation is neutral. If a task can run a build command, it can also run a download-and-execute attacker commands. If it can save you time, it can also save the attacker time.
   

3. VS Code (and a lot of other IDEs) aren’t just text editors anymore. They’re an automation platform that can run commands, load extensions, and interact with your system. That power is exactly what makes them valuable and exploitable.
   

4. That’s why when you open a new folder, VS Code shows “Trust this folder” vs “Restricted Mode.” Trust means VS Code can fully enable tasks, extensions, and integrations that may execute commands. Restricted Mode limits that blast radius. So if the repo is from a stranger or shared over DMs , start with restricted.

   

5. Similarly, npm install is not a harmless step. Most developers think it only “downloads packages.” But in reality, it can also run code automatically. When you run npm install, npm reads the project’s package.json file. That file can contain scripts like preinstall, install, postinstall. These scripts execute automatically during installation, without you explicitly running them. A lot of attacks hide in these “normal setup steps.”

---

Closing Thought

This is what makes these attacks annoying: they don’t look suspicious.

A recruiter reaches out, you get curious, they send a repo, you open it. That’s normal.

Most developers aren’t thinking “security incident” when they see a coding assignment.

They’re thinking “let me just check this quickly.”

And attackers know that.

They’re not exploiting VS Code as much as they’re exploiting how developers behave when there’s a job opportunity on the table.

What’s the one control you’d add to stop this?