With the v4.5 release, MalChela now runs natively on Windows. Previously, Windows users were limited to running it under WSL. The PWA interface was reachable from Windows, so driving the GUI was easy enough, but everything underneath still lived in Linux. If you’re a native Windows user, you can now skip WSL entirely and get the same toolset, CLI and web interface, that runs on macOS and Linux.
Getting started on Windows
You’ll need Rust with the MSVC toolchain (rustup will prompt you for the Visual Studio C++ build tools), Git, and Python 3 for the web interface. From the MalChela folder in PowerShell or cmd, run .\release.ps1 (or release.cmd) to build, then server\start_server.cmd to launch the PWA. The first run sets up the Python environment for you, and no server config file is needed to get going. Full details are in the native Windows install guide. WSL2 still works if you prefer a Linux environment.
Goodbye YARA, hello yara-x
The biggest hurdle to running natively on Windows was how MalChela was originally built: it required compiling YARA from source. We’ve been moving away from YARA to yara-x, VirusTotal’s rewrite of YARA in Rust, and with this release that migration is complete. yara-x is compiled in as a Rust crate, so there’s no system YARA library to install and no environment variables to point the build at, on any platform. Much of that groundwork came from Daniel Iwugo (@elementmerc), whose PRs built out and hardened the yara-x backend and moved File Analyzer onto it.
If you’re upgrading from v4.3 or earlier, the old YARA, OpenSSL, and GTK packages are no longer used by the build. You can leave them installed, and drop the YARA_LIBRARY_PATH and BINDGEN_EXTRA_CLANG_ARGS exports from your shell profile. One heads-up if you maintain your own rulesets: yara-x is highly compatible with YARA, but not 100%. Some legacy syntax that YARA tolerated will throw errors under yara-x, so it’s worth test-compiling your custom rules after upgrading.
TIQuery updates
Thanks to a PR from Jonas Lejon (@jonaslejon), TIQuery has a new URL source: ScanMalware. It checks ScanMalware’s public scan archive without ever submitting a new scan, and only the host name leaves your machine; the full URL is matched locally, so tokens or email addresses in a phishing link’s query string stay with you.
That addition also led to a rework of how keyless sources (those that don’t require an API key) are handled. Sources that send your lookups to a third party, currently urlscan.io and ScanMalware, are now off until you opt in, so you stay in complete control of your OPSEC and what gets submitted where. Your choice is saved and shared across the CLI, the web interface, and the Claude plugin.
New in v4.5, TIQuery can also download samples from Triage (tria.ge), alongside the existing MalwareBazaar integration. If MalwareBazaar doesn’t have the sample, TIQuery falls back to Triage, verifies the SHA256 against the hash you requested, and wraps it in the usual password-protected zip before anything touches disk. Check out the online documentation for details.
Thank you
In my less-than-humble opinion, MalChela has come a long way since the early days of 2025, but it wouldn’t be where it is without feedback and contributions from the community. A very big thank you to Daniel, Jonas, and everyone who’s participated! If you run into anything on Windows, or have ideas for what’s next, issues and PRs are always welcome on GitHub.
I came home from ATT&CKcon with a full notebook and a head full of technique IDs. So, fair warning: this release is on a bit of a MITRE kick. But it’s not the only thing in here. v4.4 has three headliners: a brand-new unpacker, ATT&CK mapping across the whole toolkit, and a move to YARA-X that makes installing MalChela a lot less painful.
Unpack
This one came straight out of conversations at the conference.
@dwmetz How can I extract the details strings from packed malware sample. Can Malchela support malware unpacked feature?
Up to now the honest answer was “go get another tool.” Not anymore.
Unpack detects packers, installers, and bundlers in PE, ELF, and Mach-O files and pulls out the payload statically. It never runs the sample. Every call it makes comes with the evidence behind it, and anything it recovers goes right back through Unpack again, so a dropper inside an installer inside a UPX stub comes out as a layer tree instead of just the outer shell.
UPX, including the mangled headers Mirai and friends use to make upx -d give up. Unpack repairs a working copy and records every byte it touched.
PyInstaller, and then it keeps going into the Python bytecode itself (3.7 through 3.14), peeling off the obfuscation wrappers stealers love: xz, zlib, base64, rot13, the works. The strings land in mStrings automatically.
.NET / Costura resources, NSIS, Inno Setup, fat Mach-O, overlays, and executables embedded in other executables.
Point Analyze at a packed sample and Unpack kicks in on its own. Everything it recovers gets the full MalChela treatment. Running a LunaGrabber build through it was a good test: an obfuscated entry script three layers deep, and out came the Discord webhook it exfiltrates to.
MITRE All the Things
Between Unpack, the Mac tools, File Miner, and Analyze, a single run can turn up ATT&CK findings from a dozen files and half a dozen tools. Reading those as a list gets old fast. So now every Analyze run plots them on the Enterprise matrix.
Tiles are shaded by how many files hit them. Click one and you get the evidence: which rule, which tool, which file, and the strings that matched.
Open the matrix for any saved case, and it pulls in every Analyze run and every standalone tool report in that case. Older cases work too.
Every run also saves an ATT&CK Navigator layer, so you can take it straight into Navigator.
Everything is on ATT&CK v20: Stealth and Defense Impairment instead of the retired Defense Evasion, and revoked techniques remapped.
Click a technique ID in mStrings and the built-in MITRE Lookup opens right there. (Cmd/Ctrl-click still takes you to attack.mitre.org.)
YARA-X
If you’ve ever installed MalChela on a Mac, you know the dance: brew install yara, then export YARA_LIBRARY_PATH, then BINDGEN_EXTRA_CLANG_ARGS, then hope. That’s all gone. Every MalChela tool now runs on YARA-X, VirusTotal’s Rust rewrite of YARA, compiled right in. No libyara, no bindgen, no OpenSSL. On Linux the prerequisites are now build-essential and pkg-config. On a Mac it’s the Xcode command line tools.
It also clears the biggest roadblock to running MalChela natively on Windows. WSL2 is still the supported route for now, but native Windows testing is next on my list.
A huge thank-you to Daniel Iwugo (@elementmerc), who did the groundwork on the new YARA backend and closed the gaps between it and libyara. This is what open source is supposed to look like.
YARA Scan
With the engine built in, it would have been silly not to expose it. YARA Scan is a new tool for running your own rules against a file or folder, and it speaks the same language as VirusTotal’s yr scan: same flags, same output. I tested it side by side with yr on the full signature-base rule set and got identical results. It saves reports to your case, and there’s a simplified panel in the web interface. For the deeper yr features like compiled rules and module data, the YARA-X integration is still there.
IP Reputation and GreyNoise
Threat Intel Query now looks up IP addresses on VirusTotal, AlienVault OTX, and, new in this release, GreyNoise. There’s a new IP tab, and defanged input is fine. The part I like best: an IP being “found” doesn’t mean much on its own, since 8.8.8.8 is in every source there is. So instead of FOUND, each source tells you what it actually concluded: flagged, clean, a known benign service, or a scanner. Analyze runs the same lookups on the IPs it finds.
mStrings got smarter about IPs too. When dozens of addresses are stored together, like a sandbox blocklist or a C2 pool, they’re reported as one list instead of fifty separate “C2” hits.
Odds and Ends
The Analyze summary now follows the structure of Lenny Zeltser’s Malware Analysis Report template, and the template is built into the MCP plugin, so Claude can write the full report and save it to your case.
mStrings recognizes encoded string tables. AMOS keeps its whole AppleScript as about 1,900 encoded strings; now you get one clear finding instead of a wall of matches.
The API Keys panel has a slot for GreyNoise, and At a Glance counts all 21 tools.
The docs and the PDF user guide are up to date, with new pages for Unpack and YARA Scan.
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.
The Setup
If you haven’t seen the MalChela MCP plugin before, the short version is this: MalChela is a Rust-based malware analysis toolkit I’ve been building for a while — tools like tiquery, fileanalyzer, mstrings, and others. The MCP server exposes all of those tools to Claude Desktop natively, so instead of dropping to the terminal for every command, I can run analysis steps conversationally and let Claude help interpret the results and suggest next moves.
This is not replacing the terminal — it’s augmenting it. The pivot decisions still come from the analyst. But having a reasoning layer that can look at mstrings output and say “that SetDllDirectoryW + GetTempPathW combination is staging behavior, and here’s the ATT&CK mapping” is genuinely useful when you’re moving fast.
Both samples were sitting in a folder on my Desktop. I had SHA-256 hashes. Let’s go.
Phase 1: Threat Intelligence Query
First move is always TI. The MalChela tiquery tool hits MalwareBazaar, VirusTotal, Hybrid Analysis, MetaDefender, and Triage simultaneously and returns a combined results matrix. Two calls, two answers.
Sample 1 (4f3b8971...) came back confirmed LunaStealer across all five sources. First seen 2025-12-01. Original filename sdas.exe. VT tagged it trojan.generickdq/python — already telling us something about the build.
Sample 2 (d4f57b42...) was more interesting. MalwareBazaar returned both LunaGrabber and LunaStealer tags. Triage clustered it with BlankGrabber, GlassWorm, IcedID, and Luca-Stealer. The original filename was loader.exe. That’s a different kind of name than sdas.exe. One sounds like a throwaway test artifact. The other sounds deliberate.
The TI results alone suggested these weren’t just two copies of the same thing. They were potentially different components of the same campaign.
Phase 2: Static PE Analysis
fileanalyzer and mstrings on both samples.
The first thing that jumped out was the imphash — f3c0dbc597607baa2ea891bc3a114b19 — identical on both. Same section layout, same section sizes, same import count (146), same 7 PE sections including the .fptable section that PyInstaller uses for its frozen module table. These two samples were compiled from the same PyInstaller loader template with different payloads bundled inside.
But the entropy diverged sharply. Sample 1 (sdas.exe) came in at 3.9 — low, even for a PyInstaller bundle. Sample 2 (loader.exe) was 6.9 — high, indicating the embedded payload is compressed or encrypted more aggressively. Combined with the file size difference (47 MB vs 22 MB), this was the first signal that what was inside each bundle was meaningfully different.
mstrings gave us 22–23 ATT&CK-mapped detections across both samples — largely the same set: IsDebuggerPresent, QueryPerformanceCounter, SetDllDirectoryW, GetTempPathW, ExpandEnvironmentStringsW, OpenProcessToken. Standard infostealer staging behavior. Tcl_CreateThread showed up in both, which is a PyInstaller artifact from bundling Python with Tkinter. The VT python family tag made more sense in context.
Phase 3: PyInstaller Extraction
Both samples were extracted with pyinstxtractor-ng. This is where the two samples started to diverge clearly.
Sample 1 entry point: sdas.pyc — Python 3.13, 112 files in the CArchive, 752 modules in the PYZ archive.
The name cleaner.pyc inside a file called loader.exe is a tell. That’s not a stealer payload name. That’s something that runs after.
The bundled library sets were nearly identical between both — requests, requests_toolbelt, Cryptodome, cryptography, psutil, PIL, sqlite3, win32 — same stealer framework. But Sample 2 had a unique addition: a l.js reference (mapped to T1059 — Command and Scripting Interpreter). A JavaScript component not present in the December build. The OpenSSL versions also differed: Sample 1 bundled libcrypto-3.dll (OpenSSL 3.x), Sample 2 had libcrypto-1_1.dll (OpenSSL 1.1). Different build environments, roughly one month apart.
At this point the working theory was solid: Sample 1 is a standalone stealer. Sample 2 is a later-generation dropper/installer with an updated payload and additional capability.
Phase 4: Bytecode Decompilation
decompile3 couldn’t handle Python 3.11 or 3.13 bytecode. That’s a known limitation. pycdc (Decompyle++) handles both.
sdas.pyc decompiled cleanly — the import stack made the capability set immediately obvious:
from win32crypt import CryptUnprotectData
from Cryptodome.Cipher import AES
from PIL import Image, ImageGrab
from requests_toolbelt.multipart.encoder import MultipartEncoder
import sqlite3
CryptUnprotectData for browser master key decryption. AES for the decryption itself. ImageGrab for screenshots. MultipartEncoder for structured exfiltration. Classic infostealer, nothing surprising.
cleaner.pyc was a different story. The decompiler output opened with this:
Heavy obfuscation — byte arrays used to reconstruct eval, getattr, and __import__ at runtime so none of those strings appear in plain text. The approach is designed to evade static string detection. Decode the byte arrays and you get:
Standard Python malware obfuscation. But buried further down in the decompile output was a large binary blob — a bytes literal starting with \xfd7zXZ. That’s the LZMA magic header.
Phase 5: LZMA Stage 2 Extraction
The blob was located at offset 0x17d4 in the pyc file. Extract and decompress it:
import lzma
blob = open('cleaner.pyc', 'rb').read()
idx = blob.find(b'\xfd7zXZ')
decompressed = lzma.decompress(blob[idx:])
# → 102,923 bytes
One important detail: the decompression is wrapped in a try/except LZMAError block with os._exit(0) on failure. If the decompression fails — as it would in some emulated sandbox environments — the process exits silently with no error. That’s the anti-sandbox mechanism.
The decompressed payload was another obfuscated Python source using a custom alphabet substitution encoding. The final execution chain was compile() + exec(). Decoding the full stage 2 revealed everything:
This is the live Discord injection payload. The stage 2 pulls this JavaScript file from GitHub and injects it into the Discord desktop client’s core module, persisting across restarts.
The capability set from stage 2:
Anti-analysis checks on startup: process blacklist (~30 entries including wireshark, processhacker, vboxservice, ollydbg, x96dbg, pestudio), MAC address blacklist (80+ VM prefixes), HWID blacklist, IP blacklist, username/PC name blacklists
Discord token theft from all three release channels (stable, canary, PTB)
Browser credential theft across 20+ Chromium and non-Chromium browsers
Roblox session cookie harvesting (.ROBLOSECURITY= targeting with API validation)
The ping delay is a simple trick — the 3-second wait lets the process fully exit before the delete fires, so the file removes itself cleanly after execution.
What MalChela + MCP Added to This Workflow
The honest answer is: speed and synthesis.
tiquery hitting five TI sources in one call versus five separate browser tabs or CLI invocations is a meaningful time saving, but that’s the surface benefit. The deeper value showed up in the mstrings step — getting ATT&CK-mapped output with technique IDs alongside the raw strings meant the behavioral picture came together faster than manually correlating imports against the ATT&CK matrix.
The MCP integration meant each of those steps — TI query, PE analysis, string extraction — could happen within the same conversation context. Claude could see the fileanalyzer output and the mstrings output together and note that the entropy difference between the two samples was significant, that the identical imphash meant shared loader infrastructure, that the staging imports in mstrings were consistent with the exfil approach suggested by the TI tags. That cross-tool synthesis is where the integration earns its keep.
The parts that still required manual work: pyinstxtractor-ng, pycdc, the LZMA extraction, and decoding the stage 2. Those are terminal steps on the Mac.
If you’re running MalChela in your environment and want to reproduce the TI query steps, the MalChela MCP plugin source is on GitHub at github.com/dwmetz/MalChela. Questions or additions to the IOC list — find me on the usual channels.
One of the things I value most about the open-source community is that the best improvements to a tool often don’t come from inside it — they come from outside conversations. A short while back, the author of mlget, xorhex, reached out and suggested I add more malware retrieval sources to FOSSOR, one of my earlier tools for pulling down samples from threat intel repositories. It was a generous nudge, and it landed at exactly the right moment.
FOSSOR started as a simple script. It did one job — grab malware samples from a handful of sources — and it did it well enough. When I wrote it, I already knew it was a candidate for eventual MalChela integration, but “eventually” had stayed firmly in the future tense. The message from xorhex gave me the push to actually sit down and do it properly.
The result is tiquery — and it’s become a new centerpiece to MalChela 3.2.
The Pattern I Keep Repeating (Deliberately)
If you’ve followed this blog or the MalChela project for a while, you might notice a recurring arc in how my tools tend to develop. It goes something like this:
Step one: write a focused script that solves a specific problem.
Step two: that script evolves into a standalone tool as the scope grows.
Step three: the tool finds its permanent home inside MalChela, where it benefits from the broader ecosystem — case management, the GUI, the MCP server integration, the portable workspace.
Step four: When there’s overlap between tools, follow the KISS principle.
FOSSOR was in step one. The conversation with xorhex accelerated the jump to step three. What emerged was something more ambitious than just a source expansion — it’s a unified threat intelligence query engine, built from the ground up.
If you’re new to MalChela, it’s a Rust-based malware analysis toolkit built for DFIR practitioners — static analysis, string extraction, YARA rule generation, threat intel lookups, network analysis, and now a unified case management layer tying it all together. Free, open-source, and built to run anywhere.
Introducing tiquery
tiquery is now the single threat intel tool in MalChela, replacing the retired malhash. The core idea is straightforward: submit a hash, query multiple sources in parallel, get a clean color-coded summary back. No waiting for one source to finish before the next one starts. No manually juggling browser tabs or API wrappers.
Out of the box, tiquery works with eight confirmed sources:
VirusTotal
MalwareBazaar
AlienVault OTX
MetaDefender Cloud
Hybrid Analysis
FileScan.IO
Malshare
ObjectiveSee (no API key required — queries a locally-cached macOS malware catalogue)
Sources are tiered — free sources and registration-required sources are distinguished in the interface. If you haven’t configured an API key for a given source, tiquery skips it gracefully rather than throwing an error. This means you can run it easily with whatever keys you have available.
The ObjectiveSee integration deserves a special mention. It queries the objective-see.org/malware.html catalogue for macOS-specific threats using a locally-cached copy that refreshes every 24 hours, with a stale-cache fallback for offline use. For anyone doing Mac forensics, this is a meaningful addition — a free, no-key-required check specifically against known macOS malware families.
Tiquery, like FOSSOR, supports batch lookups as well — point it to a .csv or .txt file of hashes and they’ll all be checked in parallel. You can also download samples directly, with MalwareBazaar supported in this release and additional sources on the way – (your vote matters).
What It Looks Like in Practice
The screenshots below show tiquery running in both the CLI and GUI. In both cases, for any of the matching sources you get a basic classification (malware family, tags, detections,) and direct links to threat intelligence documents about the samples. It’s the perfect jumping off point when you want to leverage community research.
The CLI output is clean and tabular — source abbreviation, status (color-coded FOUND/NOT FOUND), family and tag information, detection count, and a direct reference URL. Everything you need to make a quick triage decision, no scrolling through API response JSON required. You can run tiquery CLI as a stand-alone, or from within the MalChela CLI menu.
In the GUI, the experience is layered a bit more richly. You can toggle individual sources on or off, switch between single-hash and bulk lookup modes, download the sample directly from MalwareBazaar, and export results to CSV — all from one interface. The macOS ObjectiveSee source displays its cache age inline so you always know how fresh the data is.
Both outputs feed into MalChela’s case management system. Check “Save to Case” in the GUI, and tiquery creates a valid case.json automatically — no separate case creation step needed.
Extended Case Management Across the Toolkit
Speaking of case management — 3.2 extends “Save to Case” support across the full GUI. File Analyzer, File Miner, and mStrings, all now include the checkbox. This closes out the last gaps in the case workflow. Whatever tool you’re using for a given task, if you want to preserve the output in a named case, it’s one click. You no longer have to start with the New Case workflow, however it is recommended if that’s the direction you’re going from the start.
The Strings to YARA tool also gains a companion “Save to YARA Library” checkbox. Check it, and the generated rule gets copied directly into the project’s yara_rules/ directory alongside being saved to the case. This will automatically make the rule available when you run fileanalyzer on subsequent files. It’s a small workflow improvement, but one that eliminates a manual copy step I was taking every time anyway. I also added a quick formatter so the special character most often in need of escaping “\” gets handled automatically when the rule is generated.
A Note on malhash
malhash is retired in 3.2. If you’ve been using it in scripts or workflows, tiquery is its direct replacement — it does everything malhash did and then some. This is a breaking change in the sense that the binary is gone, but functionally tiquery is a superset, not a lateral move.
malhash served its purpose well. RIP. tiquery is where that purpose lives now.
Get It
MalChela 3.2 is available now on GitHub. The full release notes are in the repo.
Thanks to xorhex for the nudge. Sometimes the best features start with someone saying “have you thought about…”
