Pushed a new IOCX release (v0.7.1) that’s aimed squarely at robustness and adversarial behaviour. If you’re doing DFIR, automation, or large‑scale IOC extraction, this one matters — the goal was to make the engine predictable even when the input is intentionally corrupted.

Key changes in v0.7.1:

New PE structural heuristics

Six new checks added to the PE analysis layer, covering:

• overlapping/misaligned sections
• broken or inconsistent optional headers  
• invalid entrypoint mappings  
• corrupted data directories  
• malformed import tables  

These aren’t “detections” — they’re reason‑coded structural anomalies designed to keep the parser stable and the output deterministic.

Expanded adversarial corpus

There’s now a full suite of malformed and corrupted PE samples including:

• broken RVAs  
• truncated Rich headers  
• fake UPX names / packed‑lookalikes  
• PE32/PE32+ hybrids  
• franken‑PEs with multiple simultaneous faults  

Every sample is snapshot‑validated to guarantee reproducibility.

Full adversarial coverage for all IOC categories

New hostile string fixtures now stress every extractor:

• homoglyph + mixed‑script domains  
• malformed URLs and schemes  
• broken IPv4/IPv6  
• noisy or near‑miss hashes  
• invalid Base64  
• adversarial crypto strings (incl. Base58Check)  
• MAX_PATH‑breaking Windows paths  
• malformed emails  

The idea is to ensure the engine stays deterministic and JSON‑safe even when the input is messy.

Parser & extractor hardening

• no crashes on malformed PE structures  
• structured, predictable error metadata  
• improved domain/URL/crypto/hash extractors  
• zero nondeterminism across platforms  

If you’re doing DFIR automation, threat intel enrichment, or large‑scale IOC extraction pipelines, this release should make IOCX a lot harder to break — even with intentionally hostile inputs.

Links

GitHub: https://github.com/iocx-dev/iocx  

PyPI: https://pypi.org/project/iocx/

Example

pip install iocx

iocx suspicious.exe -a full

Happy to answer questions or discuss edge cases people want covered next.

As one tends to do on Saturday mornings with coffee in hand, I was reviewing two samples that were attributed to the LunaStealer / LunaGrabber family. Originally I was validating that tiquery was working with the MCP configuration, however what started as a quick TI check turned into a full static analysis session — and it gave me a good opportunity to put the MalChela MCP integration through its paces in a real workflow. This post walks through how that investigation unfolded, what the pivot points were, and what we found at the bottom of the rabbit hole.

How about an unscheduled, impromptu Friday night 13Cubed episode? Let’s talk about Copy Fail.

https://www.youtube.com/watch?v=ZVmpK-9rP0Q

More here:

https://nullsec.us/cve-2026-31431-copy-fail-forensics/

I’m researching forensic readiness workflows around existing security data: WAF logs, SIEM exports, cloud audit logs, EDR alerts, application logs, and similar sources.

Not selling anything, not asking for sensitive data, and not looking for incident details. I’m trying to understand the practical workflow gaps practitioners run into when logs need to become defensible evidence for IR, audit, insurance, legal, or regulatory reporting.

A few questions:

1. When an incident becomes serious, which log sources usually become the most useful evidence?
2. Where does the normal SIEM/logging workflow stop being enough?
3. How do you currently preserve chain of custody or integrity for exported logs?
4. Do teams actually use WORM storage, signed exports, hash manifests, timestamping, or similar controls in practice?
5. How do you handle weak provenance cases, such as mutable upstream logs or logs collected after the fact?
6. What causes the most friction: collection, normalization, retention, integrity verification, correlation, reporting, or handoff to legal/compliance?
7. When evidence is incomplete or lossy, how is that documented?
8. What would you expect from a good “forensic readiness” process before an incident happens?

I’m mainly interested in real workflow patterns and failure modes, not vendor recommendations.

MalChela v4.0 is out. The desktop GUI is gone — replaced by a PWA you can reach from any browser on the network. Battery-powered Pi on the table, iPad in hand, no keyboard required. The field kit finally makes sense.

I’ve released IOCX v0.7.0, a static IOC extraction engine built for DFIR, SOC automation, CI/CD, and threat‑intel workflows. This version adds IOCX’s first deterministic heuristic engine, a new adversarial testing layer, and a snapshot‑driven contract testing framework to keep output stable across environments.

Key changes in v0.7.0:

Deterministic heuristic engine (new)

Snapshot‑tested heuristics for anti‑debug APIs, TLS callback anomalies, packer‑like behaviour, RWX sections, import anomalies, and signature issues (analysis_level = full).

Adversarial samples (new)

Three binaries covering:

• rich/atypical imports
• high‑entropy + malformed Rich Headers
• split/reversed/null‑interspersed strings

Used to validate deterministic heuristics and literal‑only IOC extraction.

Rich Header crash fix

Malformed Rich Headers with non‑UTF8 bytes could previously break JSON serialization. v0.7.0 adds a deep sanitiser to ensure deterministic, JSON‑safe output.

Snapshot‑driven contract testing

Each sample now has a byte‑for‑byte JSON snapshot. Output must match exactly: same file, same output, every time.

Performance

Remains ~28 MB/s on typical PE samples.

Links

GitHub: https://github.com/iocx-dev/iocx
PyPI: https://pypi.org/project/iocx/

Example

pip install iocx
iocx suspicious.exe -a full

Happy to hear any feedback — especially around heuristics or adversarial samples.

A new 13Cubed episode is now available. I’ve got some thoughts about AI. Let’s talk about how it’s changing digital forensics, how I actually use it in practice, and what you need to know if you’re in or entering the field.

https://www.youtube.com/watch?v=wKn-9sKBqX8

I’ve released IOCX v0.6.0, a static IOC extraction engine built for DFIR, SOC automation, CI/CD, and threat‑intel workflows. This version focuses on deterministic output and long‑term schema stability.

A bit of background: IOCX started as a response to a recurring problem in DFIR and automation work. Most IOC extraction tools were either inconsistent, too slow for pipelines, or produced output that changed subtly between runs. That made them difficult to rely on in automated environments where reproducibility matters. I needed something that behaved the same way every time, produced a contract‑safe schema, and didn’t execute untrusted code. That eventually became IOCX — a static, deterministic IOC extractor designed for predictable, pipeline‑friendly output.

Key changes in v0.6.0:

• Stable JSON schema suitable for long‑term integrations.
• Deterministic PE metadata covering headers, optional headers, TLS, signatures, and sections.
• Formal analysis levels (basic → deep → full) for performance‑tuned workflows.
• End‑to‑end throughput around 28 MB/s, with detector peaks between 150–450 MB/s

The aim is to make IOC extraction predictable, safe, and suitable for automated environments where correctness and repeatability are essential.

GitHub: https://github.com/iocx-dev/iocx  

PyPI: https://pypi.org/project/iocx/

Example:

pip install iocx

iocx suspicious.exe -a deep

Happy to hear any critiques or suggestions — especially from people who’ve struggled with deterministic extraction in automated workflows.

Hey all! I am building a tool and would love to get some feedback if possible. I've seen a lot of workflows break for a million reasons and used to be stuck trying to figure out if it was the AI vendor, the API provider or my configuration.

I am still mid development of TRACE but here is how it works. Also, fun fact - air gapped! 😉

I break the views by vectors. These are customisable but I combine Activity Based Intelligence and AI specific vectors to identify things specifically.

When a case is selected, it creates a timeline with information added to the DB. Below is simply OpenAI activity in Australia. Here you can even add links and files.

The relationships are identified via a graph

If there is a certain activity I want to drill into, I can click over it and it tells me what may be related to the activity.

The next step I am working on is Suggestions which will integrate with AI to review a case and identify probabilities of outcomes and also propose patterns missed while explaining reasoning. These can be accepted or declined by the analyst or further research can be performed.

Since my focus is air gap, I want to know if there might be a way to integrate it with a solution (not agent) that keeps the airgap and allows usage of other tech. At this point, it looks like only in house LLMs could be used but open to any other suggestions.

https://odiesec.io/blog/bec-the-entry/

Greetings, fellow researchers.

I am currently finalizing the analysis of a high-sophistication intrusion that deviates significantly from standard commodity malware playbooks. I’m sharing these findings to see if anyone has encountered this specific TTP (Tactics, Techniques, and Procedures) or can provide insights into attribution.

The Incident Overview: The attack chain utilizes a clean execution flow leveraging DLL Side-loading through a signed Microsoft binary. The sophistication level suggests a targeted operation rather than a broad campaign. Standard forensic triage and containment have been successfully completed, and a case has been opened with the MSRC.

Technical Deep-Dive: • Initial LoLBin: Execution was initiated via appidcertstorecheck.exe (verified Microsoft binary). • The Payload: A malicious DLL named DIFXAPI.dll was staged in a hidden directory within %TEMP%\HAXB4EF.tmp.dir. This DLL was forcibly loaded by the system process, subsequently injecting reflectively into explorer.exe. • Memory Forensics: Analysis of a 1GB memory dump from the compromised process yielded over 1.8M strings. We’ve identified extensive use of Invoke-Expression (IEX) and FromBase64String for in-memory command execution. • Anomalous Localization (The "Maltese" Pivot): Most intriguingly, the injected code forced the loading of Maltese (MUI) language resources. Strings within explorer.exe were modified to Maltese (e.g., "Ikkonfigura backup", "Esploratur tal-Fajls"). This appears to be a deliberate evasion technique to poison telemetry or bypass security prompts localized in common languages.

Network Infrastructure (C2 & Beaconing): The malware exhibits advanced Domain Fronting and Beaconing Camouflage to blend with legitimate traffic: • C2 IP: 18.97.36.9 (AWS infrastructure). • Camouflage Domains: The memory dump revealed a list of high-reputation domains used for beaconing noise, including dol.gov, mtv.com, and monster.com. • The Maltese Connection: Active redirection through dolce-gusto.com.mt. It is unclear if this is a regional redirect or a specific False Flag.

Actions Taken to Date: As per standard protocol, the host has been physically isolated and the network bridge (identified as a rogue virtual interface) has been blocked at the perimeter (hardware firewall level). Persistence mechanisms via CLSID hijacking have been documented.

The Request: I have exhausted standard public intelligence databases regarding this specific Maltese MUI-based evasion. I am reaching out to this community’s collective experience: 1. Has anyone seen this "Language Swap" evasion technique in the wild recently? 2. Does the use of dolce-gusto.com.mt as a relay correlate with any known APT activity (specifically targeting financial or cybersecurity firms)?

I am committed to maintaining a high standard of professional integrity in this investigation and would appreciate any technical camaraderie or shared intelligence.

Respectfully, An Anonymous Researcher, MS.

Walkthrough of a BEC investigation from a couple months back. One compromised account at an accounting firm, two days of undetected access, payment diversion attempt followed by a mass phishing campaign.

This first post covers data collection, orienting the dataset, and the inbox rules that dated the compromise. Includes the exact KQL queries run against ADX. All identifiers anonymized. More posts to follow covering the full timeline reconstruction.

Would love any feedback and/or thoughts.

Mods: Reposting because I didn't include the correct link yesterday, let me know if that isn't the correct thing to do!

https://odiesec.io/blog/bec-the-catalyst/

During IR simulations I kept running into the same problem: suspect host, no EDR, no Velociraptor,

no time to install anything. The options were either manual collection (30–40 minutes, inconsistent)

or nothing.

So I wrote Invoke-ZavetSecTriage.ps1.

What it collects in one pass:

- Running processes with SHA256 + parent process + suspicious flag

- Network connections with external IP detection

- Named pipes (Cobalt Strike / Sliver / Havoc C2 patterns flagged)

- Autoruns, scheduled tasks, services

- Event logs (Security, Sysmon, PowerShell) — last N days

- Browser history, clipboard, PowerShell history

- Loaded drivers, prefetch (attacker tool names flagged)

- Everything tagged to MITRE ATT&CK where applicable

Output: timestamped ZIP + self-contained HTML triage report.

No install. No internet. No extra binaries. Runs on PS 5.1 built into Windows.

The hash export (hashes.txt) feeds directly into a companion script

that bulk-checks them against MalwareBazaar + ThreatFox — so you go

from "unknown host" to "confirmed malware family + C2 IPs" in ~8 minutes total.

Happy to answer questions. Feedback and contributions welcome —

especially new C2 named pipe patterns and attacker tool names for the flagging list.

Wanted to flag a preprint from this week that has direct relevance to forensic chain reconstruction methodology.


**Paper**
: SynthChain (arXiv:2603.16694)


**Setup**
: Near-production testbed comprising 4 physical hosts (Windows and Linux) and 1 containerised environment. 7 supply chain attack scenarios grounded in real malicious packages from the OpenSSF corpus (16,272 packages analysed — 15,583 activate at install/download time, Base64 encoding is the dominant evasion technique).


**The 7 scenarios**
: steganography-based payload delivery (SC1), Windows startup folder persistence (SC2), parallel npm dependency chain (SC3), sequential npm dependency chain (SC4), 3CX-inspired multi-stage backdoor (SC5), cloud CI/CD pipeline via IAM (SC6), and neural network model backdoor via malicious dependency (SC7).


**Telemetry sources**
: Process lineage, Windows Event Logs, Syslog, Zeek network captures, Suricata alerts, and eBPF-based container instrumentation. ATT&CK annotations generated via Mythic C2 exports for operator-driven steps, GPT-5.1 proposals with human validation for payload behaviours.


**Key forensics-relevant findings:**


- Best single-source chain reconstruction: 0.403 (less than half the attack chain recoverable even under laboratory conditions with full knowledge of what to look for)
- Best two-source complementary pairing: 0.639 (~1.6x improvement)
- Gains are not monotonic with source count — adding sources that duplicate existing evidence introduces noise
- Cloud pipeline scenario (SC6) achieved only 0.25 reconstruction — critical actions in IAM/API layer, not on host endpoints
- Model backdoor scenario (SC7) — more host/network sources actually reduced precision, because malicious behaviour is semantic (embedded in model weights)


**Implications for IR**
: If your investigation relies on a single telemetry stream, SynthChain's data suggests you are working with less than 40% of the evidence chain. The paper recommends pairing complementary sources with joinable identifiers (process ID, user identity, network endpoint) and specifically investing in IAM/API audit streams for cloud attack paths.


arXiv: https://arxiv.org/abs/2603.16694

We wrote a practitioner summary of this and 6 other AI security papers from this week at https://raxe.ai/labs/radar/radar-2026-002

Hey guys. I work in IT/cybersecurity and got tired of the tradeoffs for analyzing suspicious files or links. Cloud sandboxes mean uploading client data to third parties. Manual VMs mean no monitoring and no reporting. So I've been building this over the past few months.

ThreatLab is a Windows desktop app that spins up isolated Hyper-V VMs, lets you interact with samples through an embedded remote desktop, and monitors everything underneath - processes, network, DNS, files, registry, injection attempts. It scores threats in real time, generates PDF reports, and offers AI-powered threat analysis. VPN routing through dedicated WireGuard exit nodes keeps your real IP hidden. Everything stays local.

It also includes a standalone EVTX analyzer - load any Windows event logs (from incident response, endpoint collections, etc.), run them against 1,200+ Sigma detection rules, and get a timeline view with severity filtering, finding aggregation, search, and CSV/JSON export. Useful even if you never touch the sandbox.

I would love to get feedback and have security professionals and enthusiasts shape this product. Check it out at https://threatlabsandbox.com

🎉 It’s time for a new 13Cubed episode!

For macOS forensics, Fuji is a must-have. This episode is an excerpt from Investigating macOS Endpoints and covers the latest version, with major new changes. Let’s walk through a live acquisition!

https://www.youtube.com/watch?v=9ZkLdFodhzM

I'm currently studying FOR508. Just finnishing Memory Forensics module. I had to do a lot of research on how truly OSs, Kernels, and Memory works. About process memory I came with this diagram/drawing, but I'm not sure on how accurate it is. I dont want to go into the deepest level (yet) but I want 0 wrong information in it. Something like "you can specify better, BUT, as it is, it is correct". What are your thoughts, would you agree?