Consider a hypothetical incident. At 14:03, an endpoint detection and response (EDR) platform records a suspicious process on a finance workstation. At 14:04, network telemetry records an outbound connection from the same system. The security operations centre (SOC) escalates the alert at 14:07. At 14:11, a forensic investigator begins live memory acquisition.
Then the system changes.
The suspicious process disappears. The network connection terminates. Analysis of the completed image does not identify artifacts that the earlier telemetry led the investigator to expect.
An initial explanation is that the investigator was too late.
There is another possibility.
The malware detected changes associated with the investigation and altered its behaviour in response.
Attackers are already incorporating AI into malware that generates commands during execution, and researchers have identified experiments using models to rewrite code for evasion. Applied to covering tracks, those capabilities could help malware adjust its concealment while an investigation unfolds. That is the concern examined here: AI-assisted changes could make malware more elusive and the resulting evidence harder to interpret. The specific memory-acquisition scenario remains hypothetical. [6][7]
An established problem with a new source of capability
Malware does not need artificial intelligence to frustrate investigators. Attackers have deleted logs, manipulated timestamps, injected code into legitimate processes, disabled security tools and destroyed evidence for decades. Malware also checks for debuggers, virtual machines, sandboxes and security products, then follows rules written for those conditions. MITRE ATT&CK documents both debugger evasion and virtualization or sandbox evasion as established techniques. [1][2]
Anti-forensics aimed at memory acquisition is not new either. At the Chaos Communication Congress in December 2012, Luka Milković presented Dementia, a proof-of-concept toolkit designed to hide Windows operating-system artifacts such as processes and threads during memory acquisition. The activity could remain present on the running system while the resulting image concealed selected artifacts from later analysis. [3][4]
The image could be acquired successfully and remain analyzable while omitting artifacts that had been present in the live system.
Research published the following year tested several acquisition tools against active anti-forensic techniques. Johannes Stüttgen and Michael Cohen found that acquisition could succeed without warning while relevant data was excluded. Their work also showed why malware running on the target may be able to distinguish a forensic agent from ordinary software and direct its interference at the acquisition process. [5]
What has actually been observed
AI integration in malware is no longer hypothetical, but the operational evidence remains narrower than some headlines suggest.
In November 2025, Google’s Threat Intelligence Group reported the first malware families it had identified using large language models during execution. PROMPTSTEAL, which GTIG attributed to APT28 and identified as the malware CERT-UA had reported as LAMEHUG, queried Qwen2.5-Coder-32B-Instruct through the Hugging Face API. It then executed model-generated Windows commands used to collect system information and documents. [6]
GTIG also described PROMPTFLUX, an experimental VBScript dropper designed to use Gemini to rewrite and obfuscate its own code. Some features were incomplete or disabled, including a commented-out self-modification function, and Google said the observed version did not demonstrate an ability to compromise a victim system. The sample nevertheless showed an attempt to place model-generated code inside an evasion and regeneration process. [6]
In August 2025, ESET reported PromptLock, a suspected proof-of-concept that used the gpt-oss-20b model through Ollama to generate Lua scripts dynamically. ESET initially described the samples as the first known AI-powered ransomware. It later reported that an academic research team had contacted ESET about a prototype closely resembling the samples. That supported ESET’s assessment that PromptLock was probably a proof of concept rather than operational ransomware. [7]
Unit 42’s August 2026 report examined 405 samples selected using broad criteria that included functional AI integration, AI-assisted delivery and AI-themed branding. Only 12 appeared in its Cortex XDR production endpoint telemetry, covering December 2024 through June 2025. The report described approximately 97 per cent of the samples as existing only in sandboxes and on VirusTotal. It characterized the broader dataset as dominated by research prototypes, security-validation testing and researcher submissions. These findings describe the vendor’s dataset and observation window, rather than the prevalence of all malware using AI. [8]
All 12 endpoint samples generated Cortex XDR alerts, and Palo Alto Networks reported that its products detected and blocked every sample that attempted to reach a customer environment. Conventional behavioural detection, endpoint analytics and sandboxing remained effective against the samples examined. [8]
These sources establish separate capabilities: detecting analysis environments, subverting memory acquisition and generating commands during execution. None of the reviewed cases demonstrates their combination in AI-assisted evasion of forensic memory acquisition, or measures how much AI would improve concealment in that setting.
The evidence environment can respond
Suppose malware can terminate processes, release allocated memory, migrate execution, stop network communication, remove temporary artifacts, generate misleading activity and change its execution strategy.
In the hypothetical AI-assisted implementation, the attacker gives a model a role in interpreting observations and selecting or generating a response. The surrounding software executes the chosen actions and supplies subsequent observations. This could automate parts of the adjustment that would otherwise require an operator to examine the situation and issue new instructions.
Code examined before a run may not contain the commands the model will later produce.
The observations available to the malware depend on its privileges and monitoring capabilities. They might include newly launched processes, active security tools or changes in network connectivity. A model would need those observations supplied to it; adding AI does not itself grant visibility into the host or permission to change it.
The objective could be to preserve access while reducing useful evidence. The model need not understand an investigation as a person would. It would need to associate the supplied observations with increased scrutiny and propose a response that the malware can execute.
Remaining resident may preserve access while increasing exposure to discovery. Termination may interrupt activity without removing persistence mechanisms or residual evidence. Migration, memory changes and additional activity may also leave new traces. Whether any response reduces useful evidence would need to be tested.
If the model and execution loop respond quickly enough, concealment could change during the collection itself. The investigator would be examining software that can revise its response as new observations arrive. Model errors, response time and available permissions would determine whether that attempt succeeds.
By the time acquisition finishes, the endpoint may no longer be in the logical state that existed when the SOC raised the alert.
The investigator collected the system successfully.
The harder question is what state was collected and why it had changed.
Start with what we know
An unexpected memory state does not establish that AI manipulated it. It does not establish deliberate anti-forensics.
In the opening scenario, earlier telemetry records activity that analysis of the later memory image does not identify. That is the observation to explain.
Several explanations remain open. Normal operating-system activity may have changed volatile memory before or during acquisition. The malware may have contained conventional anti-analysis logic. The acquisition process itself may have altered relevant state. The analytical method may not have identified artifacts that remained in the image. The expectation that particular artifacts should persist may have been wrong. An adaptive component may also have responded to changes in its environment.
These explanations do not deserve equal confidence merely because each is possible. Each requires evidence.
That evidence may include the timing of process termination, memory release or migration; execution associated with known acquisition utilities; hooks or modifications affecting acquisition paths; and repeated responses when investigators vary their actions under controlled conditions.
The AI attribution trap
Adaptive behaviour alone does not establish AI involvement.
A sophisticated rules engine can appear intelligent from the outside. Malware containing hundreds of conditions for security products, acquisition utilities, debuggers, network states and analysis environments could behave differently across systems without any model participating in the decision.
Calling malware AI-powered because its behaviour appears adaptive infers implementation from outcome.
An AI finding requires artifacts connecting the observed behaviour to an AI component. These might include model files, inference libraries, model-loading activity, configuration data, prompts, communications with a model API or model-generated output.
Those artifacts still require interpretation. An inference library does not establish that a model controlled the anti-forensic behaviour. A model file does not establish which decision it produced. A prompt does not establish that it was executed. An API connection does not establish what the returned output caused the malware to do.
The evidentiary chain must connect the component to the decision and the decision to the observed action.
If the evidence establishes an anti-forensic response but does not establish model involvement, the defensible finding is narrower:
The malware demonstrated environment-responsive anti-forensic behaviour.
That finding may attract less attention. It may be the one the evidence supports.
Memory is only one witness
The absence of a process from memory analysis does not erase an earlier EDR observation. A terminated connection on the endpoint does not erase an upstream firewall record. Local artifacts may disappear after authentication, DNS, proxy, network or cloud systems have recorded related activity.
An attacker who controls a workstation can manipulate evidence on that workstation. That control does not automatically extend to every system that observed it.
The investigation therefore moves outward. Memory is compared with EDR telemetry. Endpoint records are compared with network, identity, cloud and infrastructure records. Each source has limitations, but discrepancies between independently generated sources can become evidence themselves.
Because the sources describe different times, a difference may be expected. The investigator must assess whether the process or its remnants should still have been recoverable before treating their absence from memory analysis as anomalous.
This strengthens the case for forensic readiness. Telemetry transmitted before an adversary reacts may preserve observations beyond the immediate control of the compromised endpoint, provided it is stored under separate administrative control. The best evidence of what existed in RAM at 14:03 may therefore be a record generated at 14:03 and sent somewhere the malware could not reach.
Integrity is not completeness
Suppose the acquisition completes successfully. The image is hashed and the hash verifies. Chain-of-custody documentation records possession, transfer, access and handling. The acquisition tool reports no errors, and nobody modifies the image after collection.
Those facts support the integrity of the acquired evidence object.
They do not establish that the image faithfully represents everything that existed before collection began.
A matching verification hash supports the conclusion that the acquired image is unchanged relative to the reference state that was hashed. It cannot show that adversary-controlled software did not alter what the acquisition process could observe. Dementia demonstrated one form of that problem, and later research showed that acquisition tools could be subverted while appearing to succeed. [3][5]
Live acquisition introduces a separate limitation. The system continues operating while its memory is copied. The acquisition process takes time and can modify the system it is collecting. SWGDE describes the resulting risk of memory smear: data changes during acquisition, creating inconsistencies in the image. [9]
An investigator may therefore possess a perfectly preserved image of a state shaped by ordinary volatility, the collection process, adversary interference or some combination of the three.
Integrity remains defensible. Representational completeness is a separate question.
When collection changes behaviour
Digital forensics already recognizes that investigative actions can change a live system. RFC 3227, the IETF’s 2002 guidance on evidence collection, directs investigators to move from the most volatile evidence to the least volatile and to document their actions. It places memory near the top of its example order and remote logging much lower. [10]
The document also warns that disconnecting or filtering a compromised system from the network could trigger a “deadman switch” that detects the loss of connectivity and wipes evidence. [10]
Acquisition order is therefore an evidentiary decision. Isolating the endpoint, issuing live queries, enumerating processes and introducing a collection agent may produce changes visible to software on the host. Reading telemetry already stored elsewhere need not affect the endpoint. Different sequences of actions on the host may produce different evidentiary states.
The evidence is not useless. The sequence that produced it becomes part of its interpretation.
Investigating the investigator’s effect
An investigation of suspected adaptive anti-forensics needs two timelines.
The first asks: What did the attacker do?
The second asks: What did investigators do, and what happened immediately afterward?
When did isolation begin? When was the first remote command issued? When did process enumeration start? When did memory acquisition begin? Which binaries and services were introduced? What changed on the endpoint after each action?
Temporal correlation alone would not prove that malware recognized the investigation. Repeated behaviour under controlled conditions could strengthen or weaken that hypothesis.
In a laboratory, investigators could reproduce the compromised system and vary the sequence. Acquire memory first in one run. Enumerate processes first in another. Disconnect networking in a third. Introduce a known forensic tool in a fourth. Substitute a different acquisition tool in a fifth.
If the malware responds consistently to particular actions, the investigation has moved beyond collecting artifacts. It is testing competing explanations.
What the snapshot can prove
Digital forensics relies on capturing system state through disk images, memory images, network captures and log exports. These are imperfect representations, but they give investigators something relatively stable to examine.
In the projected scenario, the acquired evidence may contain two histories: the attacker’s original activity and the attacker’s reaction to the investigation.
Separating them requires an account of how the evidence was produced, including the investigator’s actions and observations preserved outside the endpoint. Model involvement is a further finding to establish, not an explanation to assume.
We may acquire the memory correctly. We may verify its integrity. We may analyze it properly.
And we may still have to ask:
Did we capture the intrusion, or did we capture what the intrusion wanted us to see?
Research and sources
- MITRE ATT&CK, “Debugger Evasion, T1622.”
- MITRE ATT&CK, “Virtualization/Sandbox Evasion, T1497.”
- Luka Milković, “Defeating Windows Memory Forensics,” 29th Chaos Communication Congress, December 28, 2012.
- Luka Milković, Dementia source code and documentation; Kelly Jackson Higgins, “‘Dementia’ Wipes Out Attacker Footprints in Memory,” Dark Reading, January 3, 2013.
- Johannes Stüttgen and Michael Cohen, “Anti-Forensic Resilient Memory Acquisition,” Digital Investigation, Volume 10 Supplement, 2013, pages S105–S115. Full text hosted by DFRWS.
- Google Threat Intelligence Group, “GTIG AI Threat Tracker: Advances in Threat Actor Usage of AI Tools,” November 5, 2025.
- Anton Cherepanov and Peter Strýček, “First Known AI-Powered Ransomware Uncovered by ESET Research,” ESET Research, August 26, 2025, updated September 3, 2025.
- Unit 42, “The State of AI-Enabled Malware August 2026: From Brand Abuse to Agentic Execution,” August 2026.
- Scientific Working Group on Digital Evidence, Best Practices for Computer Forensic Acquisitions, Version 2.0, June 15, 2023, section 7.4.2.
- D. Brezinski and T. Killalea, RFC 3227: Guidelines for Evidence Collection and Archiving, Internet Engineering Task Force, February 2002.