[260816] From Buying a Bad Linux Trojan to Tricking AI: What Have Hackers Learned in the Past Decade?

TLDR

• Hackers are shifting from attacking devices to exploiting trust—from malware and supply chains to AI decision-making. Security must evolve from protecting code to protecting trust and automated actions.

In 2013, a Linux banking Trojan priced at $2,000 was considered a "bad investment" by security researchers. It was called Hand of Thief (HoT).

At the time, Windows was the primary battlefield for malware. It had a large user base and diverse software sources, with pirated software, cracks, and game cheats all serving as distribution channels. For attackers making money through scale, Windows Trojans offered an easier way to reach enough victims.

Linux desktop users were fewer, distributions were fragmented, and software installation worked differently. Yet in August 2013, this Trojan targeting Linux desktops appeared on underground markets. Its marketing claimed that it could monitor browsers, intercept forms, collect information, and exfiltrate data, making it look like a serious attempt to enter the commercial malware market.

When researchers bought and analyzed it, they found that reality was far from the marketing claims: Firefox frequently crashed on Fedora, the data collected in Chrome was almost useless, and it would not even run on Ubuntu. More ironically, the malware-generation tool itself had to run on Windows.

The final verdict was almost comical: the person who spent $2,000 on it may have been the one who truly lost money.

HoT failed not because Linux was "impossible to attack," but because attacking Linux desktops was not cost-effective at the time. The cost of an attack determines software security.

Security Advantages Often Come from Costs Attackers Are Unwilling to Pay #

Many people later cited HoT as evidence that Linux was more secure. A more accurate interpretation is: whether a system becomes a target depends not only on whether vulnerabilities exist, but also on whether attackers are willing to invest the cost and what returns they can expect.

The common attack path in the Windows era was straightforward: disguise a program, trick users into down and executing it, and then steal their data. The attacker's main concern was reaching as many people as possible.

Linux desktops made this approach more complicated—software distribution methods differed, distributions varied, permissions were stricter, and users were more fragmented. This did not mean Linux had no vulnerabilities or that users could not be compromised. It simply meant that the cost was higher for cybercriminals whose business model depended on mass distribution.

What HoT demonstrated was this: security is often not about a system being inherently stronger, but about the choices attackers make after doing the math.

Hackers Later Found Cheaper Entry Points #

If attackers could only target users' computers, they had to solve one problem: how to convince users to trust their software. Eventually, they realized that directly deceiving users was not the most efficient approach. The 2024 xz-utils backdoor is a typical example. The target was no longer a program on a single computer, but the software supply chain itself. Instead of deploying obviously malicious software, the attackers spent a long time building identities, infiltrating the community, gaining maintainer access, and eventually getting malicious code into a widely used component.

The difference from HoT is clear: HoT tried to trick users into "installing me"; xz-utils attacked the trust of developers and communities—"believe that my code belongs in the project."

In the past, attackers had to convince large numbers of users. With a supply-chain attack, compromising a critical node once could affect a large number of downstream users.

Software Security Is Becoming About Protecting the Trust Chain #

Modern software is rarely built entirely from scratch. An application may depend on open-source components, third-party services, automated builds, software repositories, and CI pipelines.

What users trust is no longer just the final code. They also trust who maintains it, why a dependency is considered safe, why a particular version is released, and why a specific commit is accepted.

Attackers are no longer looking only for code vulnerabilities, but for weak points in the trust chain. Defensive priorities therefore need to change as well: instead of simply avoiding unknown programs, we now need to manage dependency sources, code signing, build processes, and permissions.

In the AI Agent Era, the Target May Become Automated Decision-Making #

AI Agents are increasingly entering development and business workflows. In the future, an Agent may search for dependencies, read documentation, modify code, open PRs, run tests, and deploy services.

As efficiency increases, so does the attack surface. In the past, attackers tricked engineers into "down this software"; in the future, they may try to "make an Agent believe this is the right choice."

For example, when a coding Agent needs to find a date-handling library, it may evaluate whether the README is complete, whether the tests pass, whether the repository is active, and whether the community feedback looks normal. If a malicious project deliberately fakes these signals, the attack is no longer aimed directly at the code itself, but at the Agent's decision-making process. Attackers do not need to make AI do something obviously wrong; they only need to make it automatically choose the wrong direction.

Defense Must Follow the Changing Attack Surface #

In 2013, when facing desktop Trojans, the key defenses were software sources and user permissions.

In 2024, against supply-chain attacks, the focus shifted to dependency management, release processes, and maintainer identities.

In the AI Agent era, the focus shifts to restricting the permissions of automated decision-making: high-risk actions should require human confirmation, the tools used by Agents should be isolated, critical actions should be logged and audited, and external information should be verified at the source.

Hackers will not stubbornly attack a particular system; they will always look for the entry point with the lowest cost and highest return.

In 2013, it might have been tricking users into installing software; in 2024, it might have been infiltrating the software supply chain; in the future, it may be influencing AI's automated decisions.

What security needs to protect is changing as well: from devices, to code, and then to trust relationships.

As software becomes increasingly dependent on open source, automation, and AI, the core security questions will increasingly become—who is allowed into the trust chain, and who is allowed to make decisions on our behalf?

If you let an AI Agent work on its own, which step would you be most afraid of it "making decisions on its own"? Please indicate the source and link of this article when reprinting.

Help us make these docs great!

All X-CMD docs are generated from command help and multiple data sources. See something that's wrong or unclear? Feel free to let us know through any of these ways~