Skip to main content

Skynet? Not Quite -But Closer Than You'd Think

 

AINative Malware: The Emerging Reality Behind Adaptive Cyber Threats

As AI becomes woven into everyday tools and workflows, the cyber threat landscape is evolving alongside it. One of the most significant shifts is the emergence of AInative malware malicious software that doesnt just use AI during development but actively integrates AI models into its runtime behaviour.

This isn’t science fiction anymore. While we’re not facing a fully autonomous “Skynet” scenario, recent discoveries show that adaptive, AIdriven malware is already operating in the wild. The question is no longer if AInative malware will exist, but how quickly it will mature and what that means for defenders.

 What Makes Malware “AINative?

AIAssisted Malware

Traditional malware created with help from AI tools such as LLMs. Attackers may use AI to:

• Write phishing content

• Generate exploit code

• Speed up reconnaissance

But the malware itself behaves conventionally.

This aligns with Recorded Future’s AI Malware Maturity Model (AIM3):

(https://www.recordedfuture.com/blog/ai-malware-maturity-modelAINative Malware)

Malware that:

• Uses AI models during execution

• Generates commands or code dynamically

• Adapts to the victim environment

• Alters behaviour without redeployment

This corresponds to AIM3 Levels 3–4, where AI becomes part of the operational kill chain.

 

RealWorld AINative Threats Identified in the Last 12 Months

1. LAMEHUG (PROMPTSTEAL) AIDriven Command Generation

LAMEHUG is one of the first publicly documented malware families to integrate an LLM directly into its attack chain. Attributed to APT28, it uses the Hugging Face API to query the Qwen 2.5Coder32BInstruct model during execution.

It:

• Analyses the victim’s environment

• Sends prompts to the LLM

• Receives dynamically generated Windows commands for reconnaissance and data theft

References:

Splunk STRT analysis:

(https://www.splunk.com/en_us/blog/security/lamehug-ai-powered-malware-analysis.html)

BleepingComputer coverage:

(https://www.bleepingcomputer.com/news/security/apt28-malware-uses-ai-to-generate-windows-commands/ )

 

2. PROMPTFLUX AIPowered SelfRewriting Malware

PROMPTFLUX is a VBScript dropper identified by Google’s Threat Intelligence Group (GTIG). Its standout feature is a component called “Thinking Robot”, which interacts with the Gemini API to rewrite its own code.

Key behaviours:

• Requests new obfuscated versions of itself

• Regenerates code as often as every hour

• Drops new variants into the Windows Startup folder

This represents AIdriven polymorphism, far more dynamic than traditional mutation engines.

References:

Google Threat Intelligence Group report:

(https://blog.google/threat-analysis-group/ai-powered-threat-evolution/)

The Register summary:

(https://www.theregister.com/2025/01/14/google_ai_malware_promptflux/)

 

3. S1ngularity SupplyChain Attack Using AI Tools for Secret Discovery

The S1ngularity incident involved malicious npm packages published after attackers exploited a vulnerable GitHub Actions workflow in the Nx project.

Important clarifications:

• The GitHub Actions vulnerability was exploited manually, not by AI.

• The malicious packages used local AI CLI tools (Claude, Gemini, Q) to search for and extract secrets from infected systems.

• AI was used for postexploitation data discovery, not autonomous exploitation.

This still qualifies as AInative behaviour because the malware invoked AI tools at runtime.

References:

Wiz Research deepdive:

(https://www.wiz.io/blog/s1ngularity-npm-supply-chain-attack)

Nx Security Incident Postmortem:

(https:/nx.dev/blog/security-incident-analysis)

SecurityWeek coverage:

(https://www.securityweek.com/malicious-npm-packages-abused-ai-tools-to-steal-secrets/)

 

Why This Still Isn’t “Skynet”

1. API Dependency

Most AInative malware relies on external LLM APIs (Hugging Face, Gemini, OpenAI).

This creates:

• Detectable outbound traffic

• A single point of failure

• Opportunities for defenders to block or monitor LLM usage

Reference:

Google TAG

(https://blog.google/threat-analysis-group/ai-powered-threat-evolution/)

 

2. HumanintheLoop Reality

Even advanced AIassisted operations documented by major vendors still require human oversight for:

• Prompt engineering

• Target selection

• Escalation decisions

We are not yet at fully autonomous AIM3 Level 5 operations.

Reference:

Google Blog

(https://blog.google/threat-analysis-group/ai-threat-landscape/ )

 

 

3. AI Is a Force Multiplier, Not a New Class of SuperMalware

Current AInative threats:

• Accelerate existing attack chains

• Improve adaptability

• Lower the skill barrier

But they do not yet represent a fundamentally new, unstoppable threat category.

Reference:

Techcrunch.com

(https://techcrunch.com/2025/01/15/google-warns-ai-is-being-used-in-malware/)

 

What This Means for Defenders

1. AI Governance

Policies for internal AI usage reduce the risk of shadow AI and exposed API keys.

2. AI Usage Detection

Monitor for suspicious outbound LLM API calls, including to:

• Hugging Face

• Gemini

• OpenAI

3. BehaviourBased Detection

AIdriven polymorphism makes signaturebased AV increasingly ineffective.

Prioritise:

  EDR/XDR

  Behavioural analytics

 Networklevel AIusage monitoring

 

Conclusion

AInative malware is no longer theoretical. Early examples like LAMEHUG and PROMPTFLUX show how attackers are already integrating AI models into malware to increase adaptability, stealth, and operational flexibility.

We are still some distance from fully autonomous AIdriven cyber threats but the foundations are being laid now. Organisations must prepare for a rapidly evolving threat landscape where AI is not just a tool for attackers, but an active component of the malware itself.

Comments

Popular posts from this blog

Root of the Problem: Linux Flaws That Give Attackers Admin Rights

 I realised that I haven’t posted to my blog in a long time and this week an article about CVE’s in linux caught my eye and that was the perfect excuse to write another blog post. Cybersecurity researchers at Qualys have uncovered two critical local privilege escalation (LPE) flaws that are shaking the foundations of Linux security. These aren't your run-of-the-mill vulnerabilities; we're talking about direct, express lanes to full root access on major Linux distributions. If you use Ubuntu, Debian, Fedora, openSUSE Leap 15, or SUSE Linux Enterprise 15, you need to pay close attention. The Double Threat: CVE-2025-6018 & CVE-2025-6019 An article detailing the CVE’s can be found at the link below ( CVE-2025-6018 and CVE-2025-6019 Vulnerability Exploitation: Chaining Local Privilege Escalation Flaws Lets Attackers Gain Root Access on Most Linux Distributions | SOC Prime )     Qualys has pulled back the curtain on two distinct, yet chainable, vulnerabilit...

From OVA to Rocky: My Wazuh Upgrade Story

  In this blog post I will be covering something I’ve covered in a previous blog post, but I’ve decided to change my home lab and put my Wazuh SIEM on a standalone rocky linux, there are several reasons I chose to do this, Performance & Scalability: The OVA VM is a pre-built virtual machine that may not be optimized for high availability or scalability. A dedicated instance on Rocky Linux allows for better resource allocation and tuning. Customization & Flexibility: The OVA VM comes with predefined configurations. Running Wazuh on Rocky Linux gives you full control over system settings, security policies, and software updates. Compatibility & Stability: Rocky Linux is a stable, enterprise-grade OS, and Wazuh has been tested for compatibility with newer versions like Rocky Linux 9.3. This ensures long-term support and reliability. Security & Isolation: A dedicated instance provides better security isolation compared to a shared virtualized environment. You can impl...

Up the Wazuh: A SIEM-ple Adventure in Troubleshooting

Initial setup To start  I downloaded the .osa file from the  wazuh website ( https://wazuh.com ) and then installed it in my virtualbox hypervisor. Then I booted up my fedora linux VM and the wazuh VM with the dashboard and manager on.  After I had logged in to the wazuh VM with the default credentials I used the ip a command to find out the ip address of the wazuh VM. As from reading the documentation I’d need this later. In my fedora VM I opened a terminal and used the commands on the wazuh website to install the agent on the VM. After some time the installation was completed and I had to update the. conf file with the IP address of the wazuh manager. This is important because  the file is a generic file that needs to be modified to make it specific to each individual setup.  All was going well up to this point. I tried to get the fedora VM to talk to the wazuh VM. The problems I encountered It was here the problems started when I tried to pi...