Trojan

Scenario

You will be given a set of artefacts relating to a workstation that has been compromised by a malware Trojan. You need to analyse the different pieces of evidence to extract IOCs and reconstruct the phases of the infection.

Executive Summary

A user on a Windows 10 workstation downloaded a ZIP archive from a free-hosting WordPress site, advertised as a data-recovery tool. They unpacked it and ran the installer inside, which was a trojanised setup executable posing as a commercial recovery product. The sample left a Prefetch and Amcache trail on disk, was still resident in the memory capture, and reached out to several PHP endpoints on a single IP address. One of those endpoints returned a roughly 95 KB binary, a second-stage payload. VirusTotal flagged four of the contacted URLs as malicious, and strings in the process memory exposed the real product name and version the malware copies.

Artifacts

• memory.vmem / memory.vmsn: VMware memory snapshot of the workstation → vol (Volatility 3)
• disk_artifacts.ad1: AccessData logical image holding the user profile, Prefetch and Amcache → mount in FTK Imager, or extract the zlib chunks with a script if no AD1 reader is available
• network.pcapng: capture of the workstation’s traffic → tshark or Wireshark

Timestamp note: Q8 needs YYYY-MM-DD hh:mm:ss in UTC. PECmd lists the last run times in UTC; the first run is the oldest of them.

Discovery

windows.info reads the kernel debugger block from the memory image. The Major/Minor line carries the build as its second half.

vol -f memory.vmem windows.info

Process environment blocks carry COMPUTERNAME, so dumping environment variables from any process gives the hostname without touching the registry hive.

vol -f memory.vmem windows.envars | grep COMPUTERNAME

Initial Access

Carve file objects from memory and filter for archives; the download sits in the user’s profile. The pcap confirms it as a GET under a WordPress wp-content/uploads path, so memory and network agree on the name.

vol -f memory.vmem windows.filescan | grep -i '\.zip'

tshark -r network.pcapng -Y 'http.request.uri contains ".zip"' -T fields -e http.host -e http.request.uri

The Host header of the Q3 request names the site. A free-hosting subdomain serving a WordPress uploads path for a “recovery tool” is the lure’s delivery point.

tshark -r network.pcapng -Y http.request -T fields -e http.host -e http.request.uri

Execution

List processes and look for the installer extracted from the archive. It is the only entry not tied to a Windows component or the browser.

vol -f memory.vmem windows.pslist | grep -i recovery

The command line of the Q5 process holds the image path in full. It shows the archive was extracted into a Data_Recovery folder under the user’s Downloads before being run.

vol -f memory.vmem windows.cmdline --pid 484

The executable is on the AD1 image under the Q6 path. The image had no ready reader here, so the zlib chunks were extracted with a small script into work/disk, then the file hashed directly.

sha256sum work/disk/Users/John/Downloads/Data_Recovery/Recovery_Setup.exe

Parse the RECOVERY_SETUP.EXE-*.pf Prefetch file. Prefetch keeps the last eight run times, and the oldest is the first execution. AmcacheParser on the same image gives a matching entry for the binary.

PECmd -f RECOVERY_SETUP.EXE-*.pf --csv work/pecmd

AmcacheParser -f Amcache.hve --csv work/amcache

The same Prefetch parse reports a RunCount for the executable.

PECmd -f RECOVERY_SETUP.EXE-*.pf

Gotcha: Recovery_Setup.exe is an installer that spawns its own helper processes, so related Prefetch entries can look like extra runs. Read the count on the entry for RECOVERY_SETUP.EXE itself.

Prefetch also records the files the program touched in its first ten seconds. Filter that list for .TMP; the installer’s two temp files are named in the IS- pattern used by InstallShield-style setup stubs.

PECmd -f RECOVERY_SETUP.EXE-*.pf | grep -i '\.TMP'

Command and Control

Look up the Q7 hash on VirusTotal and open the Relations tab, Contacted URLs. Four PHP endpoints (puk.php, dll.php, stuk.php, plus.php) score 12 to 13 detections each. The remaining four contacted URLs are certificate-related and score zero, so they do not count.

bin/vt c34601c5da3501f6ee0efce18de7e6145153ecfac2ce2019ec52e1535a4b3193 --rel contacted_urls

List the HTTP requests that follow the Q8 execution time and check each C2 response. Only one is a large binary: a 95248-byte application/octet-stream response from /default/puk.php on the C2 IP. The response carries no filename header, so this answer is reasoned from the one binary-sized octet-stream body among the VirusTotal-flagged endpoints, not read from a Content-Disposition value.

tshark -r network.pcapng -Y 'http.response' -T fields -e ip.src -e http.content_type -e http.content_length -e http.response_for.uri

Defense Evasion

Strings from the memory image show the legitimate product’s Readme banner, which the trojan reuses. A loose case-insensitive match on the product name finds the banner with its version.

strings -a memory.vmem | grep -i finalrecovery

Tip: The first exact-version grep returns nothing. Search on the product name alone and read the banner lines around it.

Attack Summary

Phase	Action
Initial Access	User downloads Data_Recovery.zip from a free-hosting WordPress site
Execution	Archive extracted to Downloads; Recovery_Setup.exe run (PID 484)
Defense Evasion	Installer masquerades as FinalRecovery, a legitimate recovery tool
Command and Control	Sample contacts PHP endpoints on one external IP
Command and Control	puk.php returns a ~95 KB binary second stage

IOCs

Type	Value
Domain	praetorial-gears[.]000webhostapp[.]com
File	Data_Recovery.zip
Path	C:\Users\John\Downloads\Data_Recovery\Recovery_Setup.exe
SHA-256	c34601c5da3501f6ee0efce18de7e6145153ecfac2ce2019ec52e1535a4b3193
IP	45.12.253[.]72
URL path	/default/puk.php
Temp files	IS-NJBAT.TMP, IS-R7RFP.TMP

MITRE ATT&CK

Technique	ID	Description
Drive-by Compromise	T1189	ZIP fetched from a compromised or abused WordPress site
User Execution: Malicious File	T1204.002	User ran the installer from the extracted archive
Masquerading: Match Legitimate Name or Location	T1036.005	Installer posing as FinalRecovery
Ingress Tool Transfer	T1105	Binary pulled from puk.php
Application Layer Protocol: Web Protocols	T1071.001	HTTP requests to PHP C2 endpoints

Defender Takeaways

Free-hosting subdomains serving executables deserve a block or a prompt. The lure came from a 000webhostapp.com subdomain, a platform heavily abused for malware hosting. Web proxy rules that flag or sandbox archive downloads from free-hosting domains would have caught it before the user opened anything.

Memory plus Prefetch gives a complete execution picture. The PID and full path came from memory, while the first-run time, run count and touched files came from Prefetch. Collecting both on triage covers the case where the process has already exited.

Plain HTTP C2 to bare PHP endpoints is easy to detect. Several .php paths on one IP, one returning an application/octet-stream body, is a clear pattern. Alert on executable-sized octet-stream downloads from uncategorised IPs.

Product impersonation hides in plain sight. The sample reused FinalRecovery’s name and banner, so a name-based allowlist would trust it. Validate by signature and hash, not by display name.

Conclusion

A single user-run “recovery tool” from a free-hosting site was enough to start a staged infection, with a second-stage binary fetched over plain HTTP. The memory image, Prefetch and the packet capture each covered a different part of the story, and none of them was enough alone.