Malware analysts spend a lot of time deciding which signals from a sandbox run are worth keeping. A sample executed in a controlled environment can generate hundreds of measurable attributes covering file structure, registry edits, process behavior, and network traffic. Most of those attributes add noise. A recent study works through this problem in detail, and the part that earns attention from working defenders is the feature selection, not the deep learning model attached to it.

What the study set out to do

The team built a detection framework for Windows-based IoT and industrial IoT gateways. They assembled 3,000 Windows executables, ran each one through the ANY.RUN sandbox, and recorded behavioral, static, and network-level data for every sample. The samples were labeled benign, suspicious, or malicious. From the raw output, they pulled an initial pool of 146 features and reduced it to a working set of 33. A custom neural network they call TrDNN then classified the samples, and they compared it against ten common machine learning and deep learning models.

The classification results came out strong. For a cybersecurity reader, the more useful material sits in how the 33 features were chosen and what those features say about current Trojan tradecraft.

The feature set reads like a Trojan playbook

The retained features map to the stages of a Trojan compromise. Persistence shows up through registry autorun keys, scheduled tasks, Windows service installation, and startup-folder edits. Execution and evasion appear through process injection into trusted processes such as explorer.exe and svchost.exe, memory-allocation calls, hidden-window execution, and User Account Control tampering. Command-and-control activity comes through in low-jitter beaconing intervals, HTTP POST and PUT patterns that point to data exfiltration, encrypted outbound bursts, and traffic concentrated on a small number of endpoints. Binary-level signals round it out, including PE header anomalies, high section entropy, and unsigned executables sitting in system directories.

The exclusions are equally informative. The team dropped privilege-token manipulation, generic HTTP communication chains, and abuse of living-off-the-land binaries such as PowerShell and regsvr32. These behaviors carry real weight in an investigation, and they appear across ransomware, worms, and red-team tooling, which lowers their value for separating Trojans from everything else. That reasoning is a reminder that a signal common to many threat types can still be a poor discriminator for one of them.

This catalog is portable knowledge. The detection list works as a behavioral checklist for threat hunting, EDR tuning, and detection-rule writing, independent of any single model.

Background on Trojan detection and sandbox analysis

Trojan malware is one of the most prevalent threats in enterprise environments. Unlike worms that self-propagate or ransomware that encrypts immediately, Trojans often rely on social engineering to gain initial access. Once inside, they establish persistence, communicate with command-and-control servers, and execute payloads for data theft, lateral movement, or additional malware delivery. Detection is challenging because many Trojans mimic legitimate software behavior: they write to the registry, create scheduled tasks, or invoke system utilities like PowerShell.

Sandbox analysis, the technique used in this study, executes suspicious files in an isolated environment to observe their behavior. Modern sandboxes record hundreds of events per sample, from file system changes to network connections. However, not all events are equally useful for detection. The difference between a benign program that updates itself and a Trojan that downloads a payload may come down to subtle patterns in URL structures or timing intervals. Feature selection is the process of identifying which events correlate most strongly with malicious intent, and it is often more important than the classification algorithm itself.

The study addressed this by starting with 146 raw features and systematically reducing them based on relevance to Trojan activity. This approach avoids overfitting and ensures the model focuses on behaviors that genuinely separate Trojans from other software categories. The resulting 33 features are not only effective for the deep learning model but also manually reviewable by analysts, making them practical for real-world security operations.

Detailed breakdown of the 33 features

The features can be grouped into four categories: persistence mechanisms, execution and evasion techniques, command-and-control (C2) indicators, and binary-level anomalies. Each category reflects a stage in the Trojan lifecycle and provides concrete signals for detection teams.

Persistence features include creation of registry autorun keys under HKLM or HKCU, installation of Windows services via CreateService API, addition of scheduled tasks through schtasks.exe or scheduled tasks API, and modifications to the Startup folder. Trojans use these to survive reboots and user logouts. A benign installer might also create startup entries, but the combination with other behavioral markers distinguishes malicious intent.

Execution and evasion features capture how a Trojan runs its payload while hiding from detection. Process injection into explorer.exe or svchost.exe is a hallmark of many advanced Trojans, allowing them to run code within trusted processes. Calls to VirtualAllocEx or WriteProcessMemory indicate memory injection. Creating windows with hidden flags (WS_HIDDEN) is a common evasion tactic. User Account Control (UAC) bypass attempts, such as token duplication or CMSTP abuse, indicate an attempt to gain elevated privileges without prompting the user.

Command-and-control features focus on network behavior. Trojans typically beacon to C2 servers at regular intervals with low jitter – meaning the time between callbacks is nearly constant. HTTP POST requests containing encrypted or encoded data, especially with custom User-Agent strings, are strong signals. Outbound traffic that spikes in short bursts and targets a small set of IP addresses or domains also points to C2. The study found that simple statistical measures of beaconing intervals, when combined with payload characteristics, were highly discriminative.

Binary-level features look at the file itself. PE header anomalies, such as suspicious section names or unusual optional header fields, can indicate packing or obfuscation. High section entropy (e.g., >7.0 for a compressed section) is a classic sign of packed malware. Unsigned executables placed in system directories like C:\Windows\System32 are unusual for legitimate software and often appear in Trojan attacks.

The exclusion of privilege-token manipulation is worth noting. Many red team tools and legitimate software manipulate tokens for privilege escalation. Since this behavior appears across multiple threat categories, its inclusion would dilute the model's ability to focus on Trojan-specific patterns. Similarly, generic HTTP communication chains are too common in legitimate applications, while living-off-the-land binaries are abused by all kinds of threats. The study's disciplined feature reduction ensures that each selected signal has high precision for Trojan detection.

Deployment claims deserve a closer look

The researchers ran the framework as a continuous monitoring loop driven by the Windows command line, using built-in utilities such as tasklist, netstat, and wmic to enumerate processes, extract the 33 features, and pass them to the trained model. They report stable operation on a standard enterprise workstation with an Intel Core i7 processor and 32 GB of RAM, with no GPU or specialized hardware. The loop runs on a three-minute cycle, which they settled on after stress testing.

That setup matters for environments with operator workstations, human-machine interfaces, and supervisory systems, where Windows is common and spare compute is limited. A detection approach that runs on hardware already in the building lowers the barrier to adoption. The three-minute cycle is a compromise between detection latency and system load: the team tested faster cycles (one minute) but found they caused CPU spikes during peak activity; slower cycles (five minutes) missed short-lived behaviors like quick C2 callbacks. The optimal interval depends on the environment and the types of Trojans most likely to be encountered.

It is important to note that this deployment uses command-line tools that are native to Windows. This design choice avoids dependencies on third-party agents or kernel drivers, making the solution easier to deploy in air-gapped or heavily regulated environments where software installation is restricted. However, it also means the detection loop can be bypassed if an attacker gains administrative privileges and kills the monitoring process. In practice, the framework should be part of a layered defense, not a standalone solution.

Where the limits sit

The researchers are direct about the constraints. The dataset is moderate in size and comes from a single sandbox source, which raises the question of how well the model generalizes to samples it has never seen. Trojans engineered to stay dormant may never surface during a given monitoring window, since the system depends on observing live behavior. Sophisticated malware that detects sandbox conditions can suppress its activity and feed the model misleading data.

The platform constraint carries the most operational weight. The pipeline targets Windows. Many IoT devices run embedded Linux, real-time operating systems, or microcontroller firmware, and the command-line scripts do not port to those systems. The framework fits the Windows-heavy slice of an industrial environment and leaves the embedded layer for separate tooling.

Another limitation is the reliance on known behavioral patterns. While the 33 features capture common Trojan tactics, advanced Trojans such as fileless or memory-resident variants may not exhibit the same persistence or injection behaviors. The model would need retraining on samples that reflect evolving tradecraft. Additionally, the three-minute cycle may miss threats that execute quickly and then remove all traces, such as data-stealing Trojans that exfiltrate files and self-delete.

Disciplined feature work over bigger models

The transferable lesson runs deeper than one model. Strong detection came from disciplined, domain-informed feature work that isolated behaviors specific to Trojan activity. Defenders can apply that thinking to their own pipelines: identify the signals tied to a threat's lifecycle, discard the ones that fire across every category, and keep the detection logic understandable to the analysts who maintain it.

For threat hunters, the list of 33 features can be converted directly into search queries for SIEM platforms or EDR tools. They can look for simultaneous occurrence of a registry autorun entry, a process injection into explorer.exe, and periodic HTTP POSTs to a new domain. Security operations teams can tune their detection rules to prioritize these combinations over noisier alerts like PowerShell execution or raw registry modifications.

The study also underscores the value of manual feature engineering in an era of automated feature extraction. While deep learning can discover relationships in raw data, a curated feature set built on expert knowledge remains competitive and interpretable. This is especially important in cybersecurity, where false positives erode trust in automated systems. By focusing on behaviors that directly reflect adversary intent, the model provides actionable intelligence rather than probabilistic scores.

Finally, the open structure of the 33 features invites the community to test and extend them. Organizations can gather their own sandbox logs, measure how each feature performs against their threat landscape, and adjust weights or add new signals. The approach is not a black box; it is a foundation for building adaptive detection that improves over time. As Trojan tradecraft evolves, so too should the feature set, maintaining its relevance through continuous refinement.

Source:Help Net Security News