unattributed: 134a00b7 — Truncated Go PE64+ x64 (262 KB of claimed 2.4 MB image)

Executive Summary

A Go-compiled PE64+ x64 GUI executable arriving truncated: 261,834 bytes on disk presenting a 2.4 MB PE header (7 sections, SizeOfImage=0x258000). Only the DOS/NT headers and the first ~260 KB of .text survived; .rdata, .data, .idata, .reloc, .symtab, and .rsrc are entirely absent. The upstream MalwareBazaar source serves the same 262 KB, confirming source-side corruption. This is the second confirmed sibling (138b53c5 being the first) of a structural pattern: truncated Go PE64+ binaries with identical section layouts but different build IDs and truncation depths. No family attribution, no payload extraction, and no behavioural characterisation possible from the surviving stub.

What It Is

• File: SecuriteInfo.com.Trojan.GenericKDZ.117992.5647.11801 (MalwareBazaar naming) ^[metadata.json]
• SHA-256: 134a00b7f369a8945c928c6956750dca49230d5fa384ff94403ab176e84fd061
• Type: PE32+ executable (GUI) x86-64, 7 sections ^[file.txt]
• Size: 261,834 bytes on disk ^[metadata.json]
• Claimed image size: 2,457,600 bytes (SizeOfImage=0x258000) ^[pefile.txt:100]
• Build ID: lbdBnnyBahB8NB14vyKX/SfPqRAAFe2DICx9s4L-B/I29dyJ_gSnleVnfGA_2i/GI9T5NiJhyV_MslTqwpB ^[strings.txt:8]
• Toolchain: Go gc (implied by Go build ID string and .symtab section name); GOARCH=amd64, GOOS=windows ^[strings.txt:8] ^[pefile.txt]
• Subsystem: Windows GUI (0x2) ^[pefile.txt:104]
• PE timestamp: Null (0x0, 1970-01-01) ^[pefile.txt:72]
• Stripped: Yes (IMAGE_FILE_DEBUG_STRIPPED) ^[pefile.txt:77]
• ASLR / NX: Enabled (DYNAMIC_BASE, HIGH_ENTROPY_VA, NX_COMPAT) ^[pefile.txt:111]
• Signed: No (security directory at 0x1FD000 points past EOF) ^[rabin2-info.txt:34]
• Family: unattributed (truncated singleton; second confirmed instance of this pattern after 138b53c5) ^[triage.json]

Section Layout (truncated reality vs. header claims)

^[pefile.txt:115-253]

Every section after .text has PointerToRawData beyond the 261 KB file boundary. Even .text claims SizeOfRawData=0x89000 (561,152 bytes) starting at 0x600, which would extend to 0x89600 — well past EOF. pefile reports: "Error parsing section N. SizeOfRawData is larger than file" and "AddressOfEntryPoint lies outside the file." ^[pefile.txt:1-36]

The Go build ID at offset 0x600 confirms .text begins there and contains Go runtime code. ^[strings.txt:8]

How It Works

The binary cannot run. The entry point (0x5E380) falls inside .text, which is partially present (the first ~260 KB), but .rdata — containing Go string tables, type descriptors, import stubs, and read-only data — is entirely missing. Execution would fault immediately on the first data access.

Re-fetching the sample directly from MalwareBazaar via mb-fetch.py returned the same 261,834 bytes, confirming upstream corruption. ^[triage.json]

Inferable from the surviving ~260 KB stub:

• Go runtime version: The build ID format matches Go 1.18+ (four-slash build ID). The specific build ID differs from 138b53c5, confirming a distinct compilation. ^[strings.txt:8]
• No static strings: No C2 URLs, mutex names, file paths, or registry keys survived in the 114 extracted strings. ^[strings.txt]
• No imports: The import directory RVA (0x21E000) points into the missing .idata section. Zero imports recoverable statically. ^[rabin2-info.txt:1-6]
• No capa / floss results: capa errored (missing signatures directory); floss received incorrect CLI arguments during triage. Re-running would not change the outcome because the file is truncated. ^[capa.txt] ^[floss.txt]

Decompiled Behavior

radare2 analysis (level 2) found 11 functions in the .text stub: ^[r2:function-list]

No import table means all API calls would be resolved via Go syscall package or raw asm inline stubs — standard for CGO_ENABLED=0 Go binaries. No main.main or other user-defined Go functions are visible in the surviving stub; they would reside deeper in .text or in the missing .rdata/.data sections.

The disassembly at 0x00401000 shows standard Go runtime prologue code with stack canary checks. No anti-debug or anti-VM artefacts are present in the surviving stub.

C2 Infrastructure

None recoverable. The .rdata section — where Go binaries store read-only string tables, including any hardcoded C2 URLs — is entirely absent. No network IOCs in strings.txt. No CAPE detonation. ^[strings.txt] ^[dynamic-analysis.md]

Interesting Tidbits

• Clean truncation. The file ends at offset 0x3FF2A (261,834 bytes), mid-instruction inside .text. The final bytes (10 48 8b 4c 24 20 48 8b 54 24) are valid x86-64 instruction stream (MOV RDX, [RSP+0x20]; MOV RDX, [RSP+...]), not padding. This is consistent with an interrupted network download. ^[hexdump]
• MalwareBazaar serves the truncated copy. Re-fetch via mb-fetch.py on 2026-08-25 returned identical SHA-256 and size. The corruption is upstream. ^[mb-fetch verification]
• Sister sample 138b53c5 has identical section layout — same SizeOfImage, same AddressOfEntryPoint, same section count and names, same VirtualAddresses and VirtualSizes. Only the build ID, the .text content hash, and the truncation depth differ. This suggests both samples were uploaded to MalwareBazaar through the same pipeline or by the same uploader, and both suffered the same truncation event. ^[pefile.txt comparison with 138b53c5]
• Null PE timestamp is standard for Go binaries built with -trimpath or via go build without explicit linker timestamp flags. ^[pefile.txt:72]
• Seven-section layout (.text, .rdata, .data, .idata, .reloc, .symtab, .rsrc) is the canonical Go PE layout on Windows amd64. ^[pefile.txt]
• Generic AV naming. The MalwareBazaar filename (SecuriteInfo.com.Trojan.GenericKDZ...) is an auto-generated SecuriteInfo label, not a meaningful family name. ^[metadata.json]

How To Mess With It (Homelab Replication)

Because the file is truncated, replication focuses on recognising the pattern and recovering Go binaries from partial data:

1. Recognise truncated Go PEs: Check if SizeOfImage >> actual file size. pefile will emit SizeOfRawData is larger than file for every section beyond the truncation point. Go binaries are especially susceptible to truncation during download because their .rdata section is typically the largest (hundreds of KB to MB+).

2. Verify upstream integrity: Re-fetch from MalwareBazaar (mb-fetch.py <sha256>). If the size matches, the truncation is source-side.

3. Extract the Go build ID: Even from a truncated binary, the build ID at offset 0x600 (start of .text) can identify the Go version and module path hash. Use go version -m <file> on a complete binary, or grep for Go build ID: on a partial one.

4. Cluster by section layout. When multiple truncated samples share identical SizeOfImage, AddressOfEntryPoint, section names, and VirtualAddress/VirtualSize tuples but differ in build ID and truncation depth, they likely came from the same upload pipeline or suffered the same ingestion fault.

5. What you learn: How to distinguish a corrupted sample from a deliberately minimal stub. In threat-intel pipelines, truncated samples should be flagged for re-ingestion rather than deep analysis.

Deployable Signatures

YARA Rule — Truncated Go PE64 Detection

rule truncated_go_pe64
{
    meta:
        description = "Detects truncated Go PE64+ binaries where SizeOfImage vastly exceeds file size"
        author = "triage"
        date = "2026-08-25"
        sha256 = "134a00b7f369a8945c928c6956750dca49230d5fa384ff94403ab176e84fd061"
    strings:
        $go_build_id = "Go build ID: \"" ascii
        $mz = { 4D 5A }
        $pe = { 50 45 00 00 }
    condition:
        $mz at 0 and
        $pe at uint32(0x3C) and
        $go_build_id and
        // File size < 300 KB but SizeOfImage > 1 MB
        filesize < 300000 and
        uint32(uint32(0x3C) + 0x50) > 0x100000
}

Behavioral Fingerprint Statement

This binary is a truncated Go PE64+ x64 GUI executable. On a complete copy, it would exhibit standard Go runtime behaviour: self-contained single binary with no external C runtime dependencies, CGO_ENABLED=0 syscall-based API resolution, and a large .rdata section containing string tables and type descriptors. In its current truncated state it is non-executable — the entry point references memory in the missing .rdata section, causing an immediate access violation. No C2, persistence, or payload behaviour can be inferred from the surviving 260 KB stub. The identical section layout to sample 138b53c5 suggests a common upload pipeline or ingestion fault.

IOC List

Detection Signatures

No capa results (errored). No dynamic analysis. No behavioural signatures.

Static heuristics for truncated Go PEs:

• File size < 300 KB AND Go build ID: string present AND SizeOfImage > 1 MB → high-confidence truncated Go binary.
• pefile emits "SizeOfRawData is larger than file" for multiple sections → structural truncation.
• Null PE timestamp + stripped debug info + GOARCH=amd64 build ID → Go compiler fingerprint.
• Identical section VirtualAddress/VirtualSize tuples across multiple samples with different build IDs → common upload pipeline or ingestion fault.

References

• MalwareBazaar entry: SecuriteInfo.com.Trojan.GenericKDZ.117992.5647.11801 (sha256: 134a00b7...)
• unattributed — umbrella entity for singletons and low-confidence samples
• golang-stealer-build-pattern — concept page for Go malware build artefacts
• Sister analysis: /intel/analyses/138b53c57ec807db6c5a9d5b2930d0909cf34b27b4ad8b72f5d74801fdc6c1cb.html

Provenance

Artifacts generated from:

• file (file type)
• exiftool (PE metadata)
• pefile / pefile.py (section headers, structural warnings)
• rabin2 (radare2 binary info, function list, string extraction)
• strings (ASCII string extraction)
• binwalk (embedded artefact scan — found nothing beyond PE header)
• MalwareBazaar re-fetch via mb-fetch.py (2026-08-25) confirming upstream truncation
• CAPE sandbox: skipped (no Windows guest)
• capa: errored (missing signatures directory)
• floss: errored (incorrect CLI arguments during triage)
• radare2 analysis level 2 (11 functions identified in stub)