Malware uses LLMs to rank victims by how much they're worth

Original Article ↗ Hacker News Discussion ↗

Malware that uses large language models to triage victims by financial value is sharpening worries about how AI will supercharge cybercrime, from automating reconnaissance to prioritizing high‑value targets. Commenters weigh how realistic these threats are today, with some security professionals noting that many techniques are evolutions of existing attacks while others fear a return to “virus storm” conditions as agents gain autonomy. Much of the conversation centers on practical defenses—isolated machines or VMs for banking and development, stricter update and dependency practices, and stronger “default deny” security models—amid a sense that software supply chains and developer tooling are increasingly attractive attack surfaces.

Use of LLMs in Malware and Victim Ranking

  • Some argue LLMs are “good enough” for prioritizing targets but are slower, less accurate, and more expensive than dedicated tools.
  • Others note all the traditional tooling is already FOSS, so using LLMs is more about developer convenience and rapid prototyping.
  • Several comments describe current LLM “agents” already behaving intrusively (e.g., recursively scanning home directories, hunting for credentials, trying to bypass sandboxing).

Growing Anxiety About AI-Assisted Attacks

  • Multiple posters fear that auto-updating AI tools and fast-moving software stacks widen supply‑chain attack windows.
  • Comparisons are made to early-2000s “virus storms,” with concern that we’re entering a similar era, now at AI speed.
  • Others argue nothing fundamentally new is happening; AI mostly automates work attackers already did.

Isolation Strategies: Hardware, VMs, and QubesOS

  • Many propose compartmentalization: separate machines (or phones) for banking, development, browsing, gaming, socials, or 2FA.
  • Alternatives include heavy use of VMs, QubesOS, Docker (with caveats), multiple SSDs, and even separate physical LANs bridged through firewalled devices.
  • Some note cost and usability issues; this level of isolation is seen by some as “security as a hobby” or over‑engineering.

Containers, Kernels, and Security Models

  • Consensus that Docker/containers aren’t strong security boundaries; VMs and hypervisors are better but not infallible.
  • Discussion of “default allow” vs “default deny” OS models, with calls for smaller, more verifiable kernels and stronger protected input mechanisms.

Dependency and Supply-Chain Risks

  • Heavy criticism of ecosystems like npm/PyPI for normalizing huge, thin dependency trees and easy code execution on install.
  • Others push back that irresponsible dependency use predates npm and exists across languages.
  • Some note a regression in network lockdown practices (servers freely reaching the internet), making supply-chain abuse easier.

Defensive Practices and Tradeoffs

  • Suggested defenses: always patch promptly, avoid sketchy sites, minimize SaaS use, enforce MFA and unique passwords, consider cooldowns on updates, and use VMs for sensitive tasks.
  • There’s recognition of a lose‑lose tradeoff between unpatched CVEs and the risk of compromised updates.

LLM Provider Safeguards and Open Models

  • Commenters suggest/assume major labs already run safety classification on outputs, but say it’s imperfect and constrained by business incentives.
  • Several note that serious attackers will gravitate to open‑source models without such restrictions.

Speculation, Edge Cases, and Humor

  • Ideas range from “Robin Hood” malware and phase‑by‑phase societal breakdown (widely doubted) to an arms race of prompt‑injection booby‑traps in local data.
  • Some joke that being poor or heavily air‑gapped is now an accidental security advantage.