ha0td4

Behavior-Centric Malware Analysis Through Multi-Stage Processing and ATT&CK Correlation

Sun, 28 Dec 2025 00:00:00 GMT

In this project, malware analysis system is built on a three-layer architecture designed to move beyond basic detection into deep behavioral interpretation and MITRE ATT&CK mapping. Each layer operates independently but remains tightly integrated, enabling the pipeline to progress from raw execution signals to high-level threat intelligence. This structure allows not only classification of malicious samples, but also the extraction of behavioral insights that support investigation, threat hunting, and automated TTP (Tactics, Techniques, Procedures) identification.

Dataset

To evaluate the system, we aggregated malware execution traces from multiple publicly available sources. Data was collected from:

r/datasets – Malware & Benign PE Cuckoo Reports: Provides Cuckoo sandbox execution logs for both malware and benign Windows binaries.
APIMDS: A labeled malware dataset containing monitored API call sequences across various families.
MalbehavD-V1: Focused on behavior-driven samples with process execution details suitable for dynamic analysis.

All samples were executed inside a controlled sandbox environment to extract API call sequences for downstream processing. The final dataset contains multiple malware families alongside benign executables, forming a diverse testbed for behavior-based threat analysis.

The label distribution is shown in the chart below:

As illustrated in the pie chart, Trojan samples dominate the dataset, followed by Miscellaneous, Adware, and Benign classes. This imbalance reflects common trends in real-world malware distributions and highlights the importance of balanced evaluation strategies.

Layer 1 – Malware Detection

Execution traces are first collected through a sandbox environment, where each sample is analyzed and its API call sequence is recorded. These API calls are transformed into a fixed-length feature vector of 1143 dimensions, with each dimension representing the frequency of a corresponding API within the global API set. An ensemble model combining Random Forest and XGBoost is used to classify the sample as malicious or benign. In addition to classification probability, this layer produces an explainability report using SHAP values, highlighting the APIs that contributed most to the model decision. The detection component therefore acts as the primary filtering stage, providing a reliable base for deeper behavioral analysis in subsequent layers.

Layer 2 – Behavioral Analysis

While Layer 1 focuses on classification, the second layer aims to capture and interpret behavioral patterns. The raw API sequence is first processed using a Log2-based noise reduction technique to eliminate redundant consecutive calls. The cleaned sequence is then segmented using a sliding-window approach to generate API gadgets—continuous execution fragments representing localized behaviors. Each gadget is encoded using CodeBERT to generate semantic embeddings, offering a richer contextual understanding compared to traditional discrete representations.

These embeddings are clustered using HDBSCAN, and clusters with valid labels (cluster_id ≠ -1) are retained as behaviorally meaningful groups with potential malicious indicators. In parallel, a bag-of-APIs model using TF-IDF is applied, and Sequential Pattern Mining with PrefixSpan combined with Discriminative Scoring is used to extract API patterns that distinguish malware families. This layer produces two critical outputs: suspicious gadget clusters with maliciousness likelihood, and characteristic sequential API patterns representing family-specific behaviors. Both serve as essential input for semantic interpretation and MITRE mapping.

Layer 3 – MITRE ATT&CK Mapping

The final layer bridges behavioral signals with threat intelligence by translating them into ATT&CK-aligned interpretations. A Large Language Model (LLM Interpreter) is first used to convert API gadgets into natural-language behavioral descriptions—such as network communication, system manipulation, file operations, or registry modification. These descriptions are then processed by an Analysis Agent operating under a Retrieval-Augmented Generation (RAG) framework. The agent queries a MITRE knowledge base containing tactic-technique mappings, malware behavior references, and API-to-TTP correlation data.

Using semantic matching between system-generated behavior descriptions and retrieved MITRE knowledge, the system infers relevant attack techniques and tactics. The final output is an automatically generated report summarizing detected TTPs, reasoning context, and originating gadget evidence. As a result, the system evolves from simple malware detection into a comprehensive analytical engine that supports digital forensics, active attack monitoring, and strategic defense decision-making.

Additional

You can explore the most APISeqTracer source code on GitLab: https://gitlab.com/ha0td4/apiseqtracer.

Preventing Nmap OS Fingerprinting Using Snort Rules

Mon, 21 Apr 2025 00:00:00 GMT

When it comes to network security, one of the first things an attacker usually does is try to figure out what operating system you're running. Tools like Nmap make this super easy with OS fingerprinting — it sends a bunch of weirdly crafted packets to your machine, and based on how your system responds, it can make a pretty good guess about your OS. In this post, I’ll show you how I used Snort in inline mode to block those sneaky Nmap probes. I captured some traffic, broke down how Nmap does its thing, and wrote a bunch of Snort rules to stop it in its tracks. It’s a hands-on walkthrough — perfect if you’re experimenting with intrusion detection systems or just want to level up your blue team skills.

Before we dive in, it’s helpful to have some basic knowledge of:

How Snort rules work — especially how to match on packet content, headers, flags, and sizes. https://docs.snort.org/start/rules
How Nmap OS fingerprinting works — the kinds of probes it sends (TCP, UDP, ICMP) and what it's looking for in the responses. https://nmap.org/book/osdetect-methods.html

Network topology

In this setup, x = 4 and Snort is running in inline mode to actively drop suspicious traffic.

Before Adding Detection Rules

The attacker begins by scanning the victim’s open ports using Nmap. Meanwhile, the victim captures packets using tcpdump for analysis:

Packet Analysis and Rule Writing

According to the official Nmap documentation, OS fingerprinting works by sending 16 specially crafted TCP, UDP, and ICMP probes to analyze dozens of characteristics from the response packets.

UDP (U1 Probe)

The U1 packet wasn't captured directly, but we were able to analyze the ICMP error response generated by it: Cross-referencing with Nmap's documented behavior confirms this packet matches the U1 probe: Snort rule to drop U1 packets:

drop udp any any -> any any (msg:"Nmap OS fingerprinting: U1 detected"; content:"|43 43 43 43 43 43 43 43|"; sid:1000015; rev:1;)

Result: => Successfully blocked the U1 probe, reducing the confidence of Nmap’s OS detection.

Sequence generation (SEQ, OPS, WIN, and T1)

These TCP packets are tricky to detect due to Snort 2's limited TCP header inspection capabilities. However, they can still be identified using distinct TCP flags and window size values: Rules:

drop tcp any any -> any any (msg:"Nmap OS fingerprinting: SEQ/OPS/WIN/T1 #1 detected"; flags:S; window:1; sid:1000001; rev:1;)

drop tcp any any -> any any (msg:"Nmap OS fingerprinting: SEQ/OPS/WIN/T1 #2 detected"; flags:S; window:63; sid:1000002; rev:1;)

drop tcp any any -> any any (msg:"Nmap OS fingerprinting: SEQ/OPS/WIN/T1 #3#4 detected"; flags:S; window:4; sid:1000003; rev:1;)

drop tcp any any -> any any (msg:"Nmap OS fingerprinting: SEQ/OPS/WIN/T1 #5 detected"; flags:S; window:16; sid:1000004; rev:1;)

drop tcp any any -> any any (msg:"Nmap OS fingerprinting: SEQ/OPS/WIN/T1 #6 detected"; flags:S; window:512; sid:1000005; rev:1;)

ICMP echo (IE):

These echo probes can also be detected by analyzing their size and other fields: Rules:

drop icmp any any -> any any (msg:"Nmap OS fingerprinting: IE-1 detected"; dsize:120; icode:9; icmp_seq:295; tos:0; sid:1000006; rev:1;)

drop icmp any any -> any any (msg:"Nmap OS fingerprinting: IE-2 detected"; dsize:150; icode:0; icmp_seq=296; tos:4; sid:1000007; rev:1;)

TCP explicit congestion notification (ECN)

This probe uses unusual TCP flags (SCE) and a very small window size. Rule:

drop tcp any any -> any any (msg:"Nmap OS fingerprinting: ECN detected"; flags:SCE; window:3; ack:0; sid:1000008; rev:1;)

TCP (T2–T7)

Similar to SEQ probes, these can be detected through their unique flags and window fields: Rules:

drop tcp any any -> any any (msg:"Nmap OS fingerprinting: T2 detected"; flags:0; window:128; sid:1000009; rev:1;)

drop tcp any any -> any any (msg:"Nmap OS fingerprinting: T3 detected"; flags:SFUP; window:256; sid:1000010; rev:1;)

drop tcp any any -> any any (msg:"Nmap OS fingerprinting: T4 detected"; flags:A; window:1024; sid:1000011; rev:1;)

drop tcp any any -> any any (msg:"Nmap OS fingerprinting: T5 detected"; flags:S; window:31337; sid:1000012; rev:1;)

drop tcp any any -> any any (msg:"Nmap OS fingerprinting: T6 detected"; flags:A; window:32768; sid:1000013; rev:1;)

drop tcp any any -> any any (msg:"Nmap OS fingerprinting: T7 detected"; flags:FUP; window:65535; sid:1000014; rev:1;)

Final Results After Rule Deployment

The combined set of Snort rules effectively blocks all OS fingerprinting probes from Nmap while still allowing legitimate traffic through. Although false positives (FP) or false negatives (FN) could theoretically occur, in this controlled lab environment no such cases were observed. Nmap probes typically contain highly unusual characteristics—such as uncommon flag combinations (e.g., NULL, FIN+URG+PSH) and suspicious window sizes (e.g., 1, 4, 16, 128, etc.)—which makes them easier to detect and filter.

Conclusion

By analyzing how Nmap performs OS fingerprinting and crafting specific Snort rules to block its probes, we can effectively reduce the chances of our systems being accurately profiled. While this setup isn’t bulletproof — attackers can still try different evasion techniques — it definitely raises the bar and makes scanning much more difficult.

Of course, like with any IDS rules, there's always the potential for false positives or false negatives. In my lab environment, everything worked smoothly, but in a real-world network, you’ll want to monitor the logs and fine-tune the rules as needed.

This was a fun little exercise in both packet analysis and rule writing. Hopefully, it gives you some ideas on how to harden your own network or experiment more with Snort. If you’ve got other tips, tricks, or improvements, feel free to share — always happy to learn more from the community!

Stay safe and keep packet sniffing 🔍💻

A Deep Dive into Fileless Malware Detection

Wed, 12 Mar 2025 00:00:00 GMT

Traditional antivirus solutions struggle against a new breed of cyber threats: Fileless malware, which operates entirely in system memory, leaving no trace on disk. These attacks bypass conventional detection methods, making them one of the most dangerous challenges in cybersecurity today. Facing this challenge, Argus, an advanced early-stage fileless malware detection system leveraging deep learning and the MITRE ATT&CK framework to identify threats before they escalate. By analyzing memory snapshots in real time, Argus can detect malicious activity in its pre-operational phase, preventing devastating data breaches. The proposed Argus system for early-stage fileless malware detection consists of two key architectural components: the Feature Explainer and the Early-Stage Detector. Its operational workflow involves these two phases working in tandem.

1. Feature Explainer

Monitoring for Suspicious Processes: Argus continuously monitors the system in real-time for suspicious processes using Windows Management Instrumentation (WMI). It looks for unusual process names, high resource usage, and unusual network activity.
Queueing Suspicious Processes: When a suspicious process is identified, its Process ID (PID) is appended to a queue for further analysis.
Capturing Memory Snapshots: A suspicious process PID is dequeued and Argus automatically invokes the ProcDump command-line utility to capture a memory snapshot of the process.
Extracting Key Features: Custom plugins developed using Volatility documentation are used to extract key features from the acquired memory snapshot. These raw features include:
- Parent-Child Process Relationships: Detecting abnormal relationships such as a script executed by an unexpected parent process via mshta.exe.
- Tracing Execution Paths: Identifying deviations from standard execution paths, like c:\Windows\syswow64\dllhost.exe being used for malicious activity.
- Monitoring Sensitive Registry Keys: Detecting unauthorized modifications to registry keys for persistence or evasion.
- Identifying Code Injection Attempts: Recognizing attempts to inject malicious code into legitimate processes.
- Recognizing Signs of Process Hollowing: Identifying processes that appear legitimate but are executing malicious code.
- Suspicious Network Activity: Detecting anomalous network connections initiated by a process, potentially indicating communication with C2 servers.

Generating Explained Features: The extracted key features are then fed into a fine-tuned Llama model (feature explainer model) to generate explained features corresponding to those key features. This model is fine-tuned on a Feature explanation dataset created from behavioral reports, as shown below: Here is a structure of Llama feature explainer model:

2. Early-Stage Detector

MITRE-attack-dataset: This component utilizes a MITRE-attack-dataset, which is prepared from the MITRE ATT&CK enterprise matrix. This dataset contains information on adversary tactics and techniques based on real-world observations.
Correlation and Detection: The generated explained features from the Feature Explainer are correlated with the MITRE-attack-dataset.
Fine-tuned BERT Model with MLP: An early-stage detector is a fine-tuned BERT (Bidirectional Encoder Representations from Transformers) model combined with an MLP (Multilayer Perceptron), is used to identify fileless malware attacks at an early stage. The BERT model is fine-tuned on the MITRE-attack-dataset.

3. Operational Workflow

Argus continuously monitors the system for suspicious processes using WMI.
When a suspicious process is found, its PID is added to a queue.
Argus dequeues a PID and uses ProcDump to capture a memory snapshot.
Custom plugins extract key features from the memory snapshot.
The extracted features are fed to the fine-tuned Llama model to generate explained features.
These explained features are then correlated with the MITRE ATT&CK framework using a fine-tuned BERT model with an MLP to detect fileless malware at an early stage.
Argus can then identify the active stage of the fileless malware attack based on the correlation with the MITRE ATT&CK tactics.

Argus aims to detect fileless malware before its operational stage to prevent potential damage and data breaches. The experimental results showed that Argus could successfully identify fileless malware samples in both the pre-operational and operational phases.

4. Experimental Result

4.1. Argus performance on benchmark dataset

The performance of Argus evaluated across various APT threat groups. Notably, Argus did not detect any threats at the initial stage since it relies on memory analysis, which occurs after the malware has achieved initial access. Finally, Argus detected 2978 samples (out of total 5026 samples) at the pre-operation stage, 1889 samples at the subsequent stages, and 59 samples failed to detect. These results indicate that Argus is most effective in detecting fileless malware at the pre-operation stage.

4.2. Argus performance comparison with existing SOTA

Argus demonstrated robust performance by identifying 2978 fileless malware samples at the Pre-operational stage and 1378 samples at the Operational stage. The results demonstrate Argus efficiency in detecting fileless malware attacks at an early stage and outperform existing state-of-the-art methods with an impressive detection accuracy of 96.84%.

4.3. Computational performance comparison

The performance evaluation is conducted by selecting 1000 random processes of each different size. The analysis is focused on determining the average time taken by feature generation and early-stage detection for each memory dump. In conclusion, Argus outperforms existing SOTA, which takes 11.252s to analyse smaller processes and 136.343s to analyse larger processes.

5. Reference

Kara, I. (2023). Fileless malware threats: Recent advances, analysis approach through memory forensics and research challenges. Expert Systems with Applications, 214, 119133.

Process Injection

Sat, 01 Mar 2025 00:00:00 GMT

Process Injection

Tactics: Defense Evasion, Privilege Escalation Technique: Process Injection

Process injection is one of the most common techniques used to dynamically bypass antivirus engines. Many antivirus vendors and software developers rely on so-called process injection or code injection to inspect processes running on the system. Using process injection, attacker can inject malicious code into the address space of a legitimate process within the operating system, thereby avoiding detection by dynamic antivirus engines.

Base knowledge

Before we understand what process injection is, we need to know about the concept of the process address space, process-injection steps and Windows API.

Process Address Space

A process address space is a space that is allocated to each process in the operating system based on the amount of memory the computer has. Each process that is allocated memory space will be given a set of memory address spaces. Each memory address space has a different purpose, depending on the programmer's code, on the executable format used (such as the PE format), and on the operating system, which actually takes care of loading the process and its attributes, mapping allocated virtual addresses to physical addresses, and more. The following diagram shows a sample layout of a typical process address space:

Process-injection steps

The goal of process injection is to inject a piece of code into the process memory address space of another process, give this memory address space execution permissions, and then execute the injected code. This applies not merely to injecting a piece of shellcode but also to injecting a DLL, or even a full executable (EXE) file. To achieve this goal, the following general steps are required:

Identify a target process in which to inject the code.
Receive a handle for the targeted process to access its process address space.
Allocate a virtual memory address space where the code will be injected and executed, and assign an execution flag if needed.
Perform code injection into the allocated memory address space of the targeted process.
Finally, execute the injected code.

The following diagram depicts this entire process in a simplified form:

Now that we have this high-level perspective into how process injection or code injection is performed, let's turn to an explanation of Windows API functions.

Windows API

The Windows API is Microsoft's core set of APIs, allowing developers to create code that interacts with underlying, prewritten functionality provided by the Windows operating system. Windows API functions are user-mode functions that are fully documented on Microsoft's site at msdn.microsoft.com. However, most Windows API functions actually invoke Native APIs to do the work. For instance, when a Windows API function such as CreateFile() is called, depending on the parameter provided by the developer, Windows will then transfer execution to one of two Native API routines: ZwCreateFile or NtCreateFile.

Sub-technique of Process Injection

There are many sub techniques of process injection, but we'll explore some of these in this blog.

Classic DLL Injection

This technique forces the loading of a malicious DLL into a remote process by using these six basic Windows API functions:

OpenProcess: Using this function and providing the target process ID as one of its parameters, the injector process receives a handle to the remote process.
VirtualAllocEx: Using this function, the injector process allocates a memory buffer that will eventually contain a path of the loaded DLL within the target process.
WriteProcessMemory: This function performs the actual injection, inserting the malicious payload into the target process.
CreateRemoteThread: This function creates a thread within the remote process, and finally executes the LoadLibrary() function that will load our DLL.
LoadLibrary/GetProcAddress: These functions return an address of the DLL loaded into the process. Considering that kernel32.dll is mapped to the same address for all Windows processes, these functions can be used to obtain the address of the API to be loaded in the remote process.

After performing these six functions, the malicious DLL file runs within the operating system inside the address space of the target victim process. Example in IDA Pro:

Process Hollowing

This injection technique lets us create a legitimate process within the operating system in a SUSPENDED state, hollow out the memory content of the legitimate process, and replace it with malicious content followed by the matched base address of the hollowed section. Here are the API function calls used to perform the process-hollowing injection technique:

CreateProcess: This function creates a legitimate operating system process (such as notepad.exe) in a suspended state with a dwCreationFlags parameter.
ZwUnmapViewOfSection/NtUnmapViewOfSection: Those Native API functions perform an unmap for he entire memory space of a specific section of a process. At this stage, the legitimate system process has a hollowed section, allowing the malicious process to write its malicious content into this hollowed section.
VirtualAllocEx: Before writing malicious content, this function allows us to allocate new memory space.
WriteProcessMemory: As we saw before with classic DLL injection, this function actually writes the malicious content into the process memory.
SetThreadContext and ResumeThread: These functions return the context to the thread and return the process to its running state, meaning the process will start to execute.

An example about malware using process hollowing in IDA Pro:

Process Doppelgänging

This fascinating process-injection technique is mostly used to bypass antivirus engines and can be used to evade some memory forensics tools and techniques. Process doppelgänging makes use of the following Windows API and Native API functions:

CreateFileTransacted: This function creates or opens a file, file stream, or directory based on Microsoft's NTFS-TxF feature. This is used to open a legitimate process such as notepad.exe.
WriteFile: This function writes data to the destined injected file.
NtCreateSection: This function creates a new section and loads the malicious file into the newly created target process.
RollbackTransaction: This function ultimately prevents the altered executable (such as notepad.exe) from being saved on the disk.
NtCreateProcessEx, RtlCreateProcessParametersEx, VirtualAllocEx, WriteProcessMemory, NtCreateThreadEx, NtResumeThread: All of these functions are used to initiate and run the altered process so that it can perform its intended malicious activity.

An example about PE file using process doppelgänging:

Process Herpaderping

The Process Herpaderping technique bypasses security products by obscuring the intentions of the process, making it difficult for security tools to detect and prevent the malicious activity. It use the following functions:

CreateProcess: Creates a new process in a suspended state.
NtCreateSection: Creates a section object to share memory between processes.
NtMapViewOfSection: Maps a view of the section into the address space of the target process.
WriteProcessMemory: Writes the executable code into the mapped section of the target process.
SetThreadContext: Sets the context of the main thread of the target process to point to the entry point of the malicious code.
ResumeThread: Resumes the main thread of the target process, causing it to execute the malicious code.

Comparison

Process Hollowing Process Hollowing involves modifying the mapped section before execution begins, which abstractly this looks like: map -> modify section -> execute. This workflow results in the intended execution flow of the Hollowed process diverging into unintended code. Doppelganging might be considered a form of Hollowing. However, Hollowing is closer to injection in that Hollowing usually involves an explicit write to the already mapped code. This differs from Herpaderping where there are no modified sections.

Process Doppelganging Process Doppelganging is closer to Herpaderping. Doppelganging abuses transacted file operations and generally involves these steps: transact -> write -> map -> rollback -> execute. In this workflow, the OS will create the image section and account for transactions, so the cached image section ends up being what you wrote to the transaction. The OS has patched this technique. Well, they patched the crash it caused. Maybe they consider this a "legal" use of a transaction. Thankfully, Windows Defender does catch the Doppelganging technique. Doppelganging differs from Herpaderping in that Herpaderping does not rely on transacted file operations. And Defender doesn't catch Herpaderping.

Process Herpaderping The registered kernel callback is invoked when the initial thread is inserted, not when the process object is created. Because of this, an actor can create and map a process, modify the content of the file, then create the initial thread. A product that does inspection at the creation callback would see the modified content. Additionally, some products use an on-write scanning approach which consists of monitoring for file writes. An actor using a write -> map -> modify -> execute -> close workflow will subvert on-write scanning that solely relies on inspection at IRP_MJ_CLEANUP.

Type	Technique
Hollowing	`map -> modify section -> execute`
Doppelganging	`transact -> write -> map -> rollback -> execute`
Herpaderping	`write -> map -> modify -> execute -> close`

Other techniques

You can explore more techniques from: https://www.exploit-db.com/docs/47983

Transformation-based Evasion Strategy

Wed, 12 Feb 2025 00:00:00 GMT

Malware developers have continuously evolved their techniques to bypass antivirus systems. Their evasion strategies primarily fall into three categories: Transformation-based, Concealment-based, and Attack-based [^1], as illustrated in the image below: To effectively counter these evasion strategies, it is crucial to understand how they work. For example, some malware variants insert excessive NOP instructions to increase their file size, helping them bypass size-based detection thresholds used by antivirus scanners.

Transformation-based stategy

The transformation-based strategy involves modifying the structural and behavioral characteristics of malware to evade detection. This can be achieved by altering either the static structure or the dynamic behavior of malware during runtime. Static modifications help avoid signature-based detection, while dynamic changes help evade behavior-based analysis.

Examples of transformation-based evasion techniques include:

Packers

Packers use encryption and compression techniques to modify the original executable, making it harder to analyze. Some packers utilize virtual machine-based execution, where they alter the program’s opcode to run within a custom virtual environment, further complicating detection. For this demonstration, I used UPX [^2], a widely used tool among malware developers for packing binary files [^3] (as noted in a 2012 survey). To illustrate, I selected a single malware sample and created multiple packed variants. The original SHA-256 hash of the sample is: e56e4f523e0a013820d3201995073401df92402b60a1d94a105f99381e7d3499. This sample has been analyzed on VirusTotal (Here) and flagged as malware by 44 different antivirus engines: However, after using UPX, only 10 antivirus engines successfully detected it:

Code Obfuscation

Code obfuscation modifies the structure and control flow of a program to make analysis more difficult while preserving functionality. Common techniques include:

Garbage code insertion: Injecting redundant instructions that do not affect program execution.
Register substitution: Replacing register names to confuse disassemblers.
Control flow obfuscation: Modifying execution paths to make analysis harder.

For this test, I used the free version of Obfuscator Executive [^4] to obfuscate the sample. The results are shown below: Obfuscator Executive works by obscuring critical components within executables and binary files, such as class names, functions, subroutines, objects, variables, constants, and UI elements. It replaces meaningful identifiers with indistinguishable placeholders, making it harder for attackers to understand and reverse engineer your software. Before obscuring: After obscuring:

Metamorphism

Metamorphic malware undergoes extensive transformations, rewriting its own code to generate unique variants while maintaining its malicious behavior. For instance, the Frankenstein framework [^5] assembles malware by combining code fragments from legitimate software, making it resistant to signature-based detection.

Behavioral Obfuscation

Behavioral obfuscation techniques manipulate execution patterns to avoid detection. These include:

Multi-threaded execution: Splitting malicious operations across multiple threads.
API obfuscation: Masking API calls to evade detection.
Process injection: Running malicious code inside legitimate processes.

A notable example is the Shadow Attack [^6], which creates multiple processes to perform malicious tasks while evading system call-based detection methods.

Conclusion

As malware continues to evolve, security researchers must stay updated on evasion techniques to improve detection mechanisms. Transformation-based evasion alters malware’s structure, concealment-based evasion hides malicious behavior, and attack-based evasion directly targets security solutions or uses adversarial techniques to deceive them. Understanding these methods is essential for developing robust countermeasures against modern malware threats.

[^1]: Jiaxuan Geng, Junfeng Wang, Zhiyang Fang, Yingjie Zhou, Di Wu, and Wenhan Ge. 2024. A survey of strategy-driven evasion methods for PE malware: Transformation, concealment, and attack. Comput. Secur. 137, C (Feb 2024). https://doi.org/10.1016/j.cose.2023.103595 [^2]: Upx. (n.d.). GitHub - upx/upx: UPX - the Ultimate Packer for eXecutables. GitHub. Retrieved March 1, 2025, from https://github.com/upx/upx [^3]: Branco, R.R., Barbosa, G.N., & Drimel, P. (2012). Scientific but Not Academical Overview of Malware Anti-Debugging , Anti-Disassembly and Anti-VM Technologies. [^4]: Executive, O. (2024, December 1). Obfuscator Executive – secure EXE and binary files. (C) Obfuscator Executive 2025. Retrieved March 1, 2025, from https://obfuscator-executive.com/ [^5]: Mohan, V., & Hamlen, K. W. (2012). Frankenstein: Stitching Malware from Benign Binaries. WOOT, 12, 77-84. [^6]: Ma, W., Duan, P., Liu, S., Gu, G., & Liu, J. C. (2012). Shadow attacks: automatically evading system-call-behavior based malware detection. Journal in Computer Virology, 8, 1-13.

DMLDroid: Deep Multimodal Fusion Framework for Android Malware Detection with Resilience to Code Obfuscation and Adversarial Perturbations

Tue, 28 Jan 2025 00:00:00 GMT

Android malware poses a significant threat to mobile security, with attackers constantly evolving their techniques to evade detection. Traditional single-modality approaches often struggle to capture the diverse characteristics of malicious applications.

Below is an explanation of a multimodal approach for detecting Android malware using Deep Learning (DL). The framework utilizes feature fusion across three individual branches: Deep Neural Networks (DNN), Convolutional Neural Networks (CNN), and Bidirectional Encoder Representations from Transformers (BERT). Each branch processes different aspects of APK (Android Package Kit) files, and the outputs are combined in to improve predictive accuracy.

Overview the framework

My research multimodal framework integrates complementary features extracted from Android APK files using three separate branches:

DNN Branch: Extracts and analyzes tabular features such as permissions, intents, and other metadata from AndroidManifest files.
CNN Branch: Processes APK DEX files by converting them into RGB images to capture structural patterns.
BERT Branch: Analyzes API call sequences generated from the APK's call graphs using a pre-trained BERT model.

Each branch outputs a 128-dimensional feature vector and a logit prediction vector that are fused for final malware prediction.

Branch-Specific Processing

1. DNN Branch: Tabular Feature Analysis

The DNN branch processes tabular data extracted from the AndroidManifest.xml file, which is retireved by Apktool, including permissions, intents, services, and other metadata. These features are crucial for understanding the behavior and capabilities of an Android application. The input of this branch is a 1D vector of size 400, representing the tabular features. A DNN with fully connected layers is used to analyze the tabular data. The network learns to identify patterns and relationships in the metadata that may indicate malicious behavior.

2. CNN Branch: Image-Based Bytecode Analysis

The CNN branch focuses on the DEX (Dalvik Executable) files within the APK, which is extracted by decompressor like 7-zip, tar. These files contain the bytecode of the application, which is converted into RGB images. This transformation allows the CNN to analyze structural patterns in the bytecode that may be indicative of malware. The input is a 3-channel RGB image with dimensions (3, 64, 64), where 3 represents the color channels and 64x64 is the spatial resolution of the image. A CNN is employed to extract spatial features from the bytecode images. The CNN uses convolutional layers to detect local patterns and hierarchical structures in the image data.

3. BERT Branch: API Call Sequence Analysis

The BERT branch processes sequences of API calls generated from the APK's call graphs (which is extracted using Androguard). These sequences represent the dynamic behavior of the application and provide insights into how the app interacts with the Android system. The input consists of two components: input_ids (tokenized API call sequences) and attention_mask (to handle variable sequence lengths). These are standard inputs for transformer-based models like BERT. A pre-trained DistilBERT model is fine-tuned on the API call sequences. DistilBERT is a lightweight version of BERT that retains much of its performance while being more computationally efficient. The model learns to understand the semantic relationships between API calls and their potential malicious intent.

Summary of each branches

Branch	Input data	Input shape	Architecture	Extractor
DNN - Tabular Feature Analysis	Tabular data of permissions, actions, services	(400,)	A deep neural network with fully connected layers	Apktool
CNN - Image-Based Bytecode Analysis	Bytecode extracted from the DEX file, converted into RGB image	(3, 64, 64)	A convolutional neural network extracts spatial patterns	Decompressor (7-zip, tar, ...)
BERT - API Call Sequence Analysis	API call graphs are converted into sequences of API calls	(input_ids, attention_mask)	A pre-trained DistilBERT model fine-tuned on API call sequences	Androguard

Feature Fusion

The outputs from the three branches (each 128-dimensional on last hidden layer, or 1-dimesional on logit layer) are fused to create a comprehensive representation of the APK file. The fusion process combines features from all modalities to improve prediction performance. There are many fusion strategy, but mainly I've done it on intermediately fusion:

Concatenation of the three feature vectors (DNN, CNN, and BERT outputs).
Attention mechanisms to emphasize critical features.
Gated-fusion mechianism to utilize various information seamlessly for auto-adjusting prediction on each models.

Experimental Results

Below is a comparison table of the models. While binary classification only cares whether the application is malicious or not, multi-class classification gives a deeper insight into the family of malware.

Environment

My models were trained on Kaggle, with CPU Intel(R) Xeon(R) CPU @ 2.20GHz, 13 GB RAM, GPU Tesla P100-PCIE-16GB; Python 3.9, PyTorch 1.9.

Classification Report

Model	Acc.	Rec.	Pre.	F1	Training time (mins)	Testing time (mins)
DNN	96.88	95.97	95.56	95.77	0.62	0.10
CNN	95.15	93.90	93.01	93.44	1.55	0.21
BERT	87.18	80.75	83.18	81.85	181.62	35.89
Multimodal (concatenation)	97.72	96.81	96.97	96.89	179.60	34.15
Multimodal (attention)	97.70	95.89	97.80	96.80	181.66	35.03
Multimodal (gated-fusion)	97.44	96.71	96.34	96.52	180.89	34.76

DNN performs well with all high evaluation metrics. It is also the fastest in terms of training (0.62 mins) and testing (0.10 mins).
CNN has slightly lower performance compared to DNN, with accuracy and F1 scores around 95%. It is slower than DNN but still relatively efficient.
BERT underperforms compared to DNN and CNN, with all evaluation metrics around 80-90%. It is significantly slower in both training (181.62 mins) and testing (35.89 mins), likely due to its complex architecture and large number of parameters.
All multimodal methods (concatenation, attention, and gated fusion) outperform single-modality models (DNN, CNN, BERT) in all of evaluation metrics (all above 97%).

Conclusion

We explored a multimodal approach for detecting Android malware using deep learning feature fusion. By integrating three distinct branches—DNN, CNN, and BERT—we were able to leverage complementary features extracted from Android APK files.

For those interested in experimenting with the framework, the Kaggle notebook AndMalMultimodal provides a practical starting point. Feel free to explore, modify, and build upon this work to advance the field of Android malware detection.

Frida

Tue, 03 Dec 2024 00:00:00 GMT

My notes for using Frida

Android

Write script to a .js file. Usage:

frida -U com.example.app -l script.js

Common information

Check Java available

console.log(Java.available)

Check Android Version

console.log(Java.androidVersion)

List classes

Java.perform(() => {
  console.log("List classes in package com.example.app");
  Java.enumerateLoadedClasses({
    onMatch: function(className) {
      if (className.startsWith("com.example.app")) {
        console.log(className); 
      }
    },
    onComplete: function() {
      console.log("Done"); 
    }
  });
});

or, this version return a list:

Java.perform(function () {
  const classes = Java.enumerateLoadedClassesSync();
  console.log("Num of classes: ", classes.length);
  // console.log("Loaded classes: ", classes);
  // classes.forEach(function (cls) {
  //   if (cls.includes("com.example.app"))
  //     console.log(cls);
  // });
});

List methods of classes

Replace __class__ and __method__, with globs permitted.

Java.perform(() => {
  const groups = Java.enumerateMethods('*__class__*!__method__*')
  console.log(JSON.stringify(groups, null, 2));
});

Call method

Java.perform(() => {
  const targetedClass = Java.use("com.example.app");
  const instance = targetedClass.$new();
  const method = instance.__targetMethod__(var1, var2);
});

Nested call method

Java.perform(() => {
  const Activity = Java.use('android.app.Activity');
  const Exception = Java.use('java.lang.Exception');
  Activity.__targetMethod__.implementation = function () {
    throw Exception.$new('Oh noes!');
  };
});

Overwrite method

Java.perform(() => {
  const targetedClass = Java.use("com.example.app");
  const instance = targetedClass.$new();
  console.log("Instance: ", instance);
  instance.__firstTargetMethod__.implementation = function () {
    console.log("__firstTargetMethod__() called");
    // Do something here
  }

  instance.__secondTargetMethod__.implementation = function () {
    console.log("__secondTargetMethod__() called");
    // Also do something with this one
  }
});

ICTF - Forensics writeups

Sun, 01 Dec 2024 00:00:00 GMT

Two forensics CTF challenges I've done

10/31/2024: the-registrar

by lolmenow Description: Just carved this memory dump from the scarecrow's PC! Apparently he told me that his programs on startup was acting weird while trying to register his new software.

Following the clue, I try to find the hive file storing registry: Then dump this file at offset 0xb183c10b83e0: Open this .dat file using Registry Explorer, startup programs is registered at [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run], go there and get the base32 string: Decode this base32 string and reverse to get the flag: Flag: ictf{tH3_rEg1STry_i5_T0O_c0OL_foR_YOu!}

10/31/2024: the-partraditionalist

by lolmenow Description: The Forensics department over at ictf needs help recovering the flag from this image disk file!

The challenge give me a file, lets check it: Check some first line, I notice this image disk file has been corrupted: So I use testdisk tool to explore it (I run under sudo mode). Select partition table type = None Result should be like this when use select [ Analyse ]: After exploring for a time, I found there are 3 files in Software partition: Select all files and copy it to another location. Check these files, I know it use GPG to encrypt message: Importing this private key to decrypt message and get the flag: Flag: ictf{SH0Uld_i_aDd_my_L1NkeDiN_t0_tHE_6pg_Em4!L??}