Environment-Aware WinINet Downloader Analysis

Date: July 23, 2026
Platform: Windows PE32 (x86)
Author: Danyal Rana

Executive Summary

This report documents the reverse engineering of a Windows PE downloader that was renamed locally for analysis. The original filename supplied by the threat actor has intentionally been omitted.

The sample functions as a reconnaissance-aware first-stage loader whose primary responsibility is to profile the victim environment before retrieving and executing a second-stage payload from a hardcoded command-and-control (C2) server.

Before any payload retrieval occurs, the malware performs several execution-gating and victim profiling steps, including execution marker creation, Active Directory enumeration, domain name inspection, public IP geolocation, and country-based execution decisions. Systems meeting the embedded selection criteria receive a second-stage payload, which is staged within the user’s temporary directory under a randomized filename, stripped of the Windows Mark-of-the-Web, and executed using resilient process creation logic.

No persistence, privilege escalation, or process injection functionality was observed within this first-stage component.

Sample Information

The binary was renamed locally during analysis for organizational purposes. The original filename has intentionally been omitted.

Overview

The malware operates as a lightweight staging component.

Rather than immediately downloading its payload, execution follows a decision tree based on environmental profiling.

Start
│
▼
Sleep (2 seconds)
│
▼
Create execution marker
%TEMP%\aefaefaefaef.txt
│
▼
Marker exists?
│
├── Yes ─────► Exit
│
▼
Active Directory Check
│
├──────────────► Hospital Domain?
│ │
│ ▼
│ Download loader_domain.exe
│
▼
Retrieve Public Geolocation
(ip-api.com/json)
│
▼
Extract countryCode
│
▼
Country Allowlist
│
▼
Download loader.exe
│
▼
Randomize filename
(%TEMP%\%d%d.exe)
│
▼
Delete Zone.Identifier
│
▼
CreateProcessW
│
▼
ShellExecuteW (fallback)

Stage One Analysis

Initial Delay

Execution begins with:

Sleep(2000);

The two-second delay is a common sandbox evasion technique intended to bypass automated environments that terminate processes immediately after launch.

Tick Count Initialization

The malware calls:

GetTickCount()

The returned value is later consumed by an internal routine responsible for pseudo-random number generation.

This value is ultimately used to generate randomized filenames for the downloaded payload.

Active Directory Detection

One of the first significant routines is responsible for determining whether the victim belongs to an Active Directory environment.

The malware invokes:

NetGetJoinInformation()

The returned status is compared against:

NetSetupDomainName

which corresponds to a machine joined to an Active Directory domain.

Pseudo-code:

NETSETUP_JOIN_STATUS status;

NetGetJoinInformation(NULL, &DomainName, &status);

if (status == NetSetupDomainName)
{
    ...
}

Hospital Domain Identification

If the system belongs to an Active Directory domain, the malware performs an additional inspection.

It searches the domain name for the substrings:

hos
HOS

using an internal string comparison routine.

Conceptually:

if (contains(DomainName, "hos") ||
    contains(DomainName, "HOS"))
{
    Download(loader_domain.exe);
}

The presence of these specific strings strongly suggests the malware was designed to identify hospital environments.

Instead of delivering the standard payload, systems matching this profile receive an alternate executable:

http://178.16.54.109/loader_domain.exe

This behaviour indicates deliberate payload differentiation based on victim type rather than simple domain membership.

Public Geolocation

If the hospital-specific branch is not triggered, execution continues by querying an external geolocation service.

Hardcoded URL:

http://ip-api.com/json/

The malware performs an HTTP request using WinINet APIs.

Subsequently it extracts the JSON field:

countryCode

Example server response:

{
    "countryCode": "PK"
}

Country Filtering

The extracted country code is compared against a hardcoded list embedded inside the executable.

Observed country codes include:

LU
CH
NO
IE
IS
QA
SG
US
DK
AU
SE
NL
AT
SM
HK
KR
BN
DE
KW
MO

Each comparison branches into the downloader routine depending upon the comparison result.

Although the exact intent requires runtime confirmation, the malware clearly makes execution decisions based upon geographic location.

This demonstrates a level of victim profiling absent from many commodity downloaders.

Downloader Routine

Interestingly, this User-Agent is used exclusively by the payload downloader. A separate HTTP routine used for geolocation requests identifies itself simply as "MyAgent", indicating that the malware implements two distinct HTTP communication routines.

Temporary Directory Resolution

The malware expands:

%TEMP%

using:

ExpandEnvironmentStringsW()

This resolves to the user’s temporary directory.

Random Filename Generation

Rather than using a fixed filename, the malware generates a randomized executable name.

Format string:

%s\%d%d.exe

Example:

C:\Users\User\AppData\Local\Temp\381521004.exe

Randomization reduces simple filename-based detections.

User-Agent Spoofing

The malware initializes WinINet using the following User-Agent string:

Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36
(KHTML, like Gecko)
Chrome/7775543322.0.0.0
Safari/537.36

Although the Chrome version is clearly fictitious, many web servers perform only superficial validation, making the spoof sufficient for blending with normal browser traffic.

HTTP Download

Networking relies exclusively upon WinINet.

Observed API sequence:

InternetOpenW()

↓

InternetOpenUrlW()

↓

InternetReadFile()

↓

WriteFile()

The payload is downloaded incrementally until EOF.

File Creation

Downloaded data is written using:

CreateFileW()

↓

WriteFile()

No in-memory execution was observed.

The payload is written directly to disk before execution.

Mark-of-the-Web Removal

After successfully downloading the payload, the malware deletes:

<filename>:Zone.Identifier

using:

DeleteFileW()

This removes the NTFS alternate data stream responsible for Windows’ Mark-of-the-Web.

Removing this metadata helps suppress several Windows security prompts, including SmartScreen warnings that would otherwise indicate the executable originated from the Internet.

This is a relatively clean operational security technique that demonstrates awareness of modern Windows protections.

Payload Execution

Once the payload has been successfully written to disk, execution is transferred to an internal launcher routine.

The launcher first attempts to execute the downloaded file using CreateProcessW().

If process creation fails, the malware falls back to ShellExecuteW() using the "open" verb.

Both successful execution paths introduce a one-second delay before returning to the caller.

This dual-launch strategy increases execution reliability across different Windows configurations while avoiding more complex process injection techniques.

Imported APIs of Interest

Networking

InternetOpenA
InternetOpenW
InternetOpenUrlA
InternetOpenUrlW
InternetReadFile
InternetCloseHandle

Filesystem

CreateFileA
CreateFileW
WriteFile
ReadFile
DeleteFileW
ExpandEnvironmentStringsW

Process Execution

CreateProcessW
ShellExecuteW

Environment Profiling

NetGetJoinInformation
NetApiBufferFree
PathFileExistsW

Anti-Debugging

IsDebuggerPresent
SetUnhandledExceptionFilter
UnhandledExceptionFilter

These checks are relatively lightweight and do not represent advanced anti-analysis techniques.

Execution Marker

Before performing any network communication, the malware expands the %TEMP% environment variable and constructs the following path:

%TEMP%\aefaefaefaef.txt

The malware checks whether this file already exists using PathFileExistsW().

If the marker file is present, execution terminates immediately.

Otherwise, the malware creates an empty file using CreateFileW() before continuing with victim profiling.

This behaviour acts as a simple execution marker, preventing repeated execution on the same host while avoiding more traditional mutex-based techniques.

Observations

The first-stage loader exhibits several notable behaviours:

• Active Directory awareness

• Hospital-specific payload selection

• Public IP geolocation profiling

• Country-aware execution logic

• Randomized payload naming

• Browser User-Agent spoofing

• Mark-of-the-Web removal

• Plain HTTP second-stage retrieval

Interestingly, despite its environmental awareness, the malware lacks several capabilities commonly associated with more advanced loaders.

No evidence was found for:

• Process injection

• DLL injection

• APC injection

• Scheduled task creation

• Service installation

• Registry persistence

• WMI persistence

• Reflective loading

Its primary purpose appears to be staging and delivering a more capable second-stage payload.

Indicators of Compromise (IOCs)

SHA-256

336b57387bf7f74d2b707d2908e21c26fe75a7acc0d0471ba73fc606a6f6a777

MD5

2e8485c56f8045122064cc3cd30679b9

URLs

http://178.16.54.109/loader.exe
http://178.16.54.109/loader_domain.exe
http://178.16.54.109/lb1.exe
...
http://178.16.54.109/lb20.exe

http://ip-api.com/json/

Strings of Interest

Teams.exe
Slack.exe
Zoom.exe
sapgui.exe
PBIDesktop.exe
tableau.exe

These application names likely support additional environment profiling within code paths that warrant further investigation.

Conclusion

This malware is best classified as an environment-aware first-stage downloader.

Rather than indiscriminately delivering a payload, it actively profiles the victim by evaluating Active Directory membership, inspecting domain naming conventions, querying external geolocation services, and applying country-based execution logic before retrieving a second-stage executable.

Particularly noteworthy is its apparent targeting of hospital-related environments through domain string matching, suggesting that different payloads may be deployed depending on the victim’s organizational context.

Although technically straightforward, the sample demonstrates a thoughtful operational design. By combining victim profiling, randomized staging, browser impersonation, and Mark-of-the-Web removal, the authors reduce unnecessary exposure while increasing the likelihood that subsequent payloads execute successfully.

The analyzed executable should therefore be viewed not as the primary malware, but as a selective delivery mechanism whose real capabilities reside within the second-stage payloads it retrieves.

Dynamic Analysis

Dynamic execution corroborated the reconstructed first-stage execution flow. The sample first issued an HTTP GET request to ip-api.com/json/ using the MyAgent user agent to retrieve geolocation information. Following receipt of the JSON response, it attempted to download loader.exe from 178.16.54.109 using a separate Chrome-based user agent (Mozilla/5.0 ... Chrome/7775543322.0.0.0). The request returned HTTP 404 Not Found, preventing retrieval and execution of the second-stage payload. Throughout execution, no network activity involving loader_domain.exe, OUTLOOKFOUND, or the embedded lb1.exe–lb20.exe resources was observed, supporting the static analysis that these artifacts were not exercised under the observed execution path.