MalChela 3.2: More Cowbell? More Intel!

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…”

A Study in DFIR: Open-Source, Enterprise, and the Art of Analysis

Someone asked me recently how I see DFIR evolving — tooling, automation, and open-source versus enterprise platforms. It’s the kind of question that sounds like a conference panel topic, but the answer is grounded in how work actually gets done. In practice, it isn’t a binary choice. The most effective IR practitioners I’ve worked with use a combination of both commercial and open-source tools, depending on the problem in front of them.

Commercial platforms handle workflow and scale. If you’re running incident response across a large enterprise and need to triage at volume, a solid commercial solution carries weight that a collection of scripts can’t. Aggregation, case management, reporting — those layers matter when you’re briefing a CISO at 2am. Open-source, on the other hand, reacts fast. When a new artifact surfaces — a novel malware family, a Windows update exposing a new forensic data source — the OSS community often has something usable before it shows up on a vendor roadmap.

Where this gets more nuanced is support. Some vendors have excellent support — responsive, technically sharp, and genuinely useful when you’re dealing with something unusual. Others offer little more than a ticketing system and a stale knowledge base. Open-source has the same variability, some projects have highly engaged maintainers who respond quickly to well-written issues, while others are effectively one-person efforts maintained when time allows. Neither model guarantees anything.

Cost follows a similar pattern. Open-source tools remove licensing fees, but they introduce operational overhead — staying current, understanding changes, and troubleshooting issues in your own environment. That cost is real, and it tends to stay invisible until something breaks at the wrong time.

Open-source tools also serve another purpose, they’re a sanity check. When something looks significant during analysis, validating it with an independent tool that parses the same artifact differently adds confidence. This isn’t about distrust — it’s about applying defense-in-depth to analysis itself. If two independently built tools reach the same conclusion, the finding is stronger. If they don’t, that discrepancy is worth investigating before it makes its way into a report.

That ties into a broader issue, treating tools as black boxes. A result comes out, it gets documented, and it ends up in the report with very little scrutiny of how it was produced. Knowing which tools to trust means understanding what they’re actually doing under the hood. The fix is simple, but often ignored, read the release notes. Also, if a tool burned you two years ago, verify whether that’s still true. Vendors iterate. OSS projects iterate. Hanging onto an old assumption is an easy way to miss something useful. And “well-known” doesn’t mean “complete” — every tool has blind spots, and knowing where they are is part of the job.

All of this becomes more relevant when you look at how AI and automation are being positioned in DFIR. There are real capabilities being built, but there’s also a lot of noise. What’s consistently improving is automation around repeatable tasks — collection, parsing, triage. That matters. It allows a competent analyst to move faster and cover more ground. What hasn’t changed is the part that requires judgment: understanding context, recognizing when something doesn’t fit, and knowing what question to ask next. That intuition comes from experience, and there’s no real shortcut for it.

One shift that’s been more interesting is how many practitioners are now building their own tools. The barrier to entry has dropped. You don’t need to be a full-time software engineer to create something useful. If you understand the artifacts and can write a working parser in Python or Rust, you can build something that solves a real problem. That kind of domain-specific tooling — built by someone who understands what they’re looking for — is often more effective than a generic solution adapted to fit a forensic use case. It also reinforces the same principle, the more you understand the tooling, the less you rely on it blindly.

Use what works. Know its limits. Validate across tools when it matters. Don’t let a bad experience with an old version close a door. And write it down when something’s worth sharing.

The Game Is Afoot: Introducing the MalChela Video Series

There’s a moment every analyst knows — the one where an unknown file lands on your desk and the clock starts ticking. You need answers, and you need them fast. MalChela was built for exactly that moment.

Today I’m excited to announce the MalChela Video Series on YouTube — a growing collection of tutorial episodes walking through real malware analysis workflows using MalChela, the open-source Rust-based toolkit I’ve been building for the DFIR community. Whether you’re new to the tool or already running it in your lab, there’s something here for you.

Four episodes are available right now in the playlist.


What’s in the Playlist

Ep0 | Installation & First Run

Every case starts somewhere. Episode 0 is your onboarding — installing MalChela, walking through its dependencies, and getting oriented with both the CLI and GUI modes. If you’ve been curious about the tool but weren’t sure where to start, this is the episode to bookmark.


Ep1 | First Contact: Hash, Inspect, Identify

You’ve just been handed a suspicious file. What do you do first?

This episode covers the first three tools in a malware triage workflow — the exact sequence I reach for every time I encounter an unknown file:

  • hashit — generate MD5, SHA1, and SHA256 hashes to protect chain of custody and enable deduplication
  • fileanalyzer — static inspection: entropy analysis, PE header fields, compile timestamps, and import tables
  • malhash — simultaneous lookup against VirusTotal and MalwareBazaar to identify known malware families

By the end of this episode, you’ll take an unknown file from zero to confirmed malware family identification in under five minutes — no sandboxing required.


Ep2 | From Strings to Signatures

Continuing from Episode 1, we go deeper into the confirmed RedLine info-stealer sample using mStrings — MalChela’s string extraction engine. Unlike the traditional strings utility, mStrings runs every extracted string through a detection ruleset and MITRE ATT&CK mapping layer simultaneously, turning raw output into actionable intelligence.

We walk through 62 detections, including PDB path artifacts, hard-coded dropper filenames, WMI queries, credential harvesting patterns, anti-debug checks, and a code injection setup. We then feed the extracted IOCs into Strings2YARA to auto-generate a structured YARA rule — and confirm it fires against the sample using File Analyzer.

By the end, you’ll be reading a malware file not as a pile of strings, but as a window into the attacker’s tradecraft.


Ep3 | REMnux Mode & Custom Tools

MalChela doesn’t work in isolation. Episode 3 covers how to extend the toolkit through the tools.yaml config file and how enabling REMnux mode surfaces an entire distro’s worth of malware analysis utilities directly within MalChela’s interface.

We also explore three built-in integrations: Volatility 3 with a dynamic plugin builder, T-Shark with a searchable reference, and YARA-X — a faster, Rust-native rewrite of YARA.


What’s Coming

The series is ongoing. Future episodes will push further into advanced workflows — think directory-scale triage, corpus management, and the AI-assisted analysis capabilities introduced in MalChela’s MCP integration. Stay subscribed and you won’t miss them.


Get Involved

If MalChela is useful in your work, the best thing you can do is help spread the word:

  • 📺 Subscribe to the YouTube channel — Subscribe to the channel and save the playlist so you don’t miss new episodes as they land.
  • 📖 Follow Baker Street Forensics — Writeups, major releases, and workflow deep dives live here.
  • 💬 Share and comment — If an episode clicks for you, pass it along to a colleague or drop a comment on the video. That feedback genuinely shapes what comes next.

The game is afoot. Let’s get to work.


MalChela is open-source and freely available. Find the project on GitHub.

MalChela Meets AI: Three Paths to Smarter Malware Analysis

In a previous post I wrote about integrating MalChela with OpenCode on REMnux and giving the AI a quick briefing on the tool suite so it could incorporate them into its analysis workflow. That was a promising proof of concept, but it raised a natural follow-up question: how do you make these integrations more robust, reproducible, and persistent?

Since that post, I’ve been experimenting with three different approaches to bringing MalChela into AI-assisted workflows — each suited to a different environment and use case. This post walks through all three.


Approach 1: The Kali MCP Server (Toby)

The first implementation started with Toby — my portable Raspberry Pi forensics toolkit running a customized Kali Linux build. Toby is designed for headless operation via SSH, which turns out to be exactly the right architecture for an MCP server. The developers of Kali recently added an update to support MCP integrations. (See https://www.kali.org/blog/kali-llm-claude-desktop/)

Model Context Protocol (MCP) is an open standard that allows AI assistants like Claude to interface with external tools and systems in a structured, reliable way. Instead of pasting instructions into a chat window each session, you define your tools once in a server configuration and the AI has consistent, persistent access to them.

The setup leverages an existing open-source mcp-kali-server that exposes Kali’s forensic and security tooling as MCP tools. On the client side (Mac), the claude_desktop_config.json simply points to Toby (or your Kali box) over SSH:

{
"mcpServers": {
"mcp-kali-server": {
"command": "ssh",
"args": [
"-i",
"/Users/dwmetz/.ssh/id_ed25519",
"dwmetz@192.168.10.89",
"mcp-server"
],
"transport": "stdio"
}
}
}

With this in place, Claude Desktop has persistent, session-independent access to Kali’s toolkit running on Toby. No need to re-brief the AI each session — the tools are always available and always described the same way.

Key prerequisite: passwordless SSH key-based auth between your Mac and Toby. If you haven’t set that up:

ssh-keygen -t ed25519
ssh-copy-id user@<toby/kali-ip>
# Then one manual SSH to accept the host key fingerprint
ssh user@<toby/kali-ip>

Adding MalChela to the Kali MCP Server

The mcp-kali-server ships with routes for Kali’s built-in security tools, but MalChela isn’t included out of the box. Adding it requires changes to two files: kali_server.py (the Flask API backend) and mcp_server.py (the FastMCP frontend). Both live at /usr/share/mcp-kali-server/.

How the architecture works: mcp_server.py is what Claude talks to — it defines MCP tool names, descriptions, and parameter schemas. When a tool is called, it POSTs to kali_server.py, which constructs the actual shell command and executes it on Toby. The critical detail is that MalChela’s binaries must be run from within the MalChela workspace directory — running them from an arbitrary working directory causes failures. The cd {MALCHELA_DIR} && prefix in every command handles this.

kali_server.py changes

Add the MALCHELA_DIR constant (update with your MalChela install path) and Flask routes after the existing tool routes, before the health check endpoint:

# ============================================================
# MalChela Tool Routes
# Adjust MALCHELA_DIR if MalChela is installed elsewhere
# ============================================================
MALCHELA_DIR = "/home/dwmetz/tools/MalChela"
@app.route("/api/tools/malchela/fileanalyzer", methods=["POST"])
def malchela_fileanalyzer():
"""MalChela: Hash, entropy, packing detection, PE headers, YARA scan, VirusTotal lookup."""
try:
params = request.json
filepath = params.get("filepath", "")
if not filepath:
return jsonify({"error": "filepath parameter is required"}), 400
command = f"cd {MALCHELA_DIR} && ./target/release/fileanalyzer \"{filepath}\""
result = execute_command(command)
return jsonify(result)
except Exception as e:
logger.error(f"Error in malchela_fileanalyzer endpoint: {str(e)}")
return jsonify({"error": f"Server error: {str(e)}"}), 500
@app.route("/api/tools/malchela/mstrings", methods=["POST"])
def malchela_mstrings():
"""MalChela: Extract strings, apply Sigma rules, map to MITRE ATT&CK."""
try:
params = request.json
filepath = params.get("filepath", "")
if not filepath:
return jsonify({"error": "filepath parameter is required"}), 400
command = f"cd {MALCHELA_DIR} && ./target/release/mstrings \"{filepath}\""
result = execute_command(command)
return jsonify(result)
except Exception as e:
logger.error(f"Error in malchela_mstrings endpoint: {str(e)}")
return jsonify({"error": f"Server error: {str(e)}"}), 500
@app.route("/api/tools/malchela/malhash", methods=["POST"])
def malchela_malhash():
"""MalChela: Query a hash against VirusTotal and MalwareBazaar."""
try:
params = request.json
hash_value = params.get("hash", "")
if not hash_value:
return jsonify({"error": "hash parameter is required"}), 400
command = f"cd {MALCHELA_DIR} && ./target/release/malhash \"{hash_value}\""
result = execute_command(command)
return jsonify(result)
except Exception as e:
logger.error(f"Error in malchela_malhash endpoint: {str(e)}")
return jsonify({"error": f"Server error: {str(e)}"}), 500
@app.route("/api/tools/malchela/nsrlquery", methods=["POST"])
def malchela_nsrlquery():
"""MalChela: Query file hash against NIST NSRL known-good database."""
try:
params = request.json
filepath = params.get("filepath", "")
if not filepath:
return jsonify({"error": "filepath parameter is required"}), 400
command = f"cd {MALCHELA_DIR} && ./target/release/nsrlquery \"{filepath}\""
result = execute_command(command)
return jsonify(result)
except Exception as e:
logger.error(f"Error in malchela_nsrlquery endpoint: {str(e)}")
return jsonify({"error": f"Server error: {str(e)}"}), 500
@app.route("/api/tools/malchela/hashit", methods=["POST"])
def malchela_hashit():
"""MalChela: Generate MD5, SHA1, and SHA256 hashes for a file."""
try:
params = request.json
filepath = params.get("filepath", "")
if not filepath:
return jsonify({"error": "filepath parameter is required"}), 400
command = f"cd {MALCHELA_DIR} && ./target/release/hashit \"{filepath}\""
result = execute_command(command)
return jsonify(result)
except Exception as e:
logger.error(f"Error in malchela_hashit endpoint: {str(e)}")
return jsonify({"error": f"Server error: {str(e)}"}), 500
@app.route("/api/tools/malchela/fileminer", methods=["POST"])
def malchela_fileminer():
"""MalChela: Scan a directory for file type mismatches and metadata anomalies."""
try:
params = request.json
dirpath = params.get("dirpath", "")
if not dirpath:
return jsonify({"error": "dirpath parameter is required"}), 400
command = f"cd {MALCHELA_DIR} && ./target/release/fileminer \"{dirpath}\""
result = execute_command(command)
return jsonify(result)
except Exception as e:
logger.error(f"Error in malchela_fileminer endpoint: {str(e)}")
return jsonify({"error": f"Server error: {str(e)}"}), 500

Important note on malhash: Unlike the other tools which take a file path, malhash takes a hash string as its argument. The route reads a hash parameter and passes it directly to the binary. Passing a filepath to malhash will fail silently — a subtle but critical distinction.

mcp_server.py changes

The MalChela tool definitions need to be added to the setup_mcp_server() function, immediately before the return mcp line.

    @mcp.tool(name="malchela_fileanalyzer")
    def malchela_fileanalyzer(filepath: str) -> Dict[str, Any]:
        """
        MalChela: Static file analysis - hashes, entropy, packing detection,
        PE metadata (imports, sections, timestamps), YARA matches, VirusTotal status.
        Best first step for any unknown file.

        Args:
            filepath: Absolute path to the file to analyze

        Returns:
            Analysis report
        """
        return kali_client.safe_post("api/tools/malchela/fileanalyzer", {"filepath": filepath})

    @mcp.tool(name="malchela_mstrings")
    def malchela_mstrings(filepath: str) -> Dict[str, Any]:
        """
        MalChela: String extraction with IOC detection and MITRE ATT&CK mapping.
        Applies Sigma-style detection rules, flags suspicious patterns (registry keys,
        encoded payloads, suspicious DLL+API combos), maps findings to ATT&CK techniques.

        Args:
            filepath: Absolute path to the file to analyze

        Returns:
            String analysis with ATT&CK mappings and IOCs
        """
        return kali_client.safe_post("api/tools/malchela/mstrings", {"filepath": filepath})

    @mcp.tool(name="malchela_malhash")
    def malchela_malhash(hash: str) -> Dict[str, Any]:
        """
        MalChela: Query a file hash against VirusTotal and MalwareBazaar.
        Returns detection ratio, AV verdicts, first/last seen dates, and sample metadata.
        Requires VT_API_KEY env var; MB_API_KEY optional.

        Args:
            hash: MD5, SHA1, or SHA256 hash string to query

        Returns:
            Threat intel results from VirusTotal and MalwareBazaar
        """
        return kali_client.safe_post("api/tools/malchela/malhash", {"hash": hash})

    @mcp.tool(name="malchela_hashit")
    def malchela_hashit(filepath: str) -> Dict[str, Any]:
        """
        MalChela: Generate MD5, SHA1, and SHA256 hashes for a single file.
        Lightweight when you need hashes without full fileanalyzer output.

        Args:
            filepath: Absolute path to the file

        Returns:
            File hashes
        """
        return kali_client.safe_post("api/tools/malchela/hashit", {"filepath": filepath})

    @mcp.tool(name="malchela_fileminer")
    def malchela_fileminer(folderpath: str) -> Dict[str, Any]:
        """
        MalChela: Scan a folder for file type mismatches and metadata anomalies.
        Classifies all files, flags executables disguised as other types.

        Args:
            folderpath: Absolute path to the folder to scan

        Returns:
            File classification and anomaly report
        """
        return kali_client.safe_post("api/tools/malchela/fileminer", {"dirpath": folderpath})

    return mcp

One parameter naming detail worth noting: mcp_server.py receives folderpath from Claude, but must pass it as dirpath in the JSON body to kali_server.py — that’s what the Flask route reads. The tool definition above handles this correctly.

After saving both files, restart the MCP server and restart Claude Desktop.

Testing on an unknown malware sample

[below is the exact response received from Claude]

I’ll run MalChela analysis on that file via Toby. Let me load the tools first.Tools loaded. Running fileanalyzer first for static analysis, then mstrings for IOC/ATT&CK mapping. Let me verify the path exists:File confirmed on Toby. The MalChela MCP tools use local paths — let me run it directly via the Kali execute_command since the MCP path routing doesn’t map Toby paths. I’ll invoke MalChela’s binaries directly:MalChela binaries found. Running the full suite now:That’s already very telling. Now running mstrings for IOC and ATT&CK mapping:Now let me pull the VirusTotal intel on the hash:That’s a solid picture. Here’s the full analysis breakdown:

🔴 MalChela Analysis — unknown.exe

Identification

FieldValue
SHA256dca40a0120ea176aa65b99c90d171761cb8bf696be4be026941f7f54e3c21635
MD55e364c1e35445b655ca30ab0c5bc7a4a
SHA10ac9950d00429ff4509c7fb9aa7320a45a0465ea
MalwareBazaar FilenameBL 3425005143.bat (disguised as .bat, submitted as .exe)
OriginPoland (PL), submitted anonymously
First Seen2026-03-03 13:38:42 UTC — very fresh

🧬 Verdict: GuLoader

39/69 detections on VirusTotal. Multiple vendors confirm this as GuLoader (NSIS-based downloader/injector):

  • ESET: NSIS/Injector.ENS trojan
  • Malwarebytes: Trojan.GuLoader
  • Fortinet: NSIS/Injector.7A4A!tr
  • Kaspersky: HEUR:Trojan-Downloader.Win32.Minix.gen
  • MalwareBazaar Signature: GuLoader

📦 Static Analysis Highlights

  • Entropy: 7.96 — near-maximum, strongly indicating packed/encrypted payload
  • Packer: NSIS (Nullsoft Scriptable Install System) wrapper — common GuLoader delivery vehicle
  • Compile Timestamp: 2018-12-15 (likely spoofed/stomped)
  • Unsigned — no digital signature
  • 5 PE sections including .ndata (atypical NSIS section, flagged as suspicious)
  • 159 imports, including the dangerous trio:
    • GetProcAddress / LoadLibraryExA — dynamic API resolution (evasion)
    • ShellExecuteExA — process execution

🎯 MITRE ATT&CK Mappings (from mstrings)

TechniqueIDTactic
Obfuscated Files or InformationT1027Defense Evasion
Process InjectionT1055Defense Evasion / Privilege Escalation
Application Layer Protocol: Web ProtocolsT1071.001Command and Control

🌐 Network IOC

  • http://nsis.sf.net/NSIS_Error — NSIS error handler URL (confirms NSIS wrapper), not inherently malicious but characteristic of GuLoader’s packaging

Summary

This is a live GuLoader sample — an NSIS-wrapped shellcode injector/downloader commonly used as a first-stage payload to retrieve second-stage malware (often AgentTesla, Remcos RAT, FormBook, etc.). The high entropy, dynamic API loading, and process injection indicators are all consistent with GuLoader’s known behavior. Treat this as active malware — do not execute outside an isolated sandbox.


Approach 2: Persistent MalChela Instructions in OpenCode on REMnux

The REMnux OpenCode integration I described in the previous post worked, but it had one friction point: each new session required re-pasting the MalChela context. OpenCode has a solution for this — the AGENTS.md file.

Place an AGENTS.md file in your working directory (or MalChela’s root directory) and OpenCode will automatically load it as persistent context for every session started from that location. This is the most lightweight way to make MalChela tool-aware without building any infrastructure.

Create the file at /home/remnux/Tools/MalChela/AGENTS.md:

# MalChela Tool Instructions for AI Assistants
MalChela is installed at: /home/remnux/Tools/MalChela
All tools are Rust binaries. The execution pattern is:
cd /home/remnux/Tools/MalChela
./target/release/<toolname> <arguments>
## Primary Static Analysis Tools
| Tool | Binary | Description |
|------|--------|-------------|
| File Analyzer | fileanalyzer | Hash, entropy, packing detection, PE info, YARA scan, VirusTotal lookup |
| mStrings | mstrings | String extraction, Sigma rule matching, Regex, MITRE ATT&CK mapping |
| NSRL Hash Lookup | nsrlquery | Query MD5/SHA1 against the NIST NSRL known-good database |
| Malware Hash Lookup | malhash | Query a hash against VirusTotal and MalwareBazaar |
## Additional Tools
| Tool | Binary | Description |
|------|--------|-------------|
| File Miner | fileminer | Scan directories for file type mismatches and metadata anomalies |
| Hash It | hashit | Generate MD5, SHA1, and SHA256 for a single file |
| mzHash | mzhash | Recursively hash all files in a directory |
| Extract Samples | extract_samples | Extract files from password-protected malware archives |
## Recommended Workflow
For initial triage of an unknown file:
1. fileanalyzer - establish baseline: hashes, entropy, PE headers
2. mstrings - extract strings, look for IOCs and ATT&CK technique indicators
3. malhash - check community threat intelligence
4. nsrlquery - confirm or rule out known-good status
## Environment Notes
- API keys (VT_API_KEY, MB_API_KEY) should be set in the shell environment
- MalChela integrates with REMnux tools; use REMnux CLI tools in conjunction as needed
- Case management is available via the MalChela GUI if a graphical session is active

When you start an OpenCode session from the MalChela directory, this context is automatically loaded. No manual pasting, no re-briefing.

Once complete I asked it to save the results to the Desktop in markdown.

What was cool to me about this approach is that using the installed REMnux tools, you can take the analysis further after MalChela. In my testing I (OpenCode) analyzed a file with mStrings. We then followed up by running capa against the file. From there we could compare what each tool detected and missed in the sample. (screenshot truncated)


Approach 3: MalChela as a Native MCP Server (Mac)

The most powerful integration is running MalChela as its own dedicated MCP server — making its tools directly available to Claude Desktop alongside the Kali server. This is what we built out as mcp-malchela.

The server is a small Node.js project that wraps MalChela’s binaries with proper MCP tool definitions. The key files are index.js (the server logic) and package.json.

package.json:

{
"name": "mcp-malchela",
"version": "1.0.0",
"description": "MCP server exposing MalChela malware analysis tools",
"main": "index.js",
"dependencies": {
"@modelcontextprotocol/sdk": "^1.0.0"
}
}

index.js — the server defines each MalChela tool with its input schema, executes the binary when called, and streams back results. Note that malhash is handled differently from the other tools — it receives a hash string rather than a filepath, so the argument routing accounts for that explicitly:

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { CallToolRequestSchema, ListToolsRequestSchema } from "@modelcontextprotocol/sdk/types.js";
import { execSync } from "child_process";
import path from "path";
const MALCHELA_DIR = process.env.MALCHELA_DIR || "/Users/dmetz/GitHub/MalChela";
const RELEASE_DIR = path.join(MALCHELA_DIR, "target", "release");
const server = new Server(
{ name: "mcp-malchela", version: "1.0.0" },
{ capabilities: { tools: {} } }
);
const tools = [
{
name: "malchela_fileanalyzer",
description: "Analyze a file: hashes, entropy, packing detection, PE headers, YARA scan, VirusTotal lookup",
inputSchema: {
type: "object",
properties: {
filepath: { type: "string", description: "Absolute path to the file to analyze" }
},
required: ["filepath"]
}
},
{
name: "malchela_mstrings",
description: "Extract strings from a file, apply Sigma rules and Regex patterns, map to MITRE ATT&CK",
inputSchema: {
type: "object",
properties: {
filepath: { type: "string", description: "Absolute path to the file to analyze" }
},
required: ["filepath"]
}
},
{
name: "malchela_malhash",
description: "Query a hash against VirusTotal and MalwareBazaar",
inputSchema: {
type: "object",
properties: {
hash: { type: "string", description: "MD5, SHA1, or SHA256 hash string to query" }
},
required: ["hash"]
}
},
{
name: "malchela_nsrlquery",
description: "Query a file hash against the NIST NSRL known-good database",
inputSchema: {
type: "object",
properties: {
filepath: { type: "string", description: "Absolute path to the file to query" }
},
required: ["filepath"]
}
}
];
server.setRequestHandler(ListToolsRequestSchema, async () => ({ tools }));
server.setRequestHandler(CallToolRequestSchema, async (request) => {
const { name, arguments: args } = request.params;
const env = { ...process.env };
const binaryMap = {
malchela_fileanalyzer: "fileanalyzer",
malchela_mstrings: "mstrings",
malchela_malhash: "malhash",
malchela_nsrlquery: "nsrlquery"
};
const binary = binaryMap[name];
if (!binary) throw new Error(`Unknown tool: ${name}`);
// malhash takes a hash string; all other tools take a filepath
const arg = name === "malchela_malhash" ? args.hash : args.filepath;
const cmd = `cd "${MALCHELA_DIR}" && ./target/release/${binary} "${arg}"`;
try {
const output = execSync(cmd, { env, encoding: "utf8", maxBuffer: 10 * 1024 * 1024 });
return { content: [{ type: "text", text: output }] };
} catch (error) {
return { content: [{ type: "text", text: error.stdout || error.message }] };
}
});
const transport = new StdioServerTransport();
await server.connect(transport);

Setup:

mkdir ~/mcp-malchela
cd ~/mcp-malchela
# create index.js and package.json as above
npm install

claude_desktop_config.json — with both servers configured:

{
"mcpServers": {
"mcp-kali-server": {
"command": "ssh",
"args": [
"-i",
"/Users/dwmetz/.ssh/id_ed25519",
"dwmetz@192.168.10.89",
"mcp-server"
],
"transport": "stdio"
},
"malchela": {
"command": "node",
"args": ["/Users/dmetz/mcp-malchela/index.js"],
"env": {
"MALCHELA_DIR": "/Users/dmetz/Tools/MalChela"
}
}
}
}

Restart Claude Desktop and both MCP servers will be active and available in every session.


I'll load the MalChela tools and run analysis on that file on your Mac.
Searched available tools
Starting with fileanalyzer for the full static analysis pass.
Fileanalyzer
VirusTotal flags it as malicious. Let me pull the full VT/MalwareBazaar intel and then run strings analysis.
Malhash
Confirmed SalatStealer. Let me run strings analysis to surface IOCs and ATT&CK mappings.
Ran 5 commands, used malchela integration
That's a solid picture. Here's the full breakdown:

🔴 unknown3.exe — SalatStealer (Confirmed Malicious)

Identity

FieldValue
SHA256e0c90f401ae5d23a551f2d75a826cec7f187a6b7f0da2d24565c880e027ae9a3
MD5cfcd64360a0b0c3185f9a48b1dbe1bdc
FamilySalatStealer (Trojan.PWS.Salat)
VT Detections33/68 — confirmed malicious
First Seen2026-03-03 15:37 UTC (very fresh)
OriginNL (Netherlands), reported by abuse.ch
LanguageGo (Golang) — evident from stdlib and module paths
Architecturei386 (32-bit PE)
PackerUPX (MalwareBazaar notes this is the UPX-decompressed form; original packed SHA256: 30a50cc0f7...)
Code SigningAbsent
Compile TimestampEpoch zero (1970-01-01) — deliberately zeroed/spoofed

MITRE ATT&CK Coverage (11 Techniques)

TechniqueIDWhat was found
Obfuscated Files / PackingT1027DOS stub + packer artifact
OS Credential Dumping (LSASS)T1003.001String matches
WMI Execution/DiscoveryT1047ffwmic reference
Process InjectionT1055Injection-capable imports
Scripting InterpreterT1059JSON/script interpreter refs
Web Protocol C2T1071.001WebSocket + HTTP/2 libs, hardcoded domains
System Info DiscoveryT1082System enumeration strings
File & Dir DiscoveryT1083File path enumeration
Ingress Tool TransferT1105Download capability
Unsecured CredentialsT1552passwordusernameloginPBEpasswordSet

Notable IOCs from Strings

  • Clients\DiscordTokens.txt — Discord token harvesting
  • moz_cookies SQL query — Firefox cookie theft
  • yandexbrowser — Yandex Browser credential targeting
  • *main.loginPBE — Login/credential parsing function
  • WebSocket C2 comms — *websocket.netDialerFunc*websocket.netError
  • WMI usage — likely for system enumeration pre-exfil

Bottom Line

This is a Go-compiled password/credential stealer targeting browsers (Firefox cookies, Discord tokens, Yandex Browser), using WebSocket for C2, with WMI-based discovery. It was UPX-packed (this is the unpacked copy), has a zeroed compile timestamp to defeat timestamp-based triage, and was submitted to MalwareBazaar just hours ago — very fresh sample. Do not execute in any environment without proper isolation.

VT permalink for full AV breakdown: https://www.virustotal.com/gui/file/e0c90f401ae5d23a551f2d75a826cec7f187a6b7f0da2d24565c880e027ae9a3/detection


Comparing the Three Approaches

Kali MCP (Toby)OpenCode AGENTS.mdMalChela MCP
PlatformKali (Raspberry Pi)REMnuxmacOS
PersistenceFull (MCP server definition)Full (file-based)Full (MCP server definition)
Setup complexityMedium (SSH + server install + file edits)Low (one markdown file)Medium (Node.js server)
AI integration depthStructured tool callsNatural language with contextStructured tool calls
Best forField analysis with TobyREMnux-primary workflowsMac-based analysis with MalChela

All three approaches solve the same core problem from the original post: making the AI reliably aware of your tools without re-briefing it every session. The right choice depends on your primary analysis environment — or, if you’re like me, you end up running all three.


All of the configuration files discussed here — including the MCP server setup and the are available in the MalChela repository on GitHub. Clone or pull the latest and you should be ready to go. As always, if you run into issues or have ideas for where to take the MCP integration next, open an issue or drop me a note.