Are all botnets bad? Certainly not, there are countless beneficial botnets that do everything from indexing to counter attacking &… other stuff. But certainly there are bad botnets and getting rid of them is challenging work. Most botnets consist of handlers, compromised machines, and a command center that passes along instructions to target systems for a denial of service attack, and possibly/potentially other kinds of attacks.
Realistically “bad” botnets can potentially index information much like beneficial botnets, but the information they could collect would probably be vulnerabilities, open ports, or possibly even different types of data coming from the ports of the system they are infecting. This is critical to consider when routers are targeted because at least in some instances, rerouting traffic can pose a variety of new threats altogether.
Botnets are often distributed via script – but can be attached to anything from routers to game servers and are most often something the compromised system’s user would never detect.
Detecting Bot Nodes
On a local system – for example a Windows system, noticing a bot among the running processes can be trickier than it sounds. A port scan might detect unusual traffic but not enough to alert the user. Windows oriented tools that can detect/eliminate a bot node include:
- Malicious Software Removal Tool – from Microsoft
- Phrozensoft Mirage
- TrendMicros RuBotted
- Norton, Avira, and Kaspersky each have specific tools for bots as well
On a Linux System
Our beloved python may be the solution as well as the potential problem… It turns out that there are a whole bunch of ways to build a botnet in python. Libraries & modules like fabric, pexpect, pxssh, pyhook, pythoncom, are commonly used in botnet construction, and there are dozens of tutorials online. Eliminating libraries on the host system probably isn’t as useful as knowing how to prevent the infection on a target system.
It starts with preventing privilege escalation. Using tools like chattr to lock your etc/shadow folder, as well as password folders, etc. Then moves into ssh key validation and or removal in the case of invalid keys. This would be adequate to prevent 80+% of possible infections but if the system is already infected you need to go a bit further.
Building a Working Port Scanner That Detects Suspicious Activity
On Linux this is fairly straightforward and requires very little aside from the terminal – but a simple scripting tool like geany can help. A basic implementation of pescanner involves little more than the 8-12 steps in the documentation. But you can avoid this entire process if you are handy with netstat and can figure out which (if any) activity actually looks suspicious.
It helps to know how to close a socket when it is in use!
How to close a socket while it’s running a process:
Lifted from stack exchange for illustration purposes
locate the process :
You get a source/destination ip:port portstate pid/processname map
locate the the socket’s file descriptor in the process
lsof -np $pid
You get a list: process name, pid, user,fileDescriptor, … a connection string.
Locate the matching fileDescriptor number for the connection.
Now connect the process:
gdb -p $pid
Now close the socket:
//does not need ; at end.
And the socket is closed.
After this point you can eliminate the ssh key used.
ssh-keygen -R hostname
You can generate new ssh keys and the instructions are here. Though there are different kinds of ssh keys and other ways to generate them, validate them, etc.
With any luck you’ll find the whole process easy enough to follow, or you need a developer.