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

Reverse engineering for bug bounties is a thrilling adventure, often leading down rabbit holes of code and unexpected discoveries. My recent journey involved the Spotify installer, a quest to uncover a potential DLL hijacking vulnerability. This post will walk you through the process, the tools, the roadblocks, and the ultimate conclusions, highlighting key lessons learned along the way. Understanding DLL Hijacking: The Goal At its core, DLL (Dynamic Link Library) hijacking is a common vulnerability where an application attempts to load a legitimate DLL, but a malicious one is loaded instead. This often happens because applications search for DLLs in a specific order (e.g., current directory first, then system directories). If a malicious DLL with the expected name is placed in an earlier search path, the application loads it, allowing an attacker to execute arbitrary code within the application's context. Tools of the Trade Our investigation relied on a suite of powerful tools: G...

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

  We’ll need to evaluate the performance of the detector built to ensure that we are achieving a higher true positive rate than a false positive rate. Also as we increase the types of features built and used, we’ll need to monitor their performance. ROC Curve In order to evaluate the performance of the detector, we are going to use the Receiver Operating Characteristic (ROC) curve. We plot the false-positive rates against the true positive rates at various thresholds. This will help determine how to configure our detector to get the optimal settings. Detectors are not perfect, there will be false positives but we can use this method to reduce the false positive rate and increase our true positive rate.  When you think about the process and the possibilities then it seems like a never-ending story but we should look at it as evolving our detector. As we implement our function to evaluate the detector performance, we will delve further into the requirements of the ROC curve and ...

  Now we will build a machine learning detector. In order to build a machine learning detector, we need to extract a substantial amount of features from our software binary, not just malware because the point of the detector is to determine whether the software binary is malicious or benign.  But at this moment in time, I’m only using the strings feature, in the future I plan to add more features. Strings feature def get_string_features(path,hasher):  chars = r” -~”  min_length = 5  string_regexp = ‘[%s]{%d,}’ % (chars, min_length)  file_object = open(path)  data = file_object.read()  pattern = re.compile(string_regexp)  strings= pattern.findall(data) string_features = {}  for string in strings:  string_features[string] = 1 hashed_features = hasher.transform([string_features]) hashed_features = hashed_features.todense()  hashed_features = numpy.asarray(hashed_features)  hashed_features = hashed_features[0] print “Extracted...