Jump to content

Botnet infection sample and removal

Recommended Posts

Botnet Removal Overview


This thread is an overview on how to detect, identify and remove a botnet infection. This is merely one example of such an infection. Honestly the main reason I was able to detect it (before it was added to malware definition databases), is because of it's aggressive processor use. Bitcoin miners are extremely intense processes, to 98% CPU usage stood out like a sore thumb.


This will be a 5-step & thread process on how I went about checking around and figuring out how this bitcoin miner was operating. There are various ways to go about the same methods, but I am sharing mine, in hopes it helps someone remove similar trash in the future. I will make a post in this thread for each process, to help describe the methods used, and hopefully do so in a clear manner.


Steps used:

As for any infection, you have to be formidably sure you completely removed the infection, otherwise you are waiting for more damage down the road. Do you wish to reinstall the OS, or do you feel confident the exploit has been removed? This question is especially relevant in the business environment. Luckily I saw this on my personal machine, so I could afford more time to debug what was happening and log it.


The attached picture should make more sense as you read each progressive step.


Link to comment

Suspect and Detect


Tools used:

This is a Windows 7 Ultimate platform, but all versions should have the commands I listed. You will want to download the XVI and Process Explorer utilities, since they are 3rd party applications.

You can use the GUI Task Manager, but some processes can hide from that display. Also be sure to check "show processes from all users" on the Process tab, if using the GUI list. Sorting by CPU and / or Memory usage is a quick means to find anything with a big footprint. Look for anything you do not recognize. If you are not familiar with standard processes on your machine, search online to find what each process is normally used for. However do not simply assume all standard sounding services and processes are legit.


In this case, MSDT.exe was running. Typically this is a Microsoft diagnostic tool, however that was not the case this time. Using 98% CPU, this program was actually a bitcoin miner and was not an actual microsoft utility. Trying not to jump ahead too much, verifying the path this was running from, validated my suspicion.


In the GUI (Graphical User Interface) Task List, you can right click a process and say Open Location This is where I found this executable, as well as 2 other related files.

  • atieclx.vbs (Service spawning vbs code)
  • aticlx.exe (Command and control server, from what I could tell of hex edit)
  • RAVClp86.exe (Communications portion associated with Command and Control server)
  • MSDT.exe (Bitcoin miner payload)
Link to comment

Network Traffic


This step what a 2-fold operation.


Step 01:

Closing all web browsers, email clients and the like, I ran the following command.

netstat -o > C:\2014-06-08_PortList.log

Everything on the left of the ">" operator displays the open ports in a command window. The ">" operator and file path, saved the results to the filename located on the root of my C: drive. This works with many to all DOS / command line commands and is advised for archiving sake. Open the text file for your results. Look for funky results.


In this case, I found the following IP (replace letter 'o' with number 0 for the IP address. 2o8.94.24o.162:4768

After the ':' would be the port it was running on. A PID will also display for open ports in the netstat output.


Step 02:

Checking Process Explorer for processes running open network traffic. Since I had my Suspect process list of 4, I went to right-clicking one of them and clicking the TCP/IP Tab. Please notice the other 2 items appeared to be spawned via a wscript.exe process. Note that RavClp86.exe was still there as well.

(Process Explorer image attached to this post)


Link to comment

PID to Process Explorer mapping


Similar to the above Netstat command, I wanted to log my running processes to a flat-file for archiving and review.

tasklist > C:\2014-06-08_ProcessList.log

Of particular relevance is the 'Image name' and 'PID' (Process ID). The PID is going to be used in correlation to your Process Explorer investigation. When using Taskkill, you will also know if a process restarted, by it having a new PID. Speaking of TaskKill, here is how you run that command, by entering said PID for the program in question.

taskkill /pid 3916

3916 being the PID for the process explorer screenshot in my prior post. You need to substitute this with the relevant PID on your local machine.


However, simply killing the processes is not enough. As I will cover in the next post.

Link to comment

Service, Payload and Command and Control targeting


OK. So far we have a list of 4 deviant processes, but not much clearly established on how they are operating. This point (or actually earlier as well) is a great time to get XVI going. We want to peek at the flagged executables to see if anything telling is occurring.

(XVI Hex Edit of RavCLP86.exe pictured)


In this image, we see some Port communications in a seemingly innocuous local file name. Considering this is running in a profile folder, it is indeed not innocent a process at all. From what I can tell, this (in conjunction with Aticlx.exe) process is the Command and Control portion of this application. It also handles being spawned from the .vbs file in the same folder. When any of the other files are removed, this process will re-write them back out and reload them into a running state.


Here are the contents of the aticlx.vbs. This (Aticlx.exe) would be a normal process... if I owned an ATI graphics card, and if it were not running from the shady profile folder. That is until we see what this file is doing.

Set objSh = CreateObject("WScript.Shell")objSh.Run "C:\Windows\Service\Profiles\Local\Service\AppData\Roaming\Microsoft\Windows\Templates\atieclx.exe", 0

So this Service runs to keep Aticlx.exe running. This is the core C&C of the exploit. Respawning the sub-processes as described above. The Service mode running enables the executable to restart, upon termination. Helpful in the event of a user killing the process, and also if there is a code update via the infection botnet. They would want it to be remotely killed, updated and restarted in some instances.



Link to comment

Potential Removal


Notice the Potential wording. This will be a case by case basis, where you assume to have tracked down all sub-threads and related infection vectors. If someone had access to your machine, it is a very good assumption that another possible infection method was added. So explore heavily.


In this case, I would TaskKill, use Process Explorer, and monitor the output folder of these programs. In the case of TaskKill and deleting the infected files, they just came right back. Continuing, I played around until I noticed what .exe respawned the purged files. Aticlx.exe, IIRC.

To temporary mitigate this, I made a blank text file, then renamed it as the target file. Once the service spawner was prevented from making it's related protective .exe files, I was then able to stop and prevent the main process from spawning new copies.


For historic reporting, I renamed the original files to a non-exe filename. Thus preventing them from running, yet keeping a copy for detection and analysis. As I said, this is why you have to judge heavily if you indeed removed the infection. In my case, I was able to run a benchmark to see vastly improved performance. Slower system performance was the tip of the hat, that lead me to investigate this in the first place.


RATs (Remote Access Trojans) have a nearly invisible footprint compared to a Bitcoin miner, so you will be vastly looking harder for those level infections. I have heard the command line Tasklist shows hidden processes that can be masked in your task manager, but nothing is foolproof. The effort to remove malware and exploits from a machine will always be an uphill battle. Hopefully this guide made enough sense to help anyone new to removing these infections. Also it would be nice if it helped any veterans remove these infections as well, since some of this process may not be traditional malware removal.


Most of all, let this show you how limited signature based detection systems are. MalwareBytes did start finding this infection (PUP.optional.PrimeMiner) sometime around January 2014 or so. However I am not so sure it also removes the subsequent processes associated with it.

Link to comment
  • Pic0o pinned this topic
  • Create New...