Haq's Security Blog

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

  Shared code analysis In the last section, I wrote about building networks and producing a visual graph that shows the connections between Malware. In this section, I will go through the script where we create a system that will show the links between Malware based on shared code analysis. Terminology Before we start to build the system, we first need to understand the following: 1. Jaccard index 2. Minhashes Jaccard index The Jaccard index is quite simple, it is worked out by diving the total of shared attributes (between malware) and the total attributes. For example: Jaccard index = 0.5 when shared attributes (5) / total attributes (10). Now, this is useful for small data sets, but when we want to compare large data sets then we turn to “minhashes”. Minhashes Now Minhashes isn’t so simple. A minhash is a technique used to estimate the similarity of two sets.  Our minhash is a malware sample’s feature (in our below system the features will be the results from “strings”) and...