Botnet for academic purposes

I want to make a botnet, maybe with virtual machines or something. I've heard that some botnets are IRC-based. Any ideas about where to start for making a botnet? I am less concerned with the getting-people-to-install-shit angle, and more interested in the concepts of stealth, steganography, command & control, and distributed systems stuff.

>>1
https://careers.microsoft.com/

>>2
nice meme but that doesn't actually answer my question you dumb memer

>>3
http://jobs.intel.com/

Also, I don't want to just install shit that other people have made (zbot, citadel, etc) -- I want to make this shit on my own. So I need to figure out what I need to make. It's a distributed system where the bots take commands from a command and control server, or perhaps there's some way to add a peer-to-peer thing like BitTorrent or whatever so that there's a network of peers that decide what to do instead of a single point of failure or something? I don't know. It seems like it'd be easy to doxx yourself if you have a hard-coded dedicated/centralized C2 server, unless it's a tor hidden service or something. But maybe there is a distributed way to issue commands to bots. And I guess IRC could be useful for sending and receiving text.

Make it tor or bitcoin based.

>>6
Wow, everything is solved with 2 magic words!

Here I am at my computer, contemplating how to go about doing a complicated project. Someone says "tor or bitcoin." Why didn't I think of that before?

I hit the Tor button on my keyboard. It magically adds Tor anonymity to my magically-newly-created distributed system. I hit the "bitcoin" button (next to the any key) and it magically adds blockchain functionality, which is somehow useful for an IRC botnet(?) -- actually, no it isn't.

Why didn't I think of that before? Just do a complicated thing. It's that easy!

You need to consult the master hacker SuperHell.

make it blockchain based

Web-Scale Enterprise Class Agile Blockchain Synergy

>>10
Adapts to Emerging Customer Needs and Seamlessly Integrates with Existing Software Stack Solutions, Propelling Your Enterprise Infrastructure to the Next Level.

>>8
supaa hakkaa
>>10,11
you joke, but I've seen shit that's pretty much exactly that
there are so many shitty tech startups out there

i had a botnet at the uni by writing assignments for other students for booze and hiding the payload in the compiled executable that i delivered along with the source code
i got to TENS of nodes

>>13
my professors only accept source code, nothing compiled
people like you are why

>>14
nah, it's other students who run the executable out of curiosity when they receive it

>>15
sharing your answers violates academic integrity policies

you rule breaker, you

>>1
obvious disclaimer: don't use this information for anything malicious and don't put your're are malware on computers you don't own. VMs are a good tool for this kind of malware lab: just give them all IPs in range and make one of them a C&C server and have fun. FBI plz don't arrest me

I used to have a small botnet (around 200 devices) many years ago, when SlowLoris was the main tool for DDoSing things. as your're aren't interested in getting people to install it, I'll skip that part (unless anyone's interested) and get to the design.

at heart, a botnet is a bunch of slave nodes which receive commands from a server, so start with making that. polling a server is generally better than listening for connections because of firewalls. then, try to figure out the way to avoid hardcoding the server's address - the most common way of doing that is by making a domain-generation algorithm (DGA). the idea of a DGA is simple - it generates deterministic domain names based on current time. you then register those (or just edit /etc/hosts when making an academic/research pseudo-botnet) and point them towards your server. you should make a DGA as confusing as possible to make the job harder for reversers but at first a simple state machine would be enough so that people won't see your domains when running strings on your're are executable. I was thinking of ditching DGAs altogether and making some sort of peer2peer botnet with a public key instead of C&C server, which would accept commands from anyone who signed them with a matching priv-key and send them to known peers, but I couldn't figure out a way of doing that without listening on a port and therefore getting firewalled. if your're are smarter than me maybe you'll work on this idea

the other issue with stealth is hiding executables from antivirus software. avoiding file/section signatures is trivial so I won't talk much about that - what you really need to worry about are heuristics. the oldschool way of dealing with them is as follows:
1. obfuscate, compress and encrypt the machine code of malicious parts of your're are program
2. put that as an array of bytes
3. write simple assembly to reverse the process and mark the section as executable
4. ???
5. PROFIT!
this is so oldschool that antivirus became good at detecting it so don't rely on it too much. a better way is to create multi-stage programs: a downloader which downloads and installs the client, the client that polls the server and payloads which do what the server wants. the payloads are usually encrypted/obfuscated but they're rarely machine code because decrypting machine code is seen as suspicious. instead, they're usually one of the scripting languages recognized by default by the target system. as target system is usually windows, they'll be batch, jscript and powershell. bonus points for fileless execution of payloads - but even better if you design a truly devious malware which doesn't even have executing payloads as an overt functionality. think of an intentionally vulnerable, easy to exploit client that is being hacked by its own server.

>>17
Thanks for the info. Fascinating stuff.

a downloader which downloads and installs the client,

But then it'd have to download the payload from some central server, right? Again, there's the problem with stealth, since malware researchers would be able to identify the server it's coming from.

But maybe you'd just find old-ass WordPress sites with CVEs on Shodan or something and then use those to host it? Or something like that.

fileless execution of payloads

WMI hijacking?

How would malware detect that a researcher is analyzing or reverse-engineering it?

How should malware respond to anti-malware software? Should it be "shy" and uninstall itself if certain tools or antivirus programs are installed, or do you prefer to be more ballsy and go for persistence rather than stealth? Should your malware attempt to uninstall or disable antivirus software, or would that raise suspicion?

Would it be better to develop malware for macOS and/or Linux considering that Windows users are more likely to run antivirus software (since macOS and Linux people sometimes think malware is a Windows-only problem)?

What about domain sinkholing? Or what if someone reverse-engineers the DGA in your malware? How else can you authenticate C2 commands (with more than just the domain it's coming from)?

How often should a bot try to connect to the C2 server?

How often should DGA domains be rotated? Maybe a new domain for every week or something? Minimum registration is like a year, and that can be, what, 10bux for a .com domain?

Would networks that monitor DNS traffic (such as a business rather than a home) be able to see the lookups for the DGAs and flag it as suspect or something? Can DNScrypt or whatever be helpful to make it stealthier? Or maybe some alternative DNS server?

Would tor or tor2web be helpful at all in a botnet?

Should you create some sort of killswitch or dead man's key in case of law enforcement?

How can you incorporate polymorphism into your malware project so that the checksums, filenames, directories, etc. are different from computer to computer so that it's not trivially easy to label certain files as malicious?

Are portable executable packer things important? Which ones should you use? I have only heard of UPX, but I don't know if that's good enough for most use-cases. Should you check if things get detected using VirusTotal, or is that a bad idea?

If I code botnet-related software in my host OS and test it out in a VM, will my anti-malware software detect and/or remove it?

Firewalls usually accept outgoing requests, but not inbound ones. So the bot client has to establish a connection with the C2 server(s), not the other way around. Is that right?

For a domain-generating algorithm, how would you go about registering the domain names? Bitcoin, or what? Stolen credit cards?

Should you even bother with mobile malware? Maybe have a "free APK" site for Android (since a lot of Android users have shitty devices that don't get Google Play but they still want apps)? How do you get computer users to install your malware? Email attachments with word macros? Social engineering? Torrent trackers and trojanized "cracked" versions of free games? Youtube tutorials with links to Mega or something in the description? Not that I'd actually do anything like that, since this will all just be local on my own computer. But it's good to know what other people do. Are 0-days and remotely exploitable things (like remote code execution) rare? I'd imagine that exploit-based virus propagation is less common than in the past, and instead you rely on social media and link shorteners or watering hole attacks and things like that.

What do people even do with botnets once they're established? Aside from DDoSing, do people still do email spam, like for fake viagra or something? Do you use it to make your own version of Tor (for bouncing traffic between relays)? Do you use it for ransomware, or cryptocurrency mining, or what?

I am focusing on how you build a botnet, but let's say you have established a botnet with a lot of bots and you're not worried about law enforcement. Then what? After you've made it, what do you even do with it?

As I said, I am just interested in malware research from a purely academic standpoint. I think it'd be cool to become a malware analyst one day. But that involves knowing how malware works.

You don't learn about how malware works by following shitty tutorials that tell you how to only install Kali in a VM or use Dark Comet RAT or Sundown EK or Citadel or something. That's cargo cult malware. There are tutorials (and groups of people) who only focus on learning how to install things other people made. But you learn much more by actually doing things yourself (though it's good to know what design considerations other projects have). I know there are pitfalls with things like DIY cryptography, so you should see what other people are doing. But it's good to think about how to do it on your own, even if, in some ways, it's like needlessly reinventing the wheel. But the point is that it's a learning experience, not necessarily a real-world thing.

>>18
fileless execution of payload can be much simpler. consider this: a client sends a GET request to a server over TLS. server responds with a list of batch commands which are then passed to the system() function. this is of course fairly primitive and easy to detect, so consider my idea of vulnerability-as-backdoor: what if your're are client has a beingn functionality which is implemented with batch commands, but the function which executes them has a shell injection vulnerability?
>>19
that's a very broad set of questions, but you can learn answers to many of them by reading malware analysis and reverse engineering articles, there's plenty of those on the internet. then you can try experimenting with malware - writing your own but also reversing what already exists. it's not like finding a sample virus for analysis is difficult

>>20
I'd worry about malware somehow breaking out of a VM/sandbox though

>>21
if you write your're are own malware and it breaks out of a sandbox or VM then congratulations, you've got a 0-day

>>22
I didn't mean mine, I meant analyzing other people's malware. Can't some malware escape virtualization to infect the host OS?

>>23
technically, but only if it used a 0-day or if you had an unpatched VM with known vulnerabilities. most malware is simple and doesn't use exploits. you can always use an air-gapped PC for that but then again, super-fancy viruses like Stuxnet could travel through infected USBs. generally speaking, you shouldn't care (beyond having all the security updates) unless your're are analyzing shit made by actual spies.

if I were a spy or APT dude, I'd make honeypot ``amateur'' malware for researchers to analyze, and it'd look amateurish but in actuality it'd have VM escape 0-days for VMware/Virtualbox/QEMU and then I'd establish reverse shells on their host OSes or something

UEFI rootkits or some shit

fuck with their research efforts somehow

VM are unsecure. I am the only one that can fix it, nobody else has the guts to even talk about it.

If I ever made malware, I'd make it stop whatever it's doing when the user has the task manager or system monitor open (depends on the OS). Or maybe on Linux it could detect if top or htop are running.

Basically, if the user notices high CPU usage, then uses a program to view what's using up their CPU cycles, you'd want it to chill out and lie low for a while. Or maybe just do resource limitation all the time, like limiting max CPU usage and network bandwidth usage too, so as to not alert the user.

I mean, think about it: people notice cryptocurrency miners because they have high CPU usage associated with them. But if they never used more than like 10% of your CPU, nobody would really care.

bump

>>25
but why would you? it's better to fly under the radar and infect high-value targets than to get detected and wreck some malware research lab. the only thing you could potentially gain from that is access to more malware sample, and if the researchers aren't already dealing with APTs then you'll just get a lot of boring macroviruses and phishing sites.

>>27
malwares can do that. they can also detect that their're are being debugged and behave differently if that happens, although obviously an experience reverser can get around that

>>30

But researchers are high value targets. They can mess up your malware operations, so keylogging or ratting them could lead to getting dirt on them or something so you could make sure they don’t mess with you.

This is all just hypothetical, of course. But because I am only going to have a local VM pseudo-botnet, I don’t really need to think about this too much.

But what I am saying is that targeting malware researchers definitely makes sense for malware developers. Why would a malware dev just sit idly by and let malware researchers disrupt their livelihood?

>>31
because 0-days are more valuable for primary targets, like people your're are spying on. if you attack researchers with 0-days, researchers will sooner or later reverse those 0-days and then the exploit will be burned. it's better to keep a low-profile and only use 0-days in targeted attack so that it will take longer before they get burned.

exploit my dubs!

exploit my anus

>>32
You make it sound like 0-days are super rare. Look at all the CVEs out there -- those are known and reported vulnerabilities. Now imagine all the vulnerabilities people find and don't report.

Besides, you don't always need 0-days for VMs. People might be using old versions of hypervisors, or just didn't set things up correctly.

you can run bindiff to see differences between versions of software so you can figure out what was insecure in the old version (by looking at the differences between the old and new versions)

>>35,36
not everything that gets a CVE can get a fully weaponized exploit. finding a buffer overflow is one thing, acquiring all the needed exploit primitives, bypassing ASLR, finding a ROP chain and making it reliable (that's the thing people don't talk about but it's very important if you try to escape from the VMs and want to stay hidden - 90% reliability is considered very good for heap overflow standards but it still means that there's a one in ten chance that your malware will crash a hypervisor, and a malware analyst will definitely notice that) is another.

bamp