PaperlayerView exact revision on arXiv

Source-linked AI summary

Characterizing and Codifying Malware Sophistication

Angelo Porcella, Zachary Wadhams, Clemente Izurieta, Jonathan Crussell, Ann Marie Reinhold

arXiv:2610.00098v1cs.CRcs.SE

TL;DR

Malware sophistication lacks a standardized binary-based assessment, while relevant traits can be difficult to measure without source code. This SoK adapts software-quality characteristics and static indicators, identifies applicable and excluded criteria, and notes the challenge of aggregating tool outputs.

  • Problem

    No standardized framework assesses malware sophistication from binaries, although sample volumes are rising and relevant traits are difficult to measure without source code.

    Source: §I · p. 1

  • Method

    The SoK adapts ISO/IEC 25010 quality characteristics and other statically measurable features to operationalize malware sophistication from binaries.

    Source: §I · p. 1, §V · p. 5

  • Results

    The analysis treats malware resistance and code-reuse signals as relevant, while excluding five ISO/IEC 25010 characteristics as inapplicable or unreliable to measure statically.

    Source: B. Security · p. 4, C. Maintainability · p. 4, E. Excluded Characteristics · p. 4

  • Takeaways & Limitations

    A future quantification system would need a unified scoring hierarchy to aggregate heterogeneous tool outputs.

    Source: §V · p. 5

    Aggregating heterogeneous tool outputs under a unified scoring hierarchy remains a practical challenge.

    Source: §V · p. 5

Abstract

from arXiv · show

'Sophisticated' is widely used to describe malware, yet it lacks a consistent definition within academic literature. While existing software quality and complexity metrics offer some insight into malware structure, they do not capture the broader adversarial and operational traits that contribute to real-world threat potential. This paper presents a systematization of existing approaches for assessing malware quality using static binary analysis. We define malware sophistication through a quality-focused lens by reinterpreting select characteristics from the ISO/IEC 25010 software quality standard, including reliability, maintainability, flexibility, and security, and evaluating their applicability to malware binaries. We identify which characteristics are both relevant to malware and measurable through static analysis, forming the basis for future frameworks that consistently assess malware sophistication when source code is unavailable or dynamic execution is infeasible.

I. INTRODUCTION

Malware sophistication lacks a standardized binary-based assessment despite rapidly rising sample volumes; this SoK systematizes static, binary-measurable quality criteria to support evaluation.

I. INTRODUCTION

  • More than 450,000 new malicious programs were registered daily on average in 2024, motivating systematic sophistication assessment from binaries.Source: §I · p. 1
  • Sophistication combines code complexity, obfuscation, novelty, and functionality, many difficult to measure without source code.Source: §I · p. 1
  • No standardized binary-only sophistication framework exists; current approaches emphasize classification or behavior labels, while the SoK proposes broader measurable criteria.Source: §I · p. 1

II. BACKGROUND

  • Fragmented definitions and software quality metrics do not transfer directly to binaries, motivating a consistent malware-specific framework.Source: §II · p. 1

A. Malware Sophistication

Malware sophistication is used inconsistently, and this section defines it in terms of development effort while identifying measurement challenges and the need for contextual assessment.

A. Malware Sophistication

B. Current Methods of Malware Analysis

Prior malware-quality studies adapt software-engineering metrics to source code or decompiled representations, while binary analysis primarily relies on static inspection.

B. Current Methods of Malware Analysis

  • Prior studies use LOC, cyclomatic complexity, and object-oriented indicators to infer maintainability, modularity, or development effort, but need source code or high-fidelity decompilation,.Source: B. Current Methods of Malware Analysis · p. 2
  • MalSource analyzed 456 source-available samples across four decades and found a shift toward larger, modular malware; Mercaldo et al. inferred increasing sophistication over time from decompiled Android APKs [3],.Source: B. Current Methods of Malware Analysis · p. 2
  • Without source code, analysts primarily inspect binaries statically through disassembly, control-flow graphs, and strings; dynamic sandbox analysis is resource-intensive, evadable, and out of scope.Binary-analysis tools are fewer and less mature than source-code tools.Source: B. Current Methods of Malware Analysis · p. 2

C. Sophistication Proxies

Binary-observable features can inform malware threat assessment and sophistication proxies, but surface complexity measures can be manipulated and require cautious interpretation.

C. Sophistication Proxies

  • Dead-code insertion and binary padding can inflate surface metrics without reflecting engineering effort, and both are defense-evasion techniques.Source: C. Sophistication Proxies · p. 2
  • Binary-derived effort metrics require caution: apparent complexity may reflect defensive measures rather than underlying design.Source: C. Sophistication Proxies · p. 3
  • Threat assessment overlaps sophistication through observable capability, platform compatibility, and structural complexity, though its primary goal is risk, intent, and technical characterization.Source: C. Sophistication Proxies · p. 3
  • MAEC-based threat assessment organizes malware objectives, capabilities, and OS compatibility, indirectly capturing technical breadth and operational versatility.Source: C. Sophistication Proxies · p. 3
  • Threat scoring combines disassembled code, control-flow graphs, and metadata with behavioral observations, while static features can inform broader quality assessment.Source: C. Sophistication Proxies · p. 3

D. Software Quality Measurement

Traditional software quality models provide useful metrics, but their reliance on source-code constructs limits direct use on compiled malware. Binary-focused reinterpretation is therefore needed.

  • Static analysis supplies metrics such as cyclomatic complexity, code duplication, coupling, and rule violations to software quality models.Examples of tools include SonarQube, Coverity, Fortify, PMD, Cppcheck, and Bandit.Source: D. Software Quality Measurement · p. 3
  • Compiled malware lacks source-level constructs required by many quality metrics, so traditional quality models cannot be applied directly in real-world analysis.The paper calls for focusing quality measurement on features extractable from binaries alone.Source: D. Software Quality Measurement · p. 3

III. DEFINITIONS OF MALWARE SOPHISTICATION

The paper treats malware sophistication as specialized knowledge and effort, using malware quality as an incomplete proxy. It adapts ISO/IEC 25010 characteristics as a structured lens for assessing malicious software.

III. DEFINITIONS OF MALWARE SOPHISTICATION

  • Malware sophistication emphasizes specialized knowledge and effort, distinguishing sophisticated malware from commodity variants.Source: §III · p. 3
  • Because specialized knowledge and effort cannot yet be measured directly, malware quality is proposed as an incomplete, partial measure of sophistication.Source: §III · p. 3

IV. APPLICATION OF ISO/IEC 25010 TO MALWARE QUALITY ASSESSMENT

  • ISO/IEC 25010 offers a structured lens for malware quality assessment when its conventional software characteristics are carefully reinterpreted.The paper examines applicable characteristics first and identifies inapplicable or unmeasurable ones afterward.Source: §IV · p. 3

A. Reliability

Reliability concerns whether malware runs without faults or unintended behavior, while binary structure can offer indicators of reliability. Security is interpreted in reverse: sophisticated malware protects itself and its operators from discovery, analysis, and attribution.

A. Reliability

  • Reliability in malware means operating without faults, crashes, or unintended behavior, with error handling, redundancy, and fallback mechanisms serving as possible binary indicators.Multiple persistence mechanisms may suggest tolerance of removal attempts; Nexe's scheduled-task persistence and mutex checks illustrate fault tolerance.Source: A. Reliability · p. 4
  • CWE-Checker can detect a subset of reliability-related weaknesses directly from compiled binaries, although the CISQ framework primarily targets source code.The CISQ Reliability Measures define 74 CWEs aligned with ISO/IEC 25010.Source: A. Reliability · p. 4

B. Security

  • Malware security traits work in reverse, protecting malware and its operators through evasion, anti-debugging, sandbox detection, encryption, and obfuscation.Nexe disables AMSI and ETW, encrypts network traffic, and obfuscates its payload; WikiLoader uses custom code and sandbox evasion.Source: B. Security · p. 4

C. Maintainability

Maintainability signals such as code reuse and inferred complexity can reveal development patterns, but obfuscation and attribution concerns complicate their use. Flexibility concerns operation across varied systems and environments, with several binary-level indicators.

C. Maintainability

  • Code reuse and modular architectures can signal malware developed and maintained at scale, with similarity analysis revealing shared code or iterative versions.KANDYKORN has a five-stage chain with distinct components, while WikiLoader exhibits modularity and is believed sold to multiple actors.Source: C. Maintainability · p. 4
  • Binary-derived maintainability indicators have limits: obfuscation can distort them, file size can be inflated, and code reuse can aid threat-actor profiling.Cyclomatic complexity can be approximated from disassembled code; dead-code insertion or padding may artificially inflate file size.Source: C. Maintainability · p. 4

D. Flexibility

  • Flexibility means operating across varied configurations and hosts; binaries may reveal it through OS-dependent logic, abstraction layers, or multiple payload stubs.A Lazarus-linked infostealer supports Windows, Linux, and macOS, while campaigns may adapt delivery vectors and remote-access tools per target,.Source: D. Flexibility · p. 4

E. Excluded Characteristics

Five ISO/IEC 25010 characteristics are excluded because they are inapplicable to malware or not reliably measurable through static binary analysis.

E. Excluded Characteristics

  • Functional suitability cannot be assessed without source code or specifications, and its user-interaction basis does not reflect real-world malware operation.It concerns whether software achieves its intended functionality correctly and completely.Source: E. Excluded Characteristics · p. 5
  • Performance efficiency can be partly inferred from static properties, but exact resource use is most directly assessed at runtime.Optimization level and avoidance of costly operations are possible static indicators.Source: E. Excluded Characteristics · p. 5
  • Compatibility is difficult to generalize because stealthy malware may prioritize interoperability, while destructive malware may intentionally cause crashes.The passage contrasts stealthy malware [21] with HermeticWiper.Source: E. Excluded Characteristics · p. 5
  • Interaction capability is hard to generalize because many samples lack interactive components, although binaries may reveal argument parsing, GUI components, or localized strings.Source: E. Excluded Characteristics · p. 5
  • Safety attributes are largely inapplicable because malware is designed without regard for user or system safety.Debugger-triggered termination serves stealth and is more appropriately associated with reliability or security.Source: E. Excluded Characteristics · p. 5

V. CONCLUSION AND FUTURE WORK

The paper defines malware sophistication through an adapted ISO/IEC 25010 quality lens for static binary analysis. It identifies future work needed to operationalize and validate a framework for quantifying sophistication.

V. CONCLUSION AND FUTURE WORK

  • The paper defines malware sophistication and adapts ISO/IEC 25010 characteristics to malicious software, focusing on operationalizing quality for static binary analysis.Source: §V · p. 5
  • A system that quantifies sophistication remains a long-term goal, with heterogeneous tool outputs posing a practical challenge for a unified scoring hierarchy.Learned sub-characteristic weights may require empirical data, but no public dataset reflecting sophistication degrees currently exists.Source: §V · p. 5
  • Near-term work should apply the framework to real malware samples to test whether its characteristics produce meaningful, consistent signals.Once an operational model exists, statistical testing could examine and refine assumptions about adversarial software engineering.Source: §V · p. 5
Loading 2610.00098v1…