arXiv CSopen access

LCC-LLM: Leveraging Code-Centric Large Language Models for Malware Attribution

LCC-LLM: Leveraging Code-Centric Large Language Models for Malware Attribution Christopher G. Pedraza Pohlenza , Hassan Jalil Hadia,∗ , Ali Hassana and Ali Shokera

arXiv:2605.05807v1 [cs.CR] 7 May 2026

a CyberSaR, King Abdullah University of Science and Technology, Thuwal, 23955-6900, Makkah Province, Saudi Arabia

ARTICLE INFO

ABSTRACT

Keywords: Large Language Models Malware Attribution Code-Centric Dataset Reverse Engineering Chain-of-Verification Cyber Threat Intelligence

Large Language Models (LLMs) are increasingly being explored for malware analysis; however, current LLM-based malware attribution remains limited by unsupported indicators and insufficient code-level grounding for identifying malicious and vulnerable code segments. To address these limitations, this research introduces LCC-LLM, a code-centric benchmark dataset and evidencegrounded intelligent framework for malware attribution and multi-task static malware analysis. The proposed LCCD 1 dataset contains approximately 34K PE samples processed through a large-scale reverse-engineering pipeline and represented using decompiled C code, assembly code, CFG/FCG artifacts, hexadecimal data, PE metadata, suspicious API evidence, and structural features. Beyond dataset construction, LCC-LLM integrates LangGraph-orchestrated static analysis with multi-source cybersecurity knowledge. This integration supports evidence-grounded malware reasoning. The framework also employs a seven-layer retrieval-augmented generation pipeline. It uses Chain-ofVerification for IoC validation. In addition, a multi-dimensional quality gate is applied to improve factual reliability and analyst-oriented decision support. Curriculum-ordered instruction data is used to fine-tune DeepSeek-R1-Distill-Qwen-14B and Qwen3-Coder-30B-A3B using QLoRA. Evaluation across 43 malware-analysis task types achieves an average semantic similarity of 0.634, with the highest task-level performance observed in structured report generation, IoC extraction, vulnerability assessment, malware configuration extraction, and malware class detection. In a real-world casestudy evaluation using MalwareBazaar samples, the grounded pipeline achieves a 10/10 structured analysis pass rate, producing CFG/FCG evidence, MITRE ATT&CK mappings, detection guidance, and analyst-ready reports. These results show that code-centric representations, retrieval grounding, and verification-guided reasoning improve the reliability and operational usefulness of LLM-assisted malware attribution.

1. Introduction Malware continues to pose a major threat to modern digital infrastructures, affecting enterprise networks, cloud services, critical systems, and Security Operations Centers (SOCs) [1, 2]. As malware families evolve through packing, obfuscation, code reuse, and rapid variant generation, timely malware attribution has become an essential task for cyber threat intelligence [3], incident response, and defensive decision-making [4]. Malware attribution is not limited to assigning a family label to a suspicious binary; it requires understanding malicious intent, identifying suspicious code segments, interpreting API behavior, mapping observed behaviors to known attack techniques, extracting Indicators of Compromise (IoCs) [5], and generating actionable guidance for analysts [6]. Therefore, effective malware analysis systems must go beyond simple detection and provide evidence-grounded explanations that connect lowlevel reverse-engineering artifacts with higher-level threat intelligence. Furthermore, traditional malware analysis methods commonly rely on static or dynamic features such as byte sequences, opcode patterns, imported APIs, PE metadata, ∗ Corresponding author

[email protected] (H.J. Hadi)

ORCID (s): 0000-0001-7746-344X (H.J. Hadi)

1 LCC-LLM refers to the proposed framework, and LCCD refers to the benchmark dataset.

First Author et al.: Preprint submitted to Elsevier

control-flow features, sandbox traces, or manually engineered indicators [7, 8]. These approaches have been widely used for malware detection and family classification, but they often operate on isolated feature spaces and provide limited support for analyst-oriented reasoning. For example, a classifier may predict that a sample belongs to a particular malware family [4, 9], but it may not explain which code structures, suspicious APIs, function relationships, or threat-intelligence indicators support that attribution [10]. Similarly, static feature-based systems may identify suspicious imports or entropy values but fail to connect these observations with malicious code segments [11, 12], vulnerable code patterns [13], MITRE ATT&CK techniques, or remediation actions. This gap limits their practical value in operational environments where analysts require traceable, interpretable, and actionable evidence. In addition, LLMs have recently demonstrated strong capabilities in code understanding, natural language reasoning, and security-oriented analysis [6, 14, 15]. These capabilities create new opportunities for malware analysis, particularly because reverse-engineering artifacts such as decompiled C code, assembly instructions, function-call relationships, API traces, and structured reports can be represented as language-like inputs [16]. However, directly applying general-purpose LLMs to malware attribution introduces several challenges. Current LLM-based malware analysis can produce unsupported indicators, hallucinated threat claims, incomplete code-level evidence, and responses that Page 1 of 23

LCC-LLM

are not aligned with SOC workflows [17, 18]. In malware analysis, such errors are not merely linguistic mistakes; hallucinated IoCs, incorrect MITRE mappings, or unsupported family claims can mislead incident response decisions and reduce analyst trust [19]. Therefore, LLM-based malware analysis requires code-centric grounding, verified threat intelligence, deterministic reverse-engineering evidence, and quality-controlled response generation. To address these challenges, this paper presents LCCLLM, a code-centric benchmark dataset and evidencegrounded LLM framework for malware attribution and multi-task static malware analysis. The proposed LargeScale Code-Centric Dataset (LCCD) contains approximately 34K PE samples processed through a large-scale reverseengineering pipeline. Building on this dataset, LCC-LLM integrates LangGraph-orchestrated static analysis, multisource cybersecurity knowledge, retrieval-augmented generation, Chain-of-Verification (CoVe), Chain-of-Thought (CoT), and a multi-dimensional quality gate to generate evidence-grounded malware analysis outputs. The resulting curriculum-ordered instruction data is used to fine-tune code-oriented LLMs using Quantized Low-Rank Adaptation (QLoRA), enabling analyst-facing tasks such as malware attribution, malicious and vulnerable code analysis, IoC extraction, MITRE ATT&CK mapping, detection guidance, and structured malware reporting. This design connects reverse-engineering artifacts, verified threat intelligence, and LLM-based reasoning into a unified framework for reliable malware attribution and analyst-assisted security investigation. The main contributions of this study are summarized as follows: • Existing malware datasets often provide binaries, labels, API traces, or limited metadata, but they rarely unify reverse-engineering artifacts with explicit support for malicious and vulnerable code segment analysis. To address this gap, we introduce LCCD, a codecentric benchmark dataset of approximately 34K Windows PE samples represented through decompiled C code, assembly code, CFG/FCG artifacts, hexadecimal data, PE metadata, suspicious API evidence, and structural features. • Current LLM-based malware analysis is limited by the lack of structured training data that connects lowlevel malware artifacts with analyst-oriented tasks. To address this limitation, we construct an LLM-ready instruction-tuning corpus covering malware attribution, malicious code identification, vulnerable code detection, suspicious API analysis, static behavior analysis, threat identification, detection guidance, and technique explanation. • General-purpose LLMs can generate unsupported malware claims because their outputs are often not grounded in reverse-engineering evidence or verified threat intelligence. To address this problem, we propose LCC-LLM, an evidence-grounded framework First Author et al.: Preprint submitted to Elsevier

that combines LangGraph-orchestrated static analysis, deterministic reverse-engineering tools, multi-source cybersecurity knowledge, seven-layer RAG, CoVe, CoT, and a multi-dimensional quality gate. • In recent studies, LLM malware-analysis systems are evaluated only as offline text-generation models, without demonstrating usability in real analyst workflows. To address this gap, we fine-tune code-oriented LLMs using QLoRA and curriculum-ordered instruction data, evaluate the system across 43 malware-analysis task types, and demonstrate a real-time chatbot prototype for malware triage, IoC extraction, MITRE ATT&CK mapping, detection guidance, and structured malware reporting. The remainder of this paper is organized as follows. Section 2 reviews related work on malware datasets, non-LLMbased malware detection, LLM-based malware analysis and cybersecurity applications, and tool-augmented malware reasoning. Section 3 presents the construction of LCCD and its code-centric representation pipeline. Section 4 describes the LCC-LLM framework, including static analysis orchestration, knowledge enrichment, retrieval grounding, verification, and quality control. Section 5 presents model finetuning and experimental setup, and reports the evaluation results and real-world testing. Finally, Section 6 concludes the paper and outlines future research directions.

2. Related Work Malware analysis is commonly divided into static and dynamic analysis. Static analysis examines a sample without execution, using artifacts such as PE headers, imported APIs, assembly, decompiled code, CFGs, and FCGs, while dynamic analysis observes runtime behavior in a controlled environment. This research focuses on static Windows PE malware analysis for early, code-centric malware attribution and analyst-oriented reasoning.

2.1. Existing Malware Datasets Several malware datasets have been developed to support malware detection, classification, and family identification. Early datasets such as Malicia [20] and Microsoft BIG2015 [21] mainly focus on malware family classification using binaries, byte sequences, or family labels. Similarly, EMBER [22], SOREL-20M [23], and BODMAS [24] provide large-scale Windows PE samples, static features, metadata, and labels for malware detection and classification. These datasets have significantly advanced static malware analysis; however, most of them are designed for feature-based machine learning rather than code-centric reasoning. As shown in Table 1, they generally do not provide decompiled code, malicious code segment annotations, vulnerable code segments, suspicious API risk context, CTI/IoC enrichment, or LLM-oriented instruction data. Recent datasets have started to provide richer representations for malware analysis. For example, CIC-SGG2024 [25] introduces graph-based malware representations Page 2 of 23

LCC-LLM Table 1 Availability of related PE malware datasets for code-centric malware attribution and LLM-oriented analysis tasks. Dec. Code = Decompiled Code, CFG = Control Flow Graph, FCG = Function Call Graph, Mal. Code Seg. = Malicious Code Segment, Vuln. Code/CWE = Vulnerable Code/Common Weakness Enumeration, API = Application Programming Interface, CTI = Cyber Threat Intelligence, IoC = Indicator of Compromise, LLM = Large Language Model; = “Not Available”, = “Partially Available”, and = “Available”. Dataset

Dec. Code

CFG/FCG

Mal. Code Seg.

Vuln. Code/CWE

API Risk

CTI/IoC

Attribution

LLM Data

Analyst Tasks

Malicia [20] Microsoft BIG-2015[21] EMBER 2018 [22] SOREL-20M [23] BODMAS [24] CIC-SGG-2024 [25] FCG-MFD [4] SBAN [19] LCCD (Ours)

using Control Flow Graphs (CFGs) and Function Call Graphs (FCGs), making it useful for structural malware analysis. FCG-MFD [4] extends malware benchmarking through a large and modern classifier-evaluation setting, while SBAN [19] moves toward multimodal and LLMoriented software code mining. Although these datasets broaden the malware dataset landscape, they still do not jointly support malware attribution, malicious code segment identification, vulnerable code/CWE analysis, suspicious API interpretation, MITRE ATT&CK mapping, CTI/IoC grounding, and analyst-oriented LLM tasks. Furthermore, the proposed LCCD is specifically designed to overcome the limitations of existing malware datasets for LLM-based malware attribution. Existing datasets typically support either feature-based detection, family classification, API-call analysis, or graph-based modeling, but they do not preserve the complete evidence chain required for analyst-oriented malware reasoning. In contrast, LCCD links each Windows PE sample with complementary reverseengineering artifacts, including decompiled C code, assembly code, CFG/FCG structures, PE metadata, suspicious API evidence, CTI/IoC context, malicious code segment information, vulnerable code/CWE evidence, and vector embeddings. This design enables LLMs to move beyond label prediction and reason over the code, structure, behavior, and threat-intelligence evidence supporting an attribution decision. To the best of our knowledge, LCCD is the first dataset that jointly provides code-centric malware artifacts and structured instruction-tuning data for multitask malware attribution, including malicious code analysis, vulnerability analysis, API behavior reasoning, MITRE ATT&CK mapping, detection guidance, and analyst-ready report generation.

2.2. Non-LLM-Based Malware Detection Before the adoption of LLMs, malware detection and family classification were mainly addressed using signaturebased methods [26], handcrafted static features [27], machine learning [28, 8], deep learning [29], and graph-based representations [4]. In static analysis, researchers commonly First Author et al.: Preprint submitted to Elsevier

extract byte sequences, opcode patterns, imported APIs, PE header fields, entropy values, strings, CFGs, and FCGs to train classifiers for malware detection or family attribution [30, 31, 32, 33, 34, 35]. Moreover, image-based approaches convert binaries into grayscale images and use attention mechanisms to identify discriminative regions for malware family classification [30]. In addition, graphbased approaches model program structure through CFGs and FCGs; for example, CFGExplainer identifies influential CFG nodes or subgraphs for GNN-based malware classification [36]. Although these methods have improved malware detection and classification, they remain largely optimized for prediction and often provide limited analyst-oriented evidence, such as malicious code segment localization and vulnerable code reasoning. Dynamic analysis, on the other hand, executes malware in a controlled environment to observe runtime behaviors such as process creation, file-system activity, registry modification, memory behavior, and network communication [37, 38]. Although this approach provides valuable behavioral evidence, it can be costly, time-consuming, and difficult to scale for large malware collections. Moreover, advanced malware may use evasion techniques, including anti-sandboxing, delayed execution, packing, and environment fingerprinting, to hide malicious behavior during analysis [39]. Consequently, static analysis remains important for early malware triage and large-scale classification [33, 34, 35]. However, non-LLM-based methods often remain sensitive to feature drift, obfuscation, packing, code reuse, and changes in malware family behavior. As a result, they may struggle to identify previously unseen variants, zero-day malware, or samples whose observable features have been modified to evade known detection patterns. This limitation motivates code-centric LLM-assisted frameworks that can combine reverse-engineering artifacts and analyst-oriented reasoning.

Page 3 of 23

LCC-LLM

2.3. LLM-Based Malware Analysis and Cybersecurity Applications Recent studies have increasingly explored LLMs for malware detection, reverse engineering, forensic triage, and cyber threat intelligence. Jelodar et al. [6] reviewed LLM applications in malware code detection, generation, monitoring, reverse engineering, and family analysis, highlighting the growing role of LLMs in understanding malicious code semantics. However, their work is survey-oriented and does not introduce a deployable malware attribution framework or a code-centric benchmark dataset. In addition, several recent studies have focused on Android malware analysis. Feng et al. [15] proposed LLM-MalDetect, which uses stringbased APK features, prompt engineering, and LLM finetuning for Android malware detection. Similarly, Priambodo et al. [40] introduced MalQwen, a LoRA fine-tuned Qwen model for generating Android malware analysis reports from decompiled code and expert-labeled reports. Although these studies demonstrate the usefulness of LLMs for malware detection and report generation, they remain Android-specific and do not address Windows PE malware attribution. Furthermore, for Windows PE malware, Marais et al. [41] proposed a semantic preprocessing approach for LLMbased malware analysis. Their method converts PE files into analyst-readable JSON reports. Additionally, these reports are enriched with static and behavioral features, packer signatures, YARA matches, MITRE ATT&CK mappings, and Malware Behavior Catalog knowledge. This representation improves interpretability for malware classification; however, the work mainly focuses on malware category classification and does not provide a multimodal code-centric dataset or an instruction-tuning corpus for attribution-oriented LLM reasoning. Furthermore, recent studies have examined the robustness, classification reliability, and reverse-engineering capabilities of LLMs in malware analysis. Böke and Torka [16] evaluated LLMbased malware analysis under LLVM-level obfuscation and showed that model performance can degrade under compiler-level transformations, highlighting the need for stronger grounding in low-level reverse-engineering evidence. Similarly, Bai et al. [17] proposed a weighted hierarchical ensemble of LLMs for zero-label malware family classification, improving robustness through decision-level aggregation. However, the output remains primarily a family label rather than a complete analyst-facing evidence chain. In addition, Jelodar et al. [18] introduced LLM4CodeRE for bidirectional assembly-to-source and source-to-assembly translation, demonstrating the value of LLMs for malwareaware reverse engineering. Nevertheless, its focus is decompilation and code translation rather than malware attribution, IoC validation, MITRE mapping, or threat-intelligencegrounded analysis. Overall, prior LLM-based malware studies have advanced Android detection, PE semantic preprocessing, malware report generation, family classification, reverse engineering, memory forensics, and edge deployment. However,

First Author et al.: Preprint submitted to Elsevier

most focus on detection accuracy, report generation, familylabel prediction, forensic summarization, or decompilation. They do not jointly provide a Windows PE-focused benchmark dataset and an evidence-grounded LLM framework. LCC-LLM addresses this gap by combining a code-centric dataset with an expert-system framework for malware attribution, IoC validation, MITRE ATT&CK mapping, vulnerability analysis, containment guidance, and structured malware reporting.

3. Methodology for Creating the Large-Scale Code-Centric Dataset We developed LCCD for instruction-tuning Large Language Models (LLMs) on code-centric tasks, specifically focusing on malware family attribution and malicious code segment identification. The methodology relies on a multistage pipeline that integrates data collection, multimodal feature extraction, vector embedding, semantic analysis, and prompt engineering augmented by Cyber Threat Intelligence (CTI). Fig. 1 illustrates the high-level architecture of this pipeline, tracing the lifecycle of a malware sample from initial ingestion to final quality validation. Through this process, raw binaries are transformed into comprehensive, structured records. The anatomy of these finalized LCCD samples is visually detailed in Fig. 3, while the step-bystep logic driving this transformation is formalized in Algorithm 1. Algorithm 1 LCCD Generation Pipeline Require: DikeDataset 𝐷𝑖𝑘𝑒 , MalwareBazaar 𝑀𝐵 , CTI 𝐶𝑇 𝐼 Ensure: Unified Dataset 𝐿𝐶𝐶𝐷 (Multimodal, Features, & Instruction-Tuned Prompts) 1: // Phase 1: Data Collection & Preprocessing 2:  ← FetchAndFilter(𝐷𝑖𝑘𝑒 ∪ 𝑀𝐵 ) 3: for each malware sample 𝑠 ∈  do 4: // Phase 2: Multimodal Representations 5: 𝑀𝑠 ← ExtractViews(𝑠) 6: // Phase 3: Vector Embedding 7: for overlapping window 𝑤 in 𝑀𝑠 (C, Asm, Hex) do 8: Add Embed(𝑤) to 𝐸𝑠 9: end for 10: Add Embed(𝑀𝑠 (Graphs, SVGs)) to 𝐸𝑠 11: // Phase 4: Static Analysis & Labeling 12: 𝑓𝑠𝑡𝑎𝑡𝑖𝑐 ← ExtractStaticFeatures(𝑀𝑠 ) 13: 𝑓𝑠𝑒𝑚 , score𝑑𝑖𝑓 𝑓 ← MapToTaxonomies(𝑀𝑠 , 𝑓𝑠𝑡𝑎𝑡𝑖𝑐 ) 14: 𝐿𝑟𝑒𝑝 ← QueryCTI(𝐶𝑇 𝐼 , 𝑠) 15: 𝐿𝑖𝑚𝑝 ← CrossReferenceBy(imphash, 𝑠) 16: if (𝐿𝑟𝑒𝑝 ∪ 𝐿𝑖𝑚𝑝 ) ≠ ∅ then 17: label ← StandardizeWithAVClass(𝐿𝑟𝑒𝑝 ∪ 𝐿𝑖𝑚𝑝 ) 18: else 19: label ← “Unknown” 20: end if 21: // Phase 5: RAG & Prompt Engineering 22: 𝑐𝑟𝑎𝑔 ← RetrieveRAGContext(𝐶𝑇 𝐼 , 𝑓𝑠𝑡𝑎𝑡𝑖𝑐 , 𝑓𝑠𝑒𝑚 ) 23: 𝑝𝑝𝑙𝑎𝑛 ← Architect(𝑀𝑠 , 𝑐𝑟𝑎𝑔 ) 24: 𝑟𝑟𝑎𝑤 ← Analyst(𝑝𝑝𝑙𝑎𝑛 ) 25: 𝑟𝑓 𝑖𝑛 ← Judge(𝑟𝑟𝑎𝑤 , 𝑝𝑝𝑙𝑎𝑛 , ground_truth) 26: Add (𝑠, 𝑀𝑠 , 𝐸𝑠 , 𝑓𝑠𝑡𝑎𝑡𝑖𝑐 , 𝑓𝑠𝑒𝑚 , label, 𝑟𝑓 𝑖𝑛 , score𝑑𝑖𝑓 𝑓 ) to 𝐿𝐶𝐶𝐷 27: end for 28: // Phase 6: Quality Assurance 29: 𝐿𝐶𝐶𝐷 ← ValidateAndBackfill(𝐿𝐶𝐶𝐷 ) 30: return 𝐿𝐶𝐶𝐷

Page 4 of 23

LCC-LLM 2) Multi-Modal Representations CFG SVG

3) Vector Embedding

FCG SVG

Graphviz (Graph rendering)

CFG DOT file

1) Data Collection

FCG DOT file

DINOv2 (ViT)

FCG svg vector embeddings

Node2Vec (Algorithm)

FCG adjacency list vector embeddings

CodeT5+ (Code LLM)

C code vector embeddings

Malware Samples Sources

Assembly vector embeddings

Executables (.exe) MalwareBazaar

DikeDataset

Radare2 (Decompiler)

C code

RetDec (Decompiler)

Assembly code

CodeBERT (Code LLM) Hex dump vector embeddings

45k samples

Portable Executable

Raw Binary & Hex Dump

A

4) Static Feature Extraction PE file parser Structural Features

A

5) Semantic Analysis & Feature Extraction Vulnerability Analysis

MITRE

Malicious Code Segment Identification

AlienVault OTX

MISP

6) Knowledge Enhancement via RAG + GraphRAG

7) Prompt Engineering

8) Augmentation

MITRE ATT&CK database

Malware Family Intelligence Database

Architect (llama3.2:3b)

Instruction-Response

Common Weakness Enumeration (CWE) database

Windows API Behavior Database

Analyst (llama3.2:3b)

Judge (llama3.2:3b)

A

9) Quality Assurance & Validation

B

Quality Validator

Metadata

CoT

Training Data (ChatML format)

CoVe

B Difficulty Score

LCCD Dataset MongoDB Database

Figure 1: High-level overview of the LCCD generation pipeline. The multi-stage process spans from raw binary collection (1) through multimodal feature extraction and semantic analysis (2-6), to prompt generation and augmentation (7-8), before final database ingestion (9).

3.1. Data Collection We collected malware samples from the DikeDataset [42] and MalwareBazaar [43], focusing specifically on Windows Portable Executable (PE) files, as shown in Line 2. To ensure temporal relevance and capture recent or ongoing malware campaigns, the MalwareBazaar collection was limited to samples submitted between January 2020 and January 2026. This resulted in a total of 35,000 samples, each uniquely identified by its SHA-256 hash to prevent duplicates and streamline CTI integration. MalwareBazaar provides two methods to fetch malware samples: an API First Author et al.: Preprint submitted to Elsevier

and a data lake that gets updated with batch archives of samples divided by day and month. Due to the vast volume of samples we retrieved, we used the data lake archives to avoid overwhelming MalwareBazaar’s API. Both sources contain a variety of file formats in addition to PE files, so we filtered to only include in the dataset the file extension .exe, even though this format can have multiple extensions like .dll, .sys, .efi. In addition to the file format filtering, we performed an initial precheck of the file headers to remove samples that were broken. We performed this check with the intention of increasing the percentage of Page 5 of 23

LCC-LLM Raw Binary Executable

Preprocessing & Parsing

Unpack

Yes

Is Packed?

No

Disassembly with Capstone

Assembly Code

a high-level abstract syntax tree (AST). This representation helps reconstruct structured loops and conditionals, essential for finally generating the C code. RetDec’s pipeline to convert the binary data into decompiled C code is depicted in Fig. 2. While obfuscation often causes decompilation to fail, our dual-engine approach maximizes data recovery by merging outputs from both tools. Furthermore, Radare2’s native support for legacy and obscure formats ensures successful decompilation where other tools typically fail. With the previous unified decompilation pipeline, we obtained the C code, assembly code, FCG, and CFG. Additionally, we dumped the binary data as hexadecimal (hex) so it can be ingested by an LLM as text. The structural representations were further processed to obtain a visual representation of the topologies as vector images. We did this last conversion using Graphviz due to its native handling of the DOT files that are generated by RetDec, tool maturity, and easy headless integration into our pipeline.

LLVM IR

Binary Lifting & Optimization

3.3. Vector Embedding Strategy

High-Level AST Generation

FCG & CFG

CFG Structuring & Code Emission

C Code

Figure 2: The decompilation pipeline architecture of RetDec.

successful decompilations. We separated the collected files by size to have a greater diversity among samples: Small (≤ 100KB), Medium (≤ 500KB), and Large (≤ 5MB). The smaller samples dominate our dataset with 22,106, followed by the medium ones with 12,192, and lastly the large ones with 394, thus having a ratio of 55:30:1. We decided to include samples following this ratio because of the longer processing time the larger samples take.

3.2. Multimodal Representations We processed the malware samples into different code and structural representations to capture their multifaceted nature (Line 5). Additionally, each representation may capture aspects of the malware that are lost in another one, so analyzing them all enriches the analysis. The transformation is achieved by implementing a unified decompilation pipeline using RetDec [44] as the primary source and Radare2 [45] as fallback and enrichment. RetDec first preprocesses the binary data to identify the file sections, extract debugging information, and unpack it. Following this step, it utilizes the Capstone Engine [46] to disassemble the binary data into assembly code. These assembly instructions are then lifted into LLVM intermediate representation (IR) and optimized, simplifying and reconstructing the logic. RetDec proceeds to translate the LLVM IR into a back-end IR that serves as First Author et al.: Preprint submitted to Elsevier

We then precomputed the vector embeddings for each of the multimodal representations (Lines 7 to 10). While these embeddings will not be used as input for fine-tuning an LLM, they serve as fingerprints for the data. These fingerprints can be used for sorting, searching, cleaning, and visualizing the data in the dataset. For instance, they can enable semantic search in RAG pipelines, as demonstrated by Zhang et al. [47] with TraceRAG, or be used to filter duplicates and retain only high-quality samples, akin to SemDeDup’s semantic deduplication approach of Abbas et al. [48]. We utilized two distinct models to generate embeddings for the multimodal code representations: CodeT5+ [49] and CodeBERT [50]. CodeT5+ was selected to embed the decompiled C code as it is optimized for understanding programming semantics. This model was pre-trained with bimodal text-code data from 8 programming languages, including C. Conversely, we embedded the assembly code and hex dump using CodeBERT. Even though the model was trained on high-level languages, Yuki et al. [51] demonstrated in AsmDocGen the model’s ability to learn assembly code. Their work suggests that CodeBERT’s capacity to capture syntactic and semantic information translates effectively to understanding the unique grammar of low-level code. Extending this rationale, we leverage the model’s selfattention mechanism to capture the patterns and structural dependencies within the hex dump; therefore, treating the byte sequences as a low-level architectural representation of the program logic. These code representations of malware tend to exceed the context window of the embedding models, necessitating a strategy to handle these long sequences. Because it is not possible to process the entire code logic in a single pass, we implemented a 512-token sliding window strategy with a 256-token stride. These overlapping segments ensure that long-range dependencies and semantic indicators are

Page 6 of 23

LCC-LLM LCCD Sample

Code Centric

CTI

C

MITRE

int64_t function_402640(int64_t a1, char* a2...

techniques: T1555.003, T1622, T1106, T1482, ...

Binary 4c 89 f9 48 89 da e8 8b 07 00 00 45 31 c9 45 31

Assembly 0x401088:

48 89 02

mov qword ptr [rdx], rax

AlienVault OTX threat_score: 38.0

technique: system_discovery (T1082)

LCCD Sample Record

malware_family: Gozi techniques: T1570, T1087, T1219, T1082, ... targeted_countries: United States of America industries: Telecom

MISP

Malicious Code Segment snippet: return GetComputerNameW(lpBuffer,...

📄 Stored in

threat_level: Medium malware_family: Ursnif techniques: T1555.003, T1055.001, T1622

Vulnerable Code Segment snippet: memcpy(mem2, (int64_t *)*str, size);

Training Data

cwe: buffer_overflow (CWE-120)

system: You are an expert malware analyst...

Graph

user: Can you attribute this code to a known... assistant: ## Malware Family Attribution... task_type: family_attribution

Control Flow Graph dot: Node1106707506754 -> Node1106707035577;

MongoDB Database

Metadata

svg: <g id="node400123561" class="node">

Function Call Graph

LCCD Dataset

file_hash: 7d29c80a1249a1ec9af0f3047c855778...

dot: Node_function_41b874 [label="{func_41b...

architecture: x86

svg: <polygon fill="black" stroke="black"...

malware_family: Mediyes compiler: borland imports: {msvcrt.dll: [memset, malloc, ...]} strings: ["10.0.18.2", "mydesktopqos.exe", ...]

Figure 3: Anatomy of a finalized LCCD sample record. Each structured entry aggregates code-centric representations, topological graphs, enriched CTI metadata, and the generated instruction-tuning prompt configurations.

captured even if they span across distinct fragments. The embeddings from all the individual chunks are ultimately aggregated via mean pooling to produce the final 768-dimensional vector for each representation. Furthermore, we employed a bimodal strategy that captures both the topological structures for relational data and the spatial features for visual analysis. We mapped the topology of the FCG with Node2Vec [52], a technique that performs random walks across a graph to identify local neighborhoods and structural hubs among functions. To capture these structural dependencies effectively, we configured the model to generate 128-dimensional node embeddings. We simulated 200 random walks per node, with each walk spanning a length of 30 nodes. Additionally, we set up both the return parameter (𝑝) and the in-out parameter (𝑞) to 1.0, making the walks remain unbiased. This balances the exploration of local and tightly connected function clusters with the discovery of broader structural roles. Complementing this strategy, we converted the FCGs into rasterized images to treat the code execution as a visual topology problem and harness established vision techniques. While rasterizing vector graphs inherently causes some information loss, such as dropping explicit node labels and making individual First Author et al.: Preprint submitted to Elsevier

connections difficult to discern in overly dense networks, it enables us to observe macro-level topological shapes that bypass standard textual obfuscation. These visual footprints can reveal distinct structural signatures, such as prominent hubs or recurring geometric formations, that are indicative of specific malware families or categories. We generated 768dimensional vector embeddings from these images using DINOv2 [53], a self-supervised vision model highly adept at recognizing complex structural shapes and visual patterns.

3.4. Threat Intelligence Integration and Profiling Following decompilation, we performed static analysis on the C and assembly code to extract behavioral artifacts without executing the binaries (Line 12). By examining these outputs, we isolated critical features such as imported libraries and function dependencies. Additionally, we mined the code for embedded string literals to uncover IoCs. These artifacts include API names, Command-and-Control (C2) IP addresses and domains, and targeted file paths. This information provides context for understanding the sample’s intended execution flow, serving as key telemetry for threat actor attribution.

Page 7 of 23

LCC-LLM

We analyzed the static features and high-level decompiled C code using a combination of heuristics and standard malware taxonomies from CTI frameworks (Line 14). Specifically, we identified vulnerabilities in the decompiled C code by matching syntactic patterns to those in the Common Weakness Enumeration (CWE) database. Likewise, we precisely identified malicious code segments and their parent functions using a curated database of indicators. Segments exhibiting malicious behaviors were then mapped to MITRE ATT&CK techniques, creating a comprehensive behavior profile for each sample. Family Rarity ω = 0.30

Code Complexity ω = 0.40

Threat Severity ω = 0.30

Belongs to DikeDataset?

No

Use Imphash to derive family from similar samples

Curriculum Scheduler

Figure 4: Difficulty scoring model. The score determines both the augmentation mode applied to each sample and its position in the curriculum-ordered dataset.

Using this aggregate of extracted features, we implemented a multidimensional scoring system to assess the complexity of each sample, as depicted in Fig. 4. By calculating a weighted score that considers the decompiled C code, imports, implemented techniques, malware family rarity, severity of the threat, and level of obfuscation, we assigned each sample both a numeric value and a discrete category. This classification provides a clear progression from trivial to expert-level samples, categorizing them by the inherent difficulty their internal characteristics pose during analysis.

3.5. Automated Labeling and Categorization Pipeline While the samples sourced from the DikeDataset were already labeled, we required a strategy to systematically classify the unlabeled PE files retrieved from MalwareBazaar. For the DikeDataset subset, we opted to utilize the ground truth from the “Malware Detection PE-Based Analysis Using Deep Learning Algorithm Dataset” (malpe_dp) [54], which served as one of DikeDataset’s foundational sources. This substitution was necessary because the original DikeDataset labels only provided broad malware categories rather than specific family names. For the remaining samples, we implemented the labeling pipeline depicted in Fig. 5. We initially queried the MalwareBazaar API using the SHA-256 hash of each sample to retrieve its associated threat report (Line 14). Because these reports do not always provide a conclusive malware family, we corroborated the data with secondary Cyber Threat Intelligence (CTI) sources linked within the reports. This involved analyzing telemetry from dynamic analysis

First Author et al.: Preprint submitted to Elsevier

Query MalwareBazaar API

Yes

Cross-reference with labels from malpe_dl*

MalwareBazaar Report

Vendor Threat Intelligence

No

Queried via Imphash?

Difficulty Score d

Augmentation Pipeline

Malware Sample Hash

No

Conclusive family label?

Yes

Yes

Unknown Family & Category

Normalize family labels with AVClass

Derive malware category from family

Category derived?

Known Family, Unknown Category

Known Family & Category

Figure 5: Flowchart of the malware labeling pipeline. The process determines the family and category of a sample by first checking the local DikeDataset, and subsequently querying the MalwareBazaar API with fallback Imphash lookups for unknown samples. Labels are normalized via AVClass prior to final categorization. (*malpe_dl: Malware Detection PEBased Analysis Using Deep Learning Algorithm Dataset).

sandboxes, such as ANY.RUN and CAPE Sandbox, which are designed to capture complex behavioral signatures. When direct attribution from these reports was inconclusive, we leveraged the import hash (imphash) to identify structural similarities with known samples (Line 15). Unlike cryptographic hashes (e.g., SHA-256) that change entirely with single-bit modifications, an imphash remains consistent across binaries that import the exact same libraries and API functions. While shared imports are not definitive proof of identical behavior, the imphash served as a reliable fallback heuristic for family attribution when all other strategies were exhausted. Once the initial family labels were attributed, we normalized the outputs using AVClass [55], an open-source Python tool designed to standardize malware family names across Page 8 of 23

LCC-LLM

varying antivirus vendors (Line 17). Following normalization, we mapped 2,226 distinct family names to their broader malware categories. To achieve this efficiently, we utilized Gemini 3.1 Pro to automate the categorization, subsequently verifying the accuracy of the mapping through random manual inspections. This family-to-category mapping allowed us to derive the malware classification for each identified family. Despite this rigorous pipeline, a subset of samples remained unclassified, lacking a definitive family or category. These instances were explicitly assigned an “unknown” label at the family and/or category level (Line 19). We deliberately retained these unlabeled samples in the dataset, as the compiled multimodal features and precomputed vector embeddings remain highly valuable for downstream tasks, such as unsupervised clustering, anomaly detection, and exploratory data analysis.

3.6. Knowledge Enhancement via RAG To optimize LCCD for downstream LLM analysis, we structured the extracted intelligence to support both standard semantic RAG and GraphRAG architectures (Line 22). By formatting the dataset to support this dual approach, an analytical framework can retrieve specific definitions via standard RAG while simultaneously using GraphRAG to traverse the complex execution pathways inherent to malware ecosystems. To populate the RAG context for both implementations with authoritative data, we integrated four specialized cybersecurity databases into our retrieval pipeline: • MITRE ATT&CK: Maps malicious behaviors to standardized Tactics, Techniques, and Procedures (TTPs). • CWE Vulnerability: Details software weaknesses and vulnerability patterns. • Windows API Behavior: Documents legitimate Windows API usage patterns, providing a baseline to contrast against their malicious implementations in malware. • Malware Family Intelligence: Profiles known malware families, detailing attributes ranging from technical capabilities and evasion techniques to historical campaign data and threat actor attribution. Once the relevant context is retrieved from these databases, it is stored in LCCD for later use during downstream inference, and simultaneously injected into the prompt engineering stage described in the subsequent section (Section 3.7). This dual-purpose pipeline provides the LLM with the verified domain telemetry necessary to accurately execute its analytical tasks.

3.7. Prompt Engineering and Augmentation To ensure the generation of deep, accurate training data, we implemented a three-stage reasoning and refinement First Author et al.: Preprint submitted to Elsevier

prompt engineering pipeline. This architecture decouples planning from execution and evaluation: • The Architect: Processes raw sample data to generate an analysis protocol. It identifies key technical features for extraction, flags potential edge cases for investigation, and outlines the logical steps required to derive a valid conclusion (Line 23). • The Analyst: Executes the Architect’s protocol to produce a comprehensive technical report, mapping the raw data to the specified output format (Line 24). • The Judge: Performs a comparative audit of the Analyst’s report against the initial plan and the ground truth. It provides qualitative critique and generates the final refined report for inclusion in the training set (Line 25). Additionally, we crafted diverse system and user prompts for each stage to prevent a model instruction-tuned on this dataset from overfitting to specific syntactic structures. Without this diversity, models risk learning to follow rigid prompt templates, failing to generalize to varied human instructions. These prompts were tailored across 12 fundamental analyst task types, including malware family attribution, behavior and intent analysis, vulnerability and risk assessment, and malware classification. To further enrich the dataset and instill deliberate reasoning capabilities within a subsequently fine-tuned model, we augmented a subset of the generated training data using CoT [56] and CoVe [57] techniques. By applying these methodologies to the finalized outputs of the Judge, we ensured the resulting instruction pairs guide the model to either explicitly decompose the analytical tasks into a series of steps or rigorously verify its own findings before producing a final classification. This complete prompt engineering workflow, including an illustrative example of the generated prompts and responses, is depicted in Fig. 6. Finally, we assigned a difficulty score to all generated prompts based on the inherent characteristics of the analyzed samples. To categorize prompts into Beginner, Intermediate, or Expert tiers, we evaluated three sample-specific metrics: C code length, total function count, and the number of implemented techniques. These metrics directly correlate with analytical complexity: extended code length expands the search space for relevant segments; a high function count obscures control flow tracking, increasing the likelihood of losing execution context; and a dense concentration of techniques complicates the isolation of specific malicious behaviors.

3.8. Quality Assurance and Validation We integrated an automated quality assurance pipeline to ensure the integrity, reliability, and uniformity of LCCD across five critical dimensions (Line 29): • Format: Ensures strict structural compliance, verifying that all generated outputs adhere to expected schemas and predefined templates. Page 9 of 23

LCC-LLM

Prompt

Architect

Malware Classification Analysis Plan 1. Process Discovery & Injection: Investigate data collection and injection techniques. 2. API Focus: Analyze GetTickCount, OpenProcess, CryptEncrypt. 3. Behavioral Indicators: Look for registry persistence and command execution.

[SYSTEM]: You are a senior malware analyst architect. [USER]: Create a structured analysis plan for TASK TYPE: malware_classification. Focus on PRIORITY_AREAS, API_FOCUS, and BEHAVIORAL_INDICATORS based on the provided sample metadata (Family: gandcrab).

Prompt

Response

Analyst

Malware Classification Analysis Report 1. Ransomware Encryption (T1486): 90.0% Confidence. Evidence: CryptEncrypt, CryptGenKey indicates encrypting files for ransom. 2. DLL Injection (T1055.001): 70.0% Confidence. Evidence: LoadLibraryA.

[SYSTEM]: You are an expert malware analyst. [USER]: Execute the analysis plan and provide detailed findings based on the provided MALICIOUS CODE SEGMENTS (e.g., [CRITICAL] ransomware_encryption (T1486)).

Prompt

Response

Judge

Response

[SYSTEM]: You are a senior quality reviewer. [USER]: Evaluate and refine the malware analysis report. Score accuracy, completeness, and evidence quality. Output ONLY the refined, production-ready analysis.

[Refined Malware Classification Analysis Report] (Polished findings with specific MITRE mappings and CWE-78 vulnerability detections) Overall Score: 0.8

Chain-of-thought augmentation

Chain-of-verification augmentation

Prompt

Prompt

[USER]: Rewrite the analysis to include explicit step-by-step reasoning. Show the thought process that leads to each conclusion based on the assembly code.

[USER]: Add a VERIFICATION section that critically evaluates the analysis. Assess confidence based on ACTUAL evidence strength. Point out unsupported assertions.

Response

Response

Step 1: Analyze Process Discovery... Upon examining the code, I notice LoadLibrary for DLL injection. Step 2: Investigate API Focus... CryptEncrypt indicates ransomware capabilities.

Registry Persistence: 80% (Strong evidence via RegCreateKeyExW). Ransomware Encryption: 40% (Lacking concrete evidence beyond base APIs).

Figure 6: Multi-stage prompt engineering pipeline for malware classification. The workflow progresses sequentially through Architect (planning), Analyst (execution), and Judge (evaluation and refinement) roles to generate an initial, high-quality analysis. The refined output is subsequently processed through parallel augmentation modules—Chain-of-Thought and Chain-ofVerification—to enhance reasoning transparency and factual grounding. Note that the prompt and response texts depicted in each node have been significantly condensed for illustrative purposes; the full operational strings contain extensive system context, raw code segments, and strict formatting constraints.

• Content: Validates completeness and length requirements, ensuring no generated reports are truncated or missing mandatory analytical sections.

• Quality: Assesses response quality and formatting indicators, ensuring the LLM-generated text remains technically accurate and logically sound.

• Label: Audits metadata and classification consistency, confirming that the assigned malware families and categories precisely align with the upstream attribution pipeline.

A unique challenge in generating malware-centric datasets is the frequent triggering of LLM safety guardrails. Because the analytical tasks require parsing malicious code and exploring exploit techniques, models will occasionally refuse to generate a response. During the prompt execution phase, we implemented strict validation checks to detect and reject empty outputs or standard refusal strings (e.g., “I cannot assist with this request”). We automatically discarded any generation attempt that resulted in a safety refusal and

• Balance: Monitors macro-level distribution and diversity metrics across the dataset to flag unintended systemic biases introduced during data collection.

First Author et al.: Preprint submitted to Elsevier

Page 10 of 23

LCC-LLM

flagged the sample for iterative reprompting, preventing the inclusion of non-informative data. Furthermore, processing large-scale multimodal data across distributed pipelines inevitably introduces the risk of data loss due to concurrency collisions, API rate limits, or network timeouts. To mitigate this, we implemented robust backfill mechanisms that retroactively query the necessary APIs, regenerate the corrupt representations, or retrigger the LLM generation sequence. This process ensures the finalized dataset is completely exhaustive and strictly consistent.

3.9. Dataset Statistics 3.9.1. Dataset Composition and Extraction Yield To evaluate the efficacy of our multimodal extraction pipeline, we analyzed the generation yield across all 34,692 samples in LCCD. As detailed in Table 2, the dataset exhibits a highly successful feature extraction rate, reflecting the robustness of our automated backfill and quality assurance mechanisms. The pipeline achieved near-perfect extraction of assembly code via Radare2 (99.95%), demonstrating the tool’s exceptional capacity to disassemble binaries even when decompilers like RetDec fail. While the decompilation of C code via RetDec naturally faced a slightly higher attrition rate (93.84%) due to the inherent complexities of reversing heavily obfuscated or packed binaries, the intersection of samples successfully processed by both primary tools remained exceptionally high at 93.79%. Consequently, 92.25% of the total dataset successfully generated all requisite base embeddings. This comprehensive feature overlap ensures that the vast majority of the dataset contains the complete representations required for advanced downstream LLM tasks. Table 2 LCCD Extraction Yield and Composition Category

Metric

Count

Yield Rate (%)

Dataset Composition

Total Samples Malicious Samples Benign Samples

34,692 33,710 982

100.00% 97.17% 2.83%

Tooling Success

Radare2 Processing RetDec Processing Both Tools Successful

34,676 32,555 32,539

99.95% 93.84% 93.79%

Decompiled C Code Assembly Code FCG & CFG Complete Base Embeddings

32,555 34,675 34,271 32,005

93.84% 99.95% 98.79% 92.25%

Extracted Modalities

3.9.2. Instruction-Tuning Data Distribution To construct a robust instruction-tuning dataset for downstream LLM training, we generated a total of 183,070 sample-prompt pairs. As detailed in Table 3, these pairs are distributed across 12 distinct analytical tasks. The distribution intentionally favors foundational cybersecurity operations, with Malware Classification (13.64%), Code Analysis (11.32%), and Malware Class Detection (11.24%) comprising the largest subsets. This weighting ensures the model develops a strong baseline in fundamental binary analysis before tackling more nuanced, open-ended tasks like Detection Guidance or Intent Analysis. First Author et al.: Preprint submitted to Elsevier

The generation pipelines were similarly balanced to provide both structural rigidity and reasoning depth. Approximately half of the dataset (53.25%) was generated using rigorous template-filling to establish strict formatting compliance and baseline factual accuracy. The remaining (46.75%) leveraged our advanced multi-agent framework. To teach the model step-by-step logic, the final 12.94% of the dataset was routed through the augmented multi-agent pipeline. We intentionally partitioned this augmented subset into an evenly distributed 1:1:1 ratio across three reasoning configurations: a baseline unaugmented output (4.32%), Chain-of-Thought (4.31%), and Chain-ofVerification (4.30%). This perfectly balanced ablation subset ensures that an instruction-tuned model can learn advanced, multi-step reasoning pathways without artificially overfitting to a single verification methodology. Table 3 Distribution of the Samples in LCCD Category

Total Samples

Percentage (%)

Task Type Malware Classification Code Analysis Malware Class Detection Malware Family Detection Risk Assessment Vulnerability Detection API Behavior Threat Identification Detection Guidance Family Attribution Intent Analysis Technique Explanation

24,978 20,728 20,583 14,843 14,614 14,600 14,562 13,854 11,269 11,266 11,138 10,635

13.64 11.32 11.24 8.11 7.98 7.98 7.95 7.57 6.16 6.15 6.08 5.81

Generation Pipeline Template Filling Architect-Analyst-Judge Architect-Analyst-Judge (Augmented)

97,488 61,897 23,685

53.25 33.81 12.94

Reasoning Augmentation Base Prompting (No Augmentation) Chain-of-Thought (CoT) Chain-of-Verification (CoVe)

167,301 7,894 7,875

91.38 4.31 4.30

3.9.3. Class Distribution and Structural Balance LCCD has 624 different malware families represented spread across 21 malware categories. There exists a class imbalance driven by the real-world distribution in which in-the-wild malware is not balanced. Malware campaigns can dominate the threat landscape for long periods of time leading to a bigger sample size of that respective family. We intentionally preserved the inherent class imbalance to ensure an authentic representation of the malware ecosystem. Nonetheless, we still evaluated the structural balance by calculating the Shannon Entropy (𝐻) for each category. This value lets us measure the uncertainty and diversity in the categories with respect to the malware families and the samples belonging to each of them. The Shannon Entropy is calculated as: 𝐻 =−

𝑆 ∑

𝑝𝑖 log2 𝑝𝑖

(1)

𝑖=1

where 𝑆 is the total number of distinct malware families and 𝑝𝑖 the proportion of samples in the 𝑖-th family Page 11 of 23

LCC-LLM

External Datasets 35k Portable Executable Samples Fenrir v2.0

Benign

Malware

~1,000

~34,000

LCCD Dataset

Dataset Generation Pipeline

CVE-Chat

Raw Data

Instruction Data Beginner Intermediate

Complementary Task Generation

Expert

CPT Domain Adaptation

Trendyol CyberSec

SFT

Evaluation

Fine-tuned LLM Model

Instruction Tuning

Inference, similarity scoring, tests

Base Model: DeepSeek-R1-Distill-Qwen-14B

Curriculum Learning (Difficulty Sorted Tasks)

Figure 7: Overview of the proposed training methodology framework. The pipeline illustrates the data flow from raw Portable Executable (PE) samples through the Dataset Generation Pipeline to the LCCD. The extracted intelligence is partitioned into unstructured Raw Data for Continued Pre-Training (CPT) and stratified Instruction Data. The Instruction Data is augmented with external datasets and fed into the Supervised Fine-Tuning (SFT) phase utilizing a Curriculum Learning schedule to incrementally adapt the foundational DeepSeek-R1-Distill-Qwen-14B model.

A higher 𝐻 value indicates greater diversity among the families within that category, while a category dominated by a single family will have a score very close to zero. However, the Shannon entropy is sensitive to the total number of families (𝑆), and in LCCD, the ratio of families per category varies drastically. Because the maximum possible entropy (𝐻𝑚𝑎𝑥 ) increases logarithmically with 𝑆, directly comparing the Shannon Entropy between categories would not give a fair view of relative balance. To establish a standardized metric for comparison among the categories, we utilize Pielou’s Evenness (𝐽 ′ ). This metric normalizes the Shannon Entropy 𝐻 by dividing it by the maximum possible entropy for that specific category’s family count 𝑆: 𝐽′ =

𝐻 log2 𝑆

(2)

A Pielou’s Evenness score of 1 indicates a perfectly uniform distribution of samples across all families in the category, whereas a score approaching 0 indicates an imbalance dominated by a single family. Table 4 depicts the malware categories present in the dataset, organized by their number of samples. To depict the dataset distribution, we included the top family belonging to the category alongside the proportion it represents. In the case of categories in which an unknown label dominates, we included the second top family for reference. These last cases happen when we were First Author et al.: Preprint submitted to Elsevier

able to label the samples with a category but not pinpoint the exact malware family to which the sample belongs. The last column shows Pielou’s Evenness values, except for the “Benign” category, which is omitted as it contains only a single class.

4. Proposed Methodology This section presents the proposed LCC-LLM methodology for code-centric malware attribution and multi-task static malware analysis. As shown in Fig. 7, the framework begins with approximately 35K PE samples, including benign and malicious executables, which are processed through the LCCD generation pipeline. LCCD is organized into two main streams: raw data and instruction data. The raw data stream supports Continued Pre-Training (CPT) for domain adaptation, while the instruction data stream supports Supervised Fine-Tuning (SFT) using curriculum learning with beginner, intermediate, and expert-level tasks. In addition, external cybersecurity datasets, including Fenrir v2.0, Trendyol CyberSec, and CVE-Chat, are used for complementary task generation to improve task diversity and domain coverage. The resulting instruction corpus is used to adapt DeepSeek-R1-Distill-Qwen-14B [58] for malware attribution, malicious code segment identification, vulnerability analysis, IoC extraction, MITRE ATT&CK mapping, and structured report generation. To reduce training Page 12 of 23

LCC-LLM Table 4 Intra-Class Diversity and Pielou’s Evenness Across LCCD Malware Categories Category

Total Samples

Total Families (𝑆)

Top Family

Top Family %

Pielou’s Evenness (𝐽 ′ )

Rat Ransomware Stealer Rogueware

6,026 5,720 4,546 4,401

89 105 94 2

AsyncRAT Gandcrab AgentTesla Winwebsec

32.8% 58.5% 22.9% 100.0%

0.481 0.300 0.631 0.003

Loader Banker Unknown Backdoor

3,291 2,296 1,653 1,633

72 21 18 68

Unknown/Amadey Zbot Unknown/Boxter Unknown/Meterpreter

54.4% / 7.4% 91.6% 98.6% / 0.1% 21.4% / 18.0%

0.473 0.161 0.039 0.619

Adware Botnet Benign Trojan

1,555 1,512 982 363

23 50 1 38

Mediyes ZeroAccess Benign Casdet

93.2% 45.8% 100.0% 11.3%

0.128 0.520 N/A 0.855

Miner Hacktool Dropper Worm

189 136 99 85

7 26 7 14

Coinminer Cobalt Babadeda Mofksys

61.9% 30.9% 65.7% 69.4%

0.576 0.759 0.550 0.497

Keylogger Virus Wiper Spyware

69 51 47 21

4 8 10 5

VIP Neshta KillMBR Kimsuky

79.7% 78.4% 29.8% 47.6%

0.519 0.442 0.889 0.766

Rootkit Grayware Exploit

10 4 3

6 2 2

Nemesis AdLoad JuicyPotato

30.0% 75.0% 66.7%

0.917 0.811 0.918

Algorithm 2 Evidence-Grounded LCC-LLM Inference Framework Require: User query 𝑄, optional malware sample 𝑃 , fine-tuned model 𝑀 Ensure: Analyst-ready response 𝑅 and optional structured report 1: 𝑇 ← ∅ ⊳ Static-analysis transcript 2: 𝑅 ← ∅ ⊳ Final analyst response 3: 𝑄𝑛 ← Normalize(𝑄) 4: 𝜅 ← 𝐻(𝑄𝑛 , 𝑃 , 𝑀) ⊳ Cache key 5: if CacheHit(𝜅) then 6: return CachedResponse(𝜅) 7: end if 8: if 𝑃 ≠ ∅ then 9: 𝜏 ← DetectFileTypeByMagicBytes(𝑃 ) 10: 𝑇 ← RunStaticToolChain(𝑃 , 𝜏) 11: end if 12: Γ ← HybridRetrieve(𝑄𝑛 , 𝑇 ) 13: 𝑄∗ ← FormatPrompt(𝑄𝑛 , Γ, 𝑇 ) 14: 𝜎 ← MatchSpecialist(𝑄∗ ) 15: if 𝜎 ≠ ∅ then 16: 𝑅 ← RunSpecialistAgent(𝜎, 𝑄∗ , Γ, 𝑇 ) 17: else 18: 𝑅 ← GenerateWithLLM(𝑀, 𝑄∗ ) 19: end if 20: 𝑅 ← VerifyAndValidate(𝑅, Γ, 𝑇 ) 21: if 𝑃 ≠ ∅ then 22: 𝑅 ← AttachStructuredEvidence(𝑅, 𝑇 ) 23: 𝑟𝑒𝑝 ← GenerateStructuredReport(𝑃 , 𝑅, 𝑇 ) 24: end if 25: CacheStore(𝜅, 𝑅) 26: return 𝑅

overhead, the model is fine-tuned using QLoRA, enabling efficient adaptation while preserving the reasoning and codeunderstanding capabilities of the base model. Algorithm 2 summarizes the overall inference procedure of the proposed LCC-LLM framework. The process begins by initializing the response state and static analysis transcript, followed by query normalization and cache-key generation (Lines 1 to 4). This step avoids redundant computation when the same query, model, and malware sample have already been analyzed. If a malware sample is provided, the framework identifies the file type through magic-byte First Author et al.: Preprint submitted to Elsevier

Algorithm 3 Hybrid Retrieval and Static Tool Orchestration Require: Query 𝑄, optional sample transcript 𝑇 , retrieval collections  Ensure: Grounded context bundle Γ 1: Γ ← ∅ 2: for each collection 𝐶𝑖 ∈  do 3: 𝑆BM25 ← BM25Search(𝑄, 𝐶𝑖 ) 4: 𝑆dense ← DenseSearch(Encode(𝑄), 𝐶𝑖 ) 5: 𝑆rrf ← ReciprocalRankFusion(𝑆BM25 , 𝑆dense ) 6: 𝑆ranked ← CrossEncoderRerank(𝑄, 𝑆rrf ) 7: Γ ← Γ ∪ TopK(𝑆ranked ) 8: end for 9: if 𝑇 ≠ ∅ then 10: 𝐸𝑐 ← ExtractCodeEvidence(𝑇 ) ⊳ decompiled code, assembly, CFG/FCG 11: 𝐸𝑠 ← ExtractSecurityEvidence(𝑇 ) ⊳ suspicious APIs, Capa matches, PE metadata 12: Γ ← Γ ∪ 𝐸𝑐 ∪ 𝐸 𝑠 13: end if 14: Γ ← RemoveDuplicates(Γ) 15: Γ ← FilterLowConfidence(Γ) 16: return Γ

inspection and executes the corresponding static-analysis chain (Lines 8 to 11). The resulting transcript contains the reverse-engineering evidence required for grounded analysis, including PE metadata, decompiled code, assembly, CFG/FCG artifacts, suspicious APIs, and tool-generated findings. The retrieved knowledge and tool-derived evidence are then integrated into a grounded context bundle Γ and used to construct an evidence-enriched prompt 𝑄∗ (Lines 12 to 13). Based on the query intent, the framework either invokes a specialist agent or the fine-tuned LCC-LLM model for response generation (Lines 14 to 19). The generated response is not returned directly; instead, it is passed through verification and validation to reduce unsupported claims and improve factual reliability (Line 20). Finally, when a malware sample is available, structured evidence is attached to the response and an analyst-oriented report can be generated (Lines 21 to 24). This design ensures that the final output

Page 13 of 23

LCC-LLM

Algorithm 4 Verification-Guided Output Validation Require: Generated response 𝑅, grounded context Γ, tool transcript 𝑇 Ensure: Verified and quality-gated response 𝑅∗ 1: 𝐼 ← ExtractIndicators(𝑅) ⊳ MITRE, CVE, CWE, CAPEC, CVSS, IP, hash, URL, email, port 2: for each indicator 𝑖 ∈ 𝐼 do 3: 𝑣𝑖 ← ValidateIndicator(𝑖) 4: 𝑅 ← AttachProvenanceLabel(𝑅, 𝑖, 𝑣𝑖 ) ⊳ verified, valid-unverified, or invalid 5: end for 6: 𝑑1 ← InformationDensity(𝑅) 7: 𝑑2 ← StructuralCompleteness(𝑅) 8: 𝑑3 ← RepetitionPenalty(𝑅) 9: 𝑑4 ← LengthSanity(𝑅) 10: 𝑑5 ← EvidenceAlignment(𝑅, Γ, 𝑇 ) 11: 𝜎 ← WeightedQualityScore(𝑑1 , 𝑑2 , 𝑑3 , 𝑑4 , 𝑑5 ) 12: if 𝜎 ≥ 𝜏accept then 13: 𝑅∗ ← 𝑅 14: else if 𝜎 ≥ 𝜏retry then 15: 𝑅∗ ← RegenerateWithFeedback(𝑅, Γ, 𝑇 ) 16: else 17: 𝑅∗ ← GenerateFromValidatedTemplate(Γ, 𝑇 ) 18: end if 19: 𝑅∗ ← AttachVerifiedEvidence(𝑅∗ , Γ, 𝑇 ) ⊳ IoCs, MITRE mappings, suspicious APIs, code-level evidence 20: return 𝑅∗

is not only generated by an LLM, but also grounded in retrieved cybersecurity knowledge and deterministic reverseengineering evidence. Next, Algorithm 3 describes the retrieval and evidenceconstruction mechanism used to support grounded malware reasoning. The algorithm first initializes an empty context bundle Γ and iterates over the available cybersecurity knowledge collections (Lines 1 to 2). For each collection, lexical retrieval based on BM25 is applied to capture exact security identifiers, such as CVE IDs, CWE entries, MITRE ATT&CK technique, hashes, and API names (Line 3). In parallel, dense retrieval is used to identify semantically related malware behaviors, threat descriptions, and contextual evidence that may not share exact keywords with the query (Line 4). The two retrieval outputs are then combined using reciprocal-rank fusion and refined using cross-encoder reranking to select the most relevant evidence (Lines 5 to 7). When a static-analysis transcript is available, the retrieval context is further enriched with code-level and securitylevel evidence extracted directly from the analyzed sample (Lines 9 to 13). This includes decompiled code, assembly, CFG/FCG artifacts, suspicious API evidence, Capa matches, and PE metadata. Finally, duplicate and low-confidence contexts are removed before returning the final context bundle (Lines 14 to 16). This step is important because it enables the framework to combine external cybersecurity knowledge with sample-specific reverse-engineering evidence, thereby reducing reliance on unsupported LLM generation. Algorithm 4 presents the verification-guided validation stage applied after response generation. The algorithm first extracts security-relevant indicators from the generated response, including MITRE ATT&CK techniques, CVEs, CWEs, CAPEC entries, CVSS vectors, IP addresses, hashes, URLs, email addresses, and ports (Line 1). Each extracted indicator is then validated and annotated with a provenance label indicating whether it is verified, valid-butunverified, or invalid (Lines 2 to 5). This mechanism is designed to reduce hallucinated IoCs, incorrect mappings, First Author et al.: Preprint submitted to Elsevier

and unsupported attribution claims. In addition to indicator validation, the response is evaluated using five quality dimensions: information density, structural completeness, repetition penalty, length sanity, and evidence alignment (Lines 6 to 11). These dimensions are combined into a weighted quality score 𝜎, which determines whether the response should be accepted, regenerated with feedback, or reconstructed from a validated template (Lines 12 to 18). The final response is then enriched with verified IoCs, MITRE mappings, suspicious APIs, and code-level evidence before being returned to the analyst (Lines 19 to 20). This validation process strengthens the reliability of LCC-LLM by ensuring that the final output is traceable, evidencealigned, and suitable for analyst-facing malware attribution workflows.

4.1. Infrastructure All training and evaluation experiments were conducted on the IBEX High-Performance Computing (HPC) cluster at King Abdullah University of Science and Technology (KAUST). The cluster provides access to heterogeneous GPU resources; however, as a shared academic platform, experimental design must balance computational capacity, job-queue availability, and allocation constraints. For the main training configuration, we used a single SLURM compute-node equipped with four NVIDIA A100 GPUs, each with 80 GB of memory, together with 300 GB of system RAM and 32 CPU cores, as summarized in Table 5. This configuration provides 320 GB of aggregate GPU memory and supports efficient fine-tuning of the selected 14-billion-parameter backbone model. To reduce the computational and memory overhead, we adopted 4bit QLoRA, which freezes the quantized base model and updates only a small number of trainable adapter parameters. This configuration enables memory-efficient domain adaptation while preserving the reasoning and code-understanding capabilities of the base model. The use of QLoRA substantially reduces the hardware requirements compared with fullparameter fine-tuning and improves the practicality of reproducing the proposed training pipeline on moderate multiGPU academic infrastructure. Nevertheless, larger batch sizes, faster convergence, and shorter wall-clock training times benefit from high-memory GPUs such as the A100. Table 5 SLURM resource allocation for the 1 × 4 A100 configuration. Resource

Value

Nodes GPUs per node CPUs per task Memory per node

1 4× NVIDIA A100 (80 GB) 32 300 GB

4.2. Implementation Details Pipeline Objectives: The combination of CPT and SFT in our training pipeline systematically adapts the foundational model to the malware analysis domain before aligning it to execute specific analyst workflows. Page 14 of 23

LCC-LLM

Detection & Classification Malicious Code Segment

Malware Family Classification

Malicious API Detection

Vulnerable Code Detection

Response and Remediation

Deep Analysis and Reverse Engineering

Patch Management

Binary PE Analysis

Containment & Remediation

Code Behavior Analysis

Threat Intelligence and Mapping

Assessment and Scoring

MITRE Technique Mapping

Threat Assessment

Figure 8: The 10 core task types implemented in the task generator. The tasks are grouped into five distinct categories covering the threat analysis lifecycle, from initial detection through deep analysis and remediation.

Table 6 CPT Training Configuration Parameter

Value

Epochs Learning Rate Warmup Ratio Effective Batch Size Max Grad Norm Weight Decay Optimizer Gradient Checkpointing DeepSpeed Total Steps Eval Steps Save Steps Save Total Limit Final Train Loss Final Eval Loss Final Train Accuracy

3 (early stopped at ∼1.2) 1e-5 (cosine decay) 5% 32 (4 × 2 × 4 GPUs) 1.0 0.01 AdamW (fused) Enabled ZeRO-2 4,200 100 200 3 0.9224 1.1770 0.8027

Data Partitioning and Export: From LCCD, we exported two distinct data partitions as Parquet files to leverage Table 7 SFT Training Configuration Parameter

Value

Epochs Learning Rate Warmup Effective Batch Size Max Grad Norm Weight Decay Optimizer NEFTune alpha Curriculum Learning Sequence Packing Total Steps Eval Steps Final Train Loss Final Eval Loss Final Train Accuracy Final Eval Accuracy

2 5e-5 (peak, cosine decay) Warm-up to peak LR 16 (2 × 4 × 2 GPUs) 0.5 0.01 AdamW (fused) 10.0 Enabled (difficulty-sorted) Enabled (max 4096 tokens) 1,550 100 0.1471 0.1541 0.9539 0.9537

First Author et al.: Preprint submitted to Elsevier

their native compression and the fast query times enabled by columnar projection. These partitions served distinct purposes across the successive stages of our model fine-tuning. For the CPT stage (Section 4.2) and data preprocessing (Section 4.2), we utilized data from approximately 4,000 raw samples, encompassing the code variants (Section 3.2), metadata, and static analysis artifacts (Section 3.4). For the SFT stage, we instead sampled 8,000 System/User/Assistant instruction triplets. Although LCCD contains a significantly larger volume of generated data, we restricted the training sample size to accommodate computational constraints. While reducing the number of training samples may incrementally impact peak accuracy, this sampling strategy provides an optimal trade-off between maintaining robust model performance and ensuring highly efficient training cycles. Data Preprocessing: Using the raw sample data, we dynamically generated additional instruction-response pairs (based on the tasks outlined in Fig. 8) to augment the data statically generated during the initial pipeline (Section 3). We mixed these dynamic and static sets of training data to achieve three primary objectives. First, this mixture prevents the model from over-fitting to the specific syntactic templates of the static data. Second, it increases reasoning path diversity, forcing the model to learn alternative methods for reaching the same analytical conclusion. Finally, this mixture strikes a balance between high-quality static “anchor” pairs, which ground the model against hallucinations, and dynamic “explorer” pairs that introduce the variance necessary for robust generalization. The merged training data was then passed through a deduplication and normalization pipeline. This ensured schema consistency and filtered out any samples failing our quality criteria prior to splitting the data into the final training, evaluation, and test sets. Continued Pre-Training: CPT performs the initial domain adaptation by training the model directly on raw executable representations (detailed hyperparameter configurations are provided in Table 6). This unsupervised phase teaches the model the unique vocabulary, syntax patterns, and structural conventions of reverse-engineered code. It is imperative to perform this adaptation prior to task-specific instruction tuning to ensure the binary artifacts included in the prompts are accurately parsed by the model. Supervised Fine-Tuning: Building upon the CPT foundation, SFT aligns the model to follow complex malware analysis directives. The model is trained on our curated dataset using ChatML-formatted prompts and tasks generated from external datasets Fenrir v2.0 [59], Trendyol Cybersecurity Defense Instruction-Tuning [60], and CVE ChatStyle Multi-Turn Cybersecurity [61] using the configuration outlined in Table 7. With this training, the model learns to generate structured intelligence reports, map identified behaviors to specific techniques, and analyze decompiled code to identify vulnerabilities and malicious segments. Evaluation: After the CPT and SFT stages, an evaluation stage follows, starting with a subset of 30 samples. These samples are assessed to determine if they hit a mean Page 15 of 23

LCC-LLM

Figure 9: Continued Pre-Training (CPT) dynamics over 4,200 optimization steps. (A) Training and evaluation loss curves, demonstrating a steady reduction from an initial 2.89 to a final 0.92. (B) Mean token accuracy, which increased from 0.609 to 0.803, indicating successful adaptation to the vocabulary and syntax of the decompiled code. (C) Gradient norm progression. An initial gradient spike (31.8) stabilized rapidly within the first 100 steps, confirming the efficacy of the learning rate warm-up phase. (D) The learning rate schedule, featuring a linear warm-up peaking at 1.0 × 10−5 followed by a cosine decay.

semantic similarity score of at least 0.70 with respect to reference responses, serving as an initial checkpoint designed to measure the baseline quality of the model. The evaluation framework then executes an evaluation across 43 distinct task types using a Hugging Face pipeline. Performance is measured using a dual-metric approach: every response is scored for overall semantic similarity using the all-MiniLML6-v2 SentenceTransformer, while task-specific functions extract additional metrics. To ensure the model is practical for the analysis of real-world scenarios, the framework subjects the model to advanced testing across five complex scenarios. Each scenario presents a multi-step analysis challenge that requires the model to synthesize domain knowledge across multiple task types. The proposed scenarios are: Code Injection Analysis, Trojanized PE Detection, MultiVuln SAST, Family Classification, and Ransomware Containment.

5. Experimental Results and Discussion Continued Pre-Training: The CPT phase successfully adapted the base model to the specialized domain of malware analysis, as illustrated by the training dynamics in Fig. 9. Over the course of approximately 4,200 optimization steps, First Author et al.: Preprint submitted to Elsevier

the model exhibited steady and stable convergence. The training and evaluation loss decreased significantly from an initial value of 2.89 to 0.92, indicating that the model effectively internalized the underlying structure of the dataset with the raw samples. This domain adaptation is further corroborated by the token accuracy, which climbed from a baseline of roughly 0.61 to over 0.80. This steady increase demonstrates the model’s growing proficiency in parsing and predicting the unique vocabulary and syntactic patterns of the diverse code representations of a malware sample. Furthermore, despite the inherent complexity of unstructured binary artifacts, the training regime remained highly stable; an initial gradient norm spike of 31.8 was rapidly mitigated within the first 100 steps, proving the efficacy of the linear learning-rate warm-up phase. Supervised Fine-Tuning: Following the initial domain adaptation, the SFT phase aligned the model to execute specific analytical workflows, with the progression detailed in Fig. 10. Utilizing a difficulty-sorted curriculum over 1,550 steps, the model demonstrated rapid instruction alignment, marked by an 87% reduction in loss (from 1.178 down to 0.147). Crucially, the evaluation loss and accuracy tracked closely with the training metrics throughout the entire run,

Page 16 of 23

LCC-LLM

Figure 10: Supervised Fine-Tuning (SFT) dynamics over 1,550 steps using the difficulty-sorted curriculum. (A) Training and evaluation loss, exhibiting an 87% reduction from 1.178 to 0.147. (B) Token accuracy progression, rising from 0.740 to a final 0.954. The tight correlation between training and evaluation metrics throughout the run indicates minimal overfitting. (C) The learning rate schedule utilizing a cosine decay, peaking at 5.0 × 10−5 . (D) Output entropy decay, which drops sharply from 0.945 to 0.154, illustrating the model’s increasing confidence in generating precise, structured malware analysis and vulnerability reports.

indicating that the model generalized well to the task structures without overfitting to the specific training templates. By the conclusion of the SFT phase, token accuracy reached 0.954. Additionally, the output entropy experienced a sharp decline from 0.945 to 0.154. This steep entropy reduction is a critical indicator of behavioral alignment, demonstrating that the model transitioned from generating diverse, exploratory tokens to producing highly confident, deterministic, and tightly structured threat intelligence reports. Task Specific Evaluation: Fig. 11 illustrates the mean semantic similarity across the 10 core malware-analysis tasks, providing a baseline measure of how well the finetuned model adopts the stylistic and structural conventions of expert malware analysis. While semantic similarity effectively captures the model’s ability to reason and format responses appropriately, it is insufficient for tasks demanding rigid factual precision, such as classification tasks. A model can generate a highly convincing, structurally perfect analysis yielding high similarity while simultaneously failing to identify the exact classification or label that the task requires. To address this, we supplemented the semantic evaluation of Fig. 11 with other appropriate metrics for three core tasks requiring strict entity extraction, as detailed in Table 8. These supplementary metrics reveal a contrast between structural alignment and factual precision. For instance, while MITRE ATT&CK technique Mapping achieved a First Author et al.: Preprint submitted to Elsevier

Table 8 Specialized Task Evaluation: Semantic Similarity vs. ExactMatch Metrics Task Type

Sim.

Specialized Metrics

Notes

MITRE ATT&CK technique Mapping

0.761

Precision: 0.526 Recall: 0.357 F1: 0.426

Exact technique ID matching is harder than semantic alignment.

Malware Family Classify

0.655

Exact Accuracy: 0.0%

Model provides relevant analysis even when label doesn’t match exactly.

Vulnerable Code Detect

0.506

CWE F1: 0.0

Needs more structured CWE training data.

strong semantic similarity of 0.761, its F1 score was only 0.426, indicating difficulty in pinpointing exact T-codes despite understanding the broader attack mechanics. Similarly, Malware Family Classification reached a 0.655 similarity score despite a 0.0% exact accuracy. In this specific task, the model consistently outputted the generic term “classification” rather than accurately identifying specific family Page 17 of 23

LCC-LLM

inference context windows or targeted brevity constraints during training to accommodate these detailed analytical thought processes.

6. Conclusion

Figure 11: Performance profile across 10 core malware-analysis tasks. Performance is measured via semantic alignment (SentenceTransformer cosine similarity) between model predictions and reference responses. The solid blue line represents the model’s score on each specific axis. The dashed red baseline indicates the aggregate average similarity score (0.634) calculated across all 43 evaluated task types. Vertices extending beyond the baseline (e.g., MITRE ATT&CK technique Mapping, Malware Family Classification) indicate relative strengths, largely driven by the model’s pattern recognition capabilities. Points falling inside the baseline (e.g., Threat Assessment) highlight relative weaknesses in tasks requiring more nuanced reasoning.

We introduced LCCD and a tailored model training framework designed to advance the application of Large Language Models in automated malware analysis. While existing datasets offer fragmented views of malicious software, LCCD bridges this gap by unifying code-centric representations, static analysis artifacts, graph topologies, embeddings for RAG deployment, and curated instruction-response pairs into a single, cohesive resource. This combination equips researchers with the tools necessary to perform truly holistic analyses of malware behavior. By incorporating these diverse representations, our training pipeline successfully facilitated the domain adaptation of a foundational LLM, enabling it to parse and reason over complex binary artifacts. While our fine-tuned model underperformed in tasks that required specific label identification or string extraction, it was able to produce accurate and well-structured reports that provide relevant insights for cybersecurity analysts. Ultimately, LCCD provides the opensource cybersecurity community with a robust foundation for benchmarking, pre-training, and deploying advanced AIdriven defense mechanisms.

Data Availability names. Vulnerable Code Detection also struggled with exact retrieval, scoring a 0.0 F1 for specific CWE IDs. This divergence between metrics highlights a critical insight: while the model successfully learned the language and analytical flow of malware reports during training, achieving high reliability in extracting exact string segments, categorical IDs, or labels will require further targeted alignment. Complex Scenarios Evaluation: To assess practical utility, the model was evaluated against five complex scenario prompts (full generated responses are provided in Appendix A). Qualitative analysis of these responses revealed a strong adherence to CoT and CoVe reasoning patterns, which were deliberately augmented into the SFT dataset. In multiple scenarios, the model executed explicit, stepby-step reasoning preambles prior to outputting structured intelligence. In the Family Classification scenario, this learned behavior was made explicitly visible by the model generating a “</think>” token immediately before transitioning into its cleanly formatted markdown report. While this deliberate reasoning process enabled the model to correctly identify key indicators, the verbosity inherent to CoT and CoVe processing frequently caused the model to reach the token limit during inference, resulting in truncated final outputs. This indicates that while the SFT phase successfully aligned the model to utilize advanced reasoning and verification pathways, practical deployment will require either expanded First Author et al.: Preprint submitted to Elsevier

The Large-Scale Code-Centric Dataset used in this study is publicly available through the KAUST Repository at http s://repository.kaust.edu.sa/items/28da4411-6099-40ed-b ece-0848e76ed517. The dataset can also be accessed using

the DOI: 10.25781/KAUST-Z05OK.

References [1] Xiang Ling, Lingfei Wu, Jiangyu Zhang, Zhenqing Qu, Wei Deng, Xiang Chen, Yaguan Qian, Chunming Wu, Shouling Ji, Tianyue Luo, et al. Adversarial attacks against windows pe malware detection: A survey of the state-of-the-art. Computers & Security, 128:103134, 2023. [2] Georgios Xenos and Dimitrios Serpanos. Cross-silo federated learning in security operations centers for effective malware detection: G. xenos, d. serpanos. International Journal of Information Security, 24 (4):185, 2025. [3] Jiaxuan Geng, Junfeng Wang, Zhiyang Fang, Yingjie Zhou, Di Wu, and Wenhan Ge. A survey of strategy-driven evasion methods for pe malware: Transformation, concealment, and attack. Computers & Security, 137:103595, 2024. [4] Hassan Jalil Hadi, Yue Cao, Sifan Li, Naveed Ahmad, and Mohammed Ali Alshara. Fcg-mfd: Benchmark function call graphbased dataset for malware family detection. Journal of Network and Computer Applications, 233:104050, 2025. [5] Ashley Q Williamson and Michael Beauparlant. Malware reverse engineering with large language model for superior code comprehensibility and ioc recommendations. 2024. [6] Hamed Jelodar, Samita Bai, Parisa Hamedi, Hesamodin Mohammadian, Roozbeh Razavi-Far, and Ali Ghorbani. Large language model (llm) for software security: Code analysis, malware analysis, reverse engineering. arXiv preprint arXiv:2504.07137, 2025.

Page 18 of 23

LCC-LLM [7] Ori Or-Meir, Nir Nissim, Yuval Elovici, and Lior Rokach. Dynamic malware analysis in the modern era—a state of the art survey. ACM Computing Surveys (CSUR), 52(5):1–48, 2019. [8] Daniele Ucci, Leonardo Aniello, and Roberto Baldoni. Survey of machine learning techniques for malware analysis. Computers & Security, 81:123–147, 2019. [9] Manuel Egele, Theodoor Scholte, Engin Kirda, and Christopher Kruegel. A survey on automated dynamic malware-analysis techniques and tools. ACM computing surveys (CSUR), 44(2):1–42, 2008. [10] Vaibhavi Kalgutkar, Ratinder Kaur, Hugo Gonzalez, Natalia Stakhanova, and Alina Matyukhina. Code authorship attribution: Methods and challenges. ACM Computing Surveys (CSUR), 52(1): 1–36, 2019. [11] Wenbo Guo, Zhengzi Xu, Chengwei Liu, Cheng Huang, Yong Fang, and Yang Liu. An empirical study of malicious code in pypi ecosystem. In 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 166–177. IEEE, 2023. [12] Yong Fang, Chaoyi Huang, Minchuan Zeng, Zhiying Zhao, and Cheng Huang. Jstrong: Malicious javascript detection based on code semantic representation and graph neural network. Computers & Security, 118:102715, 2022. [13] Yangruibo Ding, Yanjun Fu, Omniyyah Ibrahim, Chawin Sitawarin, Xinyun Chen, Basel Alomair, David Wagner, Baishakhi Ray, and Yizheng Chen. Vulnerability detection with code language models: How far are we? arXiv preprint arXiv:2403.18624, 2024. [14] Jamal Al-Karaki, Muhammad Al-Zafar Khan, and Marwan Omar. Exploring llms for malware detection: Review, framework design, and countermeasure approaches. arXiv preprint arXiv:2409.07587, 2024. [15] Ruirui Feng, Hui Chen, Shuo Wang, Md Monjurul Karim, and Qingshan Jiang. Llm-maldetect: A large language model-based method for android malware detection. IEEE Access, 2025. [16] Ekin Böke and Simon Torka. ” digital camouflage”: The llvm challenge in llm-based malware detection. Journal of Systems and Software, page 112646, 2025. [17] Samita Bai, Hamed Jelodar, Tochukwu Emmanuel Nwankwo, Parisa Hamedi, Mohammad Meymani, Roozbeh Razavi-Far, and Ali A Ghorbani. Automated malware family classification using weighted hierarchical ensembles of large language models. arXiv preprint arXiv:2604.02490, 2026. [18] Hamed Jelodar, Samita Bai, Tochukwu Emmanuel Nwankwo, Parisa Hamedi, Mohammad Meymani, Roozbeh Razavi-Far, and Ali A Ghorbani. Llm4codere: Generative ai for code decompilation analysis and reverse engineering. arXiv preprint arXiv:2604.06095, 2026. [19] Hamed Jelodar, Mohammad Meymani, Samita Bai, Roozbeh RazaviFar, and Ali A Ghorbani. Sban: A framework & multi-dimensional dataset for large language model pre-training and software code mining. arXiv preprint arXiv:2510.18936, 2025. [20] Antonio Nappa, M Zubair Rafique, and Juan Caballero. The malicia dataset: identification and analysis of drive-by download operations. International Journal of Information Security, 14(1):15–33, 2015. [21] Royi Ronen, Marian Radu, Corina Feuerstein, Elad Yom-Tov, and Mansour Ahmadi. Microsoft malware classification challenge. arXiv preprint arXiv:1802.10135, 2018. [22] Hyrum S Anderson and Phil Roth. Ember: an open dataset for training static pe malware machine learning models. arXiv preprint arXiv:1804.04637, 2018. [23] Richard Harang and Ethan M Rudd. Sorel-20m: A large scale benchmark dataset for malicious pe detection. arXiv preprint arXiv:2012.07634, 2020. [24] Limin Yang, Arridhana Ciptadi, Ihar Laziuk, Ali Ahmadzadeh, and Gang Wang. Bodmas: An open dataset for learning based temporal analysis of pe malware. In 2021 IEEE Security and Privacy Workshops (SPW), pages 78–84. IEEE, 2021. [25] Hesamodin Mohammadian, Griffin Higgins, Samuel Ansong, Roozbeh Razavi-Far, and Ali A Ghorbani. Explainable malware detection through integrated graph reduction and learning techniques. Big Data Research, page 100555, 2025.

First Author et al.: Preprint submitted to Elsevier

[26] Giancarlo Fortino, Claudia Greco, Antonella Guzzo, and Michele Ianni. Sigil: a signature-based approach of malware detection on intermediate language. In European symposium on research in computer security, pages 256–266. Springer, 2023. [27] Jueun Jeon, Byeonghui Jeong, Seungyeon Baek, and Young-Sik Jeong. Static multi feature-based malware detection using multi sppnet in smart iot environments. IEEE Transactions on Information Forensics and Security, 19:2487–2500, 2024. [28] Joseph Gardiner and Shishir Nagaraja. On the security of machine learning in malware c&c detection: A survey. ACM Computing Surveys (CSUR), 49(3):1–39, 2016. [29] Mohana Gopinath and Sibi Chakkaravarthy Sethuraman. A comprehensive survey on deep learning based malware detection techniques. Computer science review, 47:100529, 2023. [30] Hiromu Yakura, Shinnosuke Shinozaki, Reon Nishimura, Yoshihiro Oyama, and Jun Sakuma. Malware analysis of imaged binary samples by convolutional neural network with attention mechanism. In Proceedings of the Eighth ACM Conference on Data and Application Security and Privacy, pages 127–134. ACM, March 2018. [31] Amira, Abdelouahid Derhab, Elmouatez Billah Karbab, and Omar Nouali. A survey of malware analysis using community detection algorithms. ACM Computing Surveys, 56(2):1–29, 2023. [32] M. Gopinath and Sibi Chakkaravarthy Sethuraman. A comprehensive survey on deep learning based malware detection techniques. Computer Science Review, 47:100529, 2023. [33] Edward Raff, Jon Barker, Jared Sylvester, Robert Brandon, Bryan Catanzaro, and Charles K. Nicholas. Malware detection by eating a whole EXE. In Workshops at the Thirty-Second AAAI Conference on Artificial Intelligence, 2018. [34] Edward Raff, Richard Zak, Russell Cox, Jared Sylvester, Paul Yacci, Rebecca Ward, Anna Tracy, Mark McLean, and Charles Nicholas. An investigation of byte n-gram features for malware classification. Journal of Computer Virology and Hacking Techniques, 14:1–20, 2018. [35] Borja Molina-Coronado, Usue Mori, Alexander Mendiburu, and Jose Miguel-Alonso. Towards a fair comparison and realistic evaluation framework of android malware detectors based on static analysis and machine learning. Computers & Security, 124:102996, 2023. [36] Wai Weng Lo, Siamak Layeghy, Mohanad Sarhan, Marcus Gallagher, and Marius Portmann. Graph neural network-based android malware classification with jumping knowledge. In 2022 IEEE Conference on Dependable and Secure Computing (DSC), pages 1–9. IEEE, June 2022. [37] Rami Sihwail, Khairuddin Omar, and K. A. Zainol Ariffin. A survey on malware analysis techniques: Static, dynamic, hybrid and memory analysis. International Journal of Advanced Science, Engineering and Information Technology, 8(4-2):1662–1671, 2018. [38] Shubham Agarwal and Gaurav Raj. FRAME: Framework for real time analysis of malware. In 2018 8th International Conference on Cloud Computing, Data Science & Engineering (Confluence), pages 14–15. IEEE, 2018. [39] Ori Or-Meir, Nir Nissim, Yuval Elovici, and Lior Rokach. Dynamic malware analysis in the modern era—a state of the art survey. ACM Computing Surveys, 52(5):1–48, 2019. [40] Tegar Ganang Satrio Priambodo, Angela Oryza Prabowo, Annisa Dwi Puspitarini, Raihan Adam Handoyo Winarso, Nur Aisyah, Mohammad Yoga Pratama, Diana Purwitasari, and Baskoro Adi Pratomo. Malqwen: Fine tuned llm for static android malware analysis report. IEEE Access, 13:208483–208497, 2025. [41] Benjamin Marais, Tony Quertier, and Grégoire Barrue. Semantic preprocessing for llm-based malware analysis. arXiv preprint arXiv:2506.12113, 2025. [42] George-Andrei Iosif. DikeDataset, 2021. URL https://github.com/i osifache/DikeDataset. original-date: 2021-03-10T10:59:27Z. [43] Abuse.ch. MalwareBazaar | Malware sample exchange. URL https: //bazaar.abuse.ch/.

Page 19 of 23

LCC-LLM [44] Avast Software. RetDec: A Retargetable Machine-Code Decompiler, March 2026. URL https://retdec.com/. original-date: 2017-1212T09:04:24Z. [45] Radare Org. Radare2: Libre Reversing Framework for Unix Geeks, March 2026. URL https://github.com/radareorg/radare2. originaldate: 2012-07-03T07:42:26Z. [46] Nguyen Anh Quynh. Capstone Engine, March 2026. URL https: //github.com/capstone- engine/capstone. original-date: 2013-1127T02:32:11Z. [47] Guangyu Zhang, Xixuan Wang, Shiyu Sun, Peiyan Xiao, Kun Sun, and Yanhai Xiong. TraceRAG: A LLM-Based Framework for Explainable Android Malware Detection and Behavior Analysis, September 2025. URL h t tp : / / a r x i v . o r g / a b s / 2 5 0 9 . 0 8 8 65. arXiv:2509.08865 [cs]. [48] Amro Abbas, Kushal Tirumala, Dániel Simig, Surya Ganguli, and Ari S. Morcos. SemDeDup: Data-efficient learning at web-scale through semantic deduplication, March 2023. URL http://arxiv. org/abs/2303.09540. arXiv:2303.09540 [cs]. [49] Yue Wang, Hung Le, Akhilesh Gotmare, Nghi Bui, Junnan Li, and Steven Hoi. CodeT5+: Open Code Large Language Models for Code Understanding and Generation. In Houda Bouamor, Juan Pino, and Kalika Bali, editors, Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, pages 1069– 1088, Singapore, December 2023. Association for Computational Linguistics. doi: 10.18653/v1/ 2023.emnlp- main.68. URL https://aclanthology.org/2023.emnlp-main.68/. [50] Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, and Ming Zhou. CodeBERT: A Pre-Trained Model for Programming and Natural Languages. In Trevor Cohn, Yulan He, and Yang Liu, editors, Findings of the Association for Computational Linguistics: EMNLP 2020, pages 1536–1547, Online, November 2020. Association for Computational Linguistics. doi: 10.18653/v1/2020.findings-emn lp.139. URL https://aclanthology.org/2020.findings-emnlp.139/. [51] Jesia Yuki, Mohammadhossein Amouei, Benjamin C. M. Fung, Philippe Charland, and Andrew Walenstein. AsmDocGen: Generating Functional Natural Language Descriptions for Assembly Code. pages 35–45, March 2026. ISBN 978-989-758-706-1. doi: 10.5220/ 0012761400003753. URL https://www.scitepress.org/Link.aspx?d oi=10.5220/0012761400003753. [52] Aditya Grover and Jure Leskovec. node2vec: Scalable Feature Learning for Networks. In Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, KDD ’16, pages 855–864, New York, NY, USA, August 2016. Association for Computing Machinery. ISBN 978-1-4503-4232-2. doi: 10.1145/2939672.2939754. URL https://dl.acm.org/doi/10.1145/2 939672.2939754. [53] Maxime Oquab, Timothée Darcet, Théo Moutakanni, Huy Vo, Marc Szafraniec, Vasil Khalidov, Pierre Fernandez, Daniel Haziza, Francisco Massa, Alaaeldin El-Nouby, Mahmoud Assran, Nicolas Ballas, Wojciech Galuba, Russell Howes, Po-Yao Huang, Shang-Wen Li, Ishan Misra, Michael Rabbat, Vasu Sharma, Gabriel Synnaeve, Hu Xu, Hervé Jegou, Julien Mairal, Patrick Labatut, Armand Joulin, and Piotr Bojanowski. DINOv2: Learning Robust Visual Features without Supervision, February 2024. URL http://arxiv.org/abs/2304.07193. arXiv:2304.07193 [cs]. [54] Anh Pham Tuan, An Tran Hung Phuong, Nguyen Vu Thanh, and Toan Nguyen Van. Malware Detection PE-Based Analysis Using Deep Learning Algorithm Dataset, June 2018. URL https://doi.org/10 .6084/m9.figshare.6635642. [55] Malicia Lab. AVClass, February 2023. URL https://github.com/mal icialab/avclass. original-date: 2016-07-01T16:57:31Z. [56] Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, brian ichter, Fei Xia, Ed Chi, Quoc V Le, and Denny Zhou. Chain-ofThought Prompting Elicits Reasoning in Large Language Models. In Advances in Neural Information Processing Systems, volume 35, pages 24824–24837. Curran Associates, Inc., 2022. URL https:

13524ecf4f15af0f7b31abca4-Paper-Conference.pdf. [57] Shehzaad Dhuliawala, Mojtaba Komeili, Jing Xu, Roberta Raileanu, Xian Li, Asli Celikyilmaz, and Jason Weston. Chain-of-Verification Reduces Hallucination in Large Language Models. In Lun-Wei Ku, Andre Martins, and Vivek Srikumar, editors, Findings of the Association for Computational Linguistics: ACL 2024, pages 3563– 3578, Bangkok, Thailand, August 2024. Association for Computational Linguistics. doi: 10.18653/v1/2024.findings-acl.212. URL https://aclanthology.org/2024.findings-acl.212/. [58] Daya Guo and et al Yang. DeepSeek-R1 incentivizes reasoning in LLMs through reinforcement learning. Nature, 645(8081):633–638, September 2025. ISSN 1476-4687. doi: 10.1038/s41586-025-09422 -z. URL https://www.nature.com/articles/s41586-025-09422-z. [59] Alican Kiraz. Fenrir v2.0 — Cybersecurity Instruction-Tuning Dataset, October 2025. URL https://huggingface.co/datasets/ AlicanKiraz0/Cybersecurity-Dataset-Heimdall-v2.0. [60] Trendyol Security Team. Trendyol Cybersecurity Defense Instruction-Tuning Dataset v2.0, July 2025. URL h t t p s : //huggingface.co/datasets/Trendyol/Trendyol- Cybersecurity -Instruction-Tuning-Dataset.

[61] ansulev and Alican Kiraz. CVE Chat-Style Multi-Turn Cybersecurity Dataset (1999–2025), March 2026. URL https://huggingface.co/d atasets/ansulev/All-CVE-Chat-MultiTurn-1999-2025-Dataset.

//proceedings.neurips.cc/paper_files/paper/2022/file/9d56096

First Author et al.: Preprint submitted to Elsevier

Page 20 of 23

LCC-LLM

A. Advanced Testing Scenario Outputs

Step 1: File Triage File characteristics:

This appendix provides the raw, unedited outputs generated by the fine-tuned model during the testing phase. The responses highlight the model’s adherence to Chainof-Thought reasoning prior to generating structured reports. Note that several responses were truncated upon reaching the maximum token limit.

- Size: 3,392,815 bytes

A.1. Code Injection Analysis Execution Time: 514.2s | Word Count: 719 Response:

- Architecture: x86_64 - Compiler: MSVC 19.28 - Entry point: 0x820F - Functions detected: 130 Step 2: Code & Behavior Analysis Examining decompiled code (273 functions) for: - Process manipulation: No - Network API: No

Okay, so I’m trying to understand this malicious DLL code that uses VirtualAlloc, CreateRemoteThread, and anti-debug techniques. I’m not super experienced with reverse engineering, but I’ll do my best to break it down.

- Registry API: Yes

First, I know that VirtualAlloc is used to allocate memory in a process. In legitimate software, this is often used for things like allocating buffers or data structures. But in malware, it can be used for more nefarious purposes, like allocating space for stolen data or creating a buffer overflow to execute malicious code.

- MITRE ATT&CK mapping

Next, CreateRemoteThread is a Windows API function that creates a thread in another process. This can be used by malware to inject code into a legitimate process, allowing it to execute malicious actions without being detected. I remember reading that this is a common technique used in banking trojans and other types of malware. The anti-debug techniques in the code are designed to make it difficult for debuggers or reverse engineers to analyze the malware. Things like timing checks, API call patterns, and memory access patterns are used to detect when a debugger is attached. If the malware detects a debugger, it might terminate itself or take other actions to evade detection. Looking at the code, I can see that it’s using these APIs in a way that suggests it’s trying to hide its presence. For example, the VirtualAlloc call is followed by a check to see if the memory allocation was successful. If it wasn’t, the malware might terminate itself or take other actions to avoid detection. The CreateRemoteThread call is also suspicious because it’s creating a thread in another process without any obvious legitimate purpose. This could be used to inject malicious code into a legitimate process, allowing the malware to execute actions without being detected. The anti-debug techniques are implemented using timing checks and API call patterns. For example, the malware might make a series of API calls in quick succession, which could be

A.2. Trojanized PE Detection Execution Time: 99.2s | Word Count: 82 Response: First Author et al.: Preprint submitted to Elsevier

Step 3: Indicator Identification Examining: - API usage patterns - Behavioral indicators Step 4: Assessment & Classification Based on the above analysis: Classification: AgentTesla (Downloader) Threat Level: Low Malicious

A.3. Multi-Vuln SAST Execution Time: 546.8s | Word Count: 663 Response: Alright, so I’m trying to analyze this C code for vulnerabilities. The code is part of a daemon, which means it’s a background service running on the system. My goal is to find any buffer overflows, format string vulnerabilities, command injections, integer overflows, or double-free issues. First, I’ll look through the code to identify any obvious buffer overflow scenarios. Buffer overflows can occur when an application writes data beyond the bounds of a buffer, which can lead to code execution or data corruption. In C, this is common because of manual memory management. Looking at the code, I see several instances of ‘memcpy‘. For example, ‘memcpy(&v1, &v1, (int32_t)&v1);‘ This line seems suspicious because it’s copying data from one location to another without checking the bounds. I should verify if the source and destination buffers are of appropriate sizes and if there’s a risk of overlapping. Next, I notice a ‘strcpy‘ function call: ‘strcpy((char *)str, (char *)str2);‘ This is another potential buffer overflow risk because it doesn’t check the length of the source string. If ‘str2‘ is longer than ‘str‘, this could lead to a buffer overflow. I also see a ‘sprintf‘ function: ‘sprintf((char *)str, (char *)format, (int32_t)v1);‘ This is a format string vulnerability because it uses user input (‘v1‘) in a formatted output function without proper validation. Page 21 of 23

LCC-LLM An attacker could potentially inject malicious code using this vulnerability.

Classification: Keylogger malware

Looking further, I find an instance of ‘malloc‘: ‘malloc(0x40000000);‘ This is a memory allocation function, but I should check if the allocated memory is properly validated. If the allocation fails, it could lead to a null pointer dereference.

Malware Family: Keylogger

Another point of interest is the ‘free‘ function call: ‘free(NULL);‘ Freeing a null pointer is undefined behavior and can lead to crashes or security vulnerabilities. I should verify if this is intentional or a mistake. I also notice some suspicious API calls, such as ‘CreateThread‘ and ‘O

A.4. Family Classification Execution Time: 291.5s | Word Count: 356 Response: Alright, let’s tackle this malware classification task. The sample is a PE32+ executable with some suspicious imports and behaviors. First, I’ll start by examining the file characteristics. The file size is 3,111,896 bytes, which is quite large. Typically, larger files might contain more malicious code or be designed to evade detection through complexity. The architecture is x86, which is standard, but the presence of 128 functions might indicate a moderate level of complexity. Looking at the imports, there are 20 suspicious ones. The top 3 by frequency are InternetConnectA, WSAStartup, and connect. These are related to network communication, which is a common feature in malware. The presence of CreateFileA and ReadFile suggests the malware might interact with files or network data. Behavioral indicators include network activity, registry modifications, and process creation. The malware establishes outgoing connections, which could be for command and control (C2) communication. Registry modifications might involve creating or deleting keys, potentially for persistence or configuration storage. The MITRE ATT&CK technique mappings are T1071 (Application Layer Protocol) and T1547 (Privilege Escalation). T1071 is relevant due to the network communication indicators, while T1547 might not be directly applicable here unless there’s evidence of privilege escalation. Putting it all together, this malware sample exhibits characteristics typical of a keylogger with C2 beaconing capabilities. The large file size and moderate complexity suggest it’s designed to evade detection through complexity and network communication. </think> Malware Classification Report

Threat Level: Low Behavioral Indicators: * Network activity (establishing outgoing connections) * Registry modifications (creating or deleting

A.5. Ransomware Containment Execution Time: 495.7s | Word Count: 719 Response: Okay, so I’m trying to figure out how to contain this ransomware that’s encrypting files on a shared drive. The user mentioned SMB lateral movement, so I guess the ransomware is spreading over the network. I’m not super experienced with incident response, but I’ll try to break this down step by step. First, I think I need to understand the current situation. What exactly are the indicators of this ransomware? Is it a known variant? I remember that ransomware often encrypts files with extensions like.encrypted,.locked, or specific cipher types. Maybe I should look for those patterns in the shared drive. Next, I should assess the affected systems and network shares. Which machines are infected? Are there specific directories being targeted? It might help to map out the file system changes over time to see when the encryption started. Then, network traffic analysis. I’m not sure how to do this without specific tools, but maybe I can look for unusual SMB activity—like multiple login attempts, directory traversals, or file transfers. If the ransomware is spreading, there might be connections to other machines. Containment is the next step. I think isolating the infected machine is crucial to prevent further spread. Maybe disconnecting it from the network or blocking its IP address. Also, if the ransomware is using scheduled tasks or services, I should disable those to stop execution. For eradication, I need to remove the ransomware. That means deleting the executable files, scripts, or services. I should also scan all affected machines with updated antivirus software to catch any remaining malware. Recovering encrypted files is tricky. I don’t know if the ransomware uses known ciphers, but maybe there are decryption tools available. I should check if the attackers provide a decryption key, but that’s probably not reliable. Alternatively, maybe some files can be recovered from backups. To prevent future incidents, I need to patch any vulnerabilities the ransomware

Sample: PE32+ executable (keylogger imports, C2 beaconing, persistence via Run key) First Author et al.: Preprint submitted to Elsevier

Page 22 of 23

LCC-LLM

Figure 12: Real-time LCC-LLM chatbot prototype for interactive malware triage and analyst-oriented malware attribution.

B. Real-Time LCC-LLM Chatbot Prototype A real-time chatbot prototype was developed to demonstrate the practical deployment of LCC-LLM as an analystfacing malware-analysis expert system. The chatbot allows analysts to interactively query malware samples and request explanations related to malware attribution, malicious code segments, suspicious APIs, IoCs, MITRE ATT&CK mappings, vulnerability analysis, and containment guidance. The chatbot is connected to the proposed LCC-LLM pipeline, where retrieved cybersecurity knowledge, static-analysis evidence, verification, and quality-gated reasoning are combined to generate structured responses.

First Author et al.: Preprint submitted to Elsevier

Page 23 of 23

LCC-LLM

Figure 13: Real-time LCC-LLM chatbot prototype for interactive malware triage and analyst-oriented malware attribution.

First Author et al.: Preprint submitted to Elsevier

Page 24 of 23