Note: this report may be incomplete because the AI analysis reached the following limit(s): token.

# Malware Triage Report

**Analysis ID**: 26  
**SHA256**: `0dc710737c12ea1c1215fbd39e00347649fff1fb0e512287c86873f66a9f0a35`

---

## Summary

The sample is a 1MB x86 PE executable, code-signed by **"Umbrella LLC"** (Krasnoyarsk, Russia) via Sectigo (certificate expired 2021-09-04). The binary exhibits classic **runtime unpacking/decrypting behavior**: the entry point copies an encrypted payload from the `.data` section into dynamically allocated RWX memory, then jumps into it. The unpacking stub subsequently uses `VirtualProtect` to set RWX permissions, zeroes out its own code, and frees memory. Nine large (~200KB total) high-entropy crypto data blocks with no cross-references are embedded in `.text`. Over 200 of ~210 imported APIs are unreferenced (decoy imports). The code is heavily obfuscated with dead code, opaque predicates, XOR loops, and PEB access patterns.

---

## Key Detections/IOCs

| Indicator | Detail |
|-----------|--------|
| **Expired code signing cert** | Umbrella LLC (RU), Sectigo, expired 2021-09-04 |
| **Runtime unpacking** | EntryPoint → `VirtualAlloc` (RWX) → copy from `.data` → jump to unpacked code |
| **VirtualProtect (RWX)** | Unpacked stub calls `VirtualProtect(..., 0x40, ...)` — classic RWX shellcode |
| **Self-zeroing** | Unpacked stub zeros out its own `.data` section after execution |
| **9 encrypted data blocks** | 22KB each, entropy ~167, no xrefs — likely encrypted payload segments |
| **Decoy imports** | 201 of ~210 imports unreferenced (advapi32, gdi32, ole32, winmm, winspool, etc.) |
| **20 XOR-in-loop instances** | Heavy XOR-based obfuscation throughout code |
| **PEB access** | `FS:[0x30]` → PEB walking (anti-analysis technique) |
| **PIC construction warning** | Decompiler detected position-independent code patterns |
| **Manifest locale anomaly** | Hungarian (`hu-hu`) manifest — unlikely for Russian-signed software |

---

## Evidence

### 1. Entry Point — Runtime Unpacking (#AID=26#, ea=11402)
The decompiled entry point reveals:
- Calls `sub_408352` (a loop with XOR operations — likely integrity/check check)
- Calls `VirtualAlloc(0, size, 0x1000, 0x40)` — allocates RWX memory
- Copies data from `.data` section (ea=0x4f42f0) byte-by-byte into allocated buffer
- Jumps to `(allocated_buffer + 0x396c)` via indirect call

### 2. Unpacked Stub — Decryption & Self-Destruction (#AID=26#, ea=11622)
`sub_40396c` (called from unpacked code):
- Calls `VirtualProtect` with `0x40` (PAGE_EXECUTE_READWRITE)
- Calls `sub_40130c` — likely the actual payload decryptor
- **Zeroes out the unpacked memory buffer** (anti-forensics)
- Calls `VirtualFree` to release allocated memory

### 3. Encrypted Payload Blocks (#AID=26#)
Nine large buffers at ea=695828, 728657, 761360, 794180, 826948, 859713, 892496, 925268, 957508 — each ~22KB with entropy 167, containing no recognizable structures or strings. These are almost certainly the encrypted final payload.

### 4. Obfuscated Code Functions
All top 30 functions show heavy obfuscation: opaque predicates, constant manipulation (`^ 0xfffffa18`, `+ 0x56d`, `& 0xfffffed4`), dead stores, and arithmetic on meaningless values — hallmarks of automated obfuscation/packing.

### 5. Sub-file — Manifest (#AID=27#)
The virtual file `MANIF/1/hu-hu` contains a standard Windows application manifest requesting `asInvoker` execution level. The Hungarian locale is suspicious for a Russian-signed binary and likely chosen randomly or as a fingerprint evasion technique.

---

## Counter-Arguments

| Argument | Assessment |
|----------|------------|
| **Signed certificate** | Certificate is expired (2021) and issued to a small Russian LLC — provides no meaningful trust assurance |
| **No network IOCs found** | No URLs, IPs, or domains beyond certificate CRL/OCSP endpoints — payload behavior is unknown |
| **Kesakode: no verdict** | No automated detection — the heavy obfuscation likely defeats static analysis |
| **No YARA matches** | Packer/obfuscator is custom or uncommon enough to evade rule-based detection |
| **Could be legitimate protection** | Legitimate software protectors exist, but the combination of expired Russian cert, decoy imports, self-zeroing, RWX allocation, and PEB access is far more consistent with malware |

---

## Verdict

**MALICIOUS — Confidence: 95%**

This file is a **packed/encrypted malware dropper**. The overwhelming evidence:

1. **Runtime decryption** of ~200KB of encrypted payload into RWX memory
2. **Anti-forensic self-destruction** (zeroing code after execution)
3. **Extreme code obfuscation** (dead code, opaque predicates, XOR loops)
4. **Decoy import table** (201/210 imports unused)
5. **Expired Russian code-signing certificate** — likely stolen or purchased for evasion
6. **PEB access** — standard anti-analysis technique
7. **No legitimate functional purpose** for any of the above techniques in combination

The actual payload is fully encrypted and only decrypted at runtime, so its specific malicious behavior (stealer, RAT, ransomware, etc.) cannot be determined from static analysis alone. Dynamic analysis or memory dumping would be required to identify the final payload's capabilities.