Deep#Door Stealer: Stealthy Python Backdoor and Credential Stealer Leveraging Tunneling, Multi-Layer Persistence, and In-Memory Surveillance Capabilities
Threat Intelligence, Threat Research, Threat Security
Deep#Door Stealer: Stealthy Python Backdoor and Credential Stealer Leveraging Tunneling, Multi-Layer Persistence, and In-Memory Surveillance Capabilities
By Securonix Threat Research: Akshay Gaikwad, Shikha Sangwan, Aaron Beardslee
tldr:
Securonix Threat Research analyzed a stealthy Python-based backdoor framework, dubbed Deep#Door, which uses an obfuscated batch loader to deploy a persistent surveillance and credential-stealing implant on Windows systems.
The intrusion chain begins with execution of a batch script (install_obf.bat) that disables Windows security controls, dynamically extracts an embedded Python payload (svc.py), and establishes persistence through multiple mechanisms including Startup folder scripts, registry Run keys, scheduled tasks, and optional WMI subscriptions.
Unlike traditional malware loaders that rely on external payload downloads, Deep#Door embeds its Python implant directly inside the dropper script and reconstructs it in-memory and on disk during execution.
The implant then establishes communication with attacker infrastructure hosted on bore[.]pub, a publicly available TCP tunneling service, enabling stealthy remote access without exposing dedicated C2 servers.
Once active, the backdoor enables full remote command execution and extensive surveillance capabilities including:
Keylogging
Clipboard monitoring
Screenshot capture
Webcam access
Microphone recording
Browser credential harvesting
SSH key extraction
Cloud credential theft
System reconnaissance
The malware incorporates numerous advanced anti-analysis and defense evasion mechanisms including sandbox detection, AMSI and ETW patching, ntdll unhooking, Windows Defender tampering, command-line wiping, timestamp stomping, and log clearing.
The resulting implant operates as a fully featured Remote Access Trojan (RAT) capable of long-term persistence, espionage, lateral movement, and post-exploitation operations within compromised environments.
Introduction to DEEP#DOOR:
Threat actors increasingly adopt script-driven intrusion frameworks rather than deploying standalone malware executables. These frameworks leverage native scripting environments, legitimate runtime components, and memory-resident execution techniques to blend malicious activity with normal system behavior.
Instead of relying on traditional PE binaries, attackers increasingly use interpreted languages such as Python to deliver flexible implants capable of dynamic capability expansion.
The Deep#Door campaign exemplifies this trend.
The intrusion begins with execution of a heavily obfuscated batch script that performs multiple staging operations:
- Security control tampering
- Embedded payload extraction
- Persistence deployment
- Remote command channel initialization
Rather than dropping compiled binaries, the loader deploys a Python-based RAT payload (svc.py) extracted directly from the dropper script itself. This design reduces the need for multiple network retrieval stages and minimizes disk artifacts.
The backdoor communicates with attacker infrastructure via bore.pub, a tunneling service that allows external operators to reach internal systems without exposing traditional C2 infrastructure.
Once operational, the implant exposes a large command set enabling remote control, credential harvesting, surveillance, persistence management, lateral movement, and destructive actions.
This advisory provides a stage-by-stage technical breakdown of the Deep#Door infection chain, including payload decoding, Python implant internals, and unique attacker techniques.
Threat Research Key Findings:
- Script-based loader framework: Relies on obfuscated batch scripts instead of executables, reducing static detection opportunities.
- Embedded payload delivery: Python backdoor (svc.py) is embedded directly within the dropper script and dynamically extracted.
- Multi-layer persistence:
- Startup folder scripts
- Registry Run keys
- Scheduled tasks
- WMI event subscriptions
- Watchdog self-healing threads
- Defender and logging tampering: Disables:
- Windows Defender
- PowerShell logging
- Event logs
- SmartScreen
- Firewall logging
- Advanced anti-analysis protection: Detects:
- Debuggers
- Virtual machines (registry, drivers, CPUID)
- Sandbox environments
- EDR hooks and instrumentation
- Bore tunneling infrastructure: Uses bore.pub for stealth C2 communications.
- Surveillance capabilities include:
- Keylogging
- Webcam capture
- Microphone recording
- Screen capture
- Clipboard monitoring
- Credential harvesting targets:
- Browser credentials
- Cloud tokens
- SSH keys
- Wi-Fi credentials
- Windows Credential Manager
Initial infection:
Figure 1 Process flow
The infection chain begins with execution of an obfuscated batch script:
cmd.exe /c “C:\User\researcher\Desktop\install_obf.bat”
This script acts as the primary dropper responsible for staging the Deep#Door implant.
Figure 2 install_obf.bat
Unlike conventional malware loaders that rely on external payload retrieval, this dropper is self-contained, embedding the full Python backdoor within its own body. This design significantly reduces network-based detection opportunities and simplifies delivery into restricted environments.
Embedded Payload Decoding (install_obf.bat → svc.py)
Self-Referential Payload Extraction
A key technique used by the loader is self-referential parsing, where the batch script reads its own file contents to extract the embedded payload. This allows the attacker to deliver the entire implant in a single file without relying on external downloads, significantly reducing network-based detection opportunities.
This is achieved using the following PowerShell command:
powershell -NoP -Command “$f=[IO.File]::ReadAllText(‘%~f0′);$m=[regex]::Match($f,'(?s)#PYTHON_START\r?\n(.+?)\r?\n#PYTHON_END’);if($m.Success){[IO.File]::WriteAllText(‘%LOCALAPPDATA%\SystemServices\svc.py’,$m.Groups[1].Value)}”
Decoding Logic Breakdown
1. Self-Reading Mechanism
$f=[IO.File]::ReadAllText(‘%~f0’)
- %~f0 refers to the currently executing batch file
- The script reads its own contents into memory as a string
- Enables fully self-contained payload extraction
This approach eliminates the need for secondary payload downloads and mimics fileless execution behavior, making detection through network telemetry significantly more difficult.
2. Payload Delimitation via Regex
$m=[regex]::Match($f,'(?s)#PYTHON_START\r?\n(.+?)\r?\n#PYTHON_END’)
- The embedded Python payload is wrapped between markers:
#PYTHON_START
<encoded Python payload>
#PYTHON_END
- (?s) enables single-line mode, allowing multi-line matching
- (.+?) performs a non-greedy capture of the payload
This controlled extraction ensures that only the intended Python code is isolated, preventing corruption of the payload while keeping it hidden inside a large obfuscated script.
3. Payload Reconstruction
[IO.File]::WriteAllText(‘%LOCALAPPDATA%\SystemServices\svc.py’,$m.Groups[1].Value)
- Extracted payload is written to: %LOCALAPPDATA%\SystemServices\svc.py
Figure 3 svc.py file drop in AppData
- The directory is intentionally named to mimic legitimate Windows services
- This helps evade casual inspection and blends into normal system activity
Multi-Layer Decoding Inside svc.py
Once written to disk, the Python payload itself contains additional layers of encoding and obfuscation, requiring runtime decoding.
1. Base64 Decoding Function
def _d(s):
return base64.b64decode(s).decode()
Used to decode embedded configuration values such as:
_H = _d(“Ym9yZS5wdWI=”) → “bore.pub”
_K = _d(“Y2hhbmdlbWUxMjM=”) → “changeme123”
This conceals critical infrastructure details from static analysis tools, requiring decoding before meaningful inspection can occur.
2. XOR Obfuscation Routine
def _xd(data, key=0x55):
return bytes(b ^ key for b in data)
- Applies XOR with key 0x55
- Used for lightweight obfuscation of:
- Strings
- Runtime data
- Potential payload fragments
This adds an additional decoding layer beyond Base64.
3. Dynamic Port Generation
_P = [41234+i for i in range(10)]
- Generates port range:
41234 → 41243
- Avoids static indicators by dynamically constructing connection targets
Instead of hardcoding a single port, the malware dynamically constructs a range of possible communication ports, allowing it to probe multiple endpoints and maintain connectivity even if some ports are blocked or monitored.
Figure 4 svc.py (Encoded)
Figure 5 svc.py (Decoded)
Stage 1: Security Control Tampering
Before deploying and executing the Python backdoor, the Deep#Door loader performs extensive pre-execution defense evasion by systematically weakening host-based security controls. This stage is critical to ensure that subsequent payload execution, persistence, and C2 communication occur with minimal visibility.
Windows Defender Suppression
The loader leverages PowerShell to directly manipulate Microsoft Defender configuration using the Set-MpPreference cmdlet. Multiple core protection features are disabled:
Set-MpPreference -DisableRealtimeMonitoring $true
Set-MpPreference -DisableBehaviorMonitoring $true
Set-MpPreference -DisableBlockAtFirstSeen $true
Set-MpPreference -DisableIOAVProtection $true
Impact of Disabled Protections:
- Real-Time Monitoring Disabled
- Prevents Defender from scanning files during execution or creation
- Allows the dropper and payload (py) to execute without interception
- Behavior Monitoring Disabled
- Stops detection of suspicious runtime activities such as:
- process injection
- credential dumping
- abnormal API usage
- Block-at-First-Seen Disabled
- Prevents cloud-based reputation checks for unknown files
- Allows newly dropped payloads to execute without reputation scoring
- IOAV Protection Disabled
- Disables scanning of files downloaded from browsers or email
- Reduces inspection of file ingress vectors
- Stops detection of suspicious runtime activities such as:
Defender Exclusions for Stealth Execution
To further evade scanning, the loader adds exclusions targeting both file paths and processes:
- Directory Exclusion
%LOCALAPPDATA%\SystemServices\
Ensures the dropped payload (svc.py) is not scanned
- Process Exclusions
- python.exe
- pythonw.exe
Prevents inspection of the Python runtime executing the backdoor
This combination allows the malware to operate persistently and invisibly within a trusted execution context.
Registry-Based Security Feature Disabling
The loader modifies multiple registry keys to suppress additional Windows security mechanisms:
1. SmartScreen Bypass
- Disables SmartScreen reputation checks
- Prevents warnings for unknown or untrusted scripts
2. PowerShell Logging Suppression
The following logging mechanisms are disabled:
- Script Block Logging
- Prevents logging of executed PowerShell commands
- Transcription Logging
- Prevents recording of PowerShell session activity
Example targeted registry paths:
HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription
- Eliminates visibility into malicious PowerShell execution
- Prevents forensic reconstruction of attacker activity
Firewall Logging Suppression
The loader disables Windows Firewall logging using:
netsh advfirewall set allprofiles logging droppedconnections disable
netsh advfirewall set allprofiles logging allowedconnections disable
- Prevents logging of:
- dropped connections (blocked traffic)
- allowed outbound connections (including C2 traffic)
- Obfuscates network-based detection and investigation
Additional Defense Evasion Observed (svc.py Runtime)
Once the Python payload executes, additional runtime tampering extends these protections further:
- Registry Policy Enforcement
- Sets Defender policy keys to permanently disable protections
- PowerShell-Based Configuration Enforcement
- Re-applies disabled settings even if reverted
- Tamper Protection Disabling
- Attempts to disable Defender tamper protection via registry
- ETW (Event Tracing for Windows) Patching
- Hooks and neutralizes telemetry event generation
- AMSI (Antimalware Scan Interface) Bypass
- Patches AMSI functions in memory to prevent script scanning
- Event Log Service Disruption
- Stops and disables:
- EventLog
- Sysmon
- Clears existing logs
- Stops and disables:
Strategic Purpose of This Stage
This stage is designed to blind both preventive and detective controls before the backdoor becomes active.
Key attacker objectives include:
- Pre-execution evasion
Prevent payload detection during staging - Runtime stealth
Allow malicious activities to execute without behavioral alerts - Forensic resistance
Eliminate logs and telemetry required for incident investigation - Persistence protection
Ensure implanted mechanisms are not detected or removed
Stage 2: Persistence Deployment
Deep#Door establishes multi-layered persistence to ensure long-term access, even if individual artifacts are removed. The malware combines traditional startup techniques with self-healing and stealthier mechanisms.
Startup Folder
A VBScript launcher is dropped into the user Startup directory:
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\SystemServices.vbs
Figure 6 Startup folder
This script silently executes the Python backdoor (svc.py) during user logon, ensuring automatic execution without requiring elevated privileges, while blending in with legitimate startup items.
Figure 7 Command inside SystemServices.vbs
Registry Run Key:
The malware creates a Run key entry under:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
SystemServices = wscript launcher.vbs
Figure 8 Registry run key
This guarantees execution every time the user logs in, providing redundancy alongside the Startup folder mechanism.
Watchdog Persistence:
A background watchdog thread continuously monitors persistence artifacts:
- Verifies presence of the VBScript launcher
- Checks registry Run key entries
- Restores missing components if deleted
Figure 9 watchdog thread monitors persistence
This self-repair capability makes manual remediation difficult, as removed persistence mechanisms are automatically recreated.
Optional WMI Persistence:
The malware can deploy a WMI event subscription, which triggers execution based on system events or time intervals.
- Operates independently of traditional startup locations
- Harder to detect using standard tools
- Provides persistence even if registry and startup entries are cleaned
Stage 3: Environment Validation
Before activating the backdoor, the malware performs extensive environment validation checks to determine whether it is running in a real user system or an analysis environment. This stage is critical for evasion, as it prevents execution in sandboxes, virtual machines, and security research setups.
These include detection for:
Debugger Detection
The malware implements multiple techniques to identify debugging activity:
Figure 10 Debugger Detection
- IsDebuggerPresent API
Uses native Windows API to quickly check if a debugger is attached to the process. This provides a fast initial signal of analysis activity. - NtQueryInformationProcess Checks
Queries low-level process structures such as debug ports and flags directly from the Windows kernel. This bypasses higher-level API hooks often used by security tools. - PEB Flag Inspection
Reads Process Environment Block (PEB) fields to identify debugging-related flags that indicate instrumentation or tracing. - Timing-Based Detection
Measures execution delays using high-resolution timers.
Artificial slowdowns introduced by debuggers or emulators can trigger detection.
These combined methods ensure that both user-mode and stealth debugging attempts are detected.
Virtual Machine Detection
The malware performs deep inspection to identify virtualized environments:
Figure 10 VM Detection
- Registry Artifact Checks
Searches for known VM-related registry keys associated with:- VMware
- VirtualBox
- Hyper-V
- Xen
- QEMU
- Hardware Fingerprinting
Uses PowerShell queries (WMI/CIM) to inspect:- BIOS version strings
- Manufacturer and model
- Baseboard details
- Indicators such as “VMware”, “VirtualBox”, or “QEMU” reveal virtualization.
- MAC Address Analysis
Extracts MAC address prefixes (OUI) and compares them against known VM vendor ranges. - Driver and DLL Enumeration
Looks for VM-specific drivers and files (e.g., VBoxGuest.sys, vmtoolsd.exe) in system directories. - CPUID Hypervisor Bit Check
Executes low-level CPU instructions to detect the hypervisor flag directly from processor registers. - This layered approach ensures detection even if one indicator is masked.
Sandbox Detection
The malware evaluates behavioral and environmental characteristics commonly associated with sandbox environments:
Figure 11 Sandbox Detection
- User and Hostname Checks
Flags generic or commonly used analysis usernames such as:
“admin”, “user”, “sandbox”, “malware”, “test” - Process Enumeration
Scans running processes for analysis tools such as:- Wireshark
- Procmon
- x64dbg
- IDA
- Burp Suite
- System Resource Constraints
Identifies low-resource systems typical of sandboxes:- RAM less than expected thresholds
- Small disk size
- Low CPU core count
- User Activity Monitoring
Detects lack of real user interaction:- Static mouse cursor
- Minimal recent files
- Limited installed applications
- Display Characteristics
Checks for abnormal screen resolution (e.g., very small displays common in VMs).
These checks help distinguish automated environments from real user systems.
Advanced Sandbox / Triage Detection (_chk_triage)
The _chk_triage() function introduces more advanced detection logic targeting enterprise-grade analysis platforms:
Figure 12 Triage Detection
- Detects known sandbox artifacts and directories (e.g., Cuckoo, ThreatGrid)
- Checks environment variables associated with automated analysis frameworks
- Identifies DNS sinkholing or lack of internet connectivity
- Detects execution under SYSTEM account (common in sandboxes)
- Verifies presence of real-world artifacts such as browser data and user activity
It also correlates multiple weak signals (e.g., no mouse movement + no network) to reduce false positives while still identifying automated environments.
Hook and EDR Detection (_chk_hooks)
The malware attempts to detect userland hooking mechanisms commonly used by EDR solutions:
Figure 13 Hook and EDR Detection
- Loaded DLL Inspection
Searches for known monitoring or hooking DLLs injected into the process memory - ntdll Integrity Checks
Verifies the integrity of critical system functions such as NtCreateFile - Inline Hook Detection
Reads the first bytes of function pointers to identify modifications caused by security tools
This allows the malware to identify whether its execution is being monitored or intercepted.
Stage 4: C2 Initialization
Once environment validation is complete, the Deep#Door implant proceeds to initialize communication with attacker-controlled infrastructure. This stage establishes a resilient and stealthy command-and-control (C2) channel using a tunneling service rather than traditional dedicated servers.
Encoded Configuration Extraction
The C2 configuration is not stored in plain text but is obfuscated within the Python payload:
- Base64-encoded host value
_H = _d(“Ym9yZS5wdWI=”) → decoded at runtime to pub - Encoded authentication key
_K = _d(“Y2hhbmdlbWUxMjM=”) → resolves to changeme123 - Dynamically generated port range
_P = [41234+i for i in range(10)] → produces ports 41234–41243
This approach ensures that static analysis tools cannot easily extract infrastructure details without executing or decoding the script.
Bore Tunneling Infrastructure Usage
Instead of relying on a traditional C2 server, the malware leverages bore.pub, a public TCP tunneling service:
- Allows attackers to expose internal services to the internet without opening firewall ports
- Eliminates the need for attacker-owned infrastructure
- Blends malicious traffic with legitimate tunneling usage
This significantly complicates attribution and network-based detection, as traffic appears to connect to a legitimate service.
Mass Port Scanning Strategy
The implant uses an aggressive and parallelized scanning mechanism to locate an active tunnel:
Figure 14 find_bore_port() function
- _find_bore_port() launches up to 100 concurrent worker threads
- Scans a large port range (1024–65535), not just predefined ports
- Each thread attempts TCP connections and inspects responses
This increases the likelihood of quickly identifying an active bore tunnel while remaining within service rate limits.
Challenge-Response Authentication Mechanism
After establishing a TCP connection, the malware performs authentication using a custom handshake:
- Server sends a random challenge string (32-character hex value)
- Client computes response:
SHA256(challenge + password) - Response is sent back to server
- If valid, server replies with AUTH_OK
This mechanism:
- Prevents unauthorized connections to the tunnel
- Ensures only implants with the correct embedded key can connect
- Avoids transmitting the password in cleartext
Buffered Socket Handling
The malware wraps the socket using a custom class (_BufSock) to handle:
- Partial packet reads
- Combined authentication + command data streams
- Reliable command parsing
This ensures stable communication even when network packets are coalesced or fragmented.
Connection Resilience and Retry Logic
The implant includes robust fallback and retry mechanisms:
- Attempts localhost connections first (e.g., 127.0.0.1:9999, 8888)
- Iterates through predefined bore ports
- Falls back to full port scanning if needed
- Repeats connection attempts in a loop with randomized delays
If a connection fails, the malware:
- Sleeps briefly
- Re-attempts discovery and authentication
- Maintains persistence until a valid C2 channel is established
Stealth Characteristics of C2 Design
This C2 initialization approach introduces several stealth advantages:
- No hardcoded IP addresses
- Use of legitimate tunneling infrastructure
- Encrypted authentication handshake
- Dynamic port discovery
- No dependency on external payload downloads
Stage 5: Command and Control
After successful authentication, the implant enters a persistent command loop, enabling continuous interaction with the attacker over the bore.pub tunnel.
The malware listens for incoming commands, executes them locally, and returns results via a custom TCP-based protocol using length-prefixed responses.
Core Capabilities
Operators can issue commands to:
- Execute shell commands (full remote shell access)
- Upload/download files
- Perform system and network reconnaissance
- Harvest credentials (browsers, Wi-Fi, cloud, SSH)
- Initiate surveillance (keylogging, screenshots, webcam, microphone, clipboard)
Operational Characteristics
- Uses subprocess for hidden command execution
- Supports extensive built-in modules (file ops, persistence, evasion)
- Maintains persistent connection with automatic retries
- Communicates over raw TCP tunneled via bore.pub (no HTTP/DNS artifacts)
Core Python Implant Capabilities (svc.py Analysis)
The svc.py implant functions as a full-featured modular RAT, combining stealth, surveillance, credential theft, and post-exploitation capabilities within a single Python-based framework. Below is a breakdown of its major functional areas and how they operate.
1. Defense Evasion & Stealth
The implant prioritizes evading detection and forensic visibility by directly tampering with Windows security and telemetry mechanisms.
- _patch_amsi() modifies AMSI functions in memory so that all script content is treated as benign, effectively bypassing antivirus scanning of scripts.
- _patch_etw() disables ETW logging by patching core telemetry APIs, preventing security tools from receiving runtime event data.
- _unhook_ntdll() restores a clean copy of dll in memory, removing userland hooks commonly used by EDR solutions.
- _clear_cmdline() overwrites command-line arguments in memory, making it difficult to trace how the malware was executed.
- _stomp_pe_header() corrupts PE headers in memory to hinder memory forensics and detection by scanners.
- _kill_event_log() stops logging services (including Sysmon) and clears logs, eliminating historical evidence of execution.
Together, these techniques significantly reduce both real-time detection and post-incident forensic visibility.
2. Surveillance Modules
The implant includes extensive real-time monitoring capabilities, enabling attackers to observe user activity and capture sensitive information.
- keylog_start() continuously captures keystrokes using Windows API polling, allowing collection of credentials and user input.
- take_screenshot() captures full desktop screenshots via PowerShell and GDI APIs for visual monitoring.
- webcam_snap() accesses connected cameras using multiple fallback methods (OpenCV, DirectShow, or native APIs).
- record_audio() records microphone input using Windows multimedia APIs, enabling ambient audio surveillance.
- clipmon_start() monitors clipboard changes to capture copied sensitive data such as passwords or tokens.
These modules provide attackers with comprehensive visibility into user behavior and environment activity.
3. Credential Harvesting
The malware systematically extracts credentials from multiple sources across the system.
- get_chrome_passwords() / get_edge_passwords() access browser SQLite databases to extract stored login data (even if encrypted).
- get_firefox_history() retrieves browsing activity, which can reveal authentication endpoints and usage patterns.
- cred_dump() enumerates Windows Credential Manager and stored system credentials.
- get_cloud_creds() searches for configuration files and environment variables containing AWS, Azure, and GCP credentials.
- get_ssh_keys() scans user directories for private SSH keys used for remote access.
Targets include browser-stored passwords, cloud authentication tokens, enterprise credentials, and SSH access keys, enabling lateral movement and account compromise.
4. Remote Control & Post-Exploitation
The implant provides full remote administration capabilities, allowing attackers to control the system and expand access.
- run_command() executes arbitrary shell commands, effectively providing a remote shell.
- reverse_shell() establishes outbound connections to attacker-controlled systems for alternate access paths.
- backdoor_start() opens a hidden local listener, creating a secondary persistent access mechanism.
- port_scan() scans internal or external hosts to identify reachable services and potential pivot targets.
These capabilities allow attackers to perform reconnaissance, lateral movement, and further payload deployment.
5. Persistence Hardening
To maintain long-term access, the malware implements multiple redundant persistence mechanisms.
- _start_watchdog() continuously monitors persistence artifacts and restores them if removed, ensuring resilience.
- wmi_persist() creates WMI event subscriptions that trigger execution periodically, even if traditional persistence is cleaned.
- Additional persistence via Startup folder, Registry Run keys, and Scheduled Tasks ensures execution across reboots.
This layered approach makes removal difficult, as multiple mechanisms must be simultaneously eradicated.
6. Destructive & Advanced Capabilities
Beyond surveillance and access, the implant includes capabilities for disruption and system manipulation.
- overwrite_mbr() overwrites the Master Boot Record, rendering the system unbootable.
- trigger_bsod() forces a system crash, potentially used for anti-forensics or disruption.
- fork_bomb() spawns excessive processes to exhaust system resources and cause instability.
- disable_defender_full() aggressively disables Windows Defender services, policies, and processes.
These features indicate the malware can shift from espionage to destructive operations if required.
Defense Evasion Summary
Deep#Door incorporates a layered and highly aggressive set of defense evasion techniques designed to bypass security controls, evade detection, and complicate forensic analysis. These mechanisms operate both before and during execution to ensure the implant remains stealthy throughout its lifecycle.
Anti-Analysis Protections
The malware performs extensive environmental checks before fully activating.
It leverages multiple techniques to detect debugging, sandboxing, and virtualized environments:
- Windows API calls such as IsDebuggerPresent and low-level NtQueryInformationProcess are used to identify attached debuggers.
- Timing-based checks detect execution delays typically introduced by analysis tools.
- Virtual machine detection is performed through registry artifacts, hardware fingerprints, MAC address prefixes, and CPUID hypervisor flags.
- Sandbox detection includes identifying suspicious usernames, low system resources, lack of user activity, and presence of analysis tools.
If any suspicious indicators are found, the malware delays execution or enters a dormant state, effectively evading automated analysis systems.
Logging Tampering
To reduce visibility into its activity, the malware actively disables multiple logging mechanisms:
- Windows Event Logs (Security, System, Application) are stopped, cleared, or disabled.
- PowerShell logging features such as Script Block Logging and Transcription are turned off via registry modifications.
- ETW (Event Tracing for Windows) is patched in memory, preventing telemetry generation at the API level.
- Sysmon services may be stopped and disabled to remove advanced endpoint telemetry.
This significantly limits the ability of defenders to reconstruct attacker actions or detect anomalies through logs.
Command-Line Wiping
The implant removes evidence of its execution parameters directly from memory:
- argv values are overwritten to mask the original execution command.
- The in-memory buffer returned by GetCommandLineW is modified and replaced with benign-looking data (e.g., “svchost.exe”).
This prevents investigators and security tools from identifying how the malware was launched, which is often critical for incident response.
Timestamp Stomping
To blend in with legitimate system files, the malware modifies file metadata:
- File creation, access, and modification timestamps are altered to match trusted binaries (e.g., exe).
- This makes malicious files appear older and legitimate during forensic timeline analysis.
Such manipulation complicates efforts to determine when the compromise occurred and which files were introduced by the attacker.
Trusted Process Abuse
The malware attempts to operate within the context of legitimate system processes:
- It restores unhooked system libraries (e.g., dll) to remove security monitoring hooks.
- Code execution and malicious logic run under trusted processes such as exe or masqueraded system processes.
- Memory-level modifications (e.g., PE header wiping) further obscure the presence of malicious code.
By blending into trusted processes, the malware reduces the likelihood of detection by behavior-based security tools.
Conclusion
Deep#Door highlights the continued evolution of threat actors toward fileless, script-driven intrusion frameworks that rely heavily on native system components and interpreted languages like Python. By embedding the payload directly within the dropper and extracting it at runtime, the malware significantly reduces external dependencies and limits traditional detection opportunities.
The use of public tunneling infrastructure (bore[.]pub) further eliminates the need for dedicated attacker-controlled servers, enabling covert and resilient command-and-control communications that blend with legitimate traffic patterns.
Additionally, the combination of multi-layer persistence, advanced defense evasion (AMSI/ETW patching, ntdll unhooking), and in-memory stealth techniques allows the implant to operate with minimal forensic footprint while maintaining long-term access.
With its extensive capabilities spanning surveillance, credential harvesting, lateral movement, and system manipulation, Deep#Door represents a highly versatile Remote Access Trojan suitable for espionage and sustained compromise operations.
Defenders should prioritize behavioral and correlation-based detection approaches, focusing on:
- Suspicious script execution and self-referential payload extraction
- Unauthorized modifications to security controls and logging mechanisms
- Abnormal persistence artifacts (Startup, Registry, WMI)
- Unusual outbound connections to tunneling services
- Indicators of in-memory tampering and API patching
A layered defense strategy combining endpoint telemetry, network monitoring, and threat hunting is critical to effectively detect and mitigate such advanced, stealth-focused threats.
Securonix recommendations
Vigilance Against Script-Based Loaders:
This campaign leverages heavily obfuscated batch scripts as the primary delivery mechanism instead of traditional executables.
Exercise caution when encountering .BAT, .CMD, or script-based files delivered via email, downloads, or shared locations.
Avoid executing scripts from untrusted sources, especially those invoking PowerShell with encoded or self-referential logic.
Educate users that seemingly benign scripts can contain embedded payloads and execute multi-stage attacks without requiring additional downloads.
Monitor Self-Referential Payload Extraction:
Deep#Door uses a self-parsing technique where the batch file reads its own contents and extracts an embedded Python payload.
Security teams should monitor for:
- PowerShell commands reading %~f0 (self-file reference)
- Regex-based extraction patterns inside scripts
- File writes to suspicious directories such as:
%LOCALAPPDATA%\SystemServices\
These behaviors are strong indicators of fileless-style staging techniques.
Enhance Visibility into Script Execution:
Enable detailed logging for:
- PowerShell execution (Script Block Logging – Event ID 4104)
- Command-line process creation (Event ID 4688 / Sysmon Event ID 1)
This provides visibility into decoded runtime commands, especially when malware uses Base64 or XOR obfuscation.
Detect Defense Evasion Activity:
Deep#Door aggressively tampers with security controls including:
- Windows Defender configuration changes
- AMSI and ETW patching
- Event log clearing and disabling
Monitor for:
- Set-MpPreference abuse
- Registry modifications under Defender and logging policies
- Suspicious use of wevtutil, sc stop EventLog, or audit policy changes
These actions often occur early in execution and indicate preparation for stealth persistence.
Monitor Persistence Mechanisms:
The malware establishes multi-layer persistence across several locations.
Track and audit:
- Startup folder modifications
- Registry Run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run)
- Scheduled tasks and WMI event subscriptions
Additionally, monitor for watchdog behavior, where persistence artifacts are recreated after deletion.
Network Monitoring and C2 Detection:
Deep#Door uses bore[.]pub tunneling infrastructure for command-and-control communication.
Monitor for:
- Outbound connections to pub
- Unusual TCP connections across dynamic port ranges (41234–41243)
- Repeated connection attempts across sequential ports
This behavior may indicate automated port scanning for active tunnels.
In-Memory and API Tampering Detection:
The implant performs advanced in-memory evasion techniques including:
- ntdll unhooking
- AMSI patching
- ETW patching
Deploy EDR or Sysmon to detect suspicious API usage such as:
- VirtualProtect
- WriteProcessMemory
- CreateRemoteThread
These may indicate runtime patching or code injection activity.
Proactive Threat Hunting:
Security teams should hunt for:
- Python execution from unusual directories (e.g., %LOCALAPPDATA%\SystemServices\)
- Hidden or masquerading processes (e.g., fake service names)
- Command-line anomalies or cleared arguments
Look for signs of long-running Python-based processes with network connectivity.
Credential Access and Data Exfiltration Monitoring:
Deep#Door targets a wide range of sensitive data sources including:
- Browser credential stores
- Cloud configuration files
- SSH keys and system credentials
Monitor access to:
- Browser SQLite databases
- .ssh directories
- Cloud credential paths (.aws, .azure, .config)
Unusual access patterns may indicate credential harvesting activity.
Incident Response Guidance:
In suspected infections:
- Isolate affected systems immediately
- Inspect persistence locations (Startup, Registry, WMI)
- Analyze memory for signs of patched system libraries
- Review network logs for tunneling activity
Securonix customers can leverage hunting queries to identify:
- Script-based execution chains
- Suspicious persistence artifacts
- Connections to tunneling infrastructure
MITRE ATT&CK Matrix
| Tactics | Techniques |
| Initial Access | T1566 – Phishing T1204 – User Execution |
| Execution | T1059.003 – Command and Scripting Interpreter: Windows Command Shell T1059.001 – Command and Scripting Interpreter: PowerShell T1059.006 – Command and Scripting Interpreter: Python |
| Persistence | T1547.001 – Boot or Logon Autostart Execution: Registry Run Keys/Startup Folder T1053.005 – Scheduled Task/Job: Scheduled Task T1546.003 – Event Triggered Execution: WMI Event Subscription |
| Defense Evasion | T1562.001 – Impair Defenses: Disable or Modify Tools T1562.006 – Impair Defenses: Indicator Blocking T1070.001 – Indicator Removal: Clear Windows Event Logs T1070.006 – Indicator Removal: Timestomp T1027 – Obfuscated Files or Information T1140 – Deobfuscate/Decode Files or Information T1562.004 – Disable or Modify System Firewall |
| Privilege Escalation | T1548.002 – Abuse Elevation Control Mechanism: Bypass User Account Control |
| Discovery | T1082 – System Information Discovery T1057 – Process Discovery T1083 – File and Directory Discovery T1046 – Network Service Discovery T1018 – Remote System Discovery |
| Command and Control | T1071.001 – Application Layer Protocol: Web Protocols T1572 – Protocol Tunneling T1095 – Non-Application Layer Protocol |
| Collection | T1056.001 – Input Capture: Keylogging T1113 – Screen Capture T1125 – Video Capture T1123 – Audio Capture T1115 – Clipboard Data |
| Exfiltration | T1041 – Exfiltration Over C2 Channel T1567 – Exfiltration Over Web Service |
Relevant Securonix detections
- EDR-ALL-1038-RU
- EDR-ALL-1015-RU
- WEL-ALL-999-RU
- PSH-ALL-5-RU
Additional Detections on Securonix Connect
Relevant hunting queries
(remove square brackets “[ ]” for IP addresses or URLs)
- index = activity AND rg_functionality = “Endpoint Management Systems” AND (deviceaction = “Process Create” OR deviceaction = “Process”) AND (processcommandline CONTAINS “install_obf.bat” OR processcommandline CONTAINS “svc.py”)
- index = activity AND rg_functionality = “Endpoint Management Systems” AND (deviceaction = “File created” OR deviceaction = “File created (rule: FileCreate)”) AND (TargetFileName CONTAINS “\SystemServices\svc.py” OR TargetFileName CONTAINS “\SystemServices\launcher.vbs”) OR TargetFileName CONTAINS “\Startup\SystemServices.vbs”)
- index = activity AND rg_functionality = “Endpoint Management Systems” AND (deviceaction = “Registry value set”) AND (registrykey CONTAINS “Software\Microsoft\Windows\CurrentVersion\Run” AND registryvalue CONTAINS “SystemServices”)
- index = activity AND rg_functionality = “Endpoint Management Systems” AND (deviceaction = “Process Create”) AND (processcommandline CONTAINS “Set-MpPreference” OR processcommandline CONTAINS “DisableRealtimeMonitoring” OR processcommandline CONTAINS “DisableBehaviorMonitoring”)
- index = activity AND rg_functionality = “Next Generation Firewall” AND (destinationhostname CONTAINS “bore.pub” OR destinationport >= 41234 AND destinationport <= 41243)
- index = activity AND rg_functionality = “Endpoint Management Systems” AND (deviceaction = “Process Create”) AND (processcommandline CONTAINS “Add-MpPreference” OR processcommandline CONTAINS “netsh advfirewall set allprofiles logging”)
C2 and infrastructure
| C2 Address |
| bore[.]pub |
Analyzed files/hashes
| File Name | SHA256 |
| install_obf.bat | 2c2386ef6416ce821e377223d2a3b79f2b7ea9e8dc9ed2549f4676fe060b7ddd |
| svc.py | 84515368e2f8ff4467e38bf48dabb267b5b895f54df5be5ceb5428a414ae15e9 |
| svc.py (decoded) | 4e3ae82eed8980bbc396020c197c767ba22483a124a00ee04c264dd394378485 |
| launcher.vbs / SystemServices.vbs | c6f00569913cd6bd1017b26bd33bbb28f1d92b9c9e0f830adcc24af59e181d3e |
