How to use Codex to extract malware evidence
Codex produced malware assessments and evidence-backed IOC artifacts in FLARE-VM. Incomplete strings stayed labelled; execution required engineer approval.
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
Run static-only triage in this analysis VM: collect hashes, file types, strings and packing evidence, then produce an IOC table and YAML with exact local evidence lines. Label uncertain or malformed strings without enrichment or guessing. Pause for engineer approval if executing a sample becomes necessary.
Reach people exploring AI agents
See placements →What happened
Static reports, packing assessments and IOC table/YAML artifacts were produced across four samples. Uncertain strings remained labelled, and dynamic execution required approval.
Reported by Joshua McKiddy — Personal research blogHow the agent did it
- McKiddy selected four samples and ran static hashes, type and strings checks in FLARE-VM.
- Codex produced packing assessments and evidence-backed IOC table and YAML outputs.
- The workflow labelled incomplete strings and paused when execution would require engineer approval.
Where a person stepped in
McKiddy selected samples, kept analysis static, reviewed artifacts and required engineer approval before any controlled execution.
Joshua McKiddy used Codex skills for defensive reverse-engineering triage in a FLARE-VM environment. He tested two playbooks across four malware samples: one produced a packing assessment and unpacking plan, while the other produced an evidence-backed IOC table and YAML artifact.
The first runs gathered hashes, file types and strings before searching for candidate indicators. Tool availability, Windows quoting and fragile one-line commands caused problems, so McKiddy refined the workflow toward simple searches and predictable artifacts. Every retained indicator needed an exact local evidence line.
That boundary mattered when certificate URLs appeared with trailing junk. The output labelled incomplete or uncertain strings instead of guessing clean endpoints or enriching them from outside sources. Packing assessment also separated statically understandable samples from one that required further investigation.
The unpacking playbook paused if execution became necessary, leaving the engineer to approve a controlled next step. The result was repeatable static reports and structured evidence, not automatic detonation or completed unpacking of every sample. McKiddy describes portability and consistent handoff artifacts as the improvement, with analyst review and explicit gaps remaining part of the workflow.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: Personal research blog · Joshua McKiddy
Frequently asked questions
Were malware samples detonated?
The reported workflow stayed static unless an engineer approved controlled execution.
What backed each indicator?
An exact line from local strings or other collected evidence.
What improved through iteration?
Tool portability and predictable report artifacts rather than a claimed intelligence score.
More details
About this account
McKiddy selected four samples and ran static hashes, type and strings checks in FLARE-VM. Codex produced packing assessments and evidence-backed IOC table and YAML outputs.
Original post and primary date metadata opened. Four samples were analyzed statically; incomplete or certificate-related strings were labelled rather than promoted to confirmed malicious endpoints. No detonation or complete unpacking is claimed. Suggested prompt written by Agents In Use; no original task prompt was published in the verified account.
Credit: Joshua McKiddy — Personal research blog
Source published 15 Feb 2026
Source checked 14 Oct 2026
Tools and topics
Codex · FLARE-VM · FLOSS · capa · strings.exe · PowerShell
Defensive triage · Evidence artifacts
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.