## Summary

The submitted sample #AID=39# (`0dc710737c12ea1c1215fbd39e00347649fff1fb0e512287c86873f66a9f0a35`) is a 32-bit Windows PE executable, size 1,017,320 bytes, timestamped `2020-10-05 10:54:52`.

High-level observations for #AID=39#:

- Type: PE32 / x86 executable.
- Sections: `.text`, `.data`, `.rsrc`, plus an overlay containing a PKCS#7 signature/certificate blob.
- Code signing metadata is present:
  - Subject: `Umbrella LLC`
  - Country: `RU`, Locality: `Krasnoyarsk`
  - Issuer: `Sectigo RSA Code Signing CA`
  - Validity: `2020-09-04` to `2021-09-04`
- Kesakode verdict: none.
- YARA matches: none.
- The executable appears heavily obfuscated or packed. The entry point allocates/copies a large internal buffer and jumps into it, which is typical loader/unpacker behavior.

Pertinent sub-files/resources in #AID=39#:

- `MANIF/1/hu-hu` #AID=39#: small manifest resource, 338 bytes.
- Carved PKCS#7 certificate blob at file offset `1011208`, size 6106 bytes #AID=39#: corresponds to the Authenticode/certificate data.

Overall, #AID=39# is assessed as **malicious or very likely malicious**, primarily due to executable unpacking behavior, RWX memory allocation, indirect execution transfer, high obfuscation, decoy/unreferenced imports, and multiple entropy/code anomalies. Confidence is medium-high because the final unpacked payload was not fully recovered during static triage.

## Key detections/IOCs

### Key detections

For #AID=39#:

- **Self-unpacking / loader-like entry point**
  - Entry point calls `VirtualAlloc` with protection `0x40` / `PAGE_EXECUTE_READWRITE`.
  - It copies a large buffer into the allocated region.
  - It jumps indirectly into the copied region at an offset around `0x396c`.
- **Heavy obfuscation**
  - Numerous functions decompile into arithmetic noise, opaque-looking state variables, and nonsensical control flow.
  - Multiple `XorInLoop` anomalies.
  - Many functions with high-value immediates and high arithmetic/binary operation counts.
- **Suspicious import table**
  - 201 unreferenced imports were reported.
  - Imports include many unrelated Windows APIs across `advapi32`, `gdi32`, `gdiplus`, `ole32`, `oleaut32`, `winmm`, `winspool`, etc.
  - This pattern is consistent with decoy imports or packed code.
- **Large medium/high entropy buffers**
  - 9 large unreferenced medium-to-high entropy buffers were detected, each roughly 21–24 KB.
- **PEB access**
  - Constant `code::PEBx86` was detected in code, often associated with manual module walking / anti-analysis / loader behavior.
- **Resource/PE anomalies**
  - Extra physical data after the resource directory.
  - Invalid initialized data size.
  - Bound imports present.

### IOCs

Network-like strings in #AID=39# appear to be certificate/CRL/OCSP infrastructure, not malware C2:

- `http://ocsp.sectigo.com`
- `https://sectigo.com/CPS`
- `http://ocsp.comodoca.com`
- `http://ocsp.usertrust.com`
- Various Sectigo/Comodo/UserTrust CRL and certificate URLs.

Certificate-related identity from #AID=39#:

- `Umbrella LLC`
- `umbrella.smolyaninov@yandex.ru`
- Certificate issuer: `Sectigo RSA Code Signing CA`
- Certificate serial: `1249aa2ada4967969b71ce63bf187c38`

No clear C2 domain, IP address, dropped file name, mutex, registry key, or command string was recovered from the visible strings.

## Evidence

### File structure and metadata

#AID=39# is a PE32 x86 executable with 3 sections:

- `.text`: RX, size around 993 KB
- `.data`: RW
- `.rsrc`: RW
- overlay containing certificate data

The executable is signed, but the signing certificate is expired. A valid or present signature does not make the file clean, especially when the code itself shows loader/packer behavior.

The certificate/PKCS#7 data was also carved from #AID=39# at offset `1011208`, size 6106 bytes.

### Entry point behavior

The entry point of #AID=39# is highly suspicious. Decompiled/disassembled code shows:

- Attempt to obtain/prepare a memory region.
- If that fails, call to:

```text
VirtualAlloc(0, [0x4f42a0], 0x1000, 0x40)
```

Where:

- `0x1000` = `MEM_COMMIT`
- `0x40` = `PAGE_EXECUTE_READWRITE`

The value at the referenced data location corresponds to a large allocation/copy size, approximately `0xFB000`.

The entry point then performs a `rep movsb` copy from an internal data region into the allocated destination and finally performs an indirect jump into the copied buffer:

```text
jmp eax
```

with the target calculated as the allocated/copied buffer plus an offset around `0x396c`.

This is characteristic of a packer/unpacker stub or shellcode-style loader.

### Obfuscation indicators

The decompiled functions in #AID=39# are dominated by operations such as:

- repeated XORs,
- arithmetic on global-looking offsets,
- opaque state assignments,
- meaningless immediate values,
- indirect control flow.

Examples include functions such as:

- `sub_402c3a` #AID=39#
- `sub_408db5` #AID=39#
- `sub_40c140` #AID=39#
- `sub_40d08f` #AID=39#
- `sub_40ae84` #AID=39#

These functions do not resemble ordinary application logic and instead look like generated/obfuscated code or virtualized unpacking logic.

Malcat anomalies supporting this include:

- `ManyHighValueImmediates`: 33 hits
- `ManyUniqueImmediateBytes`: 1 hit
- `SequentialFunction`: 40 hits
- `XorInLoop`: 20 hits
- `BigBufferNoXrefMediumToHighEntropy`: 9 hits

### Import table anomalies

#AID=39# has a large number of imports, but most are not referenced. Malcat reported:

- `UnreferencedImports`: 201 hits

The imported APIs are broad and seemingly unrelated, including UI, graphics, OLE, printing, multimedia, registry/service APIs, and memory-management APIs.

Notable referenced imports include:

- `kernel32.VirtualAlloc`
- `kernel32.VirtualProtect`
- `kernel32.GetProcAddress`
- `kernel32.LoadLibraryA`
- `kernel32.GetModuleHandleA`

This supports the hypothesis that the import table may contain decoys while the true payload is unpacked or resolved dynamically.

### PEB/module manipulation behavior

Function `sub_403788` #AID=39# references the PEB via `FS:[0x30]` style access and walks loader/module structures. The function appears to interact with module list fields and rewrite module-related pointers. This behavior is commonly seen in loaders, packers, and malware that performs manual module resolution, hiding, or anti-analysis behavior.

### Sub-files/resources

Pertinent internal files in #AID=39#:

- `MANIF/1/hu-hu` #AID=39#
  - Small manifest resource.
  - No suspicious behavior observed from the resource itself.

- Carved PKCS#7 certificate blob #AID=39#
  - Represents the Authenticode/signature material.
  - Contains certificate-related URLs and identity strings.
  - The URLs observed are certificate infrastructure, not evidence of malware C2 by themselves.

## Verdict

**Final verdict: Malicious / packed malware loader**  
**Confidence: 75%**

Rationale:

#AID=39# exhibits strong malware-like loader behavior: RWX allocation, copying a large embedded buffer, and indirect execution transfer into that buffer. This is combined with heavy obfuscation, PEB access, many unreferenced/decoy imports, entropy anomalies, XOR loops, and generated-looking arithmetic/control-flow noise.

### Counterarguments / limitations

- No YARA rule matched #AID=39#.
- Kesakode produced no verdict.
- The file is signed by `Umbrella LLC`, although the certificate is expired.
- No obvious C2, downloader URL, credential theft string, ransom note, persistence key, or dropped filename was recovered from visible strings.
- The final unpacked payload was not fully extracted during this static triage, so the precise end behavior could not be conclusively documented.
- Some commercial protectors/packers can produce similar obfuscation and loader behavior for legitimate software.

Despite these limitations, the executable memory allocation plus copy-and-jump unpacking pattern and the surrounding obfuscation are strong enough to classify #AID=39# as malicious or at minimum unsafe to execute.