S0354: Denis
Security context for executives and security teams
Denis is a Windows backdoor/Trojan documented by ATT&CK as used by APT32 and associated with SOUNDBITE and Goopy. Its importance is not just the malware name: the related behaviors cover host discovery, command execution, obfuscation, process hollowing, DNS-based command and control, tool transfer, file deletion, DLL abuse, and archiving. For leaders, this makes Denis a useful test case for whether Windows endpoint, DNS, and incident response visibility can reconstruct a stealthy post-compromise intrusion rather than only detect a known file hash.
Executive priority
Prioritize this as a Windows intrusion-readiness and evidence-quality issue. Ask whether the organization can prove coverage for PowerShell/cmd execution, registry and system discovery, suspicious DLL loading, process injection, DNS C2 patterns, tool ingress, and cleanup activity. Because the official ATT&CK object has no detection guidance, leadership should not assume product coverage; require SOC validation, IR evidence retention, and control testing mapped to the related techniques.
Technical view
ATT&CK lists Denis as Windows malware and links it to techniques spanning discovery, execution, stealth/evasion, command-and-control, and collection. SOC and IR teams should validate telemetry for Query Registry, System/User/File/Network Discovery, PowerShell and Windows Command Shell, Native API use, Process Hollowing, Obfuscated/Encoded/Decoded content, File Deletion, DNS C2, Ingress Tool Transfer, Archive via Library, and Hijack Execution Flow/DLL abuse. The object itself has no specified tactics and no official detection text, so detections should be behavior-led and tested against local Windows baselines rather than signature-only.
Likely telemetry
- Windows process creation events with command-line arguments
- PowerShell script block, module, and operational logs where enabled
- Registry query/access telemetry from EDR or Windows auditing
- File creation, modification, deletion, and archive creation events
- DLL load/module load telemetry and application execution context
Detection direction
- Build detections around behavior chains: discovery followed by command execution, obfuscated commands, tool transfer, DNS communication, and cleanup is higher value than any single weak signal.
- Tune PowerShell and cmd detections for suspicious encoded or obfuscated usage, but account for legitimate administration to reduce false positives.
- Validate visibility into process hollowing and Native API-driven execution; basic process logs may miss memory-level behavior.
- Review DNS analytics for unusual domains, query volume, encoding-like patterns, or rare destinations, while recognizing DNS is noisy and widely used for legitimate administration.
- Correlate DLL abuse and execution-flow hijacking with unusual paths, unsigned or unexpected libraries, and parent-child process context.
Mitigation priorities
- Start with evidence readiness: ensure Windows endpoint, PowerShell, DNS, file, registry, and process telemetry are collected and retained for IR reconstruction.
- Harden and monitor script and shell execution, including PowerShell logging and restrictions appropriate to business operations.
- Apply application control and DLL search-order hardening where feasible to reduce execution-flow hijacking and DLL abuse opportunities.
- Use EDR capabilities that can observe process injection/hollowing and suspicious Native API behavior, not only file-based malware detection.
- Restrict and monitor unnecessary outbound DNS and file-transfer paths; centralize DNS logging for investigation.
Additional notes and limits
The supplied ATT&CK data identifies Denis as a Windows backdoor/Trojan used by APT32, with similarities to SOUNDBITE and use alongside Goopy. The strongest defensive value comes from the related technique set, which describes what telemetry and controls should be validated. Attribution should remain conservative: the APT32 relationship is useful for intelligence enrichment but does not establish attribution for any local alert.
Official detection guidance is not provided for this object, and the object itself has no specified tactics. Several relationship descriptions are general ATT&CK technique descriptions, not Denis-specific procedural detail. Local baselines, logging configuration, EDR capability, DNS architecture, and administrative practices are required to determine actual detection coverage and priority.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Denis
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.