There is a genre of security headline that says AI has created unstoppable malware. There is also a body of published threat intelligence from model providers and security vendors describing what threat actors are really doing with these tools.
The two do not match well. The reality is less dramatic and more useful to plan around.
What Published Threat Reporting Shows
The major model providers, including Anthropic, OpenAI, and Google Threat Intelligence, publish reports on accounts they have banned for malicious use. Microsoft has published similar research.
The consistent pattern across those reports is assistance rather than autonomy. Threat actors use these tools for reconnaissance and research, translating and drafting social engineering content, debugging and refactoring their own tooling, explaining unfamiliar code and systems, and building scripts to handle the tedious parts of an operation.
What the reporting has not shown is a model independently discovering and weaponizing novel vulnerability classes at scale. Capabilities are improving, and this section will need updating over time, but that is where the public evidence sits.
The Polymorphic Malware Claim
The scary version of this story is malware that rewrites itself constantly using AI so no signature ever matches. It is worth understanding why this is less impressive than it sounds.
Polymorphic and metamorphic malware has existed since the 1990s, and packers and crypters that change a binary on every build have been sold in criminal markets for over a decade. Signature based detection stopped being the primary defense a long time ago for exactly this reason.
Modern endpoint detection watches behavior: what a process does, what it spawns, what it touches, where it connects. Rewriting the code does not change the fact that something has to inject into a process, establish persistence, or reach out to a controller. See EDR and XDR explained for how that works.
Where AI Genuinely Helps Attackers Technically
Understanding unfamiliar code quickly. An attacker who obtains source code or a decompiled binary can get oriented much faster than before.
Adapting existing exploit code. Taking a public proof of concept and making it work against a slightly different target version used to require real skill. It still does, but less of it.
Building the boring infrastructure. Parsers, loaders, data exfiltration scripts, and log cleaning utilities are ordinary programming tasks, and AI is good at ordinary programming tasks.
Scaling reconnaissance. Reading through large amounts of public data about an organization and summarizing what matters is exactly the sort of text work these tools do well.
Vulnerability Research Is the Area to Watch
Automated bug finding has been a serious research area for a long time, going back through fuzzing and symbolic execution to the DARPA Cyber Grand Challenge in 2016. Language models are now being combined with those techniques.
Google has published work on using models to find memory safety bugs in real code, and there are public projects doing AI assisted triage of fuzzing results. Some of this work has found genuine vulnerabilities in widely used software.
The important detail is that this cuts both ways and currently favors the side with the source code, which is usually the maintainer. Faster bug finding applied to open source projects by their own maintainers is a defensive win.
The Supply Chain Angle Nobody Expected
One genuinely new problem comes from AI writing code rather than attacking it. Models sometimes reference software packages that do not exist, inventing plausible names.
Researchers noticed that these invented names are often repeatable, which means an attacker can register a package with a commonly hallucinated name and wait for developers to install it. The technique has been nicknamed slopsquatting, and it is a variation on typosquatting that does not require the developer to make a typo.
The defense is ordinary supply chain hygiene: verify that a dependency exists and is maintained before adding it, pin versions, use a lockfile, and scan dependencies. It is a good reminder that generated code is untrusted input.
What Defenders Should Actually Change
Very little at the technical level, which is the reassuring conclusion. Behavior based detection, patching what is exposed, least privilege, and phishing resistant authentication all still work because the fundamentals of intrusion did not change.
What should change is the assumption that low skill attackers stay low skill. The floor moved up. Defenses that quietly depended on attackers being sloppy are the ones that will fail first.
What should also change is how you treat AI generated code inside your own organization. Read it before running it, review it before shipping it, and verify its dependencies. This is covered in the scripting course material and in AI in the SOC.
Learn This at HackRange
Module 7 of the CEH course covers malware analysis hands on, including building and analyzing a payload safely inside the range.