I Set Up a Fake Internet to Catch a Trojan: Analyzing FlexenseActivator.exe

There's a malware trick I'd read about but never witnessed firsthand: a trojan that checks whether it's connected to the real internet before doing anything malicious. If it detects a sandbox — no internet, wrong hardware, a debugger slowing it down — it goes quiet.

So for a graduate malware analysis project, I decided to give it a real internet. A fake one.

This is a walkthrough of how I analyzed FlexenseActivator.exe — a trojan disguised as a software activation tool — inside a fully isolated two-VM lab. I'll explain what the malware does, how I caught it doing it, and what any of this means for defenders.

⚠️ Safety note: All analysis was conducted in isolated virtual machines with no internet access. A REMnux VM intercepted all network traffic. Nothing ran on a production system.

The Sample

File:    FlexenseActivator.exe
SHA-256: 18676ae2eaa48ac6037fa239d282acca0b6c7cd6c7d384abe6b5cd379f2c5e50
Family:  Trojan.Win32.Tiggre / Zpevdo
Packed:  UPX v0.89.6 (Delphi stub)
Score:   100/100 (Hybrid Analysis) | 33/76 AV vendors (VirusTotal)

This file is distributed inside pirated RAR and ZIP archives for Flexense disk management software — SysGauge, Disk Pulse Pro, Disk Savvy. Users download what they think is a crack tool. VirusTotal shows 151 tracked execution parent archives, all pirated Flexense software bundles. The infection vector is straightforward: software piracy.

The Lab Setup

Before touching the sample, I built an isolated environment:

┌─────────────────────────────────────┐
│         Host Machine                │
│  ┌─────────────┐  ┌──────────────┐  │
│  │ Windows 10  │  │   REMnux     │  │
│  │ Analysis VM │←→│ Gateway VM   │  │
│  │  (AV off)   │  │ INetSim 1.3.2│  │
│  │             │  │ FakeDNS      │  │
│  └─────────────┘  └──────────────┘  │
│     192.168.56.20   192.168.56.10   │
│         Host-only network only      │
└─────────────────────────────────────┘

INetSim simulates HTTP, HTTPS, and DNS services on the REMnux VM. FakeDNS redirects every DNS query the Windows VM makes to INetSim. So when the malware asks "am I connected to the internet?" — INetSim answers yes.

This matters because many modern trojans check for connectivity before acting. On a disconnected analysis machine, they stay dormant. You see nothing.

Phase 1: Static Analysis — What Is This Thing?

Before executing anything, I loaded the file into PEStudio.

The first number that caught my attention: entropy 7.916.

Entropy measures byte randomness on a scale from 0 to 8. Normal executables land between 5 and 7. Packed or encrypted content pushes above 7.5. At 7.916, this binary is almost maximally random — direct evidence of a packer.

PEStudio confirmed: UPX v0.89.6 (Delphi stub). The actual malicious code is compressed inside and only appears in memory at runtime.

The PE sections told the same story:

UPX0 has zero raw size but 790KB virtual size. That's the decompression target — empty on disk, filled at runtime.

One more detail: the binary's compiler timestamp is 2019, but the resource section timestamp is 2011. The icons and cursors were borrowed from an older Delphi project. This is a common fingerprint — malware authors recycle legitimate application templates to make binaries look more credible.

VirusTotal cross-check: 33/76 vendors detected it. The 43 who missed it are exactly why packing works.

Phase 2: Dynamic Analysis — Watching It Run

With Process Hacker open, I launched the sample.

It immediately appeared highlighted in pink — Process Hacker's color for suspicious processes. Windows Security fired a threat notification even with Defender mostly disabled. The process lived for a few seconds, did its work, and terminated. It doesn't stay resident. It sets things up and leaves.

Process Monitor captured everything during that window. Within the first second: 6 threads created simultaneously. UPX-packed malware often launches parallel threads — one to decompress, one to inject, one to handle network.

The GoogleUpdater Disguise

The most sophisticated behavior: the malware drops a complete fake GoogleUpdater installation:

C:\Program Files (x86)\Google\GoogleUpdater\136.0.7079.0\
    ├── updater.exe
    ├── Crashpad\
    │   └── attachments\
    └── uninstall.cmd

C:\Program Files (x86)\Google\GoogleUpdater\137.0.7129.0\
    └── (same structure)

Two versions — 136 and 137 — dropped simultaneously. This is a persistence mechanism designed to survive removal attempts. If you delete one version, the other reinstates it.

Legitimate Google Update has one version directory. Multiple numbered Google1184, Google2872, Google2972 directories in Program Files are a strong indicator of compromise.

Process Injection × 5

The malware then injected its code into five separate GoogleUpdater processes — each launched with --update --system --enable-logging flags that mimic the real Google Update service signature.

It also injected into WMIADAP.EXE (WMI Activity Performance Data).

After injection: the malware terminated all the injected processes, plus svchost (WerSvcGroup) and wmiadap. It cleaned up its injection targets. Its code was already running inside Windows processes — it no longer needed the hosts.

Phase 3: Catching the Fake Internet Call

This is where INetSim paid off.

Once the malware confirmed it was in a (seemingly) live environment, it made an HTTP GET request:

GET /ncsi.txt HTTP/1.1
Host: www.msftncsi.com
User-Agent: Microsoft NCSI

NCSI is Microsoft's Network Connectivity Status Indicator — the system Windows uses to show the internet icon in your taskbar. By querying this URL and getting a 200 OK response, the malware confirms internet access before proceeding with any C2 activity.

INetSim's log:

[http_80_tcp] recv: GET /ncsi.txt HTTP/1.1
[http_80_tcp] info: Sending fake file configured for extension 'txt'
[http_80_tcp] send: HTTP/1.1 200 OK

FakeDNS showed the full domain redirect chain:

fakedns[INFO]: update.googleapis.com  -> 192.168.56.10
fakedns[INFO]: ctldl.windowsupdate.com -> 192.168.56.10
fakedns[INFO]: www.msftncsi.com       -> 192.168.56.10

Wireshark then captured TCP/443 connections to Microsoft CDN IPs — the malware was doing SSL certificate chain verification before attempting any real C2 communication. It checks the TLS infrastructure is legitimate before exposing itself.

In a real analysis sandbox without INetSim, all of this either fails silently or never triggers. The malware would appear to do nothing malicious.

Phase 4: A Look Inside with IDA Pro

The final step: loading the binary into IDA Pro to see the UPX decompressor stub's assembly.

The entry point at 0x512130 matched what both PEStudio and Hybrid Analysis reported — consistent across all tools, which is a good sign your analysis is clean.

The opening instructions are textbook UPX 3.x:

start:
    pusha                               ; save all registers
    mov  esi, offset dword_4C2EE0       ; point to compressed data
    lea  edi, [esi - 0xC1EEEh]         ; destination: UPX0 section
    mov  dword ptr [edi+0xD09F4h], 592F7785h  ; write decompression seed
    push edi
    xor  ebp, 0FFFFFFFFh               ; init CRC counter
    jmp  loc_51215A                     ; enter decompression loop

A full reverse engineering of the unpacked payload is the next step — that requires letting the process reach its OEP (Original Entry Point) in a debugger, then dumping memory. That's for the next analysis round.

MITRE ATT&CK Summary

What Defenders Should Watch For

If you run a SOC or manage endpoints:

• Multiple GoogleUpdater version directories in Program Files (x86)\Google\ — legitimate installs have one
• GoogleUpdater processes launched with unusual session IDs or --enable-logging on non-Google machines
• NCSI queries repeated at intervals — legitimate Windows checks this occasionally; malware polls it repeatedly
• Unsigned executables in %TEMP% re-executing themselves
• Entropy > 7.5 in scanned files — flag for manual review

The SHA-256 hash is your most reliable IOC: 18676ae2eaa48ac6037fa239d282acca0b6c7cd6c7d384abe6b5cd379f2c5e50

What I Learned

Setting up INetSim and FakeDNS taught me something I couldn't learn from just reading: malware is network-aware by design. Modern trojans don't just run — they check their environment, verify connectivity, validate TLS infrastructure, and only then proceed. A naïve sandbox catches none of this.

The NCSI check was the most elegant evasion technique I encountered. It's not suspicious on its own — Windows does it constantly. But watching a trojan use it as a readiness gate was a clear demonstration of how blending into normal system behavior is itself a form of defense evasion.

Full Technical Report + IOCs

Complete report with PEStudio output, Wireshark captures, IDA Pro screenshots, full IOC list, and ATT&CK mapping:

🔗 https://github.com/MalwareAnalysisLabs/malware-analysis-writeups

What's Next

• Unpack the binary dynamically in x32dbg, dump memory at OEP
• Reverse engineer the unpacked payload's main function
• Attempt to decode the XOR-obfuscated config strings (2,/+0&7!4-)1# etc.)
• Compare Tiggre family behavior across different campaign variants

What tools or techniques have you used for packed binary analysis? Drop a comment — I'm particularly curious about approaches to Delphi-compiled malware.