Haq's Security Blog

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 ...

My recent bug bounty adventure with the Spotify installer took an interesting turn. After thoroughly investigating potential DLL hijacking vulnerabilities and finding the installer to be surprisingly resilient, the next logical step was to peek into its network communications. After all, the installer prominently displayed a "downloading installer" message, implying it was reaching out to the internet. This blog post chronicles our journey into capturing HTTP/HTTPS requests, battling DNS complexities, attempting local server interception, and ultimately, uncovering more about the installer's robust design. The New Challenge: Capturing Network Traffic Our trusted Process Monitor was fantastic for file system and registry activity, but it falls short when it comes to detailed HTTP/HTTPS requests. For that, we needed a dedicated network analysis tool. While Fiddler Classic is often my go-to for web traffic (especially with its easy HTTPS decryption), we opted for the powerf...