{"id":30420,"date":"2026-04-22T21:42:23","date_gmt":"2026-04-22T16:12:23","guid":{"rendered":"https:\/\/www.kaspersky.co.in\/blog\/why-hackers-target-developers\/30420\/"},"modified":"2026-04-22T21:42:23","modified_gmt":"2026-04-22T16:12:23","slug":"why-hackers-target-developers","status":"publish","type":"post","link":"https:\/\/www.kaspersky.co.in\/blog\/why-hackers-target-developers\/30420\/","title":{"rendered":"How and why cybercriminals are targeting software developers"},"content":{"rendered":"

Lately, hackers have been turning up the heat on software developers. On the surface, this might seem like a puzzling move \u2014 why go after someone who\u2019s literally paid to understand tech when there are plenty of less-savvy targets in the office? As it turns out, compromising a developer\u2019s machine offers a much bigger payoff for an attacker.<\/p>\n

Why developers are such high-value targets<\/h2>\n

For starters, compromising a coder\u2019s workstation can give attackers a direct line to source code, credentials, authentication tokens, or even the entire development infrastructure. If the company builds software for others, a hijacked dev environment allows attackers to launch a massive supply chain attack, using the company\u2019s products to infect its customer base. If the developer works on internal services, their machine becomes a perfect beachhead for lateral movement, allowing hackers to spread deeper into the corporate network.<\/p>\n

Even when attackers are purely chasing cryptocurrency (and let\u2019s face it, tech pros are much more likely to hold crypto than the average person), the malware used in these hits doesn\u2019t just swap out wallet addresses; it vacuums up every scrap of valuable data it can find \u2014 especially those login credentials and session tokens. Even if the original attackers don\u2019t care about corporate access, they can easily flip those credentials to initial access brokers or more specialized threat actors on the dark web.<\/p>\n

Why developers are sitting ducks<\/h2>\n

In practice, developers aren\u2019t nearly as good at understanding cyberthreats and spotting social engineering as they think they are. This misconception is a big reason why they often fall prey to cybercriminals. Professional expertise can often create a false sense of digital invincibility. This often leads technical professionals to cut corners on security protocols, bypass restrictions set by the security team, or even disable security software on their corporate machines when it gets in the way of their workflow. That mindset, combined with a job that requires them to constantly download and run third-party code, makes them sitting ducks for cyberattackers.<\/p>\n

Attack vectors targeting developers<\/h2>\n

Once an attacker sets their sights on a software engineer, their go-to move is usually finding a way to slip malicious code onto the machine. But that\u2019s just the tip of the iceberg \u2014 hackers are also masters at rebranding classic, battle-tested tactics.<\/p>\n

Compromising open-source packages<\/h3>\n

One of the most common ways to hit a developer is by poisoning open-source software. We\u2019ve seen a flood of these attacks over the past year. A prime example hit in March 2026, when attackers managed to inject<\/a> malicious code into LiteLLM, a popular Python library hosted in the PyPI repository. Because this library acts as a versatile gateway for connecting various AI agents, it\u2019s baked into a massive number of projects. These trojanized versions of LiteLLM delivered scripts designed to hunt for credentials across the victim\u2019s system. Once stolen, that data serves as a skeleton key for attackers to infiltrate any company that was unlucky enough to download the infected packages.<\/p>\n

Malware hidden in technical assignments<\/h3>\n

Every so often, attackers post enticing job openings for developers, complete with take-home test assignments that are laced with malicious code. For instance, in late February 2026, malicious actors pushed out web application projects built on Next.js<\/em> via several malicious repositories, framing them as coding tests<\/a>. Once a developer cloned the repo and fired up the project locally, a script would trigger automatically to download and install a backdoor. The attackers gained full remote access to the developer\u2019s machine.<\/p>\n

Fake development tools<\/h3>\n

Recently, our experts described an attack<\/a> where hackers used paid search-engine ads to push malware disguised as popular AI tools. One of the primary baits was Claude Code, an AI coding assistant. This campaign specifically targeted developers looking for a way to use AI-assistants under the radar, without getting the green light from their company\u2019s infosec team. The ads directed users to a malicious site that perfectly mimicked the official Claude Code documentation. It even included \u201cinstallation instructions\u201d, which prompted the user to copy and run a command. In reality, running that command installed an infostealer that harvested credentials and shuttled them off to a remote server.<\/p>\n

Social engineering tactics<\/h3>\n

That said, attackers often stick to the basics when trying to plant malware. A recent investigation<\/a> into a compromised npm package \u2014 Axios \u2014 revealed that hackers had gained access to a maintainer\u2019s system using a shockingly simple \u201coutdated software\u201d ruse. The attackers reached out to the Axios repository maintainer while posing as the founder of a well-known company. After some back-and-forth, they invited him to a video interview. When the developer tried to join the meeting on what looked like Microsoft Teams, he hit a fake notification claiming his software was out of date and needed an immediate update. That \u201cupdate\u201d was actually a Remote Access Trojan, giving the attackers access to his machine.<\/p>\n

Niche spam<\/h3>\n

Sometimes, even a blast of fake notifications does the trick, especially when it\u2019s tailored to the audience. For example, just recently, attackers were caught posting<\/a> fake alerts in the Discussions tabs of various GitHub projects, claiming there was a critical vulnerability in Visual Studio Code that required an immediate update. Because developers subscribed to those discussions received these alerts directly via email, the notifications looked like legitimate security warnings. Of course, the link in the message didn\u2019t lead to an official patch; it pointed to a \u201cfixed\u201d version of VS Code that was actually laced with malware.<\/p>\n

How to safeguard an organization<\/h2>\n

To minimize the risk of a breach, companies should lean into the following best practices:<\/p>\n