Skip to main content

Unearthing the Real Deal: How We Found Spotify's Hidden Installer Payload


Our journey into dissecting the Spotify installer has been a series of interesting detours. After hitting a dead end trying to intercept the initial download traffic (thanks, QUIC encryption!), we knew it was time for a pivot. If the installer was "downloading," then by definition, it had to be writing data to our local disk.

This led us to a different kind of hunt: a forensic examination of the installer's file system activities.

The Pivot: From Network Packets to Filesystem Footprints

The network analysis had revealed that SpotifySetup.exe made a successful DNS query for apresolve.spotify.com, which resolved to 35.186.224.24. And while we saw it attempting both QUIC (HTTP/3) and traditional TCP/TLSv1.3 connections, the QUIC traffic remained an impenetrable "protected payload." Trying to build a QUIC proxy felt like a rabbit hole deeper than we wanted to go.

So, the question became: If we can't see what it's downloading over the network, can we see where it's downloading it to on the disk?

Enter our old friend, Process Monitor (ProcMon).

The Hunt with Process Monitor: Finding the Fingerprints

Our initial attempts to filter ProcMon logs were a bit too broad or too narrow. WriteFile operations alone weren't capturing everything. This often happens when an application employs more nuanced file operations or spawns child processes that do the heavy lifting.

A deeper dive into ProcMon's raw events, however, revealed the key players:

  • IRP_MJ_CREATE: This is a fundamental operation indicating a file is being created or opened for access. It's the prelude to data being written.
  • FASTIO_WRITE: This is a highly optimized, direct-to-disk write operation. When you see this, it means raw data is being efficiently dumped into a file.

By focusing our ProcMon filters to include these specific operations, along with WriteFile and common temporary/installation paths, the logs became much clearer. We ran SpotifySetup.exe again, intently watching the incoming stream of file system events.

The "A-ha!" Moment: Two Significant Paths Emerge

As the "downloading" progress bar crept along, two paths repeatedly appeared in our ProcMon logs, filled with IRP_MJ_CREATE and FASTIO_WRITE operations:

  1. C:\Users\ul_ha\AppData\Roaming\Spotify\SpWebInst0.exe: This path, within the user's roaming application data, suggested a component of the web installer itself, perhaps a temporary executable it was using or building.
  2. C:\Users\ul_ha\AppData\Local\Microsoft\Windows\INetCache\IE\WV05H7IU\SpotifyFullSetupX64[1].exe: This was the real gem!
    • The INetCache\IE part immediately flagged it as Internet Explorer's temporary cache folder. This strongly indicated that even if the Spotify installer has a custom UI, it leverages IE's underlying download components (like the WinINet API) to fetch the main payload.
    • SpotifyFullSetupX64[1].exe clearly sounded like the full 64-bit setup executable. The [1] suffix is also typical of IE downloads when a file with the same name already exists in the cache.

Initially, we assumed, as is common with installers, that these temporary files would be deleted upon completion. And for SpWebInst0.exe, that appeared to be the case. However, a quick check after the installation confirmed the thrilling news:

SpotifyFullSetupX64[1].exe was still there!

The Significance of Our Find

This discovery is a major step forward. We've managed to bypass the QUIC encryption and directly obtain the true installer payload. This SpotifyFullSetupX64[1].exe is no longer the small initial downloader; it's the full-fledged executable responsible for installing the entire Spotify application.

This means we now have a static target for in-depth analysis. We can examine its contents, understand its behaviors, and scrutinize its logic without needing to race against its self-deletion mechanisms or decrypt complex network streams in real-time.

What's Next for the Investigation?

With the SpotifyFullSetupX64[1].exe in hand, our next phase will involve:

  • Hashing and VirusTotal Lookup: To confirm its legitimacy and see if any unexpected flags appear.
  • Static Analysis (PE Viewing, Strings): Deconstructing the executable to understand its imports, resources, and any hardcoded strings or URLs.
  • Dynamic Analysis in a Controlled Sandbox: Running this actual installer in a virtual machine while meticulously monitoring all its file system, registry, process, and potentially network activities (hoping its installation-phase network calls might be more amenable to standard HTTPS proxying).

This shift in strategy allowed us to overcome a significant hurdle, proving once again that persistence and adaptability are key tools in any cybersecurity researcher's arsenal! Stay tuned for what secrets the full installer might reveal.

Comments

Post a Comment

Popular posts from this blog

Building my own write blocker

  Spoiler — It’s cheaper than buying one I was looking to buy a write blocker to do data recovery/forensics tasks but I quickly noticed that I was window shopping write blockers due to their cost. Some starting at £300, others that cost less were no longer being built or sold, maybe you could find a 2nd hand one with or without the wires. Most of these write blockers were industry standard, used by law enforcement but was it necessary for me to buy such an expensive write blocker….or is it possible to build my own….. So th e  research began, reading through articles, publications, and so on, and with the information gained, I felt that I could build my own write blocker. So what do I need: A Raspberry Pi A Linux distro. HDD/SSD to test the write blocker And to put the information I gained into practice Building the write blocker So, I brought a Raspberry Pi 4 Model B that came with a power supply, HDMI cables, 32GB SD card, a case, and some extras. ( https://www.okdo.com/c/pi-...
Post a Comment
Read more

Malware Analysis: Dissecting a Golang Botnet - Part 1

Introduction In this post, I walk through the process of analyzing a Golang-based botnet sample — specifically a variant of FritzFrog , a peer-to-peer (P2P) botnet known for brute-forcing SSH servers and spreading laterally across networks. The goal here is to share my steps, tools, and insights while preparing for a cybersecurity analyst role.  🐸 1. Downloading the Malware Sample I began by grabbing the malware sample from Da2dalus’ excellent GitHub repository of real-world malware: URL: FritzFrog Sample on GitHub To fetch the raw binary into my WSL environment, I used: wget -O botnet_malware_IM https://github.com/Da2dalus/The-MALWARE-Repo/raw/refs/heads/master/Botnets/FritzFrog/001eb377f0452060012124cb214f658754c7488ccb82e23ec56b2f45a636c859 📤 2. Transferring the Malware to the Flare VM (Windows) My analysis environment was running inside a Windows VM using FLARE VM . Since the malware was downloaded via WSL, I needed a way to securely transfer it to the Windows VM. First, ...
Post a Comment
Read more

Notes from a Linux command line course

 Recently I took a course on Linux command line and shell scripting, below are the notes I took which I decided to write into a blog to refer to for future reference (there's no way I could remember all of this in a single sitting) 1. Kernel vs Shell OS has 3 layers: Application layer - User apps, Daemons Shell - Command line interface. Kernel - Hardware management, memory management, I/O Handler, CPU, process management. Closest layer to the hardware The kernel controls and mediates access to hardware, for example, it schedules and allocates system resources like memory, CPU, disk etc. The shell works as an interface to access the services provided by the OS. We can further breakdown the layers into the following: User space - If you run a for loop etc, you are in user space. But when you want to perform an operation such as, write to the disk, for example, save a file, then it needs to talk to the kernel space. As the application can't directly talk to the hardware. Kernel sp...
Post a Comment
Read more