Malware analysts spend countless hours deciding which signals from a sandbox run are worth keeping. A single 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—they fire across benign and malicious samples alike, diluting the signal that actually matters. 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.

The research team built a detection framework specifically for Windows-based IoT and industrial IoT gateways—devices often overlooked in enterprise security but increasingly targeted by threat actors. 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 its performance against ten common machine learning and deep learning models.

The classification results came out strong, with high accuracy and low false-positive rates. But 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 selection process was not automated; it relied on expert knowledge of malware behavior. The team manually examined each of the 146 raw features, discarding those that were too generic, too noisy, or too easily evaded. This domain-driven approach stands in contrast to the common practice of throwing all features into a black-box model and hoping for the best.

The feature set reads like a Trojan playbook

The retained features map directly to the stages of a Trojan compromise. Persistence mechanisms show up through registry autorun keys, scheduled tasks, Windows service installation, and startup-folder edits. These are classic footholds that Trojans use to survive reboots. Execution and evasion appear through process injection into trusted processes such as explorer.exe and svchost.exe, memory-allocation calls like VirtualAllocEx, hidden-window execution, and User Account Control (UAC) tampering. Command-and-control (C2) activity comes through in low-jitter beaconing intervals—regular heartbeat communications that avoid predictable patterns—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 (e.g., mismatched section sizes), high section entropy (indicating packed or encrypted code), 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 (LOLBins) 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. For example, PowerShell usage is ubiquitous in both legitimate administration and malicious activity; including it would have flooded the model with false positives.

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. Defenders can take the 33 features and map them directly to their own SIEM queries or YARA rules. The study published the full feature set, which includes specific registry keys (e.g., HKCU\Software\Microsoft\Windows\CurrentVersion\Run), process names commonly injected into, and network indicators such as beaconing jitter thresholds. This level of detail enables teams to quickly assess their coverage against Trojan tactics, techniques, and procedures (TTPs).

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 to balance detection responsiveness with system load.

That setup matters for environments with operator workstations, human-machine interfaces, and supervisory control 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. Many industrial organizations cannot deploy heavy security agents on legacy machines; a lightweight, script-driven loop that relies only on native OS commands is far more palatable. The researchers also note that the three-minute interval is sufficient to catch most active Trojans, which typically maintain persistent C2 channels or perform regular file operations.

However, the deployment claims deserve scrutiny from a practical standpoint. Running continuous enumeration with wmic and netstat every three minutes creates a measurable performance overhead, especially on older hardware. The study measured CPU usage at around 5–8% during peak extraction, which is acceptable for most workstations but could interfere with real-time processes on a control system. Additionally, the reliance on wmic is problematic because Microsoft has deprecated the tool in recent Windows versions in favor of PowerShell cmdlets. Organizations still running Windows 10 or Server 2016 may find wmic functional, but future-proofing would require migration to PowerShell-based scripts, which introduces different attack surface considerations.

Where the limits sit

The researchers are direct about the constraints. The dataset is moderate in size—3,000 samples—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 ANY.RUN sandbox has known evasion countermeasures, but advanced Trojans can still detect virtualization or emulation and alter their execution path accordingly.

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. This is a significant gap, given that the majority of IoT gateways—especially in manufacturing, energy, and transportation—run Linux-based distributions. The study acknowledges this limitation but does not offer a cross-platform solution. For defenders overseeing heterogeneous environments, this means retaining separate detection stacks for Windows and non-Windows devices.

Another limitation not fully discussed is adversarial machine learning. An attacker aware of the 33 features could deliberately alter Trojan behavior to evade detection. For example, they could reduce beaconing jitter to match network noise, sign executables with stolen certificates, or avoid process injection by using fileless techniques. The model itself is a neural network, which is susceptible to carefully crafted perturbations. The researchers did not test adversarial robustness, leaving a gap for real-world deployment where attackers actively probe defenses.

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. The study demonstrates that a smaller, carefully curated feature set can outperform a larger, noisier one, even when the latter is paired with a more complex model.

This principle has been echoed in other security research—for instance, in phishing URL detection or network anomaly detection. But here it is applied to Trojan malware, a category that continues to evolve and dominate the threat landscape. The Behavioral Indicators of Compromise (BIOCs) derived from the 33 features can serve as a foundation for automated response actions, such as terminating suspicious processes or blocking outbound connections to unknown IPs. The study also provides a benchmark for future work: any new detection system should at least match the performance of TrDNN on a comparable dataset, using the same or better feature engineering.

For defenders, the immediate takeaway is to audit their current detection rules against the 33-feature checklist. How many of those signals are already covered? Which ones are missing? Do their EDR sensors capture registry autorun changes? Do they monitor for process injection into svchost.exe? Are they tracking beaconing intervals in network logs? The answers will reveal gaps that can be closed without purchasing new tools—only by adjusting existing configurations.

Source: Help Net Security News