Malware Analysis — Part 1: The Payment Advice (That Was Also a Turkish Game)

# Table of Contents

1. Introduction
2. Initial Triage: The RAR Archive
3. Static Analysis: PE Bear
4. Decompilation: dnSpy and Assembly.Load
5. The Bitmap Trick: Pixel Extraction
6. Extracting Stage 2: Python Script
7. A Turkish Game
8. Conclusion and What's Next

# Introduction

Every now and then a sample lands in your lap that makes you go "wait, they did WHAT?". This is one of those samples.

What started as a suspicious RAR attachment turned into a multi-stage malware investigation with bitmap steganography, .NET reflection tricks, and — yes — what appears to be a fully playable Turkish video game hiding in the binary.

This is Part 1 of the series. We'll cover the initial unpacking through to the extraction of the second stage payload. Dynamic analysis and actually playing the game will come in a later post (stay tuned).

Note: All analysis was performed in an isolated environment. Don't run unknown samples on your host machine. You know this. I know you know this. I'm saying it anyway.

# Initial Triage: The RAR Archive

The sample arrived as a RAR archive. First things first — check the contents before opening anything.

Inside the archive was a single Windows executable. No DLLs, no config files, no decoys — just the one binary. Classic first stage.

At this point the goal is simple: don't execute it, don't trust it, and figure out what it actually is.

# Static Analysis: PE Bear

Dropped the executable into PE Bear for a quick look at the headers.

A few things jumped out immediately:

• Architecture: .NET PE
• Compilation timestamp: Only a few days old — freshly baked malware, not a recycled old sample
• Sections: Nothing obviously packed or encrypted at the PE level — the real magic is happening at the .NET layer

The .NET runtime dependency meant this was going to be straightforward to decompile. Time to fire up dnSpy.

# Decompilation: dnSpy and Assembly.Load

Loaded the binary into dnSpy and let it do its thing. The decompiled code came out cleanly — no significant obfuscation at the surface level.

While browsing the decompiled code, one call immediately stood out:

Assembly.Load dynamically loads a .NET assembly at runtime — a well-known technique to execute a second-stage payload without writing it to disk. The question was: where is the payload coming from?

The answer: pf.ToArray().

# The Bitmap Trick: Pixel Extraction

pf is a list object, which is then turned into an array and loaded into memory as executable code. There's a function that reads pixels from a bitmap image does some processing (obfuscated, math operations and decryption) and puts data into the pf list.

The general logic:

1. Load the embedded bitmap from resources
2. Iterate over pixels in a defined order
3. Extract specific channel byte(s) from each pixel (e.g., the blue channel, or LSB of each channel)
4. Reconstruct a byte array
5. Pass to Assembly.Load

I saved the bitmap from dnSpy's resource viewer and handed the extraction function off to AI to get a Python equivalent.

# Extracting Stage 2: Python Script

With the algorithm understood, the AI-generated Python script replicated the pixel extraction logic and wrote the recovered bytes to a file.

from PIL import Image
import math


def glacial_moraine_filter(
    glacier_face,
    trench_seal="TS-2048",
    bedrock_tier=4,
    melt_velocity=0.236,
    crevasse_dual=False,
):
    
    # The rest of the code

    return result

sr1 = Image.open("SR1.bmp").convert("RGB")

pf = glacial_moraine_filter(sr1, trench_seal="TS-2048",bedrock_tier=4,melt_velocity=0.236,crevasse_dual=False,)

with open("output.bin", "wb") as f:
    f.write(bytes(pf))

print(f"Generated {len(pf)} bytes")

The actual extraction logic matched what dnSpy showed — the script is cleaned up here for readability.

Running the script against the saved bitmap produced a new file. Checking the magic bytes:

$ file output.bin                                                                                                             
output.bin: PE32 executable for MS Windows 4.00 (DLL), Intel i386 Mono/.Net assembly, 3 sections

Another .NET assembly. Stage 2 successfully extracted.

# A Turkish Game

Here's where it gets weird (well, weirder).

While browsing the Stage 1 decompiled code, the variable names, string literals, and UI elements were... in Turkish. Not obfuscated, not encoded — just plainly written Turkish.

The code structure looked like a game loop. There were references to scores, levels, player state, and what appeared to be game logic. It looks like the malware author took an existing Turkish game or wrote one themselves, and used it as the carrier for the payload.

This is actually a clever(ish) delivery mechanism:

• The file looks and behaves like a legitimate game if run
• The malicious payload loads silently in the background via Assembly.Load
• A casual user might not notice anything wrong other than they are playing a turkish game after clicking for financial advice.

We'll find out more in the final part of this series when we throw it into a sandbox and let it run.

# Conclusion and What's Next

To recap what we found in Stage 1:

The steganography-via-bitmap approach is not new, but it's an effective way to carry a payload past simple signature-based detection — the embedded resource looks like an image and is treated as one.

Coming up in Part 2: We dig into the extracted Stage 2 assembly. What does it actually do?

Coming up in the final part: Dynamic analysis in a sandboxed environment — and yes, we play the game.

If you found this useful or have seen similar samples, feel free to reach out. Indicators of Compromise (IOCs) will be published in the final post of this series.

Disclaimer: All samples analyzed in this series were handled in an isolated environment. This writeup is for educational and research purposes only.