How do you investigate a ransomware attack when the attacker may have used AI in ways that traditional forensic workflows were never designed to reconstruct?
That question is becoming less theoretical.
Ransomware investigations have traditionally focused on a familiar set of questions. How did the attacker get in? Which accounts and systems were compromised? How did they escalate privileges and move laterally? What data did they access or exfiltrate? How was the ransomware deployed? Is persistence still present?
The evidence is equally familiar. Endpoint telemetry, authentication records, network logs, memory, file system artifacts, PowerShell, cloud audit records, malware samples, email, DNS, and proxy records.
AI does not make those sources obsolete. It introduces another evidentiary layer.
Google Threat Intelligence has documented malware that queries large language models during execution to generate commands or modify code. PROMPTSTEAL, attributed to APT28 activity against Ukraine, queried a hosted model through the Hugging Face API to generate Windows commands rather than carrying those commands inside the malware itself. Google has also documented PROMPTFLUX, an experimental dropper that prompts the Gemini API to rewrite its own code to evade detection.
The same period produced a caution. In August 2025, ESET reported samples found on VirusTotal as the first known AI-powered ransomware and named them PROMPTLOCK. Within days, researchers at NYU Tandon confirmed that the code was their own laboratory proof-of-concept, uploaded during testing without an academic label. The samples existed. The in-the-wild actor inferred from them did not.
Anthropic has separately reported criminal use of AI across extortion and ransomware development. That reporting includes an actor with limited coding capability using Claude to develop ransomware, and an extortion operation that used Claude Code across reconnaissance, credential access, data analysis, and victim targeting.
The operational implication is already being discussed. The forensic implication deserves equal attention.
If malware can ask a model what to do next, the executable recovered from disk may no longer contain the complete behaviour the investigator is trying to reconstruct. Part of that behaviour may have existed only in a prompt, a model response, a temporary script, an API transaction, or volatile memory.
That changes the investigation.
A synthetic ransomware incident
Consider a fictional company, Marrowfield Industrial Group.
Marrowfield operates a hybrid Microsoft environment with approximately 2,500 employees. It uses endpoint detection and response, centralized authentication, cloud email, several on-premises file servers, and an internet proxy. Security logs are forwarded to a SIEM.
At 02:21 on a Sunday, the SOC receives simultaneous alerts from multiple servers. Files are being renamed and encrypted. Several administrative accounts have been used across systems. A ransom note appears on affected hosts.
The organization initiates its ransomware response plan. Systems are isolated, privileged credentials are reset, external communications are moved to a separate channel, and the incident response team begins determining the extent of compromise.
Those actions address the immediate incident. The forensic investigation asks a different set of questions. What happened? How did it happen? What evidence supports that reconstruction? And, in this case: what role, if any, did AI play in the intrusion?
The case is synthetic. It combines capabilities already observed separately in current threat reporting rather than claiming that this exact sequence has occurred in a documented campaign. That distinction is necessary.
The investigation should not begin by assuming that an unusual attack was AI-driven. It should begin with a claim that can be tested.
Phase 0: Authority and Scope
Under the Zemi Method, the investigation begins with authority and scope. That may appear procedural until the evidence extends outside the victim organization.
Marrowfield authorizes examination of:
- affected endpoints and servers;
- identity and authentication records;
- EDR and SIEM telemetry;
- firewall, DNS, and proxy records;
- cloud infrastructure;
- email;
- memory captures;
- ransomware samples;
- relevant administrator and service accounts; and
- systems believed to have participated in command execution or exfiltration.
During triage, investigators identify repeated outbound connections from a compromised system to an external generative AI service. The scope now changes. Potentially relevant evidence may exist with the model provider, including API request timestamps, account or API-token identifiers, model versions, request identifiers, prompts, responses, usage records, and associated security records.
Technical visibility into a connection does not create legal or contractual authority to obtain the content behind it. If provider records cannot be obtained, that becomes an evidentiary limitation. It cannot be filled by inference.
This is the first way AI changes the ransomware investigation. Some of the most important evidence may exist outside the compromised environment.
Phase 1: Frame
The original incident description might say: the attackers used AI-powered ransomware.
That is not yet a forensic finding. It collapses several propositions into one. The investigation separates them.
H1: AI was used before compromise. The attacker used a model for reconnaissance, phishing, vulnerability research, exploit development, or malware development.
H2: AI was used during execution. Malware inside Marrowfield's environment communicated with an AI system and consumed its output.
H3: AI materially affected attacker actions. Model output generated or selected commands, scripts, targets, or data that were subsequently used during the intrusion.
H4: AI contributed to data selection or extortion. A model helped identify sensitive material, determine victim pressure points, calculate a demand, or generate negotiation content.
H5: AI independently selected a strategic objective in the ransomware operation.
H6: AI conducted material portions of the ransomware operation without human control.
A seventh explanation must remain open.
H7: The apparent AI activity was unrelated to the ransomware operation.
Each proposition requires different evidence. Proof that the malware connected to an AI service does not prove that the AI generated malicious commands. Proof that AI generated a command does not establish that the command was executed. Proof that a model produced a script does not establish that the script caused encryption. None of those findings establish that the model decided to attack Marrowfield.
The Zemi Method, Version 1.2 requires these propositions to remain separate because technical execution, causation, objective selection, intent, authorization, and accountability are not interchangeable findings. The current published version incorporates that separation into investigations involving consequential AI activity.
Phase 2: Preserve
The incident-response team still needs the conventional ransomware evidence. Memory is captured from selected systems where operational conditions permit it. Disk evidence and relevant malware are preserved. EDR, authentication, firewall, DNS, proxy, cloud, email, PowerShell, and other relevant records are exported. Time sources and retention limits are documented.
Containment remains the priority when systems are actively being compromised. Evidence preservation should be designed into the response process rather than becoming a reason to leave an attacker operating in the environment.
CISA's ransomware guidance makes the same operational trade-off visible. It recommends rapid isolation of affected systems, warns that powering systems down destroys volatile evidence, and recommends preserving memory, logs, and malware samples where circumstances permit.
This incident requires another collection category.
AI Action Provenance
At 01:34, investigators reconstruct execution of a suspicious binary from a compromised administrative workstation. At 01:38:11, proxy records show the system establishing an outbound connection to a hosted model API. Memory examination identifies remnants of a structured API request that asks the model to generate a command for enumerating specific characteristics of the Windows domain. At 01:38:13, the system receives a response. At 01:38:16, EDR records PowerShell launched as a child of the suspicious process. The command executed by PowerShell corresponds materially with the model response recovered from memory.
That sequence is interesting. It is not yet enough.
The investigation preserves:
- the malicious executable;
- process ancestry;
- memory;
- the recovered request and response fragments;
- destination IP and domain information;
- DNS resolution;
- proxy records;
- timestamps;
- the API credential or token where recoverable;
- script execution records;
- PowerShell telemetry;
- resulting processes, commands executed, and files created;
- authentication events; and
- resulting changes in the environment.
The investigation later obtains provider-side records through an authorized process. Those records contain a request identifier matching evidence recovered from the endpoint and confirm the time, model interaction, and response.
The model interaction is now part of the incident evidence. Not because the model says what happened. Because records from independent systems can be compared.
A second AI interaction
At 01:52, investigators identify another series of model API calls. This time the interaction is not limited to generating a reusable command. A malware-controlled orchestration component submits batches of file metadata and extracted text to the model. It asks the model to classify the material according to categories relating to pending acquisitions, cyber insurance coverage, legal disputes, regulatory investigations, and sensitive employee information.
The component is configured to add files to a staging queue when the model returns specified classifications. Endpoint telemetry records the orchestration process. Recovered configuration establishes the classifications that trigger staging. File-system auditing records access to the selected files, and a temporary output file contains several thousand paths grouped by the model's returned categories.
Later network evidence and the attacker's exfiltration tooling show that 237 files from those categories were transferred to external infrastructure before encryption began.
AI is no longer merely present. The model's classifications triggered a downstream workflow that selected files for staging. That is a materially different proposition.
Phase 3: Corroborate
This is where an AI-enabled ransomware investigation can go wrong.
An AI platform may produce several records describing the same interaction. A malware log may record an API request. An orchestration component may record it again. A user interface may display it a third time. That does not necessarily provide three independent sources. It may be one event pipeline represented three ways.
The ransomware investigation therefore moves outward.
For the 01:38 event:
- Source one: memory contains the model request and response.
- Source two: proxy and DNS records independently establish communication with the model service.
- Source three: provider-side records confirm the transaction.
- Source four: EDR records execution of the resulting command.
- Source five: PowerShell and host telemetry record the effects of that command.
The evidence now supports more than the statement that an AI service was contacted. It supports a sequence. Model queried. Response returned. Command created. Command executed. System state changed.
For the data-selection activity, investigators similarly compare the AI interaction records, orchestration configuration, process execution, file-access records, the temporary classification output, staging records, exfiltration manifests, and network transfer records.
The question is not whether the artifacts tell a plausible story. The question is whether they arise from sufficiently independent evidentiary paths and still tell the same story.
What cannot be corroborated
The phishing email associated with the compromised account is polished. Its grammar is clean. Its language appears tailored to the employee. None of that proves it was generated by AI. The attacker may have written it. A template may have been used. A translation service may have assisted. A language model may have produced it. Marrowfield has no access to the attacker's pre-compromise AI interactions. The proposition remains unresolved.
The ransom note states that the attackers used an AI system to assess Marrowfield's ability to pay. The demand closely resembles the organization's cyber insurance limit. Investigators know the insurance documentation was among the exfiltrated material. They do not possess evidence showing how the ransom amount was calculated. The ransom note is an attacker statement. It is not independent evidence of the process used to establish the demand. That finding also remains unresolved.
This illustrates a limitation that is likely to become common.
AI-assisted malware is not necessarily AI-attributable malware.
A model can help an attacker create an exploit, phishing message, loader, or ransomware binary entirely outside the victim environment. The resulting artifact does not automatically reveal how it was produced. Code style is not enough. Comments are not enough. Sophistication is not enough. Apparent AI characteristics are not enough.
PROMPTLOCK is the public version of this problem. Competent researchers examined a real artifact and inferred an active adversary. The inference was reasonable, and it was wrong. Apparent AI characteristics supported a story the evidence did not establish. Where the evidentiary trail ends, the conclusion has to end with it.
Phase 4: Analyze
Traditional ransomware reconstruction usually produces an intrusion timeline. In this investigation, a second timeline is needed.
The intrusion timeline
- 01:17: Valid remote-access credentials used.
- 01:34: Suspicious executable launched.
- 01:38: Domain reconnaissance begins.
- 01:44: Privilege escalation activity observed.
- 01:52: Data-identification activity begins.
- 02:03: Selected files staged.
- 02:08: External transfer begins.
- 02:16: Lateral ransomware deployment begins.
- 02:21: Encryption begins across multiple systems.
The AI interaction timeline
- 01:38:11: Model request transmitted.
- 01:38:13: Model response received.
- 01:38:16: Resulting command executes.
- 01:52:07: Data-classification request transmitted.
- 01:52:11: Model classifications returned.
- 01:52:15: Matching files enter the staging queue.
- 01:53 onward: Additional batches are classified and staged.
Overlaying the two timelines lets the investigation ask a better question than whether AI was used. Where did AI materially alter the attack sequence?
The evidence supports two points of contribution. AI generated a reconnaissance command. AI also classified victim data within an automated workflow that used the returned classifications to trigger file staging. There is no equivalent evidence that the model selected Marrowfield as a target, determined that ransomware should be deployed, selected the attack objective, or decided when encryption should begin.
Those distinctions affect how the AI role should be classified. Version 1.2 distinguishes AI that is merely present from AI-assisted, AI-orchestrated, and claims of autonomous AI activity. The two contributions here are not equivalent, and the classification should reflect that.
The reconnaissance step is a single request, a single response, and one executed command. The model produced output that a script then used once. That is an AI-assisted role.
The data-selection step goes further. A human-configured orchestration component repeatedly submitted victim data for classification and used the model's returned classifications to trigger file staging. The model's classifications drove a coordinated, multi-step workflow that a human had configured, rather than producing a single reusable command. For that bounded portion, an AI-orchestrated role is supported.
Neither finding establishes more. Describing the whole intrusion as an autonomous AI ransomware attack would overstate the record at every one of those boundaries.
Phase 5: Adjudicate
The investigation now reaches the human decision gate. The evidence can be classified.
Known
The compromised system communicated with an external language model during the ransomware intrusion. Support basis: endpoint evidence, proxy telemetry, and provider-side records.
The model generated a command that was subsequently executed on the compromised endpoint. Support basis: recovered request and response material, provider records, process ancestry, and PowerShell execution telemetry.
Model classifications triggered the staging of files subsequently exfiltrated. Support basis: AI interaction records, orchestration configuration, process execution, classification output, file-system activity, staging artifacts, exfiltration records, and network telemetry.
Encryption was performed by ransomware deployed across compromised systems. Support basis: endpoint, file-system, and malware evidence.
Assumed
The attacker controlling the ransomware infrastructure also controlled the credentials used to access the external model service. The evidence links the infrastructure and activity operationally but does not uniquely identify the natural person controlling each component.
Undetermined
- Whether AI was used to create the original phishing message.
- Whether AI was used to develop the initial malicious executable.
- Whether AI helped identify Marrowfield as a target.
- Whether AI was used to calculate the ransom demand.
- Whether a model independently selected any strategic objective in the operation.
- Whether AI conducted any material portion of the operation without human control.
- Whether one natural person controlled every attacker account, API credential, and infrastructure component observed during the intrusion.
These are not gaps to be quietly removed during report writing. They are findings about the limits of the available evidence.
Phase 6: Report
The initial incident description was:
Marrowfield suffered an AI-powered ransomware attack.
The forensic finding is different:
The evidence establishes that ransomware operators compromised Marrowfield Industrial Group and used an external language model during portions of the intrusion. Endpoint, network, and provider-side records establish that malware queried the model for a domain-reconnaissance command and subsequently executed a command materially corresponding to the returned response. Independent endpoint, configuration, and file-system records further establish that a human-configured orchestration component used model classifications to trigger the staging of sensitive information later exfiltrated. The reconnaissance interaction supports an AI-assisted role. The data-selection interaction supports an AI-orchestrated role for that bounded portion of the intrusion.
The evidence does not establish that AI selected Marrowfield as a target, independently determined the objectives of the attack, initiated ransomware deployment, calculated the ransom demand, or operated the campaign without human control.
Evidence available within the victim environment is insufficient to determine whether AI was used in the creation of the original phishing material or development of the initial malware.
The finding is narrower than "AI-powered ransomware." It is also more useful. It tells the organization where AI entered the attack chain and where the evidence stops.
The incident-response problem and the forensic problem are different
Ransomware creates an immediate operational problem: stop encryption, contain lateral movement, protect unaffected systems, disable compromised accounts, preserve critical services, and recover.
The current NIST Ransomware Risk Management profile treats ransomware risk across governance, identification, protection, detection, response, and recovery, while SP 800-61 Revision 3 integrates incident response throughout the broader cybersecurity risk-management process.
The forensic problem continues alongside that response. How did access occur? What did the attacker do before encryption? What information left? What accounts were compromised? What persistence remains? What role did AI actually play? And what does the evidence permit the organization to tell executives, insurers, regulators, customers, law enforcement, or a court?
Containment and reconstruction cannot be treated as separate activities, because some evidence disappears while the incident is being contained. Memory is volatile. Logs roll over. Temporary scripts disappear. API records may have short retention periods. Processes terminate. Cloud infrastructure changes.
AI interactions create an additional problem, because portions of the relevant execution may be transient by design. A prompt may never be stored locally. A response may exist briefly in memory. Generated code may execute and disappear. A model may change. An API account may be disabled. Provider retention may expire.
The investigation conducted three weeks later depends on preservation decisions made during the first few hours.
This is where forensic readiness changes
Traditional ransomware readiness asks whether an organization can detect, contain, and recover from ransomware. AI-enabled ransomware adds another question. Could the organization reconstruct AI-mediated activity if it occurred during the intrusion?
That requires thinking about evidence before the incident. Organizations should consider whether they retain sufficient:
- endpoint process and parent-child telemetry;
- PowerShell and scripting records;
- DNS, proxy, and outbound connection metadata;
- cloud and identity audit records;
- memory-acquisition capability;
- network security telemetry, and centralized logs held outside compromised systems;
- accurate and consistent timestamps;
- local AI-model and AI-CLI artifacts where such tools exist internally;
- approved AI gateway and enterprise AI activity records;
- service-account and API-token activity;
- agent or automated-tool execution logs; and
- records of consequential automated containment actions taken by defensive systems.
Where an external AI provider becomes relevant to an intrusion, the response plan should also establish how provider evidence will be identified, preserved, and lawfully requested.
The organization may never receive every record. The point of readiness is not perfect reconstruction. It is preventing avoidable evidence loss from deciding the investigation before it begins.
The defender's AI creates another evidentiary layer
The attacker may not be the only party using AI. The SOC may use AI to summarize alerts, generate queries, correlate activity, explain scripts, or recommend containment. An automated system may isolate endpoints, revoke credentials, or terminate processes. That can improve response speed. It can also alter the evidence being investigated.
For the defender's investigative process, the Zemi principle remains: AI-assisted, never AI-decided.
An AI-generated incident summary is not a finding. A model's assertion that two events are related does not make them related. A generated timeline must still trace to the underlying timestamps and artifacts. A containment recommendation must remain distinguishable from the action actually taken. When automated defensive actions alter the environment, those actions become part of the incident record.
The investigation may therefore contain two AI action chains. One belongs to the attacker. The other belongs to the defender. Both need provenance.
The defensibility check
Before the final ransomware findings leave the investigation, the record should survive a basic challenge. Was authority established for every material source examined? Were claims about AI framed as propositions rather than assumptions? Was the underlying evidence preserved and tested against independent endpoint, network, cloud, or provider evidence? Were execution and causation kept separate, and was AI involvement distinguished from autonomous objective selection? Were attacker statements treated as claims rather than facts? Were alternative explanations tested? Were Known, Assumed, and Undetermined findings separated? Could another competent examiner reconstruct the finding from the preserved evidence? Did a human adjudicate the conclusion?
The Zemi Method's standing defensibility check requires a finding that fails an applicable test to return to the phase where the evidentiary weakness arose. That becomes valuable when AI is involved, because AI introduces a temptation to explain gaps with plausible narratives. Plausibility is not corroboration.
What actually changes
AI does not invalidate digital forensics. The fundamental discipline is stable. Preserve the evidence. Establish provenance. Test competing explanations. Corroborate across independent sources. Separate observation from inference. Keep attribution proportional to what the evidence can establish. State where the record ends.
What changes is the distance between the malicious executable and the behaviour the investigator needs to explain. A conventional malware sample may contain much of the logic required to understand what it can do. AI-mediated malware can move portions of that logic elsewhere: into an API, a prompt, model context, dynamically generated code, an orchestration layer, or memory that disappears when the process ends.
The evidence surface has expanded. The attacker may still leave a ransomware binary behind, but the binary may no longer tell the entire story. The investigation has to reconstruct the interaction around it.
That is the emerging forensic problem. And it is why the question for ransomware investigators is no longer whether AI was involved.
The better question is: what can the evidence establish that AI actually did?