{"_id":{"$oid":"69e7925759a6632dae07ddfe"},"sha256":"e37c838dc5eaa1b302ffbd8721c6a5f52a068e8f78bbec63b19b950462fe6cf8","content":"## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### 5.5.1 Registry-Based Persistence\n\n| Registry Key | Value | Data Written | MITRE Technique | [CODE] Writer Function | [STATIC] Path in Strings | [DYNAMIC] API Confirmed | Confidence |\n|-------------|-------|-------------|----------------|----------------------|-------------------------|------------------------|------------|\n| HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run | 2 | C:\\Users\\0xKal\\AppData\\Roaming\\2.exe | T1547.001 | sub_401230 | Yes | RegSetValueExW | HIGH |\n\n#### Correlation Analysis\n\nThe registry-based persistence mechanism demonstrates a classic autorun implantation strategy with strong tri-source corroboration. **[STATIC]** analysis reveals the target registry path `HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run` embedded as a wide-string within the binary's `.rdata` section at virtual address 0x403120, indicating deliberate hardcoding of the persistence location. **[CODE]** decompilation identifies `sub_401230` as the responsible function, which constructs a registry value entry using `RegSetValueExW`, setting the value name \"2\" with data pointing to the malware's dropped executable path `C:\\Users\\0xKal\\AppData\\Roaming\\2.exe`. This function systematically opens the target key via `RegCreateKeyExW` before writing the persistence entry. **[DYNAMIC]** sandbox execution confirms this behavior through multiple `RegSetValueExW` calls originating from process ID 8140, specifically observed during the persistence phase at call IDs 42751-42757, with explicit registry key manipulation targeting the exact HKCU Run key identified statically.\n\nThis HIGH CONFIDENCE finding indicates sophisticated understanding of Windows persistence mechanisms, utilizing the current user context to avoid administrative requirements while ensuring execution at every user login. The choice of value name \"2\" suggests an attempt at blending with legitimate software entries, while the dropped executable path in the user's AppData folder aligns with typical malware staging directories for maintaining stealth.\n\n### 5.5.4 File-Based Persistence\n\n| Mechanism | Location/Key | Severity | MITRE ID | [CODE] Function | Removal Complexity |\n|-----------|-------------|----------|----------|-----------------|-------------------|\n| Startup Folder Link | C:\\Users\\0xKal\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\wvcHSnDAjR.lnk | High | T1547.001 | sub_4015a0 | Medium |\n\n#### Correlation Analysis\n\nThe file-based persistence mechanism leverages the Windows Startup folder through symbolic link creation, demonstrating layered persistence strategies. **[STATIC]** examination reveals the target path `C:\\Users\\0xKal\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\` embedded within the binary, alongside a randomly generated filename `wvcHSnDAjR.lnk` designed to evade pattern-based detection. **[CODE]** analysis identifies `sub_4015a0` as the dedicated function responsible for creating this persistence artifact, implementing a multi-step process involving `CreateFileW` for link creation followed by `WriteFile` operations to embed the target executable metadata. The function includes logic for generating unique filenames to prevent collision and enhance stealth. **[DYNAMIC]** execution traces confirm the creation of the exact `.lnk` file through `CreateFile` API calls from process ID 8140, specifically at call IDs 42737 and subsequent related calls, with the sandbox capturing both the file creation event and the final presence of `wvcHSnDAjR.lnk` in the Startup directory.\n\nThis persistence method represents advanced tradecraft by combining registry and file-system approaches, ensuring redundancy if one mechanism is discovered and removed. The use of randomized filenames and legitimate system paths indicates awareness of defensive monitoring practices, requiring defenders to implement behavioral rather than signature-based detection methods.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-04-29T09:46:49.080572"}
{"_id":{"$oid":"69e9aa4f59a6632dae07de18"},"md5":"9a5ff998dbf0f6923d0b454d89800fb4","content":"# **MILITARY-GRADE TECHNICAL INTELLIGENCE REPORT**  \n## **Section 5: Anti-Analysis & System Persistence — Full Implementation-to-Runtime Chain**\n\n---\n\n## **5.1 Anti-VM Techniques — Binary Artifact to Runtime Check**\n\nNo evidence of anti-VM techniques was observed across any of the three analysis pillars. Static markers such as hypervisor-specific strings, registry paths, or file artifacts were absent. No corresponding code logic implementing VM checks was identified in decompilation. Dynamic behavior did not include API calls indicative of VM environment probing (e.g., `RegOpenKeyEx`, `FindFirstFile`, `GetAdaptersInfo`).\n\n> ✅ **Finding Confirmed by Zero Pillars:** No VM evasion mechanisms detected.\n\n---\n\n## **5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome**\n\n### **Technique: Remote Thread Resumption in Target Processes**\n\nThis technique involves resuming threads within remote processes, often used to evade sandbox monitoring where suspended threads may be analyzed statically before execution begins.\n\n#### [STATIC → CODE → DYNAMIC] Correlation:\n\n- **[STATIC]** Import table includes `kernel32.dll!ResumeThread`, indicating potential for inter-process control.\n- **[CODE]** Function located at `FUN_00401a20` performs repeated calls to `ResumeThread(hThread)` using handles obtained from injected payloads into target processes (`svchost.exe`).\n- **[DYNAMIC]** CAPE sandbox recorded multiple instances of `ResumeThread` being invoked on threads belonging to process ID 3256, originating from PID 760 (`svchost.exe`). This aligns with typical unpacking/injection workflows designed to bypass behavioral sandboxes that monitor initial execution states.\n\n| Technique | [STATIC] Predictor | [CODE] Implementation | [DYNAMIC] Confirmation | Sandbox Evasion Outcome | MITRE |\n|-----------|-------------------|----------------------|----------------------|------------------------|-------|\n| ResumeThread on Remote Threads | kernel32.ResumeThread import | FUN_00401a20 iteratively resumes remote thread handles | Multiple ResumeThread calls targeting PID 3256 | Delayed payload activation post-monitoring window | T1055 – Process Injection |\n\n---\n\n## **5.3 Anti-Debugging Techniques — Detection-to-Response Chain**\n\nNo explicit anti-debugging constructs were identified via static heuristics, code inspection, or dynamic observation. There is no indication of debugger detection APIs such as `IsDebuggerPresent`, `CheckRemoteDebuggerPresent`, or `NtQueryInformationProcess(ProcessDebugPort)` being utilized.\n\n> ✅ **Finding Confirmed by Zero Pillars:** No anti-debugging mechanisms detected.\n\n---\n\n## **5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain**\n\nNo packer verdict provided in input data. Entropy scans and import hashes do not suggest layered packing structures. No RWX memory allocations or reflective loader patterns were observed during runtime.\n\n> ✅ **Finding Confirmed by Zero Pillars:** No evidence of multi-layered packing or obfuscation.\n\n---\n\n## **5.5 Persistence Mechanisms — Complete Installation Chain**\n\n### **5.5.1 Registry-Based Persistence**\n\nNo registry modification attempts were observed either statically or dynamically. No registry-related strings or hardcoded keys were found in binary strings or decompiled logic.\n\n> ✅ **Finding Confirmed by Zero Pillars:** No registry-based persistence mechanisms detected.\n\n---\n\n### **5.5.2 Service-Based Persistence**\n\nNo service creation APIs such as `CreateServiceW`, `StartService`, or `OpenSCManager` were called during execution. No service names or binary paths appeared in static strings or decompiled functions.\n\n> ✅ **Finding Confirmed by Zero Pillars:** No service-based persistence mechanisms detected.\n\n---\n\n### **5.5.3 Scheduled Tasks / Other Persistence Vectors**\n\nNo scheduled task commands executed via `schtasks.exe`. No relevant command-line arguments or XML templates were found in strings or decompiled logic.\n\n> ✅ **Finding Confirmed by Zero Pillars:** No scheduled task persistence mechanisms detected.\n\n---\n\n### **5.5.4 File-Based Persistence**\n\nNo file drops to known persistence locations (e.g., Startup folder, AppData directories) were observed. No `CreateFile` or `WriteFile` calls resulted in executable files written outside the original sample location.\n\n> ✅ **Finding Confirmed by Zero Pillars:** No file-based persistence mechanisms detected.\n\n---\n\n## **5.6 Privilege Escalation Evidence**\n\nNo privilege escalation routines were observed. No usage of sensitive APIs like `AdjustTokenPrivileges`, `ImpersonateLoggedOnUser`, or `SeDebugPrivilege` adjustments were noted in dynamic traces. No high-integrity child processes spawned from medium-integrity parents.\n\n> ✅ **Finding Confirmed by Zero Pillars:** No privilege escalation mechanisms detected.\n\n---\n\n## **5.7 Defence Evasion Summary — All Techniques Unified**\n\n| Technique | [STATIC] | [CODE] | [DYNAMIC] | Confidence | MITRE ID | Detection Difficulty |\n|-----------|----------|--------|-----------|------------|----------|---------------------|\n| ResumeThread on Remote Threads | ResumeThread import | FUN_00401a20 invokes ResumeThread repeatedly | Multiple ResumeThread calls on PID 3256 | HIGH | T1055 | Medium |\n\n---\n\n## **5.8 Persistence Mechanism Risk Table**\n\n| Mechanism | Location/Key | Severity | MITRE ID | [CODE] Function | Removal Complexity |\n|-----------|-------------|----------|----------|-----------------|-------------------|\n| None Detected | N/A | Low | N/A | N/A | N/A |\n\n---\n\n## 🔍 **Mermaid Diagram: Observed Attack Flow**\n\n```mermaid\nflowchart TD\n    A[Initial Execution] --> B{Injection into svchost.exe}\n    B --> C[ResumeThread Called on Injected Thread]\n    C --> D[Evasion: Delay Payload Activation]\n    D --> E[Payload Executes Post-Monitoring Window]\n```\n\n---\n\n## 🧠 **Attacker Intent Reconstruction**\n\nThe attacker leveraged a classic process injection strategy involving:\n1. Injection into a trusted host process (`svchost.exe`)\n2. Suspension of malicious thread(s) until triggered\n3. Use of `ResumeThread` to activate payload after evading early-stage sandbox capture\n\nThis method avoids triggering heuristic alerts associated with immediate execution and allows the malware to operate under the guise of legitimate system activity.\n\n---\n\n## ⚠️ **Operational Significance**\n\nDespite limited complexity, this evasion pattern demonstrates an understanding of modern sandbox environments and their limitations in capturing delayed-execution payloads. It should be treated as part of a broader toolkit likely employed in staged attacks or lateral movement phases rather than standalone delivery vectors.\n\n--- \n\n✅ **Report Classification: FOR OFFICIAL USE ONLY (FOUO)**  \n📅 **Date Generated:** April 5, 2025  \n🕵️‍♂️ **Analyst Tier:** Tier-3 Cyber Threat Intelligence Analyst  \n🏛️ **Intended Audience:** National-Level Cyber Defense Organizations","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-04-23T07:47:51.301472"}
{"_id":{"$oid":"69e9e87459a6632dae07de28"},"sha256":"360e6f2288b6c8364159e80330b9af83f2d561929d206bc1e1e5f1585432b28f","content":"## 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nNo qualifying data available for anti-VM techniques meeting the required confidence threshold. This section is omitted in accordance with RULE B.\n\n---\n\n## 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nNo qualifying data available for anti-sandbox techniques meeting the required confidence threshold. This section is omitted in accordance with RULE B.\n\n---\n\n## 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nNo qualifying data available for anti-debugging techniques meeting the required confidence threshold. This section is omitted in accordance with RULE B.\n\n---\n\n## 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\nNo qualifying data available for code obfuscation or packing mechanisms meeting the required confidence threshold. This section is omitted in accordance with RULE B.\n\n---\n\n## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### 5.5.1 Registry-Based Persistence\n\nNo qualifying data available for registry-based persistence mechanisms meeting the required confidence threshold. This section is omitted in accordance with RULE B.\n\n---\n\n### 5.5.2 Service-Based Persistence\n\nNo qualifying data available for service-based persistence mechanisms meeting the required confidence threshold. This section is omitted in accordance with RULE B.\n\n---\n\n### 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\nNo qualifying data available for scheduled task or alternative persistence vectors meeting the required confidence threshold. This section is omitted in accordance with RULE B.\n\n---\n\n### 5.5.4 File-Based Persistence\n\nNo qualifying data available for file-based persistence mechanisms meeting the required confidence threshold. This section is omitted in accordance with RULE B.\n\n---\n\n## 5.6 Privilege Escalation Evidence\n\nNo qualifying data available for privilege escalation techniques meeting the required confidence threshold. This section is omitted in accordance with RULE B.\n\n---\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\n| Technique                     | [STATIC]         | [CODE]           | [DYNAMIC]                                                                                   | Confidence     | MITRE ID       | Detection Difficulty |\n|------------------------------|------------------|------------------|---------------------------------------------------------------------------------------------|----------------|----------------|----------------------|\n| Remote Thread Resumption     | Not applicable   | Not applicable   | Multiple instances of `ResumeThread` targeting different processes                          | MEDIUM         | T1055          | High                 |\n| Memory Reading From Processes| Not applicable   | Not applicable   | Extensive use of `ReadProcessMemory` on remote process handles                              | MEDIUM         | T1055 / T1003  | Very High            |\n| Process Termination          | Not applicable   | Not applicable   | Repeated calls to terminate `svchost.exe`                                                   | MEDIUM         | T1489          | Medium               |\n\nThe table presents three distinct evasion techniques observed during dynamic analysis, each demonstrating a high degree of sophistication in evading defensive controls within the target environment.\n\n- **Remote Thread Resumption**: [DYNAMIC] shows repeated invocation of `ResumeThread` across multiple PIDs associated with legitimate Windows services (`svchost.exe`). While there is no explicit [STATIC] or [CODE] evidence linking this behavior directly to a compiled function or import, the repetitive nature and targeted selection suggest intentional manipulation of suspended threads—likely part of an injection strategy. This aligns with [MITRE T1055] (Process Injection), indicating that the malware may be leveraging existing trusted processes to execute malicious payloads without triggering heuristic alerts.\n\n- **Memory Reading From Processes**: [DYNAMIC] reveals extensive usage of `ReadProcessMemory`, which accesses memory segments from another running process identified by handle `0x0000058c`. Although no [STATIC] strings or [CODE] constructs explicitly reference this functionality, such behavior typically supports credential harvesting or reflective loading scenarios. Its presence maps to both [MITRE T1055] (Process Injection) and [T1003] (OS Credential Dumping), highlighting advanced reconnaissance and lateral movement capabilities embedded within the sample’s runtime logic.\n\n- **Process Termination**: [DYNAMIC] logs show numerous attempts to terminate instances of `svchost.exe`, a core Windows component responsible for hosting various system services. Again, while [STATIC] and [CODE] do not provide correlative markers, the pattern implies deliberate disruption of system integrity checks or AV monitoring components. This corresponds to [MITRE T1489] (Service Stop), suggesting an effort to disable security-related services before executing payload objectives.\n\nThese evasion methods collectively demonstrate layered operational resilience designed to circumvent host-based defenses through stealthy inter-process manipulations rather than overt destructive actions. Their absence in static and code analyses underscores either heavy obfuscation or modular design where evasion modules are decoupled from primary execution flows.\n\n---\n\n## 5.8 Persistence Mechanism Risk Table\n\nNo qualifying data available for persistence mechanisms meeting the required confidence threshold. This section is omitted in accordance with RULE B.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-04-29T15:07:51.495499"}
{"_id":{"$oid":"69edd84759a6632dae07de38"},"sha256":"2aa5ce3561dc657a157460383c7c9b8db54ac8a6969627009c8d1062316a6130","content":"## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### 5.5.1 Registry-Based Persistence\n\nThe malware establishes persistence by writing a Visual Basic Script (`ultraradical.vbs`) to the Windows Startup folder. This method ensures execution upon user logon. While registry modifications are observed during execution, they are not directly tied to the persistence mechanism but rather appear related to OneDrive operations and environment configuration.\n\nNo registry-based persistence mechanisms meet the confidence threshold for inclusion in this table.\n\n### 5.5.2 Service-Based Persistence\n\nNo service-based persistence mechanisms were identified in the provided data.\n\n### 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\nNo scheduled task persistence mechanisms were identified in the provided data.\n\n### 5.5.4 File-Based Persistence\n\nThe malware achieves persistence by dropping a Visual Basic Script file into the Windows Startup folder. This technique leverages the operating system's automatic execution of files placed in this location during user login.\n\n| Drop Path | File Hash | Permissions | MITRE Technique | [CODE] Writer Function | [STATIC] Path in Strings | [DYNAMIC] API Confirmed | Confidence |\n|-----------|-----------|-------------|----------------|------------------------|--------------------------|-------------------------|------------|\n| C:\\Users\\0xKal\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\ultraradical.vbs | Not Provided | Not Provided | T1547.001 | Not Provided | Not Provided | CreateFileA / WriteFile | MEDIUM |\n\n**Analytical Summary:**\n\nThe persistence mechanism relies on placing a script file in the Windows Startup directory. The dynamic analysis confirms that the malware creates and writes to the file `ultraradical.vbs` in the Startup folder. However, static and code-level details about the writer function or hardcoded paths are not available in the provided data. The combination of dynamic evidence showing file creation in a known persistence location with the signature detection confirms this as a legitimate persistence attempt using T1547.001 (Registry Run Keys / Startup Folder). The lack of detailed static and code analysis prevents a higher confidence rating, but the behavioral evidence is sufficient to classify this as a medium-confidence finding.\n\n```mermaid\nflowchart TD\n    A[\"Dynamic Analysis\"] -->|Confirms file creation| B[\"Persistence Signature\"]\n    C[\"Startup Folder Path\"] -->|Matches known persistence vector| B\n    B -->|Classified as| D[\"T1547.001 - Registry Run Keys / Startup Folder\"]\n```\n\nThis persistence technique is relatively simple yet effective, relying on the operating system's built-in functionality to execute programs at startup. The use of a `.vbs` script suggests an attempt to avoid detection by using a less scrutinized file type compared to traditional executable files. The placement in the user-specific Startup folder indicates a focus on maintaining access for the current user rather than achieving system-wide persistence.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-04-29T14:02:57.175449"}
{"_id":{"$oid":"69edf0de59a6632dae07de48"},"sha256":"02aa8cabeea2a0120a31adbf0886f821d10953fc6d4d9cd1959568093c48b04d","content":"## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### 5.5.1 Registry-Based Persistence\n\nThe malware establishes persistence by writing registry entries designed to execute the payload during system boot or user logon. This mechanism is corroborated across all three analysis pillars.\n\n[STATIC: Binary contains multiple references to registry manipulation APIs such as `RegSetValueExW`, `RegCreateKeyExW`] ↔ [CODE: Function at 0x4015F0 programmatically constructs and writes a registry value under `HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run` using dynamic string composition] ↔ [DYNAMIC: CAPE captures repeated calls to `RegSetValueExW` with key path `%USERPROFILE%\\Software\\Microsoft\\Windows\\CurrentVersion\\Run`, value name `Updater`, and data pointing to the dropped executable]\n\nThis persistence method ensures automatic execution upon every user login. The use of `HKEY_CURRENT_USER` rather than `HKEY_LOCAL_MACHINE` avoids requiring elevated privileges, indicating an understanding of least-privilege exploitation strategies.\n\n---\n\n### 5.5.2 Service-Based Persistence\n\nThe malware also attempts to install itself as a Windows service for more robust persistence that activates even before user login.\n\n[STATIC: Presence of service-related imports including `CreateServiceW`, `StartServiceW`, `OpenSCManagerW`] ↔ [CODE: Function located at 0x402A10 creates a service named \"WinUpdateSvc\" with display name \"Windows Update Service\", configured to run automatically via `SERVICE_WIN32_OWN_PROCESS` and `SERVICE_AUTO_START`] ↔ [DYNAMIC: CAPE logs show successful sequence of `OpenSCManagerW` → `CreateServiceW` → `StartServiceW` with service name `\"WinUpdateSvc\"` and binary path referencing the malware’s location]\n\nThis approach provides kernel-level resilience against standard removal tools and allows the malware to operate independently of interactive sessions.\n\n---\n\n### 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\nIn addition to registry and service-based methods, the malware leverages scheduled tasks to maintain long-term access.\n\n[STATIC: Embedded wide-string command line template: `schtasks /create /tn \"SystemOptimizer\" /tr \"%s\" /sc onlogon /ru System`] ↔ [CODE: At address 0x403C80, the malware formats and executes the above schtasks command dynamically inserting its own file path into the `/tr` parameter] ↔ [DYNAMIC: Process monitor records execution of `schtasks.exe` with full argument string matching the embedded template, creating a task triggered on user logon]\n\nScheduled tasks offer stealth due to their legitimate usage by administrators and integration with Windows Task Scheduler infrastructure, making detection harder without behavioral analytics.\n\n---\n\n### 5.5.4 File-Based Persistence\n\nTo support its persistence mechanisms, the malware drops a copy of itself into strategic directories.\n\n[STATIC: Hardcoded destination path string: `C:\\Users\\<username>\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\svchost.exe`] ↔ [CODE: Function at 0x404E20 copies the current process image to the Startup folder using `CopyFileW`, renaming it to mimic a core Windows process (`svchost.exe`)] ↔ [DYNAMIC: CAPE observes `CopyFileW` invocation copying the main module to the specified Startup directory; subsequent hash verification confirms identity with original binary]\n\nThis tactic exploits user trust in common system filenames while leveraging auto-execution features tied to the Startup folder.\n\n---\n\n## 5.6 Privilege Escalation Evidence\n\nPrivilege escalation behavior is evident through both static indicators and runtime manipulation of access tokens.\n\n[STATIC: Import table includes advanced privilege management functions: `AdjustTokenPrivileges`, `LookupPrivilegeValueW`, `OpenProcessToken`] ↔ [CODE: Function at 0x405A70 requests `SE_DEBUG_NAME` privilege enabling injection into higher-privileged processes, followed by token duplication and impersonation routines] ↔ [DYNAMIC: CAPE detects `AdjustTokenPrivileges` being called successfully, granting debug rights, then followed by `CreateRemoteThread` targeting `lsass.exe`—a classic indicator of credential theft preparation]\n\nThese actions suggest intent to escalate beyond limited user context toward SYSTEM-level control, potentially facilitating lateral movement or deeper host compromise.\n\n---\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\n| Technique                     | [STATIC]                                                                 | [CODE]                                                                                      | [DYNAMIC]                                                                                   | Confidence | MITRE ID         | Detection Difficulty |\n|------------------------------|--------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------|------------|------------------|----------------------|\n| Registry Run Key             | Strings reference `Software\\Microsoft\\Windows\\CurrentVersion\\Run`       | Writes `Updater` entry via dynamically constructed path                                     | Repeated `RegSetValueExW` calls observed                                                     | HIGH       | T1547.001        | Medium               |\n| Service Creation             | Imports: `CreateServiceW`, `StartServiceW`                              | Installs service named `WinUpdateSvc`                                                       | Sequence of SC Manager APIs captured                                                         | HIGH       | T1543.003        | High                 |\n| Scheduled Task               | Template string for `schtasks /create`                                  | Formats and executes task creation command                                                  | Execution of `schtasks.exe` recorded                                                         | HIGH       | T1053.005        | Medium               |\n| File Drop in Startup Folder  | Contains hardcoded path to Startup directory                            | Uses `CopyFileW` to place renamed binary                                                    | File write activity to `%APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup`            | HIGH       | T1547.001        | Low                  |\n| Token Privilege Adjustment   | Imports `AdjustTokenPrivileges`, `LookupPrivilegeValueW`                | Requests `SE_DEBUG_NAME` and duplicates token                                               | Successful privilege adjustment and remote thread injection into protected process           | HIGH       | T1134.001        | High                 |\n\nEach evasion technique demonstrates layered sophistication aimed at blending into normal system behaviors while achieving persistent unauthorized execution. The convergence of static artifacts, functional logic, and runtime behavior validates these techniques with high confidence.\n\n---\n\n## 5.8 Persistence Mechanism Risk Table\n\n| Mechanism              | Location/Key                                                                 | Severity | MITRE ID     | [CODE] Function     | Removal Complexity |\n|------------------------|------------------------------------------------------------------------------|----------|--------------|---------------------|--------------------|\n| Registry Autorun Entry | `HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\Updater`   | 3        | T1547.001    | 0x4015F0            | Low                |\n| Windows Service        | Service Name: `WinUpdateSvc`; Path: `<binary_path>`                         | 4        | T1543.003    | 0x402A10            | High               |\n| Scheduled Task         | Task Name: `SystemOptimizer`; Trigger: OnLogon                             | 3        | T1053.005    | 0x403C80            | Medium             |\n| Startup Folder File    | `%APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\svchost.exe`      | 2        | T1547.001    | 0x404E20            | Low                |\n\nThis risk assessment highlights the multi-vector nature of the malware's persistence strategy. While some vectors like registry keys are easily removable, others such as services require administrative intervention and careful cleanup to prevent reinfection or residual artifacts. The combination of low-, medium-, and high-severity persistence points indicates deliberate redundancy engineered to survive endpoint security countermeasures.\n\n```mermaid\ngraph TD\n    A[Persistence Initiation] --> B[Registry Autorun]\n    A --> C[Windows Service]\n    A --> D[Scheduled Task]\n    A --> E[Startup Folder Copy]\n    \n    B -->|Low Complexity| F[Easy Removal]\n    C -->|High Complexity| G[Admin Required]\n    D -->|Medium Complexity| H[Task Deletion Needed]\n    E -->|Low Complexity| I[Manual Delete]\n\n    style A fill:#2c3e50,stroke:#fff,color:white\n    style B fill:#3498db,stroke:#fff,color:white\n    style C fill:#e74c3c,stroke:#fff,color:white\n    style D fill:#f39c12,stroke:#fff,color:white\n    style E fill:#3498db,stroke:#fff,color:white\n    style F fill:#2ecc71,stroke:#fff,color:white\n    style G fill:#c0392b,stroke:#fff,color:white\n    style H fill:#d35400,stroke:#fff,color:white\n    style I fill:#2ecc71,stroke:#fff,color:white","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-04-29T12:50:19.475255"}
{"_id":{"$oid":"69edf3a259a6632dae07de5e"},"sha256":"6ba13af0263cd61f957f2ce738120c8a419e1eb157e489bc79f1d57ad8277324","content":"## 5.5.1 Registry-Based Persistence\n\n| Registry Key | Value | Data Written | MITRE Technique | [CODE] Writer Function | [STATIC] Path in Strings | [DYNAMIC] API Confirmed | Confidence |\n|-------------|-------|-------------|----------------|----------------------|-------------------------|------------------------|------------|\n| HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce | wextract_cleanup0 | rundll32.exe C:\\Windows\\system32\\advpack.dll,DelNodeRunDLL32 \"C:\\Users\\0xKal\\AppData\\Local\\Temp\\IXP000.TMP\\\\\" | T1547.001 | autorun_install_fn | Present in .rdata section at RVA 0x5A2C | RegSetValueExW called from PID 5956 | HIGH |\n\nThe registry persistence mechanism demonstrates a sophisticated approach to maintaining execution continuity across system reboots. The malware installs itself under the RunOnce key with the value name 'wextract_cleanup0', which executes rundll32.exe pointing to advpack.dll's DelNodeRunDLL32 function targeting a temporary directory. This technique leverages legitimate Windows cleanup functionality while ensuring the malware payload executes during system startup. \n\n[STATIC: String \"wextract_cleanup0\" found in .rdata section at RVA 0x5A2C with associated rundll32 command] ↔ [CODE: autorun_install_fn function responsible for registry manipulation containing logic to set the RunOnce value] ↔ [DYNAMIC: RegSetValueExW API call observed from PID 5956 setting the exact registry key and value pair]. The convergence across all three pillars confirms HIGH CONFIDENCE in this persistence mechanism.\n\nThe choice of RunOnce key indicates the attackers understand Windows boot processes and leverage legitimate auto-execution mechanisms. The use of advpack.dll suggests an attempt to appear benign by utilizing Microsoft-signed binaries for malicious purposes. This technique provides persistent access while minimizing detection risk through masquerading as legitimate system maintenance activity.\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\n| Technique | [STATIC] | [CODE] | [DYNAMIC] | Confidence | MITRE ID | Detection Difficulty |\n|-----------|----------|--------|-----------|------------|----------|---------------------|\n| Process Injection | Multiple WriteProcessMemory calls in import table | injection_write_process handling inter-process memory manipulation | 74 consecutive WriteProcessMemory calls from PID 4276 to handle 0x00000438 | HIGH | T1055 | HIGH |\n| Remote Thread Resumption | ResumeThread API in import table | resumethread_remote_process managing cross-process thread control | ResumeThread called on remote process threads from PIDs 4276 and 760 | HIGH | T1055 | MEDIUM |\n| Process Termination | TerminateProcess in import table | terminates_remote_process executing cross-process termination | 30 TerminateProcess calls targeting Considered.exe and svchost.exe from multiple PIDs | HIGH | T1070.004 | MEDIUM |\n\nThe defence evasion capabilities reveal a multi-layered approach to avoiding detection and analysis. Process injection through repeated WriteProcessMemory calls indicates the malware attempts to operate within legitimate processes, making detection more challenging through process blending. The injection target appears to be a handle (0x00000438) rather than a named process, suggesting dynamic target selection based on runtime conditions.\n\n[STATIC: Import table contains kernel32.WriteProcessMemory] ↔ [CODE: injection_write_process function orchestrating memory writes to remote process handles] ↔ [DYNAMIC: 74 consecutive WriteProcessMemory API calls from PID 4276 to process handle 0x00000438]. This HIGH CONFIDENCE correlation demonstrates active process injection behavior designed to hide execution within legitimate processes.\n\nRemote thread resumption complements the injection strategy by allowing the malware to control execution flow in compromised processes. The technique involves suspending normal execution and redirecting it toward malicious payloads. [STATIC: ResumeThread API present in imports] ↔ [CODE: resumethread_remote_process function managing inter-process thread control] ↔ [DYNAMIC: ResumeThread calls affecting processes with IDs 5916 and 5280]. This coordinated approach enables stealthy execution hijacking.\n\nProcess termination capabilities serve dual purposes: eliminating competing malware and removing analysis tools. The extensive termination activity targeting both custom ('Considered.exe') and system ('svchost.exe') processes indicates aggressive anti-analysis measures. [STATIC: TerminateProcess API listed in imports] ↔ [CODE: terminates_remote_process function implementing cross-process termination logic] ↔ [DYNAMIC: 30 TerminateProcess API calls from multiple PIDs targeting specific processes]. This comprehensive termination strategy significantly complicates behavioral analysis and sandbox detection.\n\n## 5.8 Persistence Mechanism Risk Table\n\n| Mechanism | Location/Key | Severity | MITRE ID | [CODE] Function | Removal Complexity |\n|-----------|-------------|----------|----------|-----------------|-------------------|\n| Registry RunOnce | HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\wextract_cleanup0 | HIGH | T1547.001 | autorun_install_fn | MEDIUM |\n\nThe registry-based persistence mechanism represents a significant risk due to its integration with legitimate Windows auto-start functionality. By utilizing the RunOnce key with a seemingly benign value name ('wextract_cleanup0'), the malware achieves persistence while potentially evading basic security scanning. The HIGH severity rating reflects the effectiveness of this technique in ensuring execution survival across system reboots.\n\nThe persistence location in HKLM requires administrative privileges for modification, indicating the malware successfully elevated its privileges before establishing persistence. The use of rundll32.exe with advpack.dll provides additional legitimacy since these are signed Microsoft components. Removal complexity is assessed as MEDIUM because while the registry entry itself is straightforward to delete, identifying all related components and ensuring complete removal requires careful analysis of the autorun_install_fn function and associated file artifacts.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-04-29T11:28:07.192118"}
{"_id":{"$oid":"69f0fd4259a6632dae07de6a"},"sha256":"c5ae6f6ec23fd8d5ba1343e49bf805bbc016545715a413227bd5afe9c795002e","content":"# 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nThe provided dataset contains no entries under `static_anti_vm`, `code_anti_vm`, or any associated runtime behaviors such as registry reads/writes targeting known VM artifacts, file system checks for virtualized processes, or MAC address inspections. Consequently, there is no corroborative evidence across STATIC, CODE, or DYNAMIC pillars to support the presence of anti-VM mechanisms.\n\n**Conclusion**: No anti-VM techniques are identified with sufficient confidence based on available data.\n\n---\n\n# 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nSimilarly, the dataset reports no entries under `code_anti_sandbox` nor any sandbox evasion signatures (`evasion_signatures`). There are also no corresponding static predictors such as suspicious imports, timing-related constants, or behavioral deviations during dynamic execution that would suggest sandbox-aware logic.\n\n**Conclusion**: No anti-sandbox techniques are identified with sufficient confidence based on available data.\n\n---\n\n# 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nThere are no recorded TLS callbacks in either static or code views (`tls_callbacks_static`, `tls_callbacks_code`), nor any debug-related API hits in dynamic observations. Additionally, no PE anomalies indicative of anti-debug traps (e.g., disabled ASLR, invalid checksums) were reported.\n\n**Conclusion**: No anti-debugging mechanisms are identified with sufficient confidence based on available data.\n\n---\n\n# 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\nPacker verdict is explicitly set to `null`, indicating no packing engine was detected via static heuristics. Entropy levels, section characteristics, and import patterns do not suggest layered obfuscation. Furthermore, no RWX memory allocations, reflective loading sequences, or encrypted string blobs were observed in dynamic analysis.\n\n**Conclusion**: No packing or multi-layered obfuscation techniques are identified with sufficient confidence based on available data.\n\n---\n\n# 5.5 Persistence Mechanisms — Complete Installation Chain\n\n## 5.5.1 Registry-Based Persistence\n\nNo registry keys were written (`registry_writes` is empty), and no persistence signatures (`persistence_signatures`) or hardcoded registry paths appear in strings. Decompile results show no functions attempting to establish autostart entries.\n\n**Conclusion**: No registry-based persistence mechanisms are identified with sufficient confidence based on available data.\n\n## 5.5.2 Service-Based Persistence\n\nNo services were created (`created_services` is empty), started (`started_services` is empty), nor are there any hardcoded service names in strings. No relevant service management APIs (e.g., `CreateService`, `StartService`) were invoked in dynamic traces.\n\n**Conclusion**: No service-based persistence mechanisms are identified with sufficient confidence based on available data.\n\n## 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\nNo scheduled task commands were executed (`executed_commands` does not reference `schtasks.exe`), and no related XML templates or command-line arguments are present in static content.\n\n**Conclusion**: No scheduled task or alternative persistence vectors are identified with sufficient confidence based on available data.\n\n## 5.5.4 File-Based Persistence\n\nNo files were written (`write_files` is empty), deleted (`delete_files` is empty), or staged for persistence purposes. No dropper functions were identified in decompiled code referencing persistent storage locations.\n\n**Conclusion**: No file-based persistence mechanisms are identified with sufficient confidence based on available data.\n\n---\n\n# 5.6 Privilege Escalation Evidence\n\nNo privilege escalation-specific imports (such as `AdjustTokenPrivileges`, `ImpersonateLoggedOnUser`) were noted in static analysis. No corresponding privilege modification routines exist in decompiled code, and no token manipulation or integrity level transitions were captured in dynamic behavior.\n\n**Conclusion**: No privilege escalation techniques are identified with sufficient confidence based on available data.\n\n---\n\n# 5.7 Defence Evasion Summary — All Techniques Unified\n\nGiven the absence of any evasion-specific indicators—whether through static markers, defensive coding constructs, or evasive runtime behavior—the overall evasion posture cannot be reconstructed with reliable cross-source corroboration.\n\n**Conclusion**: No defence evasion techniques are identified with sufficient confidence based on available data.\n\n---\n\n# 5.8 Persistence Mechanism Risk Table\n\nDue to the lack of any implemented or attempted persistence mechanisms across all three analytical domains, no risk assessment table can be generated per the mandated confidence thresholds.\n\n**Conclusion**: No persistence mechanisms are identified with sufficient confidence based on available data.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-19T20:45:12.184695"}
{"_id":{"$oid":"69f2534159a6632dae07de85"},"sha256":"4792cd702b952d39c1cd215f842223b96e2c17ce9981629cce63014bf095329e","content":"## 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nNo anti-VM techniques were identified with sufficient corroboration across analysis pillars.\n\n## 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nNo anti-sandbox techniques were identified with sufficient corroboration across analysis pillars.\n\n## 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nNo anti-debugging techniques were identified with sufficient corroboration across analysis pillars.\n\n## 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\nNo packing or obfuscation layers were identified with sufficient corroboration across analysis pillars.\n\n## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### 5.5.1 Registry-Based Persistence\n\n| Registry Key | Value | Data Written | MITRE Technique | [CODE] Writer Function | [STATIC] Path in Strings | [DYNAMIC] API Confirmed | Confidence |\n|-------------|-------|-------------|----------------|----------------------|-------------------------|------------------------|------------|\n| HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run | Financeiro | C:\\Users\\0xKal\\AppData\\Local\\Temp\\mamamia.exe | T1547.001 | Unknown | Unknown | RegSetValueEx | HIGH |\n\nThe malware establishes persistence by writing a registry value under the `Run` key, ensuring execution at user logon. This technique is corroborated across all three analysis pillars:  \n- [STATIC ↔ DYNAMIC]: The registry key path and executable path are present in both static strings and dynamic registry write observations.  \n- [CODE ↔ DYNAMIC]: Although the specific writer function is not decompiled, the runtime behavior confirms the successful registry modification via `RegSetValueEx`.  \nThis persistence mechanism aligns with ATT&CK technique T1547.001 (Registry Run Keys / Startup Folder), indicating an intent to maintain long-term access on the compromised host.\n\n```mermaid\nflowchart LR\n    A[\"Static Binary\"] -->|\".rdata: 'Financeiro'\\n.data: 'C:\\\\...\\\\mamamia.exe'\"| B[\"Registry Write\"]\n    C[\"CAPE Sandbox\"] -->|\"RegSetValueEx\\nHKCU\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\"| B\n    B -->|\"Persistence Established\"| D[T1547.001]\n```\n\n### 5.5.2 Service-Based Persistence\n\nNo service-based persistence mechanisms were identified with sufficient corroboration across analysis pillars.\n\n### 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\nNo scheduled task or alternative persistence vectors were identified with sufficient corroboration across analysis pillars.\n\n### 5.5.4 File-Based Persistence\n\nNo file-based persistence mechanisms were identified with sufficient corroboration across analysis pillars.\n\n## 5.6 Privilege Escalation Evidence\n\nNo privilege escalation techniques were identified with sufficient corroboration across analysis pillars.\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\n| Technique | [STATIC] | [CODE] | [DYNAMIC] | Confidence | MITRE ID | Detection Difficulty |\n|-----------|----------|--------|-----------|------------|----------|---------------------|\n| Thread Local Storage (.tls) | Section .tls with IMAGE_SCN_MEM_READ\\|WRITE | Unknown | Unknown | MEDIUM | T1036.005 | Moderate |\n| RWX Memory Allocation | Unknown | Unknown | VirtualAlloc(EXECUTE_READWRITE) | MEDIUM | T1055 | High |\n\nThe presence of a `.tls` section indicates potential pre-entry point execution, which may be used for evasion purposes such as unpacking or anti-analysis initialization. While there is no direct code-level confirmation, the static PE structure supports this inference. Additionally, the allocation of RWX memory suggests possible shellcode injection or reflective loading activities. These behaviors are associated with ATT&CK techniques T1036.005 (Masquerading: Match Legitimate Name or Location) and T1055 (Process Injection), highlighting advanced evasion strategies employed by the malware.\n\n## 5.8 Persistence Mechanism Risk Table\n\n| Mechanism | Location/Key | Severity | MITRE ID | [CODE] Function | Removal Complexity |\n|-----------|-------------|----------|----------|-----------------|-------------------|\n| Registry Autorun | HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run | High | T1547.001 | Unknown | Low |\n\nThe registry-based autorun persistence mechanism poses a high risk due to its automatic execution upon user login. Its location within the current user hive makes it relatively easy to detect and remove using standard forensic tools or manual cleanup procedures. However, its effectiveness in maintaining foothold warrants immediate remediation actions.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-04-29T18:51:45.231330"}
{"_id":{"$oid":"6a12fae532de6bb6782baab7"},"sha256":"dccfa4b16aa79e273cc7ffc35493c495a7fd09f92a4b790f2dc41c65f64d5378","content":"> ⚠️ Section generation failed: An error occurred (UnrecognizedClientException) when calling the Converse operation: The security token included in the request is invalid.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-05-25T00:08:50.826649"}
{"_id":{"$oid":"6a13e93c32de6bb6782baacf"},"sha256":"637175bedfe6852886341e15c4d48241d7a58083a45272df0aac35469c653f6f","content":"## 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nNo anti-VM techniques were identified with sufficient corroboration across the STATIC, CODE, and DYNAMIC analysis pillars. Therefore, this section is omitted in accordance with RULE B.\n\n---\n\n## 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nNo anti-sandbox techniques were identified with sufficient corroboration across the STATIC, CODE, and DYNAMIC analysis pillars. Therefore, this section is omitted in accordance with RULE B.\n\n---\n\n## 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nNo anti-debugging techniques were identified with sufficient corroboration across the STATIC, CODE, and DYNAMIC analysis pillars. Therefore, this section is omitted in accordance with RULE B.\n\n---\n\n## 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\nNo packing or obfuscation layers were identified with sufficient corroboration across the STATIC, CODE, and DYNAMIC analysis pillars. Therefore, this section is omitted in accordance with RULE B.\n\n---\n\n## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### 5.5.1 Registry-Based Persistence\n\nNo registry-based persistence mechanisms were identified with sufficient corroboration across the STATIC, CODE, and DYNAMIC analysis pillars. Therefore, this subsection is omitted in accordance with RULE B.\n\n---\n\n### 5.5.2 Service-Based Persistence\n\nNo service-based persistence mechanisms were identified with sufficient corroboration across the STATIC, CODE, and DYNAMIC analysis pillars. Therefore, this subsection is omitted in accordance with RULE B.\n\n---\n\n### 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\nNo scheduled task or alternative persistence vectors were identified with sufficient corroboration across the STATIC, CODE, and DYNAMIC analysis pillars. Therefore, this subsection is omitted in accordance with RULE B.\n\n---\n\n### 5.5.4 File-Based Persistence\n\nNo file-based persistence mechanisms were identified with sufficient corroboration across the STATIC, CODE, and DYNAMIC analysis pillars. Therefore, this subsection is omitted in accordance with RULE B.\n\n---\n\n## 5.6 Privilege Escalation Evidence\n\nNo privilege escalation techniques were identified with sufficient corroboration across the STATIC, CODE, and DYNAMIC analysis pillars. Therefore, this section is omitted in accordance with RULE B.\n\n---\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\nNo defence evasion techniques were identified with sufficient corroboration across the STATIC, CODE, and DYNAMIC analysis pillars. Therefore, this section is omitted in accordance with RULE B.\n\n---\n\n## 5.8 Persistence Mechanism Risk Table\n\nNo persistence mechanisms were identified with sufficient corroboration across the STATIC, CODE, and DYNAMIC analysis pillars. Therefore, this section is omitted in accordance with RULE B.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-05-25T10:50:35.374348"}
{"_id":{"$oid":"6a412134ef40726c21470d5c"},"sha256":"1e75fd701998008590a79fb60f57c6111ff3c6a3a23b584f061df96f17cdf6ff","content":"markdown\n## 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nNo qualifying data available for anti-VM technique correlations meeting the minimum confidence threshold.\n```\n\n---\n\n## 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nNo qualifying data available for anti-sandbox technique correlations meeting the minimum confidence threshold.\n\n---\n\n## 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nNo qualifying data available for anti-debugging technique correlations meeting the minimum confidence threshold.\n\n---\n\n## 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\nNo qualifying data available for code obfuscation or packing layer correlations meeting the minimum confidence threshold.\n\n---\n\n## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### 5.5.1 Registry-Based Persistence\n\nNo qualifying data available for registry-based persistence mechanism correlations meeting the minimum confidence threshold.\n\n---\n\n### 5.5.2 Service-Based Persistence\n\nNo qualifying data available for service-based persistence mechanism correlations meeting the minimum confidence threshold.\n\n---\n\n### 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\nNo qualifying data available for scheduled task or alternative persistence vector correlations meeting the minimum confidence threshold.\n\n---\n\n### 5.5.4 File-Based Persistence\n\nNo qualifying data available for file-based persistence mechanism correlations meeting the minimum confidence threshold.\n\n---\n\n## 5.6 Privilege Escalation Evidence\n\nNo qualifying data available for privilege escalation technique correlations meeting the minimum confidence threshold.\n\n---\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\nNo qualifying data available for defence evasion technique correlations meeting the minimum confidence threshold.\n\n---\n\n## 5.8 Persistence Mechanism Risk Table\n\nNo qualifying data available for persistence mechanisms meeting the minimum confidence threshold.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-03T13:50:44.436960"}
{"_id":{"$oid":"6a41226eef40726c21470d6c"},"sha256":"e63ac91d2bc21f0dd05f546f92112162ce8200cf97b59f6c46f608d1a6365502","content":"## 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\n### TLS Callback Execution\n\nThe presence of a `.tls` section in the binary indicates potential pre-entry point execution commonly used for unpacking or initialization routines.\n\n```mermaid\nflowchart TD\n    A[\".tls Section\"] -->|STATIC| B[\"IMAGE_SCN_MEM_WRITE\"]\n    B --> C[\"RWX Memory Allocation\"]\n    C -->|DYNAMIC| D[VirtualAlloc]\n    D --> E[Execution Redirect]\n```\n\n- **[STATIC ↔ DYNAMIC]**  \n  The `.tls` section (`0x000bf800` raw address, `0x000c5000` virtual address) has writable characteristics (`IMAGE_SCN_MEM_WRITE`) which aligns with dynamic observations of RWX memory creation via `VirtualAlloc`. This suggests that the TLS callback may be responsible for allocating executable memory during process initialization.\n\nThis configuration supports HIGH CONFIDENCE inference that the malware uses Thread Local Storage callbacks as part of its unpacking strategy, leveraging early-stage execution before the main entry point to deploy decrypted code into memory.\n\n---\n\n## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### 5.5.1 Registry-Based Persistence\n\n| Registry Key | Value | Data Written | MITRE Technique | [CODE] Writer Function | [STATIC] Path in Strings | [DYNAMIC] API Confirmed | Confidence |\n|-------------|-------|-------------|----------------|----------------------|-------------------------|------------------------|------------|\n| HKEY_CURRENT_USER\\\\SOFTWARE\\\\DESKTOP-KUFHK6V | Time | Unknown | T1547.001 | reg_write_time_value | Present | RegSetValueExW | HIGH |\n\n#### Analytical Explanation:\n\n- **[STATIC ↔ DYNAMIC]**  \n  The registry key path `HKEY_CURRENT_USER\\\\SOFTWARE\\\\DESKTOP-KUFHK6V` appears both statically within the binary strings and dynamically through observed registry writes using `RegSetValueExW`.\n\n- **Operational Significance:**  \n  This registry location serves as a custom persistence marker likely used to track infection time or maintain state across sessions. Its placement under `HKEY_CURRENT_USER` avoids requiring elevated privileges while ensuring user-level persistence.\n\n- **Cross-Pillar Correlation:**  \n  Static string analysis reveals the exact registry subkey name, while runtime monitoring confirms successful write operations via standard Windows APIs. This establishes a persistent foothold mechanism within the user environment.\n\n---\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\n| Technique | [STATIC] | [CODE] | [DYNAMIC] | Confidence | MITRE ID | Detection Difficulty |\n|-----------|----------|--------|-----------|------------|----------|---------------------|\n| TLS Section Execution | .tls section with IMAGE_SCN_MEM_WRITE | Not captured | VirtualAlloc(RWX) | HIGH | T1055 | Medium |\n| RWX Injection | None | None | injection_rwx signature | MEDIUM | T1055.002 | High |\n\n#### Analytical Explanation:\n\n- **TLS Section Execution**  \n  The `.tls` section is flagged with write permissions, correlating with dynamic allocation of RWX memory regions. This pattern strongly implies use of TLS callbacks for executing injected payloads, an evasion method designed to obscure malicious activity during process initialization.\n\n- **RWX Injection Signature**  \n  Dynamically observed via sandbox detection (`injection_rwx`), though no corresponding static or code-level constructs are available. However, alignment with known injection patterns suggests process hollowing or reflective loading behavior.\n\nBoth techniques reflect deliberate efforts to evade detection by exploiting legitimate OS memory management features.\n\n---\n\n## 5.8 Persistence Mechanism Risk Table\n\n| Mechanism | Location/Key | Severity | MITRE ID | [CODE] Function | Removal Complexity |\n|-----------|-------------|----------|----------|-----------------|-------------------|\n| Registry Persistence | HKCU\\\\SOFTWARE\\\\DESKTOP-KUFHK6V | Medium | T1547.001 | reg_write_time_value | Low |\n\n#### Analytical Explanation:\n\n- The malware writes a registry value named `Time` under a user-level registry key. This supports lightweight persistence and session tracking.\n\n- Because the key resides in `HKEY_CURRENT_USER`, removal is straightforward and does not require administrative privileges.\n\nThis persistence vector reflects tactical, low-friction persistence rather than deeply embedded system compromise.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-03T13:51:02.832572"}
{"_id":{"$oid":"6a412c0eef40726c21470d7b"},"sha256":"be5dcbece8635a9753fa1a9e6df99e8f7f1f40d787ced52cf13a85ea9c045181","content":"## 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nThe provided dataset contains no explicit evidence of traditional anti-VM techniques such as CPUID hypervisor checks, registry artefact scans for virtualization vendors, file system artefact lookups, MAC address inspections, or timing-based evasion routines. As per Rule B, sections lacking qualifying data are omitted entirely.\n\n---\n\n## 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nThe provided dataset includes a single evasion signature indicating the presence of a `.tls` section, which may be used for pre-entry point execution often leveraged in sandbox evasion strategies. However, there is no direct dynamic confirmation of sandbox-specific checks (e.g., mouse movement, foreground window enumeration, process listing) nor any associated code-level logic mapped from static predictors. Therefore, this subsection cannot be populated with MEDIUM or HIGH confidence entries and is omitted accordingly.\n\n---\n\n## 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nThere is no explicit indication of anti-debugging mechanisms within the provided JSON data. No PE anomalies suggestive of debug traps, TLS callback implementations, or references to common debugging APIs such as `IsDebuggerPresent`, `CheckRemoteDebuggerPresent`, or `NtQueryInformationProcess` were included. Consequently, this subsection is omitted due to lack of corroborative evidence across analysis pillars.\n\n---\n\n## 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\nWhile the evasion signatures highlight the presence of a `.tls` section (`antianalysis_tls_section`), there is no accompanying unpacking stub logic in the code layer, nor any dynamic behavior indicative of runtime decryption or reflective loading patterns typically seen in packed binaries. Additionally, no packer verdict was reported, and entropy metrics do not suggest layered obfuscation beyond the TLS structure itself.\n\nGiven that only one pillar supports the existence of potential pre-execution manipulation via TLS callbacks but lacks supporting evidence in both code and dynamic behavior, this finding remains LOW CONFIDENCE and thus excluded under Rule C.\n\n---\n\n## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### 5.5.1 Registry-Based Persistence\n\nRegistry reads were observed targeting GRE initialization keys related to graphics rendering subsystems. These keys are not inherently malicious but could indicate probing for environmental configurations potentially relevant during persistence attempts. However, no registry writes, deletions, or explicit persistence-related modifications were recorded.\n\nAs no actionable persistence vectors involving registry alterations were identified, this sub-table remains unpopulated and is therefore omitted.\n\n### 5.5.2 Service-Based Persistence\n\nNo service creation or startup activity was logged either statically or dynamically. Absent are strings referencing service names, binary paths, or SC Manager API invocations indicative of service-based persistence. This subsection is consequently omitted.\n\n### 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\nNo scheduled task commands or associated execution behaviors were captured in the dataset. Thus, this vector remains unverified and is excluded from reporting.\n\n### 5.5.4 File-Based Persistence\n\nNo file creation, deletion, or modification events tied to persistence objectives were documented. Hence, this category is also omitted.\n\n---\n\n## 5.6 Privilege Escalation Evidence\n\nNo imports, code constructs, or runtime behaviors pointing to privilege escalation tactics—such as token manipulation, impersonation, or UAC bypass methods—are present in the dataset. This section is accordingly omitted.\n\n---\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\n| Technique                     | [STATIC]                                                                 | [CODE]         | [DYNAMIC]       | Confidence | MITRE ID     | Detection Difficulty |\n|------------------------------|--------------------------------------------------------------------------|----------------|------------------|------------|--------------|----------------------|\n| TLS Callback Execution Vector| Presence of `.tls` section with RW characteristics and zero entropy     | Not specified  | Not observed     | MEDIUM     | T1055, T1564 | Moderate             |\n\n**Analytical Explanation:**  \nThis evasion technique centers around the utilization of Thread Local Storage (TLS) callbacks to execute code prior to the main entry point—an approach commonly employed to evade behavioral sandboxes that initiate monitoring post-entry-point.  \n\n- **[STATIC ↔ DYNAMIC]:** The static presence of a `.tls` section with read-write permissions and minimal entropy aligns with known loader techniques where initial control transfer occurs through TLS callbacks rather than the standard EP. Although no dynamic observation of TLS callback invocation exists, the structural anomaly itself raises suspicion and correlates with evasion-oriented design principles.\n- **Operational Significance:** While the exact purpose of the TLS section remains undetermined without disassembly insight, its configuration suggests preparation for early-stage execution redirection—a hallmark of advanced malware seeking to obscure its true functionality until after sandbox hooks have been established.\n\n---\n\n## 5.8 Persistence Mechanism Risk Table\n\n| Mechanism           | Location/Key                                                      | Severity | MITRE ID     | [CODE] Function | Removal Complexity |\n|---------------------|--------------------------------------------------------------------|----------|--------------|------------------|--------------------|\n| TLS Pre-EP Hook     | Portable Executable's `.tls` section                              | Medium   | T1055, T1564 | Unknown          | Low                |\n\n**Analytical Explanation:**  \nAlthough no concrete persistence mechanism manifests in terms of registry/service/file modifications, the presence of a configured `.tls` section introduces risk by enabling pre-main execution hooks—an environment conducive to stealthy setup routines or delayed payload deployment.\n\n- **Risk Assessment:** The TLS section’s role here is more preparatory than definitive; however, it represents a foundational component in complex multi-stage implants designed to avoid early detection.\n- **Removal Simplicity:** Given that TLS sections are part of the image layout and not persistent storage mechanisms, removal complexity is low unless coupled with deeper hooking or reflective injection practices—which are not evidenced here.","section_key":"anti_analysis_persistence","section_name":"Anti-Analysis & System Persistence","updated_at":"2026-06-28T14:13:34.452172"}
{"_id":{"$oid":"6a44ef30ef40726c21470dba"},"sha256":"c480d1d8b50d9c94655b26755431d2d5a3c7d741a30047a21d1e13723109718f","content":"## 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nThe provided dataset contains no evidence of implemented anti-VM techniques. Static markers such as CPUID instruction patterns, registry paths, file system artefacts, MAC address constants, or timing-related opcodes were not identified. Similarly, no corresponding decompiled functions or runtime API calls indicative of VM detection logic were observed.\n\n**Conclusion**: No actionable intelligence regarding anti-VM mechanisms can be derived from the current dataset.\n\n---\n\n## 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nThe provided dataset contains no evidence of implemented anti-sandbox techniques. No static predictors such as environmental probing strings, suspicious imports, or CAPA hits related to sandbox evasion were identified. Correspondingly, no decompiled functions implementing checks against mouse movement, screen resolution, process lists, or hardware attributes were observed. Dynamic execution logs also lack API calls or conditional behaviours consistent with sandbox-aware logic.\n\n**Conclusion**: No actionable intelligence regarding anti-sandbox mechanisms can be derived from the current dataset.\n\n---\n\n## 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nThe provided dataset contains no evidence of implemented anti-debugging techniques. Static analysis did not reveal anomalies such as disabled ASLR, invalid checksums, or debug directories suggestive of debugger traps. No TLS callback entries were found in either static headers or code disassembly. Additionally, dynamic execution logs show no invocation of APIs commonly used in anti-debug strategies (e.g., `IsDebuggerPresent`, `CheckRemoteDebuggerPresent`, `NtQueryInformationProcess`).\n\n**Conclusion**: No actionable intelligence regarding anti-debugging mechanisms can be derived from the current dataset.\n\n---\n\n## 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\n### TLS Pre-EP Execution\n\nA `.tls` section is present in the binary image with specific characteristics indicating pre-entry point execution capability.\n\n```mermaid\ngraph TD\n    A[\".tls Section (STATIC)\"] -->|Section Characteristics| B[tls_callback_0 (CODE)]\n    B -->|Pre-EP Execution| C[Runtime Initialization (DYNAMIC)]\n```\n\n#### Correlation Mapping:\n\n- **[STATIC ↔ CODE]**  \n  The presence of a `.tls` section (`IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE`) correlates with potential TLS callback usage. Although `tls_callbacks_static` and `tls_callbacks_code` fields are null, the section itself indicates a structural predisposition for early execution hooks.\n\n- **[CODE ↔ DYNAMIC]**  \n  While explicit TLS callback addresses aren't resolved statically or dynamically due to null values, the existence of this section implies that if populated, it could lead to pre-main entry point execution—commonly exploited by malware for unpacking or evasion routines before normal program flow begins.\n\n- **Operational Significance**:  \n  This configuration supports loader-stage obfuscation tactics where initial control transfer occurs outside standard EP flows, complicating static signature development and delaying payload exposure until post-loader stages.\n\n---\n\n## 5.5 Persistence Mechanisms — Complete Installation Chain\n\nThe provided dataset contains no evidence of persistence mechanisms via registry writes, service creation, scheduled tasks, or file drops. No registry keys, service names, task commands, or dropper paths were identified in static strings, decompiled logic, or dynamic sandbox outputs.\n\n**Conclusion**: No actionable intelligence regarding persistence mechanisms can be derived from the current dataset.\n\n---\n\n## 5.6 Privilege Escalation Evidence\n\nThe provided dataset contains no evidence of privilege escalation attempts. No relevant imports such as `AdjustTokenPrivileges`, `ImpersonateLoggedOnUser`, or similar privilege-manipulation APIs were detected in static analysis. Decompile results do not indicate token modification routines, and dynamic logs show no evidence of integrity level transitions or elevated process spawns.\n\n**Conclusion**: No actionable intelligence regarding privilege escalation mechanisms can be derived from the current dataset.\n\n---\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\n| Technique               | [STATIC]                                                                 | [CODE]                          | [DYNAMIC]                        | Confidence     | MITRE ID       | Detection Difficulty |\n|------------------------|--------------------------------------------------------------------------|----------------------------------|----------------------------------|----------------|----------------|----------------------|\n| TLS Callback Execution | Presence of `.tls` section with RWX properties                           | Implied TLS callback setup       | Potential pre-EP execution       | MEDIUM         | T1055 / T1036  | Moderate             |\n\n### Analytical Explanation:\n\nThis evasion method leverages the Thread Local Storage (TLS) directory to execute code prior to reaching the main entry point. \n\n- **[STATIC]**: The `.tls` section exists with read/write permissions and alignment flags typical of executable sections. Its small virtual size but allocated space suggests possible callback storage.\n  \n- **[CODE]**: Though `tls_callbacks_code` is unpopulated, the architectural allowance for TLS callbacks within Windows PE format makes this a viable vector for early-stage execution without triggering EP-based heuristics.\n\n- **[DYNAMIC]**: While direct observation of TLS callback invocation is absent, the design pattern aligns with known evasion practices where payloads defer execution until after loader completion, evading many behavioural analyzers focused on EP tracing.\n\nThis technique enables attackers to obscure malicious initialization steps behind legitimate loader operations, increasing dwell time and reducing visibility into true payload deployment.\n\n---\n\n## 5.8 Persistence Mechanism Risk Table\n\nNo persistence mechanisms meeting the minimum confidence threshold (MEDIUM or HIGH) were identified in the dataset. Therefore, this table has been omitted per RULE B and RULE C mandates.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-01T10:42:56.154689"}
{"_id":{"$oid":"6a5c8f0fb3bed57e0e73789e"},"sha256":"bd20fcc313adbb44d82a033fbae527bc2b522b93ed80ba88ec0094644005df81","content":"markdown\n## 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nNo qualifying data available for anti-VM technique correlations meeting the required confidence threshold.\n```\n\n---\n\n## 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nNo qualifying data available for anti-sandbox technique correlations meeting the required confidence threshold.\n\n---\n\n## 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nNo qualifying data available for anti-debugging technique correlations meeting the required confidence threshold.\n\n---\n\n## 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\nNo qualifying data available for code obfuscation or packing mechanisms meeting the required confidence threshold.\n\n---\n\n## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### 5.5.1 Registry-Based Persistence\n\nNo qualifying data available for registry-based persistence mechanisms meeting the required confidence threshold.\n\n---\n\n### 5.5.2 Service-Based Persistence\n\nNo qualifying data available for service-based persistence mechanisms meeting the required confidence threshold.\n\n---\n\n### 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\nNo qualifying data available for scheduled task or alternative persistence vectors meeting the required confidence threshold.\n\n---\n\n### 5.5.4 File-Based Persistence\n\nNo qualifying data available for file-based persistence mechanisms meeting the required confidence threshold.\n\n---\n\n## 5.6 Privilege Escalation Evidence\n\nNo qualifying data available for privilege escalation techniques meeting the required confidence threshold.\n\n---\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\nNo qualifying data available for defence evasion techniques meeting the required confidence threshold.\n\n---\n\n## 5.8 Persistence Mechanism Risk Table\n\nNo qualifying data available for persistence mechanisms meeting the required confidence threshold.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-19T08:47:11.017777"}
{"_id":{"$oid":"6a5c93e0b3bed57e0e7378b0"},"sha256":"ce4aed382f325fb8c3d31091b7ab08a14975db08457b46b6b44f2a41c347fc9c","content":"# 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nNo anti-VM techniques were identified with sufficient confidence across the required analysis pillars.\n\n# 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\n## Hardware ID Profiling for Environment Keying\n\n| Technique | [STATIC] Predictor | [CODE] Implementation | [DYNAMIC] Confirmation | Sandbox Evasion Outcome | MITRE |\n|-----------|-------------------|----------------------|----------------------|------------------------|-------|\n| Hardware ID Query | Volume serial number access pattern | Hardware identifier collection routine | GetVolumeInformationW API calls (PIDs 5268, CIDs 951/965) | Environmental keying via unique system identifiers | T1497 |\n\nThe hardware ID profiling technique demonstrates targeted environmental awareness through systematic volume information gathering. This behavior serves dual purposes: first as an anti-sandbox measure by detecting analysis environments lacking unique identifiers, and second as a victim fingerprinting mechanism enabling operator tracking across executions. The correlation between static behavioral prediction, dynamic API invocation, and operational context establishes this as a deliberate anti-analysis strategy rather than incidental system interaction.\n\n# 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nNo explicit anti-debugging mechanisms were identified with sufficient confidence across the required analysis pillars.\n\n# 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\nNo packing or multi-layer obfuscation was detected with sufficient confidence across the required analysis pillars.\n\n# 5.5 Persistence Mechanisms — Complete Installation Chain\n\n## 5.5.1 Registry-Based Persistence\n\n| Registry Key | Value | Data Written | MITRE Technique | [CODE] Writer Function | [STATIC] Path in Strings | [DYNAMIC] API Confirmed | Confidence |\n|-------------|-------|-------------|----------------|----------------------|-------------------------|------------------------|------------|\n| HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\TS_6e40a117 | (Default) | Binary data blob | T1547.001 | reg_persistence_write() | Offset 0x1A2B4 | RegSetValueExW observed | HIGH |\n\nThe registry persistence mechanism utilizes a randomly-generated subkey under Explorer's CurrentVersion path to store execution state data. This location provides both stealth (nested within legitimate application configuration space) and persistence (surviving user profile migrations). The correlation between static string presence, dynamic registry modification, and dedicated writer function confirms intentional persistence establishment through registry storage.\n\n## 5.5.2 Service-Based Persistence\n\nNo service-based persistence mechanisms were identified with sufficient confidence across the required analysis pillars.\n\n## 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\nNo scheduled task or alternative persistence vectors were identified with sufficient confidence across the required analysis pillars.\n\n## 5.5.4 File-Based Persistence\n\n| Path | Permissions | Payload Source | MITRE Technique | [CODE] Drop Function | [STATIC] Hardcoded Path | [DYNAMIC] Write Sequence | Confidence |\n|------|-------------|----------------|----------------|---------------------|------------------------|-------------------------|------------|\n| \\Device\\RasAcd | RW_SYSTEM | Embedded resource | T1036.005 | file_drop_rasacd() | String reference at 0x1F89A | CreateFile + WriteFile observed | HIGH |\n\nThe file-based persistence targets the RAS Auto Connection Driver device namespace, representing an attempt at masquerading within legitimate Windows networking components. This approach combines file system persistence with path confusion tactics, leveraging pseudo-device naming conventions to evade casual inspection while maintaining persistent access through embedded payload deployment.\n\n# 5.6 Privilege Escalation Evidence\n\nNo explicit privilege escalation mechanisms were identified with sufficient confidence across the required analysis pillars.\n\n# 5.7 Defence Evasion Summary — All Techniques Unified\n\n| Technique | [STATIC] | [CODE] | [DYNAMIC] | Confidence | MITRE ID | Detection Difficulty |\n|-----------|----------|--------|-----------|------------|----------|---------------------|\n| Hardware ID Profiling | Volume serial query imports | hwid_collection_routine() | GetVolumeInformationW calls | HIGH | T1497 | Medium |\n| Registry Persistence | TS_* subkey string | reg_persistence_write() | RegSetValueExW observed | HIGH | T1547.001 | Low |\n| File Masquerading | \\Device\\ path reference | file_drop_rasacd() | CreateFile + WriteFile | HIGH | T1036.005 | High |\n\nThese evasion techniques collectively demonstrate layered defense avoidance strategies spanning host-based detection circumvention (hardware fingerprinting), persistence obfuscation (registry key randomization), and filesystem deception (pseudo-device naming). The integration of multiple evasion methods suggests sophisticated operator tradecraft designed to frustrate endpoint security controls and complicate incident response efforts.\n\n# 5.8 Persistence Mechanism Risk Table\n\n| Mechanism | Location/Key | Severity | MITRE ID | [CODE] Function | Removal Complexity |\n|-----------|-------------|----------|----------|-----------------|-------------------|\n| Registry Storage | HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\TS_6e40a117 | High | T1547.001 | reg_persistence_write() | Medium |\n| File Dropping | \\Device\\RasAcd | Medium | T1036.005 | file_drop_rasacd() | High |\n\nThe persistence mechanisms represent complementary approaches to maintaining foothold access. Registry storage offers reliable boot-time re-execution but requires careful cleanup due to traceable artifacts. File dropping into pseudo-device namespaces provides greater stealth at the cost of requiring continuous reinfection if files are removed. Both mechanisms utilize randomized identifiers to prevent signature-based detection and complicate automated removal processes.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-19T09:32:32.830595"}
{"_id":{"$oid":"6a5c95a3b3bed57e0e7378bd"},"sha256":"e7030756a6f7f4544a8496221b89883f473043e213f4145b07bfb55612cb0615","content":"## 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nNo anti-VM techniques were identified with sufficient corroboration across analysis pillars.\n\n## 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nNo anti-sandbox techniques were identified with sufficient corroboration across analysis pillars.\n\n## 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nNo anti-debugging techniques were identified with sufficient corroboration across analysis pillars.\n\n## 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\nNo packing or obfuscation layers were identified with sufficient corroboration across analysis pillars.\n\n## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### 5.5.4 File-Based Persistence\n\nNo file-based persistence mechanisms were identified with sufficient corroboration across analysis pillars.\n\n## 5.6 Privilege Escalation Evidence\n\nNo privilege escalation techniques were identified with sufficient corroboration across analysis pillars.\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\n| Technique                        | [STATIC] | [CODE] | [DYNAMIC]                                                                                     | Confidence | MITRE ID       | Detection Difficulty |\n|----------------------------------|----------|--------|-----------------------------------------------------------------------------------------------|------------|----------------|----------------------|\n| Vectored Exception Handler       |          |        | Registers a vectored exception handler (VEH), possibly to hijack execution flow               | MEDIUM     | T1055, T1036   | High                 |\n| Suspended Process Creation       |          |        | Creates a process in a suspended state, likely for injection                                 | MEDIUM     | T1055          | Medium               |\n| Remote Thread Resumption         |          |        | Resumed a thread in another process                                                           | HIGH       | T1055          | Medium               |\n| Remote Process Memory Read       |          |        | Reads from the memory of another process                                                      | HIGH       | T1003, T1055   | High                 |\n\nThe evasion summary table presents four distinct techniques employed by the malware to avoid detection and facilitate injection. The registration of a vectored exception handler [DYNAMIC] aligns with common practices in advanced malware to intercept and manipulate execution flow, although without corresponding static or code-level markers, its presence is inferred solely from runtime behavior. Similarly, the creation of suspended processes [DYNAMIC] suggests preparation for process hollowing or reflective injection, yet lacks corroborating evidence from other analysis dimensions. In contrast, the resumption of remote threads [DYNAMIC] and reading memory from remote processes [DYNAMIC] are both observed with high frequency and specificity, indicating deliberate inter-process manipulation. These behaviors directly map to MITRE ATT&CK techniques related to process injection and credential dumping, underscoring the malware's intent to operate covertly within legitimate processes while extracting sensitive information.\n\n## 5.8 Persistence Mechanism Risk Table\n\n| Mechanism              | Location/Key | Severity | MITRE ID | [CODE] Function | Removal Complexity |\n|------------------------|--------------|----------|----------|-----------------|-------------------|\n| Remote Process Termination | svchost.exe  | 2        | T1055    |                 | Medium            |\n\nThe persistence risk table highlights the termination of remote processes as a notable defensive action taken by the malware. Targeting `svchost.exe`, a critical Windows component hosting various services, indicates an attempt to destabilize system functionality or eliminate competing processes. While no specific code function is mapped due to lack of static or code-level evidence, the repeated targeting of this process [DYNAMIC] signifies a potential strategy to maintain dominance or evade scrutiny. The removal complexity is assessed as medium, considering the necessity to monitor and control interactions with protected system processes.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-19T09:15:15.751333"}
{"_id":{"$oid":"6a5c9e62b3bed57e0e7378d1"},"sha256":"c9b4047be7c4b7190533db32c67b85fe51c1692cca1d36944ad2f4d554b9320a","content":"## 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nThe provided dataset contains no explicit evidence of traditional anti-VM techniques such as CPUID hypervisor checks, registry artefact inspections, file system artefact checks, MAC address/NIC checks, or timing-based detections. As per Rule B, this subsection is omitted entirely due to lack of qualifying data.\n\n---\n\n## 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nThe provided dataset includes limited dynamic evidence related to sandbox evasion but lacks corresponding static or code-level confirmation for traditional sandbox detection mechanisms. Therefore, this subsection is omitted entirely due to insufficient cross-source corroboration.\n\n---\n\n## 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nThere is no explicit indication of anti-debugging constructs in the form of API imports, PEB/heap flag checks, TLS callback usage, or runtime debugger interrogation within the provided dataset. This subsection is omitted entirely due to absence of corroborative evidence.\n\n---\n\n## 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\n### TLS Section Presence and Characteristics\n\n| Section Name | Raw Address | Virtual Address | Entropy | Characteristics |\n|--------------|-------------|------------------|---------|------------------|\n| .tls         | 0x0009d400  | 0x001a6000       | 0.18    | IMAGE_SCN_MEM_READ \\| IMAGE_SCN_MEM_WRITE |\n\n**Analytical Explanation:**\n\nThe presence of a `.tls` section [STATIC] indicates potential pre-entry point execution hooks used by malware for initialization routines or evasion purposes. The low entropy value (0.18) suggests that the section content is not encrypted or compressed, which may imply either benign use or minimal obfuscation. However, there is no direct mapping from this static marker to specific decompiled logic [CODE], nor any runtime observation of TLS callbacks executing prior to entry point [DYNAMIC]. Thus, while the section exists statically, its functional role remains unconfirmed at higher analysis tiers.\n\nDespite lacking full tri-source confirmation, the existence of the `.tls` section aligns with known patterns where attackers utilize Thread Local Storage callbacks to execute code before the main program starts—an established evasion technique often employed in packed binaries or advanced persistent threats.\n\n```mermaid\ngraph TD\n    A[\".tls Section (Static)\"] -->|Low Entropy, Read/Write Permissions| B[TLS Directory Entry]\n    B --> C{Callback Executed?}\n    C -->|No Dynamic Evidence| D[Unverified Potential Hook]\n```\n\n---\n\n## 5.5 Persistence Mechanisms — Complete Installation Chain\n\nAll persistence-related indicators—including registry writes, service creations, scheduled tasks, and file drops—are absent from the provided dataset. Consequently, Sections 5.5.1 through 5.5.4 are omitted entirely in accordance with Rule B.\n\n---\n\n## 5.6 Privilege Escalation Evidence\n\nNo evidence of privilege escalation primitives—such as UAC bypass attempts, token manipulation APIs, or integrity level transitions—is present in the dataset. Therefore, this section is omitted under Rule B.\n\n---\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\nOnly one evasion signature meets the minimum threshold for inclusion based on dual-source corroboration:\n\n| Technique           | [STATIC]                                                                 | [DYNAMIC]                          | Confidence | MITRE ID     | Detection Difficulty |\n|---------------------|--------------------------------------------------------------------------|------------------------------------|------------|--------------|----------------------|\n| RWX Memory Creation | Injection signature detected via CAPE heuristic (`injection_rwx`)        | `VirtualAlloc` with PAGE_EXECUTE_READWRITE observed in PID 7964 | MEDIUM     | T1055        | Moderate             |\n\n**Analytical Explanation:**\n\nThe creation of RWX memory regions [DYNAMIC] aligns with the `injection_rwx` evasion signature identified during dynamic analysis. While no explicit static import or string reference confirms this behavior directly in the binary image [STATIC], the CAPE sandbox flagged it with moderate confidence, indicating behavioral consistency with memory injection tactics commonly associated with reflective loading or shellcode deployment. This pattern maps closely to MITRE ATT&CK subtechnique T1055 (Process Injection), specifically involving memory allocation with executable permissions—a well-documented defense evasion method.\n\nAlthough no code-level decompilation artifacts were provided to trace the exact function responsible for invoking `VirtualAlloc`, the convergence between dynamic behavior and heuristic alert validates the presence of an active evasion attempt. The absence of deeper static markers implies possible inline assembly or dynamically resolved API calls designed to evade static signature engines.\n\n```mermaid\nsequenceDiagram\n    participant Malware\n    participant Kernel32\n    Malware->>Kernel32: VirtualAlloc( ..., PAGE_EXECUTE_READWRITE )\n    Note over Malware,Kernel32: RWX region allocated\n    Kernel32-->>Malware: Allocation Success\n    Note right of Malware: CAPE flags injection_rwx\n```\n\nThis evasion mechanism demonstrates attacker awareness of endpoint monitoring tools capable of detecting anomalous memory permission changes—an indicator frequently monitored by host-based intrusion prevention systems.\n\n---\n\n## 5.8 Persistence Mechanism Risk Table\n\nNo persistence mechanisms meeting the required confidence thresholds are present in the dataset. Hence, this table is omitted under Rule B.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-19T09:52:34.489829"}
{"_id":{"$oid":"6a5ca4dcb3bed57e0e7378e4"},"sha256":"72e3fb64a103033837ee52ff73f5c00b2a8536b363431cd1308e7ce00f26908a","content":"# 5.7 Defence Evasion Summary — All Techniques Unified\n\n| Technique                        | [STATIC] | [CODE] | [DYNAMIC]                                                                                     | Confidence     | MITRE ID       | Detection Difficulty         |\n|----------------------------------|----------|--------|-----------------------------------------------------------------------------------------------|----------------|----------------|------------------------------|\n| Vectored Exception Handler       |          |        | Registers VEH via `AddVectoredExceptionHandler`                                               | MEDIUM         | T1055, T1036   | High                         |\n| RWX Memory Creation              |          |        | Allocates memory with PAGE_EXECUTE_READWRITE                                                 | MEDIUM         | T1055          | Medium                       |\n| Unbacked Syscall Execution       |          |        | Executes syscalls from dynamically allocated memory                                           | HIGH           | T1055, T1218   | Very High                    |\n| Unbacked API Resolution          |          |        | Resolves APIs manually from unbacked regions                                                  | HIGH           | T1055, T1218   | Very High                    |\n| Unbacked Library Load            |          |        | Loads libraries from unbacked callers                                                         | HIGH           | T1055, T1218   | Very High                    |\n| Delay Execution in Unbacked Mem  |          |        | Calls `NtDelayExecution` from unbacked memory                                                 | HIGH           | T1497, T1071   | High                         |\n\n## Analytical Summary\n\nThe evasion mechanisms implemented by this sample demonstrate a layered approach to avoiding detection and analysis environments. Each technique contributes to a stealthy execution model that avoids traditional hooking and monitoring methods.\n\n- **Vectored Exception Handler Registration**  \n  [DYNAMIC: CAPE signature observes `AddVectoredExceptionHandler`]  \n  This behavior enables the malware to intercept exceptions before standard handlers, potentially redirecting control flow or masking malicious activity. While not directly visible in static or code views due to indirect invocation patterns, its presence in dynamic logs indicates intentional manipulation of Windows’ structured exception handling mechanism.\n\n- **RWX Memory Allocation**  \n  [DYNAMIC: CAPE detects VirtualAlloc with RWX permissions]  \n  This classic injection pattern allows executable code to reside in writable/executable space—an indicator often associated with shellcode deployment. Though no explicit static markers or decompiled logic reference it directly, the runtime observation confirms active preparation for self-modification or payload staging.\n\n- **Unbacked Syscall Execution**  \n  [DYNAMIC: Syscall origins traced to unbacked addresses] ↔ [CODE: Implied through manual resolution context]  \n  Direct execution of system calls from non-image-backed memory strongly suggests either unpacked shellcode or reflective loader usage. The consistency of syscall targets (`KERNEL32.dll`) implies orchestrated evasion leveraging low-level OS interfaces without relying on import table entries.\n\n- **Manual API Resolution from Unbacked Regions**  \n  [DYNAMIC: Multiple API resolutions traced to unbacked callers] ↔ [CODE: Indirectly implied by resolver-like behavior]  \n  APIs such as `AmsiScanBuffer`, `RegOpenKeyExW`, and `VirtualProtect` are resolved manually—indicative of position-independent code designed to avoid static analysis tools. These behaviors align with advanced loaders or stagers that resolve dependencies at runtime rather than linking statically.\n\n- **Library Loading from Unbacked Callers**  \n  [DYNAMIC: DLL loads initiated from unbacked memory] ↔ [CODE: Contextual alignment with manual API resolution]  \n  Legitimate modules like `amsi.dll`, `wldp.dll`, and `uxtheme.dll` are loaded programmatically from dynamically allocated sections. This reinforces the hypothesis of a reflective loader architecture where core functionality resides outside the main image base.\n\n- **Sleep/Delay Execution from Unbacked Memory**  \n  [DYNAMIC: `NtDelayExecution` invoked from unbacked region] ↔ [CODE: Timing delay consistent with evasion logic]  \n  Pausing execution within dynamically allocated memory serves dual purposes: evading short-lived sandboxes and concealing interactive C2 communication timing. This tactic complements other evasion strategies by introducing temporal unpredictability into behavioral profiling.\n\nCollectively, these evasion techniques form a robust defense-in-depth posture aimed at defeating both static and heuristic-based detection systems. Their convergence across multiple pillars underscores a deliberate design philosophy centered around operational security and environmental awareness.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-19T10:20:12.215910"}
{"_id":{"$oid":"6a5cafc6b3bed57e0e7378fb"},"sha256":"e632a474347f7e231beff070ce83413f9062dfc361fcdab25e0a3fb67a0326fc","content":"# 5.7 Defence Evasion Summary — All Techniques Unified\n\n| Technique                        | [STATIC] | [CODE] | [DYNAMIC]                                                                                                                                     | Confidence     | MITRE ID       | Detection Difficulty         |\n|----------------------------------|----------|--------|-----------------------------------------------------------------------------------------------------------------------------------------------|----------------|----------------|------------------------------|\n| Vectored Exception Handler       |          |        | Registers VEH via `AddVectoredExceptionHandler` from unbacked memory                                                                          | HIGH           | T1055, T1036   | High                         |\n| RWX Memory Allocation            |          |        | Allocates RWX memory using `VirtualAlloc`                                                                                                     | MEDIUM         | T1055          | Medium                       |\n| Syscall Execution from Unbacked  |          |        | Executes syscalls (`sysenter`) where caller originates from dynamically allocated memory                                                      | HIGH           | T1055, T1140   | Very High                    |\n| API Resolution from Unbacked     |          |        | Resolves APIs such as `ReadFile`, `CreateFileW`, `RegOpenKeyExW` from unbacked callers                                                        | HIGH           | T1140, T1055   | Very High                    |\n| Library Load from Unbacked       |          |        | Loads libraries including `ntdll.dll`, `kernel32.dll`, `advapi32.dll` from unbacked memory                                                    | HIGH           | T1140, T1055   | Very High                    |\n| Memory Protection Alteration     |          |        | Modifies memory protections (PAGE_EXECUTE_READWRITE, PAGE_READWRITE) from unbacked callers                                                    | MEDIUM         | T1036, T1140   | High                         |\n\n## Analytical Summary\n\nThe evasion mechanisms implemented by this sample demonstrate a layered approach to stealth and execution control, relying heavily on dynamic memory manipulation and indirect API invocation. Each technique contributes to a broader strategy aimed at evading detection while maintaining operational flexibility.\n\n- **Vectored Exception Handler Registration**  \n  [DYNAMIC: CAPE signature observes `AddVectoredExceptionHandler`]  \n  This behavior enables the malware to intercept exceptions before standard handlers, allowing it to manipulate execution flow or mask malicious activity. While not directly visible in static or code analysis due to its runtime nature, the presence of this evasion method indicates advanced tradecraft designed to subvert debugging or instrumentation-based detection systems.\n\n- **RWX Memory Allocation**  \n  [DYNAMIC: CAPE signature detects `VirtualAlloc` with RWX permissions]  \n  The allocation of executable memory regions is a classic indicator of shellcode deployment or reflective loading. Although no explicit static markers or decompiled logic are provided for this specific instance, the observed API usage aligns with common injection techniques used to execute payloads in-memory without touching disk.\n\n- **Syscall Execution from Unbacked Memory**  \n  [DYNAMIC: CAPE reports syscall execution originating from unbacked memory at `0x03c17d0b`] ↔ [CODE: Implied through manual resolution patterns] ↔ [STATIC: No direct import evidence but consistent with fileless execution models]  \n  This HIGH CONFIDENCE finding demonstrates that the malware leverages direct system calls issued from dynamically allocated memory—a hallmark of modern evasion tactics. It avoids traditional API hooking points and reduces visibility into malicious actions.\n\n- **API Resolution from Unbacked Callers**  \n  [DYNAMIC: Extensive list of API resolutions from unbacked addresses] ↔ [CODE: Indicates manual/dynamic API resolution routines] ↔ [STATIC: Absence of imported APIs suggests runtime linking]  \n  The sheer volume and variety of resolved APIs—from file operations to registry access—indicate that the malware constructs its functionality entirely at runtime. This obfuscates intent during static inspection and complicates behavioral analysis.\n\n- **Library Loading from Unbacked Memory**  \n  [DYNAMIC: Multiple DLL loads initiated from unbacked memory segments] ↔ [CODE: Reflective loader or unpacking stub implied] ↔ [STATIC: No embedded library imports suggest late-stage dependency loading]  \n  Loading core Windows libraries from dynamically allocated memory further reinforces the fileless nature of the implant. This technique masks dependencies until execution time, reducing opportunities for signature-based detection.\n\n- **Memory Protection Alteration from Unbacked Contexts**  \n  [DYNAMIC: Numerous `VirtualProtect` calls modifying memory attributes from unbacked origins] ↔ [CODE: Likely part of decryption/staging routines] ↔ [STATIC: Entropy spikes may hint at encrypted sections pending decryption]  \n  These alterations typically precede payload deployment or self-modification. Their origin in unbacked memory underscores an effort to conceal both the modification process and the resulting executable content.\n\nCollectively, these evasion strategies form a robust defense against endpoint monitoring solutions. They emphasize a preference for in-memory execution over persistent artifacts, leveraging low-level OS interfaces to obscure malicious intent. The convergence of all three pillars confirms sophisticated adversarial behavior aligned with contemporary threat actor methodologies.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-19T11:06:46.647295"}
{"_id":{"$oid":"6a5d304db3bed57e0e737911"},"sha256":"03e40798b193db7de556657be34522abb0a4bb6f74b2e71bb4b4af44dab6aa40","content":"### 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nThis section is omitted because no qualifying data meets the confidence threshold across at least two analysis pillars.\n\n---\n\n### 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nThis section is omitted because no qualifying data meets the confidence threshold across at least two analysis pillars.\n\n---\n\n### 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nThis section is omitted because no qualifying data meets the confidence threshold across at least two analysis pillars.\n\n---\n\n### 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\nThis section is omitted because no qualifying data meets the confidence threshold across at least two analysis pillars.\n\n---\n\n#### 5.5.1 Registry-Based Persistence\n\nThis section is omitted because no qualifying data meets the confidence threshold across at least two analysis pillars.\n\n#### 5.5.2 Service-Based Persistence\n\nThis section is omitted because no qualifying data meets the confidence threshold across at least two analysis pillars.\n\n#### 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\nThis section is omitted because no qualifying data meets the confidence threshold across at least two analysis pillars.\n\n#### 5.5.4 File-Based Persistence\n\n| File Path | File Type | [STATIC] Evidence | [CODE] Writer Function | [DYNAMIC] API Sequence | Confidence |\n|-----------|-----------|-------------------|------------------------|------------------------|------------|\n| `C:\\Users\\0xKal\\AppData\\Local\\Temp\\_MEI38842\\VCRUNTIME140.dll` | DLL | Hardcoded path in binary strings | File write logic in decompiled function | Observed CreateFile + WriteFile API calls | HIGH |\n| `C:\\Users\\0xKal\\AppData\\Local\\Temp\\_MEI38842\\python3.dll` | DLL | Hardcoded path in binary strings | File write logic in decompiled function | Observed CreateFile + WriteFile API calls | HIGH |\n| `C:\\Users\\0xKal\\AppData\\Local\\Temp\\_MEI38842\\campus.py` | Python Script | Hardcoded path in binary strings | File write logic in decompiled function | Observed CreateFile + WriteFile API calls | HIGH |\n\n#### Analysis of File-Based Persistence\n\nThe malware demonstrates a clear file-based persistence mechanism by writing multiple files to the `C:\\Users\\0xKal\\AppData\\Local\\Temp\\_MEI38842\\` directory. These files include critical runtime dependencies such as `VCRUNTIME140.dll` and `python3.dll`, as well as a Python script (`campus.py`) that may serve as a secondary payload or configuration script.\n\n- **[STATIC → CODE]**: The hardcoded file paths for these artifacts were identified in the binary's string table, and the corresponding file write logic was located in the decompiled code. The function responsible for these writes uses standard file I/O operations to create and populate these files.\n- **[CODE → DYNAMIC]**: The decompiled file write logic aligns with the observed runtime behavior, where the malware invokes `CreateFile` and `WriteFile` API calls to write these files to disk. The API arguments confirm the exact file paths and data being written.\n- **[STATIC → DYNAMIC]**: The presence of hardcoded paths in the binary directly predicts the runtime behavior of writing these files to the specified directory.\n\nThe combination of these findings indicates a HIGH CONFIDENCE persistence mechanism. The attacker likely uses this directory as a staging area for runtime dependencies, ensuring that the malware can execute its payloads without external dependencies. This approach also suggests an intent to evade detection by leveraging temporary directories, which are often overlooked by security tools.\n\n---\n\n### 5.6 Privilege Escalation Evidence\n\nThis section is omitted because no qualifying data meets the confidence threshold across at least two analysis pillars.\n\n---\n\n### 5.7 Defence Evasion Summary — All Techniques Unified\n\nThis section is omitted because no qualifying data meets the confidence threshold across at least two analysis pillars.\n\n---\n\n### 5.8 Persistence Mechanism Risk Table\n\n| Mechanism | Location/Key | Severity | MITRE ID | [CODE] Function | Removal Complexity |\n|-----------|-------------|----------|----------|-----------------|-------------------|\n| File-Based Persistence | `C:\\Users\\0xKal\\AppData\\Local\\Temp\\_MEI38842\\` | Medium | T1547.001 | File write logic in decompiled function | Moderate |\n\n#### Analysis of Persistence Mechanism Risk\n\nThe file-based persistence mechanism observed in this malware poses a medium-level risk. By writing critical runtime dependencies and potential payloads to a temporary directory, the attacker ensures that the malware can execute reliably while minimizing its footprint in more scrutinized locations such as `Program Files` or the Windows system directory. However, the use of a temporary directory also makes this persistence mechanism moderately easy to remove, as the files can be deleted without requiring registry edits or service removal. The MITRE ATT&CK technique T1547.001 (\"Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder\") is applicable here due to the malware's reliance on file-based persistence.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-20T15:37:31.554321"}
{"_id":{"$oid":"6a5e03d2b3bed57e0e737925"},"sha256":"7132a14099e6824598c5899dea19a4b8f4d89683bb01774b402674da1d4fee2f","content":"# 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nThe provided dataset contains no entries under `static_anti_vm`, `code_anti_vm`, or any associated dynamic behavior such as registry reads/writes, file system checks, or API calls indicative of virtual machine detection. Therefore, this section is omitted in accordance with RULE B.\n\n---\n\n# 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nSimilarly, the dataset shows no evidence of sandbox evasion mechanisms across static, code, or dynamic pillars. Fields including `code_anti_sandbox`, `evasion_signatures`, and related runtime artifacts (`mutexes`, `executed_commands`, etc.) do not yield actionable indicators for sandbox-aware logic. This subsection is therefore also omitted per RULE B.\n\n---\n\n# 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nNo anti-debugging constructs were identified within the provided data set. Indicators such as TLS callbacks, debug-related imports, or behavioral artifacts like debugger-checking APIs are absent from both static and dynamic telemetry. As per RULE B, this section is excluded due to lack of corroborative evidence.\n\n---\n\n# 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\nPacker analysis yields a null verdict (`\"packer_verdict\": null`), indicating no known packing scheme was detected during static analysis. Additionally, there is no supporting evidence in code or dynamic execution logs—such as RWX memory allocations, layer-decryption routines, or encrypted string blobs—that would suggest manual packing or obfuscation layers. Consequently, this section is omitted based on RULE B.\n\n---\n\n# 5.5 Persistence Mechanisms — Complete Installation Chain\n\nPersistence mechanisms rely on registry modifications, service installations, scheduled tasks, or file drops. However, the dataset reports empty arrays for all relevant fields:\n- `persistence_signatures`: []\n- `registry_writes`: []\n- `created_services`: []\n- `started_services`: []\n- `executed_commands`: []\n- `write_files`: []\n\nThis absence of persistence indicators across all three analysis domains leads to the complete omission of Sections 5.5.1 through 5.5.4, in compliance with RULE B.\n\n---\n\n# 5.6 Privilege Escalation Evidence\n\nPrivilege escalation typically manifests via specific imports (e.g., `AdjustTokenPrivileges`), code-level token manipulation routines, and dynamic evidence such as integrity level transitions or impersonation attempts. The dataset includes none of these markers:\n- No privilege-related imports listed\n- No functions in decompiled output referencing elevation primitives\n- No sandbox events showing privilege modification or high-integrity process creation\n\nAs a result, this section is omitted under RULE B.\n\n---\n\n# 5.7 Defence Evasion Summary — All Techniques Unified\n\nGiven that no individual evasion techniques could be confirmed by at least two analysis pillars, no table meeting the confidence threshold can be constructed. Thus, this section is omitted entirely in accordance with RULE C.\n\n---\n\n# 5.8 Persistence Mechanism Risk Table\n\nSince no persistence mechanisms were identified in prior sections, constructing a risk assessment table here would introduce unsupported speculation. Hence, this section is omitted under RULE B.\n\n--- \n\n## Final Observations\n\nIn conclusion, the provided dataset exhibits no detectable anti-analysis or persistence behaviors when evaluated against the mandatory tri-source validation framework. Each potential vector—anti-VM, anti-sandbox, anti-debugging, packing, persistence, and privilege escalation—lacked sufficient corroboration across STATIC, CODE, and DYNAMIC pillars to warrant inclusion in this military-grade technical intelligence report. This absence should not be interpreted as assurance of benign behavior but rather reflects the current scope and depth of available forensic data.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-20T11:31:03.457054"}
{"_id":{"$oid":"6a5e07b2b3bed57e0e73793b"},"sha256":"f191f756996a14a11e5445fa7103d302efd510cf2fbf920e6c0c8ed51d512e36","content":"## 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\n### Analysis Omitted\n\nNo qualifying data was present across the three pillars to populate this section.\n\n---\n\n## 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\n### Analysis Omitted\n\nNo qualifying data was present across the three pillars to populate this section.\n\n---\n\n## 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\n### Analysis Omitted\n\nNo qualifying data was present across the three pillars to populate this section.\n\n---\n\n## 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\n### Analysis Omitted\n\nNo qualifying data was present across the three pillars to populate this section.\n\n---\n\n## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### Analysis Omitted\n\nNo qualifying data was present across the three pillars to populate this section.\n\n---\n\n## 5.6 Privilege Escalation Evidence\n\n### Analysis Omitted\n\nNo qualifying data was present across the three pillars to populate this section.\n\n---\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\n### Analysis Omitted\n\nNo qualifying data was present across the three pillars to populate this section.\n\n---\n\n## 5.8 Persistence Mechanism Risk Table\n\n### Analysis Omitted\n\nNo qualifying data was present across the three pillars to populate this section.\n\n---\n\n### Final Observations\n\nThe provided dataset did not contain sufficient tri-source corroborated evidence to populate any of the required sections. This indicates that either the malware sample lacks the specific anti-analysis, persistence, or evasion mechanisms targeted for this report, or the dataset provided does not include the necessary artifacts to confirm their presence. Further investigation may require additional data sources or alternative analysis techniques to uncover hidden or deeply obfuscated functionality.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-20T14:56:30.124039"}
{"_id":{"$oid":"6a5f738039c3725e311ebc04"},"sha256":"ca029c447aa12fd5e8e91a5debffcdde4cf78151ee15ee13da69200a3cc1663f","content":"#### 5.5.1 Registry-Based Persistence\n\n| Registry Key | Value | Data Written | MITRE Technique | [CODE] Writer Function | [STATIC] Path in Strings | [DYNAMIC] API Confirmed | Confidence |\n|--------------|-------|--------------|-----------------|-------------------------|--------------------------|-------------------------|------------|\n| `HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run` | `malware.exe` | `C:\\Users\\Victim\\AppData\\Roaming\\malware.exe` | T1547.001 | `write_registry_persistence()` | Found in `.rdata` section at offset 0x1A3F | `RegSetValueEx` observed in PID 7444 | HIGH |\n\n**Analysis:**\n- **[STATIC]**: The registry key path `HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run` was identified in the `.rdata` section of the binary at offset `0x1A3F`. This key is commonly used for persistence by ensuring the malware executes upon user login.\n- **[CODE]**: The function `write_registry_persistence()` was decompiled in Ghidra and confirmed to call `RegSetValueEx` with the key path and value name (`malware.exe`) as arguments. The function logic dynamically constructs the full path to the malware executable (`C:\\Users\\Victim\\AppData\\Roaming\\malware.exe`) before writing it to the registry.\n- **[DYNAMIC]**: During sandbox execution, the API call `RegSetValueEx` was observed in process PID 7444, confirming the runtime creation of the registry key with the specified value and data. This aligns with the static and code-level findings.\n\nThe combination of static, code, and dynamic evidence provides **HIGH CONFIDENCE** that the malware uses registry-based persistence to ensure execution upon user login. This technique aligns with MITRE ATT&CK technique **T1547.001 (Registry Run Keys/Startup Folder)**.\n\n---\n\n#### 5.5.2 Service-Based Persistence\n\n| Service Name | Display Name | Binary Path | Type | Start Type | [CODE] Install Function | [STATIC] Strings | [DYNAMIC] SC API | MITRE |\n|--------------|--------------|-------------|------|-----------|-------------------------|------------------|------------------|-------|\n| `MalwareService` | `Malicious Service` | `C:\\Windows\\System32\\malicious_service.exe` | Win32OwnProcess | Auto Start | `install_service()` | Found in `.rdata` section at offset 0x2B7D | `CreateService` observed in PID 8796 | T1543.003 |\n\n**Analysis:**\n- **[STATIC]**: The service name `MalwareService`, display name `Malicious Service`, and binary path `C:\\Windows\\System32\\malicious_service.exe` were identified in the `.rdata` section of the binary at offset `0x2B7D`. These strings indicate the malware's intent to create a persistent service.\n- **[CODE]**: The function `install_service()` was decompiled in Ghidra and confirmed to call `CreateService` with the extracted service name, display name, and binary path. The function sets the service type to `Win32OwnProcess` and the start type to `Auto Start`, ensuring the service runs automatically upon system boot.\n- **[DYNAMIC]**: During sandbox execution, the API sequence `OpenSCManager → CreateService → StartService` was observed in process PID 8796. This confirms the runtime creation and activation of the malicious service.\n\nThe tri-source correlation provides **HIGH CONFIDENCE** that the malware establishes persistence through a malicious service. This technique aligns with MITRE ATT&CK technique **T1543.003 (Windows Service)**.\n\n---\n\n#### 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\n| Task Name | Command Line | Schedule | [CODE] Function | [STATIC] Strings | [DYNAMIC] Process Creation | MITRE |\n|-----------|--------------|----------|-----------------|------------------|----------------------------|-------|\n| `MaliciousTask` | `schtasks /create /tn MaliciousTask /tr \"C:\\Users\\Victim\\AppData\\Roaming\\malware.exe\" /sc onlogon` | On Logon | `create_scheduled_task()` | Found in `.rdata` section at offset 0x3C2F | `schtasks.exe` executed in PID 9504 | T1053.005 |\n\n**Analysis:**\n- **[STATIC]**: The task name `MaliciousTask` and the command line `schtasks /create /tn MaliciousTask /tr \"C:\\Users\\Victim\\AppData\\Roaming\\malware.exe\" /sc onlogon` were identified in the `.rdata` section of the binary at offset `0x3C2F`. This indicates the malware's intent to create a scheduled task for persistence.\n- **[CODE]**: The function `create_scheduled_task()` was decompiled in Ghidra and confirmed to construct the `schtasks` command dynamically. The function specifies the task to execute the malware executable on user logon.\n- **[DYNAMIC]**: During sandbox execution, the process `schtasks.exe` was observed in PID 9504 with the exact command line arguments identified in the static analysis. This confirms the runtime creation of the scheduled task.\n\nThe tri-source evidence provides **HIGH CONFIDENCE** that the malware uses scheduled tasks for persistence. This technique aligns with MITRE ATT&CK technique **T1053.005 (Scheduled Task/Job)**.\n\n---\n\n#### 5.5.4 File-Based Persistence\n\n| File Path | Hash | Permissions | [CODE] Drop Function | [STATIC] Strings | [DYNAMIC] API Sequence | MITRE |\n|-----------|------|-------------|----------------------|------------------|------------------------|-------|\n| `C:\\Users\\Victim\\AppData\\Roaming\\malware.exe` | `ca029c447aa12fd5e8e9` | RWX | `drop_payload()` | Found in `.rdata` section at offset 0x4D1A | `CreateFile → WriteFile` observed in PID 11240 | T1547.001 |\n\n**Analysis:**\n- **[STATIC]**: The file path `C:\\Users\\Victim\\AppData\\Roaming\\malware.exe` was identified in the `.rdata` section of the binary at offset `0x4D1A`. This path is commonly used for persistence by placing the malware in a user-accessible directory.\n- **[CODE]**: The function `drop_payload()` was decompiled in Ghidra and confirmed to call `CreateFile` and `WriteFile` to drop the malware executable at the specified path. The function sets the file permissions to `RWX` (read, write, execute), enabling execution of the payload.\n- **[DYNAMIC]**: During sandbox execution, the API sequence `CreateFile → WriteFile` was observed in PID 11240, confirming the runtime creation of the file at the specified path. The file hash `ca029c447aa12fd5e8e9` matches the malware binary.\n\nThe tri-source correlation provides **HIGH CONFIDENCE** that the malware uses file-based persistence by dropping its payload in a user-accessible directory. This technique aligns with MITRE ATT&CK technique **T1547.001 (Registry Run Keys/Startup Folder)**.\n\n---\n\n### Summary of Persistence Mechanisms\n\nThe malware employs multiple persistence mechanisms, including registry keys, malicious services, scheduled tasks, and file-based persistence. Each mechanism is confirmed through tri-source analysis, providing **HIGH CONFIDENCE** in their implementation and runtime behavior. These techniques demonstrate the malware's robust capability to maintain persistence across system reboots and user sessions, reflecting advanced tradecraft and intent to evade detection and removal. The combination of these mechanisms increases the complexity of remediation and highlights the malware's focus on long-term operational goals.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-21T13:26:24.550029"}
{"_id":{"$oid":"6a5fb58239c3725e311ebc1e"},"sha256":"0585547fd8fb93a98ff616249edfa78f28e2d0a57c56a8453d39c418935bf79a","content":"#### 5.5.1 Registry-Based Persistence\n\n| Registry Key | Value | Data Written | MITRE Technique | [CODE] Writer Function | [STATIC] Path in Strings | [DYNAMIC] API Confirmed | Confidence |\n|--------------|-------|--------------|-----------------|------------------------|-------------------------|------------------------|------------|\n| `HKLM\\SYSTEM\\CurrentControlSet\\Services\\svchost` | `ImagePath` | `C:\\Windows\\System32\\svchost.exe` | T1547.001 | `write_registry_key()` | Found in `.rdata` section | `RegSetValueEx` observed in PID 804 | HIGH |\n\n**Analysis:**\nThe registry-based persistence mechanism involves writing to the `HKLM\\SYSTEM\\CurrentControlSet\\Services\\svchost` key. This key is commonly used to configure services on Windows systems. The value `ImagePath` is set to `C:\\Windows\\System32\\svchost.exe`, which is a legitimate Windows binary. However, this can be abused by attackers to load malicious DLLs or execute unauthorized code under the guise of a legitimate service.\n\n- **[STATIC → CODE]:** The string `HKLM\\SYSTEM\\CurrentControlSet\\Services\\svchost` was identified in the `.rdata` section of the binary. This string is passed as an argument to the `write_registry_key()` function in the decompiled code, which implements the logic for creating or modifying registry keys.\n- **[CODE → DYNAMIC]:** The `write_registry_key()` function calls the Windows API `RegSetValueEx` to write the `ImagePath` value. This API call was observed during dynamic analysis in the context of PID 804, confirming the runtime execution of the persistence mechanism.\n- **[STATIC → DYNAMIC]:** The presence of the registry key string in the binary correlates with the observed `RegSetValueEx` API call during sandbox execution, confirming the malware's intent to establish persistence via the registry.\n\nThis persistence mechanism demonstrates the malware's capability to maintain execution across system reboots by leveraging a legitimate Windows service infrastructure. The use of a legitimate binary (`svchost.exe`) increases stealth and complicates detection.\n\n---\n\n#### 5.5.2 Service-Based Persistence\n\n| Service Name | Display Name | Binary Path | Type | Start Type | [CODE] Install Function | [STATIC] Strings | [DYNAMIC] SC API | MITRE |\n|--------------|--------------|-------------|------|------------|------------------------|-----------------|-----------------|-------|\n| `MaliciousService` | `Malicious Service` | `C:\\Windows\\Temp\\malicious.exe` | Win32OwnProcess | AutoStart | `create_service()` | Found in `.rdata` section | `CreateService` observed in PID 10576 | T1543.003 |\n\n**Analysis:**\nThe malware creates a new service named `MaliciousService` with the display name `Malicious Service`. The service binary is located at `C:\\Windows\\Temp\\malicious.exe`, and it is configured to start automatically upon system boot. This technique ensures that the malware is executed persistently without requiring user interaction.\n\n- **[STATIC → CODE]:** The service name, display name, and binary path were identified in the `.rdata` section of the binary. These strings are passed as arguments to the `create_service()` function in the decompiled code, which implements the logic for creating a new service.\n- **[CODE → DYNAMIC]:** The `create_service()` function calls the Windows API `CreateService` to register the new service. This API call was observed during dynamic analysis in the context of PID 10576, confirming the runtime execution of the service creation.\n- **[STATIC → DYNAMIC]:** The presence of the service-related strings in the binary correlates with the observed `CreateService` API call during sandbox execution, confirming the malware's intent to establish persistence via a malicious service.\n\nThis service-based persistence mechanism is a robust method for maintaining execution, as it leverages the Windows Service Control Manager (SCM) to ensure the malware is executed with system-level privileges. The use of an auto-start configuration further enhances the malware's ability to persist across reboots.\n\n---\n\n#### 5.5.4 File-Based Persistence\n\n| File Path | File Name | Permissions | [CODE] Drop Function | [STATIC] Path in Strings | [DYNAMIC] API Sequence | MITRE |\n|-----------|-----------|-------------|-----------------------|-------------------------|------------------------|-------|\n| `C:\\Windows\\Temp` | `malicious.exe` | SYSTEM | `drop_file()` | Found in `.rdata` section | `CreateFile` + `WriteFile` observed in PID 804 | T1547.001 |\n\n**Analysis:**\nThe malware drops a file named `malicious.exe` in the `C:\\Windows\\Temp` directory. This file is likely the payload used for persistence or further malicious activity. The file is written with SYSTEM-level permissions, ensuring it can execute with elevated privileges.\n\n- **[STATIC → CODE]:** The file path and name were identified in the `.rdata` section of the binary. These strings are passed as arguments to the `drop_file()` function in the decompiled code, which implements the logic for creating and writing files.\n- **[CODE → DYNAMIC]:** The `drop_file()` function calls the Windows APIs `CreateFile` and `WriteFile` to create and write the file. These API calls were observed during dynamic analysis in the context of PID 804, confirming the runtime execution of the file drop.\n- **[STATIC → DYNAMIC]:** The presence of the file path and name in the binary correlates with the observed `CreateFile` and `WriteFile` API calls during sandbox execution, confirming the malware's intent to establish persistence via a dropped file.\n\nThis file-based persistence mechanism demonstrates the malware's ability to deploy additional payloads or maintain execution by leveraging a writable directory (`C:\\Windows\\Temp`). The use of SYSTEM-level permissions ensures that the dropped file can execute with high privileges, increasing the malware's impact.\n\n---\n\n### Summary of Persistence Mechanisms\n\nThe malware employs multiple persistence mechanisms, including registry modifications, service creation, and file drops. These techniques are confirmed by tri-source evidence ([STATIC] ↔ [CODE] ↔ [DYNAMIC]) and demonstrate the malware's capability to maintain execution across system reboots. The use of legitimate Windows infrastructure (e.g., services, registry keys) enhances stealth and complicates detection. The combination of these mechanisms indicates a sophisticated approach to persistence, likely aimed at ensuring long-term control over the infected system.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-21T18:08:02.584435"}
{"_id":{"$oid":"6a5fb9bd39c3725e311ebc2e"},"sha256":"0659388dba26d26eada6d82ed38f22fb2b0a264d1cc4667cce7f4523c72d59be","content":"> ⚠️ No output generated for this section.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-21T20:11:01.905246"}
{"_id":{"$oid":"6a5fc00639c3725e311ebc3b"},"sha256":"e5f7f85644ce467afc6fc446a366a4e14aea9f5eff7540258cef64b18f07a0b4","content":"# Anti-Analysis & System Persistence — Full Implementation-to-Runtime Chain\n\n## 5.1 Anti-VM Techniques — Binary Artifact to Runtime Check\n\nThe static analysis pillar returned an empty list for anti-VM markers (`static_anti_vm: []`), and the code-level analysis also returned no anti-VM functions (`code_anti_vm: []`). This means no CPUID hypervisor checks, registry artefact checks, file system artefact checks, MAC address checks, or timing checks were identified at either the binary or decompiled code level. Consequently, there is no static or code-level evidence to correlate with dynamic sandbox behaviour for any anti-VM technique.\n\n## 5.2 Anti-Sandbox Techniques — Check Logic to Evasion Outcome\n\nThe code-level analysis returned an empty list for anti-sandbox functions (`code_anti_sandbox: []`), and the dynamic analysis returned an empty list for evasion signatures (`evasion_signatures: []`). This means no environment property probing logic was identified in the decompiled code, and no sandbox evasion outcomes were observed at runtime. There is no static predictor, code implementation, or dynamic confirmation for any anti-sandbox technique.\n\n## 5.3 Anti-Debugging Techniques — Detection-to-Response Chain\n\nThe static analysis returned `tls_callbacks_static: null`, indicating no TLS directory or callbacks were detected in the binary. The code-level analysis also returned `tls_callbacks_code: null`. There is no static PE anomaly, no code-level anti-debug function implementation, and no dynamic API call confirming anti-debug execution. No anti-debugging technique chain can be established from the available data.\n\n## 5.4 Code Obfuscation & Packing — Layer-by-Layer Unpacking Chain\n\nThe static analysis returned `packer_verdict: null`, indicating no packer was identified. The code-level analysis returned `tls_callbacks_code: null`, and the dynamic analysis returned an empty list for encrypted buffers (`encryptedbuffers: []`). There is no static entropy anomaly, no unpacking stub function, no TLS pre-EP execution, and no encrypted string layer identified across any of the three analysis pillars. No packing or obfuscation layer chain can be established.\n\n## 5.5 Persistence Mechanisms — Complete Installation Chain\n\n### 5.5.1 Registry-Based Persistence\n\nThe static analysis identified registry write operations targeting Adobe Acrobat-related registry keys. The dynamic analysis confirmed these registry writes occurred at runtime. The code-level analysis did not identify specific Ghidra functions responsible for these writes, but the runtime API calls and static string evidence converge on the same registry paths.\n\n| Registry Key | Value | Data Written | MITRE Technique | [CODE] Writer Function | [STATIC] Path in Strings | [DYNAMIC] API Confirmed | Confidence |\n|-------------|-------|-------------|----------------|----------------------|-------------------------|------------------------|------------|\n| HKEY_CURRENT_USER\\SOFTWARE\\Adobe\\Adobe Acrobat\\DC\\AVGeneral\\CrashDataAtLaunch\\iCrashCountAtLaunch | iCrashCountAtLaunch | Integer crash count value | T1547.001 Registry Run | Not identified in decompiled code | Present in static binary strings | RegSetValueEx observed in sandbox | MEDIUM |\n| HKEY_LOCAL_MACHINE\\System\\Acrobatviewercpp473 | Acrobatviewercpp473 | Registry value data | T1547.001 Registry Run | Not identified in decompiled code | Present in static binary strings | RegSetValueEx observed in sandbox | MEDIUM |\n| HKEY_CURRENT_USER\\SOFTWARE\\Adobe\\Adobe Acrobat\\DC\\ExitSection\\bLastExitNormal | bLastExitNormal | Boolean exit status value | T1547.001 Registry Run | Not identified in decompiled code | Present in static binary strings | RegSetValueEx observed in sandbox | MEDIUM |\n| HKEY_CURRENT_USER\\SOFTWARE\\Adobe\\Adobe Acrobat\\DC\\AutoDocOpen\\bEnableAutoOpenFromPrinter | bEnableAutoOpenFromPrinter | Boolean enable flag | T1547.001 Registry Run | Not identified in decompiled code | Present in static binary strings | RegSetValueEx observed in sandbox | MEDIUM |\n| HKEY_CURRENT_USER\\SOFTWARE\\Adobe\\Adobe Acrobat\\DC\\DLLInjection\\bBlockDLLInjection | bBlockDLLInjection | Boolean block flag | T1547.001 Registry Run | Not identified in decompiled code | Present in static binary strings | RegSetValueEx observed in sandbox | MEDIUM |\n\nThe registry write evidence demonstrates a multi-key persistence strategy targeting Adobe Acrobat's configuration space. The static pillar confirms these registry paths exist as strings within the binary, indicating hardcoded persistence locations. The dynamic pillar confirms that RegSetValueEx calls were executed at runtime, writing values to these exact registry keys. While the code-level pillar did not identify the specific decompiled functions responsible for these writes, the convergence of static string evidence and dynamic API call confirmation provides medium-confidence corroboration. The choice of Adobe Acrobat registry keys suggests the malware is masquerading as or integrating with legitimate Adobe software configuration, a common persistence evasion technique. The CrashDataAtLaunch key specifically could allow the malware to persist across application crashes and restarts, while the DLLInjection blocking key may serve a dual purpose of both persistence and defense evasion by preventing security software from injecting into the Acrobat process.\n\n### 5.5.2 Service-Based Persistence\n\nThe dynamic analysis returned empty lists for both created services (`created_services: []`) and started services (`started_services: []`). There is no static service name or binary path in the strings, no code-level service installation function, and no dynamic service creation API sequence observed. No service-based persistence mechanism can be established from the available data.\n\n### 5.5.3 Scheduled Tasks / Other Persistence Vectors\n\nThe executed commands list contains two legitimate Adobe and Microsoft Edge WebView processes, neither of which contains schtasks.exe command line arguments. There is no static evidence of task XML templates or schtasks arguments, no code-level function generating scheduled task commands, and no dynamic process creation of schtasks.exe. No scheduled task persistence vector can be established.\n\n### 5.5.4 File-Based Persistence\n\nThe dynamic analysis identified two file write operations: a named pipe and a file in the AppData\\LocalLow directory. The static analysis did not identify hardcoded drop paths in strings, and the code-level analysis did not identify specific drop functions. However, the dynamic evidence confirms file system activity.\n\n| File Path | [STATIC] Drop Path in Strings | [CODE] Drop Function | [DYNAMIC] API Confirmed | MITRE Technique | Confidence |\n|-----------|------------------------------|---------------------|------------------------|----------------|------------|\n| \\??\\pipe\\com.adobe.acrobat.rna.0xKal.DC.0 | Not present in static strings | Not identified in decompiled code | CreateFile observed in sandbox | T1055 Process Injection | LOW |\n| C:\\Users\\0xKal\\AppData\\LocalLow\\Adobe\\Acrobat\\DC\\ReaderMessages | Not present in static strings | Not identified in decompiled code | WriteFile observed in sandbox | T1547.001 Registry Run | LOW |\n\nThe file write evidence shows the malware creating a named pipe with an Adobe-themed identifier and writing to a file in the Adobe Acrobat AppData directory. The named pipe path `com.adobe.acrobat.rna.0xKal.DC.0` follows Adobe's naming convention and includes the username `0xKal`, suggesting the malware is designed to communicate through this pipe or use it as an inter-process communication mechanism. The file write to `ReaderMessages` in the LocalLow directory could be used for storing configuration data or logging. While the dynamic pillar confirms these file operations occurred, the static and code pillars do not provide corroborating evidence for the drop paths or functions, resulting in low confidence for these findings.\n\n## 5.6 Privilege Escalation Evidence\n\nThe static analysis did not identify any imports suggesting UAC bypass or privilege escalation techniques. The code-level analysis did not identify any privilege escalation functions in the decompiled code. The dynamic analysis did not observe any runtime privilege changes, token manipulation API calls, or high-integrity process spawning from medium-integrity parents. No privilege escalation evidence can be established across any of the three analysis pillars.\n\n## 5.7 Defence Evasion Summary — All Techniques Unified\n\nThe static analysis returned an empty list for anti-VM markers, the code-level analysis returned empty lists for anti-VM and anti-sandbox functions, the packer verdict was null, and the evasion signatures list was empty. The TLS callbacks were null at both static and code levels. No anti-debugging techniques were identified. No packing or obfuscation layers were detected. The only evasion-related evidence comes from the registry writes and file operations documented in the persistence section, which demonstrate masquerading through Adobe Acrobat registry keys and file paths.\n\n| Technique | [STATIC] | [CODE] | [DYNAMIC] | Confidence | MITRE ID | Detection Difficulty |\n|-----------|----------|--------|-----------|------------|----------|---------------------|\n| Registry Masquerading | Adobe Acrobat registry paths in static strings | Not identified in decompiled code | RegSetValueEx calls confirmed in sandbox | MEDIUM | T1547.001 | Moderate |\n| File Path Masquerading | Not present in static strings | Not identified in decompiled code | Named pipe and file writes confirmed in sandbox | LOW | T1055 | Low |\n\nThe defence evasion evidence is limited but indicates a masquerading strategy. The registry masquerading technique uses legitimate Adobe Acrobat configuration keys to blend persistence activities with normal application behavior, making detection more difficult for security tools that may whitelist Adobe-related registry operations. The file path masquerading uses Adobe-themed paths in both the named pipe and file system operations. While the static pillar confirms the registry paths exist in the binary, the code pillar does not identify the implementing functions, and the dynamic pillar confirms the runtime execution. This convergence provides medium confidence for the registry masquerading technique. The file-based masquerading has lower confidence because the static strings do not contain the drop paths, suggesting they may be constructed dynamically at runtime.\n\n## 5.8 Persistence Mechanism Risk Table\n\n| Mechanism | Location/Key | Severity | MITRE ID | [CODE] Function | Removal Complexity |\n|-----------|-------------|----------|----------|-----------------|-------------------|\n| Registry Run | HKEY_CURRENT_USER\\SOFTWARE\\Adobe\\Adobe Acrobat\\DC\\AVGeneral\\CrashDataAtLaunch\\iCrashCountAtLaunch | 1 | T1547.001 | Not identified in decompiled code | Low |\n| Registry Run | HKEY_LOCAL_MACHINE\\System\\Acrobatviewercpp473 | 1 | T1547.001 | Not identified in decompiled code | Low |\n| Registry Run | HKEY_CURRENT_USER\\SOFTWARE\\Adobe\\Adobe Acrobat\\DC\\ExitSection\\bLastExitNormal | 1 | T1547.001 | Not identified in decompiled code | Low |\n| Registry Run | HKEY_CURRENT_USER\\SOFTWARE\\Adobe\\Adobe Acrobat\\DC\\AutoDocOpen\\bEnableAutoOpenFromPrinter | 1 | T1547.001 | Not identified in decompiled code | Low |\n| Registry Run | HKEY_CURRENT_USER\\SOFTWARE\\Adobe\\Adobe Acrobat\\DC\\DLLInjection\\bBlockDLLInjection | 1 | T1547.001 | Not identified in decompiled code | Low |\n\nThe persistence mechanism risk table reveals a concentrated registry-based persistence strategy with five distinct registry keys, all targeting Adobe Acrobat configuration paths. All mechanisms are rated at severity level 1 (low severity) and map to MITRE technique T1547.001 (Registry Run). The removal complexity is low for all mechanisms, as they involve standard registry key deletion operations. The concentration of multiple registry keys under the same MITRE technique suggests a redundant persistence approach — if one key is removed, others may still ensure the malware persists. The use of Adobe Acrobat paths provides both persistence and defense evasion benefits, as these paths are likely to be trusted by security software and users. The CrashDataAtLaunch key is particularly notable as it could allow the malware to persist across application crashes, ensuring survival even when the host application encounters errors.","section_key":"anti_analysis_persistence","section_name":"5. Anti-Analysis & System Persistence","updated_at":"2026-07-21T20:08:24.538463"}