Malware Analysis of a Cryptocurrency Miner

Malware Analysis of a Cryptocurrency Miner — Part 5

Debugging

In this write-up, I want to bypass some checks our binary does. I’ll be using x32dbg…..Well…let’s just dive straight in.

Debugging a bitcoin miner

From the previous analysis, we know we need to concentrate on bypassing the following 2 conditions:

So let’s load the binary into x32dbg and set 2 breaks points, one at each condition:

but I will skip the first condition by filling the condition with NOPs:

This way, we can bypass the size check.
Just before the call to “strstr”, we can see that “haystack” and “needle” being passed in, which is something I covered in the last writeup.

As I tried to continue to see what will happen (before changing the passed arguments), I recevied an “expection_access_violation” —

After a bit of researching and going through each instruction step by step, I found that the instruction causing the issue:

test ecx,3 — and the problem was that ecx held no value which looks to have caused the violation. This will be due to the Malware getting a HTTP response it’s not expecting.
I had put in a value that I saw it used in a previous test: sjlj_once and then I was able to get past it, but I had hit “run” and then got the following error :

From here we see the name: “NsCpuCNMiner32.exe. Now if you Google the exe you will find a lot of information about this miner.
Now, thankfully I had Wireshark running which shows:

From the research I did on this Malware, I can tell that it’s trying to find an open FTP port (21) across the internet and if it can log in, it will copy itself to that machine! This could explain all the username and password strings we saw in our static analysis. (This shows the importance of running Malware within a secure network!)

Comments

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

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

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

Haq's Security Blog

Search This Blog