Malware ships with bugs that defenders could use against it

Static analysis tools have spent years scanning legitimate software for security bugs before it goes out the door. The same scanners work on malware, and malware carries a steady supply of its own bugs. Researchers ran four of these tools across 658 leaked malware projects and found that close to 90 percent contained at least one recognized software weakness.

The malware code came from VX-Underground, a public repository of leaked samples. The scanners were Cppcheck, Bandit, Snyk, and Semgrep. For comparison, the team ran the same analysis on 249 open-source projects, among them the most-downloaded Python and JavaScript packages and a group of security tools that includes nmap, sqlmap, and zap. The team picked smaller community projects on purpose, so the comparison would sit closer to the size and staffing of malware work.

What the scanners found

Poor code quality showed up most often by a wide margin. Missing integrity checks, unused variables, and dead code followed. The pattern matched the way malware operates. Web-application risks such as SQL injection and cross-site scripting appeared less often, in keeping with code that takes little user input and runs with minimal interaction. Many of the flags point to quick, low-care development: variables assigned and never read, code paths that go unused, functions called with the wrong arguments.

One recurring weakness stood out for its consequences. A share of the samples turned off TLS certificate validation, a step authors take so their traffic avoids certificates that could tie back to them. Turning off that check leaves the malware’s command-and-control traffic open to interception. A defender who spots it can monitor and locate infected hosts.

Turning weaknesses into a defensive tool

Defenders normally study how malware exploits weaknesses in other software. The reverse case, weaknesses inside the malware, has a track record. The WannaCry outbreak stopped when someone registered a domain that the worm checked before running, a hard-coded kill switch. Law enforcement and researchers have taken over the Emotet and Torpig botnets by working through flaws in how they operated. Reverse engineers have built free decryptors by finding mistakes in how ransomware generates its keys. The Malvuln project, started in 2021, has cataloged security bugs in malware samples for the same purpose. The same logic extends forward: a known flaw could crash a piece of malware or hand a defender control of its command server.

What makes a systematic approach plausible is repetition. More than two-fifths of the weaknesses the team detected came from code fragments shared across several malware families. Authors copy and reuse the same routines, which means a single recurring flaw can sit inside many separate threats at once. A weakness worth exploiting in one family has a chance of working against others built from the same parts.

Code that reads like everyone else’s

Code quality tells a separate story. On maintainability scores, the malware landed in the same range as the benign packages, sometimes higher. The samples tend to be small, sparsely commented, and flat in structure, with few classes and rare use of closures. Authors leave out comments to slow down anyone analyzing the code and to keep peers from forking it. Those traits fit code built for one job and a short life. The quality holds up because the scope stays narrow.

The overlap with ordinary code runs deep enough that structure alone failed to separate malware from benign software. The researchers tie the steady quality to the Malware-as-a-Service market, where buyers pay for tools and expect them to work, which pushes authors to write cleaner code. The same lone-developer habits found in hobbyist open-source projects show up in malware built by small teams.

Where the comparison breaks down

The comparison has limits the authors name directly. The malware was mostly written in C and C++. The benign projects were mostly Python and JavaScript. Some of the structural differences may come from the languages themselves, separate from any question of intent. The metric tooling covered a subset of the languages in the set, so the structural measurements reach about 70 percent of the malware, roughly 463 of the 658 projects. The leaked samples on VX-Underground also represent the malware that ended up public, which is a slice of what exists.

The authors stop short of endorsing hack-back, the practice of striking at attackers’ systems, which carries legal and ethical questions they leave open. Malware is software, software has bugs, and those bugs are worth cataloging. A library of common weaknesses gives defenders a head start on finding the next kill switch before a campaign spreads.

Guide: What automated pentesting alone cannot see