Behavior-Centric Malware Classification with Fine-Grained Malicious Logic Localization

arXiv:2609.38390 · cs.CR · Submitted 2026-09-29 · Read on arXiv

Listen

Radio episode about this paper

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: Today's paper: "Behavior-Centric Malware Classification with Fine-Grained Malicious Logic Localization".

Elias: Effective malware analysis requires understanding not only whether a program is malicious, but also which behaviors it exhibits and where those behaviors originate in the code.

Nadia: First, who's behind it and why it matters.

Paper summary: Nadia: So we're talking about the paper "Behavior-Centric Malware Classification with Fine-Grained Malicious Logic Localization," which tackles how to understand not just if malware is bad, but exactly what actions it performs and where in the code those actions are happening.

Elias: Right, so the core idea seems to be moving away from black-box detection towards a framework that decomposes samples into behaviors and tracks those behaviors back to specific code regions. It’s about localization, which is really important for understanding the actual malicious logic involved.

Priya: From a privacy and measurement standpoint, I'm interested in how this framework handles the data collection aspect; what kind of evidence are they actually gathering that is meaningful?

Nadia: Exactly. The paper proposes this behavior-centric analysis framework to achieve several things: accurately classifying malware by modeling these behavior traces, building robustness against structural changes in malware variants, creating representations that are discriminative for similar families, and providing explainability so we don't end up with decisions that are totally black boxes.

Elias: That focus on localization sounds critical because understanding the origin of a malicious action is what separates sophisticated analysis from just flagging something as suspicious. The methodology involves starting with a PE file and extracting function-level evidence before building these behavioral subgraphs.

Priya: And I see the process starts by static parsing to get an initial capability view, followed by generating a control-flow graph using tools like angr to map out those basic blocks and call relationships for that interprocedural view. What does that initial mapping actually tell us about the potential malicious intent?

Nadia: It maps out the basic blocks and their call relationships, which then allows them to map each API into a coarse taxonomy of intent categories, like process or thread control or file activity. Then they use context-sensitive backward slicing from those security-relevant system API calls to trace code regions back to their entry points, yielding an isolated behavior subgraph.

Elias: That tracing mechanism sounds like it’s designed to reconstruct the control and data dependency chains for each specific behavior, which is a deep dive into how the malware actually functions. But they also mention manually annotating basic blocks after this slicing to provide that fine-grained supervision for both classification and localization.

Priya: So they are not just relying on what the API calls suggest, but actively inspecting those subgraphs to determine which ones genuinely correspond to malicious objectives versus benign scaffolding, which gives them a grounded behavioral prior. What about the scoring mechanism?

Nadia: They assign two related measures: a raw, unbounded integer maliciousness score computed at the basic-block level from weighted API roles plus bonuses for suspicious patterns, and then they normalize that into a float threat score between zero and one computed at the behavior-path level to serve as an explicit supervision signal.

Paper summary: Elias: Having that normalized threat score acting as an active signal in the Transformer branch, reshaping the representation's magnitude ahead of core model layers sounds like a sophisticated way to prioritize behavior-critical regions during semantic processing. That’s a clever integration of the structural and behavioral data points.

Priya: And when you move into feature engineering, how are they handling that raw assembly data? Are they using something specific to make it usable for deep learning, especially considering compiler variations can mess up simple tokenization?

Nadia: They apply normalization and tokenization to mitigate the variability across different compiler versions before generating dense semantic embeddings for each basic block. Then these are augmented with the manual threat score, creating a score-aware embedding that feeds into the model.

Elias: That custom Tiny Transformer Encoder generates those embeddings, and then you get two complementary views: a structural view where blocks are nodes connected by edges encoding execution order along the entry-to-sink trace, and a sequence view where behavior embeddings are mean-pooled into single vectors for an ordered sequence.

Priya: The dual representation—the structural graph view versus the sequential behavior vector stack—does it help capture different aspects of the malware's operation? Does one view handle the control flow better than the other?

Nadia: They use a dual architecture where a Behavior Transformer branch processes that ordered sequence of behavior vectors, while a Graph Neural Network branch processes each individual behavior subgraph, where node features are rescaled by that threat score to amplify those critical regions.

Elias: That GNN branch aggregating node embeddings into a single graph-level representation before passing it to a linear classifier seems like it’s designed to capture the structural dependencies within the behavior graphs, which complements the semantic analysis from the Transformer branch.

Priya: So, when you combine these two representations—the Transformer's sequence view and the GNN's structural view—how do they actually make their final decision on family classification? Is it a simple weighted average?

Nadia: The final classification uses late fusion at the decision level where the Transformer outputs a single logit vector per sample, and the GNN produces one logit vector per behavior graph. They aggregate these by taking the elementwise maximum across all of the sample’s graph-level predictions to get a UID-level GNN prediction.

Elias: And then they combine those two vectors through weighted linear interpolation governed by a scalar weight picked during validation to yield the final family prediction, and they report achieving ninety-nine point eight seven percent accuracy. That level of consistency across the fusion method is something to watch closely.

Priya: Speaking of consistency, I'm thinking about the implications for real-world detection systems; if this framework can localize malicious logic with that high degree of accuracy, what does that mean for defenders trying to build more effective defenses?

Paper summary: Nadia: It means moving beyond just catching known signatures or simple behavioral patterns and actually understanding the precise sequence of actions leading to a classification. If we can pinpoint exactly which basic blocks are responsible for the malicious intent, we can target those specific logic paths directly.

Elias: That level of detail in localization is powerful for cryptographers because it helps us analyze the assumptions underlying a piece of code; if we know *why* a certain sequence of blocks executes, we can better assess the security implications of that execution path.

Priya: From a privacy angle, I'm curious about what kind of data they actually used for training this system; did it rely heavily on real-world execution traces or were there synthetic ones involved in generating those behavior graphs?

Nadia: The paper utilizes a modified, distributed Cuckoo sandbox running on parallel virtual machines to record the sequence and frequency of API calls and their input arguments during execution. These traces are then combined with signature-based features drawn from AV-vendor malware encyclopedias for classification.

Elias: That combination of dynamic traces and static signatures is interesting; it sounds like they’re trying to bridge the gap between observing behavior in a controlled environment and leveraging known malicious patterns.

Priya: The paper does mention that they are looking at security-relevant system API calls as anchors, which suggests the data collection focuses on actions that interact with the operating system in meaningful ways, rather than just noise. What limitations do the authors point out regarding this data source?

Nadia: They state a limitation plainly: they rely on manual inspection to provide that grounded behavioral prior by inspecting representative subgraphs across families to determine what constitutes genuinely malicious objectives versus benign scaffolding.

Elias: So the manual annotation step is essential because the automated system can't inherently tell which observed behavior is truly harmful without that human input guiding the initial labeling process.

Priya: And since this framework decomposes malware into behaviors and links them back to code regions, what are the practical implications for how we approach threat hunting in a large enterprise environment?

Nadia: The implication is that instead of just looking at a list of suspicious files, security teams could analyze the behavioral subgraphs of an unknown sample and immediately see which specific execution paths correspond to high-risk activities.

Elias: It suggests that future automated analysis tools might need to prioritize tracing these behavior graphs rather than just looking for isolated indicators, focusing on the interconnected chains of events.

Priya: Overall, this work on "Behavior-Centric Malware Classification with Fine-Grained Malicious Logic Localization" seems to be about providing a structured way to move from observing 'what' happened to understanding precisely 'where' and 'why' it happened within the code.

Conclusion: Nadia: So, we've been digging into this paper, "Behavior-Centric Malware Classification with Fine-Grained Malicious Logic Localization," which essentially takes malware samples and breaks them down into specific behaviors tied directly to the code they originate from.

Elias: And I'm still thinking about how they manage to link those high-level behaviors back to the actual basic blocks, which is a tricky feat from a cryptographic standpoint because it requires such fine-grained structural awareness.

Priya: From my side, I'm really focused on what the data actually shows us; this framework uses dynamic traces combined with static features to create these behavioral subgraphs that reveal the true intent behind the malicious code.

Nadia: Exactly, and that focus on localization means we can start understanding exactly which parts of a program are doing the harmful work, which is a big step forward for defenders.

Elias: But I wonder about the practical exploitability; if we have this level of detail, does it mean an attacker can easily find a weakness to exploit cheaply?

Priya: The data suggests that by focusing on these malicious logic regions rather than just general file characteristics, we get a much more precise signal for threat hunting.

Nadia: That's the core idea—moving from broad detection to pinpointing the exact sequence of events that constitutes an attack.

Elias: It opens up new avenues for analysis, but I need to know what assumptions they made about the code structure to build this system in the first place.

Priya: The authors admit they had to rely on manual inspection initially to set a baseline for what truly constitutes malicious objectives versus benign scaffolding, which is an important caveat.

Nadia: So it's a framework that uses both automated tracing and human guidance to create these score-aware embeddings for deep learning classification.

Elias: That dual representation—the structural graph view and the sequential view—is what I find most interesting from a theoretical standpoint; it seems to capture both the flow and the semantic meaning of the code simultaneously.

Priya: It really does show how combining different analytical views, like those from graph theory and sequence modeling, can provide a more robust signal for classification.

Nadia: It gives us a way to get explainability in our security tools, which is crucial for building trust in the detection results we get out there.

Elias: The paper's conclusions suggest that this approach offers a consistent way to handle structural and syntactic variations across different malware families.

Priya: That robustness is key because it means the system won't just fail when faced with slight code changes or polymorphism, which is something I worry about in real-world data.

Nadia: So, the main implication here is that we can move beyond simple file identification to a deeper understanding of malware function and intent.

Elias: It points toward future research where we might look at how these behavior traces themselves can be used to build more resilient cryptographic defenses against obfuscation attempts.

Prakriti Baral, Zhuoyun Qian, Hailu Xu

Gianforte School of Computing, Montana State University · College of Computer Science and Technology, Shandong University

cs.CR

Submitted: 2026-09-29

Updated: 2026-09-29

License: http://creativecommons.org/licenses/by/4.0/

Importance score: 91/100

The gist: Effective malware analysis requires understanding not only whether a program is malicious, but also which behaviors it exhibits and where those behaviors originate in the code.

Key concepts

Behavior Subgraphs
These are isolated maps of malware activity derived from the code. The process starts by parsing the executable, building a call graph, and tracing suspicious API calls backward to isolate specific sections of code responsible for a particular action or intent.
Score-Aware Embedding (Ebb ⊕ Sbb)
This is a mathematical representation of each basic block in the code. It combines the block's inherent structural meaning with its manually assigned threat score. The score acts as an active signal, modifying the embedding to emphasize regions that are deemed more dangerous or suspicious.
Dual Architecture (Transformer and GNN)
The model uses two separate neural networks to understand malware. The Transformer branch analyzes the sequence of behaviors over time, while the GNN branch examines how these behaviors are connected structurally within the code graph. Both branches provide different perspectives for robust classification.
Late Fusion
This is a final decision-making step where predictions from different parts of the model (the Transformer and GNN) are combined. The framework takes the best prediction from each component and blends them using a weighted average to produce the most reliable final malware family classification.

Terminology

Summary

Effective malware analysis requires understanding not only whether a program is malicious, but also which behaviors it exhibits and where those behaviors originate in the code. This paper addresses malicious behavior localization and classification at the basic-block level by proposing a behavior-centric analysis framework that decomposes malware samples into behaviors and systematically links these behaviors to their originating code regions.

Framework Overview

The framework is designed with four primary objectives: i) Accurate malware classification by modeling behavior traces, ii) Robustness to structural and syntactic variation across variants: remain resilient to polymorphism/obfuscation and minor code changes by focusing on higher-level behavioral intent and execution context, iii) Discriminative, score-aware representations that reduce ambiguity between similar families, and iv) Provide explainability and localization to avoid blackbox decisions. The pipeline begins by ingesting raw Windows Portable Executable (PE) files, followed by a static and dynamic analysis stage that extracts function-level evidence and identifies API sinks calls as reliable indicators of suspicious intent.

Behavior Identification and Subgraph Extraction

The first stage converts the PE executable into a set of isolated behavior subgraphs. This process involves:

  1. Static parsing to obtain an initial capability view, including extracting imported functions from the Import Address Table and using string evidence.

  2. Generating a control-flow graph (CFG) using angr to provide an interprocedural view of basic blocks and call relationships.

  3. Mapping each API into a coarse taxonomy of intent categories (e.g., process/thread control, file activity).

  4. Using context-sensitive backward slicing from these security-relevant system API calls to trace code regions back to their entry points, resulting in an isolated behavior subgraph.

Labeling and Scoring

After extraction, the framework incorporates manual inspection to provide a grounded behavioral prior. This involves:

  1. Manually inspecting representative subgraphs across families to determine which correspond to genuinely malicious objectives versus benign scaffolding.

  2. Defining a Malicious DNA reference based on recurring patterns in these manually identified behaviors.

  3. Assigning two related measures: a raw, unbounded integer maliciousness score computed at the basic-block level from weighted API roles plus bonuses for suspicious patterns, and a normalized threat score, which is a float in [0,1] computed at the behavior-path level to serve as an explicit supervision signal.

Feature Engineering and Dual Representations

The framework transforms raw assembly into mathematical representations suitable for deep learning by applying normalization and tokenization to mitigate variability across compiler versions.

  1. A custom Tiny Transformer Encoder generates dense semantic embeddings for each basic block, which are then augmented with the manual threat score, producing a score-aware embedding (Ebb ⊕ Sbb).

  2. This leads to two complementary representations: a structural view and a sequence view. For the structural view, each basic block is a node in a graph where edges encode execution order along the entry-to-sink trace. For the sequence view, per-behavior embeddings are mean-pooled into single vectors and stacked into an ordered sequence of behavior vectors.

Malware Classification Using Transformer and GNN

The model utilizes a dual architecture to capture both semantics and structure:

  1. The Behavior Transformer branch processes the ordered sequence of behavior vectors, using a score-aware rescaling step where the threat score acts as an active signal that reshapes the representation’s magnitude ahead of the core model layers. It predicts family logits and is trained with auxiliary objectives predicting a binary maliciousness label and a categorical behavior-type label.

  2. The score-aware GNN branch processes each behavior subgraph, where node features are rescaled by the threat score to amplify behavior-critical regions. This branch aggregates node embeddings into a single graph-level representation, which is then passed through a linear classifier to produce family logits.

Late Fusion and Evaluation

The final classification is achieved through late fusion at the decision level. The Transformer outputs a single logit vector per sample, while the GNN produces one logit vector per behavior graph; these are aggregated by taking the elementwise maximum across all of the sample’s graph-level predictions to obtain a UID-level GNN prediction. The final family prediction is determined by combining these two vectors through weighted linear interpolation, governed by a scalar weight selected on the validation split, yielding the most consistent results (99.87% accuracy). Furthermore, an evaluation metric called behavior coverage measures the overlap between high-attention behaviors and manually labeled malicious regions to quantify localization quality.

Improvements for AI systems

Here are the specific improvements that an AI system, when implemented using the framework described in this paper, can achieve:

  1. Answering Where is the malicious logic? by providing fine-grained localization at the basic-block level. The system will output a precise map of code regions responsible for each detected malicious behavior, moving beyond black-box classification to actionable code evidence.

  2. Achieving true explainability by linking model attention directly to manually validated Malicious DNA behaviors via the Behavior Coverage metric. This allows analysts to see exactly which structural and semantic features the model relies on for its decisions, validating whether the highlighted regions are genuinely harmful or merely benign scaffolding.

  3. Developing a robust defense against adversarial malware transformations (polymorphism/obfuscation). Because the framework focuses on security-relevant system API calls as anchors and models high-level behavioral intent rather than superficial instruction sequences, it is inherently more resilient to code changes that preserve functionality but alter syntax.

  4. Creating highly discriminative family classification by leveraging a dual representation (Transformer for sequence semantics and GNN for structural dependencies). The fusion of these two views ensures the model captures both what the code does (semantics) and how the code is structured (topology), leading to superior performance in distinguishing subtle malicious variants.

  5. Generating interpretable, actionable threat scores that are grounded in empirical evidence. Instead of arbitrary labels, the system produces a continuous threat score [0, 1] for each behavior subgraph based on manually defined family patterns, which serves as a reliable supervision signal that guides the deep learning process toward high-confidence malicious regions.

  6. Automating the identification of complex behavioral routines through context-sensitive backward slicing. The AI can automatically decompose a monolithic binary into isolated execution units (behavior subgraphs), effectively separating benign boilerplate from core malicious logic for more focused analysis and detection.

Abstract

Effective malware analysis requires understanding not only whether a program is malicious, but also which behaviors it exhibits and where those behaviors originate in the code. Existing machine-learning-based malware detectors largely operate as black boxes, providing limited insight into the malicious logic responsible for their decisions. This paper addresses malicious behavior localization and classification at the basic-block level. We propose a behavior-centric analysis framework that decomposes malware samples into behaviors and systematically links these behaviors to their originating code regions. Using context-sensitive backward slicing from security-relevant system API calls, we reconstruct control- and data-dependency chains and represent each behavior as a structured graph of related basic blocks. A Transformer-based model captures instruction-level semantics, while a Graph Neural Network models structural dependencies within behavior graphs. The resulting representations are fused to enable accurate and interpretable classification, with attention-based attribution identifying code regions responsible for malicious behaviors. We evaluate our approach using standard classification metrics and a behavior coverage metric that measures the detection of manually labeled malicious behaviors. Our results demonstrate that the proposed framework achieves accurate malware classification while providing fine-grained, behavior-aware localization of malicious logic.

Sources

Related papers