Overview

I analyzed a suspicious Windows executable in an isolated VM. I first ran it offline to observe local behavior, then re-ran it with FakeNet to simulate network connectivity. The offline run completed and showed environment checks. The FakeNet run resulted in a blue screen before any network activity was captured. The behavior points to a loader or stager that checks conditions before attempting payload delivery. It did not reach that stage during this analysis.

Sample Info

Quick note: the filename is the SHA256 hash, a common convention for unambiguous sample identification. For the purposes of this analysis, I've renamed it to sample.exe

What Happened

The Two Phase Approach

I ran the sample in two stages:

• Offline first, with no network connectivity, to observe local behavior
• Then with FakeNet, to simulate network services and observe outbound behavior

The offline run completed without a crash. The FakeNet run ended in a system bugcheck before any network activity was recorded.

Process Behavior (Offline)

When you run a program in Windows, there is a parent child relationship. If you double click something in Explorer, Explorer is the parent and the program is the child. This can often be examined for anomalies.

Observed process behavior:

• Explorer spawned my sample.exe
• The sample launched winver.exe and taskmgr.exe
• The sample relaunched itself under taskmgr.exe

The malware made itself look like it was launched by Task Manager instead of Explorer, which makes it harder to spot in process monitoring tools. I couldn't figure out exactly how it pulled this off, just that it did.

Registry Queries (Offline)

The sample queried the registry for:

• Safe Mode state and system setup indicators
• Software Restriction Policies and AppLocker configuration
• Image File Execution Options (IFEO)
• AppCompat shim infrastructure
• Filesystem redirection settings
• User and system identity information

These registry checks suggest the malware is profiling the environment before deciding whether to continue execution.

File Activity (Offline)

After execution, the original executable was no longer present in its launch directory. I could not capture the delete operation in Procmon, so the removal mechanism is unconfirmed.

DLLs and API Calls (Offline)

The sample loaded standard Windows DLLs: ntdll.dll, kernel32.dll, KernelBase.dll, advapi32.dll, user32.dll. The malware didn't try to hide code in memory or intercept system calls.

Then It Crashed With FakeNet Enabled

During the FakeNet run, the VM hit a blue screen:

• BugCheck Code: 0x000000EF (CRITICAL_PROCESS_DIED)

This crash happens when a critical Windows process gets terminated unexpectedly. Since the malware didn't load any kernel drivers, it was operating in user-mode meaning it likely tried to manipulate or kill a protected process and Windows shut everything down in response. I wasn't able to confirm exactly which process or action caused it.

What I Didn't See

• No captured network traffic (the system crashed before any requests were recorded)
• No second stage payload
• No persistence (registry run keys, scheduled tasks, services)
• No credential or browser data access
• No file encryption or exfiltration

Since I didn't see it steal data, encrypt files, or do anything obviously malicious, I can't say what this malware was actually supposed to do.

What I Think This Is

Based on the environment checks and lack of observed payload delivery, this appears to be a loader or stager. It likely performs checks and then retrieves a second stage if conditions are met. In this analysis, it did not progress past those checks before crashing.

What I Couldn't Figure Out

• How it deleted itself (Procmon did not capture the delete operation)
• What it attempted to connect to (no network requests were logged)
• What the payload would have been (no download occurred)
• The exact crash cause (would require deeper debugging and additional VM rebuilds)

The Takeaway

This looks like loader or stager behavior—it checks the environment before doing anything else. The crash only happened when I gave it network access, which points to something going wrong in its network code. I never saw a payload get delivered, so I can't say what it was supposed to drop.