Conclusion

65099f306d27c8bcdd7ba3062c012d2471812ec5e06678096394b238210f0f7c.exe is a destructive Windows native binary. The main execution path reaches routines that enumerate drives, recurse through directories, overwrite file contents with generated 16-byte data blocks at multiple offsets, delete files and directories, and then obtain SeShutdownPrivilege and force a reboot. The combination of cross-drive destructive file handling and forced system restart supports a malicious, wiper-like classification even though some code coverage remains incomplete.

Immediate safety implication: running this sample on a real Windows system risks broad file corruption and deletion across local/removable drives followed by a forced reboot.

Scope and Coverage

Examined artifact

Root artifact: /workspace/65099f306d27c8bcdd7ba3062c012d2471812ec5e06678096394b238210f0f7c.exe

File type: PE32 GUI executable, x86, 167,424 bytes

SHA-256: 65099f306d27c8bcdd7ba3062c012d2471812ec5e06678096394b238210f0f7c

Entropy: 6.44 overall

Analysis performed

File-type triage and entropy measurement

Plaintext string extraction

Static reverse engineering with bintools, including entry-point tracing and focused code review of behavior-bearing functions

Coverage limits

Bintools reported incomplete static coverage even though the artifact metadata in the project listing said coverage was complete:

98% of code-section bytes disassembled

25 unattributed code regions totaling 1,645 bytes

47 unresolved indirect branches

This gap does not weaken the positive destructive findings below, but it does mean absence-based claims are limited. In particular, I did not rely on “no C2,” “no ransom note,” or “no additional payload” as conclusions.

No dynamic execution was required to establish the destructive behavior.

Artifact Relationships and Behavioral Sequence

This is a single-file case.

Observed execution chain:

_start at 0x408256 tail-calls sub_408260

sub_408260 performs CRT/startup work and calls sub_403020

sub_403020 invokes the destructive routines, then forces reboot

Within sub_403020 (0x403020), the relevant sequence is:

sub_403a90 initializes state

sub_401f40 generates a 16-byte buffer later used for file writes

sub_402e40 performs a recursive file-processing pass

sub_402f30 performs a recursive deletion pass

The process enables SeShutdownPrivilege

ExitWindowsEx(EWX_REBOOT | EWX_FORCE, 0x20003) is called

Key Findings

1. The program explicitly enables shutdown privilege and forces a reboot

In sub_403020 (0x403020), the code:

calls OpenProcessToken(GetCurrentProcess(), 0x28, ...)

looks up SeShutdownPrivilege with LookupPrivilegeValueW

enables it via AdjustTokenPrivileges

calls ExitWindowsEx(EWX_REBOOT | EWX_FORCE, 0x20003)

This is direct code-backed evidence that the sample is designed to restart the system forcibly after its earlier actions complete.

Relevant string/data evidence:

0x424984: UTF-16 string SeShutdownPrivilege

Why this matters: forced reboot is consistent with destructive malware that wants the system to restart after file damage or cleanup activity.

2. The sample enumerates drive letters and targets fixed/removable drives

sub_402ce0 (0x402ce0) calls:

GetLogicalDrives

GetDriveTypeW

It iterates drive letters A: through Z: and only recurses into drives whose type is:

3 = fixed drive

2 = removable drive

The loop is explicitly bounded by the drive-letter range in the function body.

Why this matters: the sample is not acting on one user-selected path. It systematically expands scope to available local/removable volumes.

3. One recursive pass walks directories and corrupts files

sub_402500 (0x402500) performs recursive traversal using:

FindFirstFileW

FindNextFileW

FindClose

For non-directory entries, it calls sub_402b30 (0x402b30), which opens the file with CreateFileW for read/write and issues WriteFile calls.

File-corruption routine

In sub_402b30:

CreateFileW(..., 0xC0000000, ..., OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, ...) opens the target for read/write

SetFilePointerEx(..., FILE_BEGIN) seeks to the beginning

WriteFile writes 16 bytes from a buffer at ecx + 0x1388

if the file is larger than 16 bytes, the function calls sub_402900 to obtain additional offsets and writes the same 16-byte block at each returned offset

Relevant assembly evidence from sub_402b30:

0x402c02 / 0x402c07 / 0x402c0e: first WriteFile uses pointer ecx + 0x1388, length 0x10

0x402c55–0x402c71: repeated per-offset WriteFile loop, again length 0x10

0x402c8f / 0x402c91: loop bound check over the generated offset vector

Byte provenance for written content

The written bytes are not inferred from names; they are traceable.

In sub_401f40 (0x401f40), the program seeds PRNG-like state and stores 16 generated bytes into the same buffer later written to disk. The decisive store is:

0x402065: mov byte [esi+edi+0x1388], al

Later, sub_402b30 passes that buffer to WriteFile:

0x402c02–0x402c0e

This satisfies byte provenance: the overwritten file content comes from the generated buffer populated in sub_401f40, not from the original file or user data.

Loop bounds

The destructive loops are bounded, but still broad in impact:

drive enumeration: bounded to A:–Z: in sub_402ce0

directory traversal: bounded by filesystem enumeration (FindNextFileW until exhausted) in sub_402500

overwrite loop per file: bounded by the number of offsets returned by sub_402900, with an internal cap path that limits count per invocation

Why this matters: this is deliberate, automated file corruption at scale, not incidental file access.

4. A second recursive pass deletes files and directories

sub_402f30 (0x402f30) walks the same drive set and calls sub_402290 (0x402290).

sub_402290:

traverses directories recursively with FindFirstFileW / FindNextFileW

for directories, can clear attributes using SetFileAttributesW(FILE_ATTRIBUTE_NORMAL) before descending

calls DeleteFileW on encountered items after optional recursion

Why this matters: the sample does not stop at corrupting data. It also removes files/directories, increasing destructive impact and complicating recovery.

5. The program deliberately avoids some system and administrative paths while continuing broad destructive scope

sub_402500 contains path-substring checks against the following UTF-16 strings:

system32

windows

program files

program files(x86)

temp

recycle.bin

$recycle.bin

boot

perflogs

appdata

documents and settings

These are visible in data around 0x424800–0x424920, and the corresponding calls appear in sub_402500 assembly around 0x402726–0x402803.

Why this matters: the exclusions look like operational choices to preserve bootability or avoid some high-friction paths while still damaging many other files. That pattern is more consistent with intentionally destructive tooling than with routine administration.

6. The binary likely resolves or uses additional Windows APIs beyond its tiny visible import table

Plaintext strings include API and DLL names such as:

LoadLibraryExW

GetProcAddress

KERNEL32.dll

USER32.dll

ADVAPI32.dll

WriteFile

CreateFileW

DeleteFileW

OpenProcessToken

LookupPrivilegeValueW

AdjustTokenPrivileges

The import view exposed only IsProcessorFeaturePresent and RtlUnwind, so the sample either relies on runtime resolution, statically linked wrappers, or analysis limitations around indirect calls. Because static coverage is incomplete, I treat this as contextual support, not as a negative or positive finding by itself.

Alternative Explanations and Contrary Evidence

Strongest alternative: a legitimate cleanup or secure-deletion utility

A benign explanation would require evidence that the binary is a user-directed cleanup, shredder, or maintenance tool.

What argues against that explanation in the examined code:

traversal is broad and automatic across fixed/removable drives, not scoped to user-selected targets

the program corrupts file contents before or alongside deletion

it enables SeShutdownPrivilege and forcibly reboots the host

no examined code showed consent prompts, backup/restore logic, logging for administration, or target selection UI

excluded paths appear operational, not user-safety-oriented

I did not find positive evidence of a legitimate maintenance purpose that accounts for the observed destructive effects.

Unknowns

Additional hidden behavior: 2% of code bytes were not attributed to functions, and 47 indirect branches were unresolved. More behavior may exist in those gaps, but the existing evidence already proves malicious destructive capability.

Network/C2 or ransom logic: plaintext string extraction did not surface obvious network or ransom-note strings, but because I did not perform a dedicated deobfuscation/decryptor recovery pass and static coverage is incomplete, absence of those features is unverifiable rather than disproven.

Exact overwrite strategy details: sub_402900 clearly supplies additional write offsets for per-file corruption, but I did not fully characterize its statistical pattern because that was not necessary to establish malicious destructive behavior.

Verdict Rationale

The verdict is malicious because the sample’s reachable main path contains direct, code-backed destructive behavior:

cross-drive discovery of fixed/removable volumes (sub_402ce0)

recursive file traversal (sub_402500, sub_402290)

file corruption through repeated WriteFile calls using generated 16-byte data (sub_402b30 with provenance from sub_401f40)

file/directory deletion (sub_402290)

forced reboot after enabling shutdown privilege (sub_403020)

Those behaviors are sufficient to classify the binary as destructive malware, likely wiper-like in effect. Incomplete static coverage limits only the negative claims about what else it may or may not do; it does not undermine the positive destructive findings that drive the verdict.

A destructive Windows native binary