How To: Use UFONet

Use UFONet

With the release of the Mirai source code, botnets are back in a big way. In the early days of botnets, zombies (infected hosts) would report to IRC (Internet Relay Chat) channels for CNC (command and control) instructions. Modern botnets have evolved, but they continue to use the same concepts as their predecessors.

The basics of botnets are simple. The first step is to find lots of machines that are vulnerable to attack. In the case of Mirai, IoT's devices with hardcoded or default credentials set. Next, the vulnerability is exploited. In some cases, this means installing a RAT (remote administration tool). Infected or vulnerable machines are then controlled by a bot herder with a CNC tool. Often, botnets are custom-coded and the source is kept secret. The reason for this is the profit involved. Botnets are used for DDoS, bitcoin mining, data theft, spam distribution, and ad fraud. Some bot herders even rent their botnets out by the minute!

In this article, we will be examining UFONet, "a free software tool designed to test DDoS attacks against a target using 'Open Redirect' vectors on third party web applications like botnet." I will be walking through the steps as if I were going to launch an attack on a host. This open-source botnet is easy to install and run, and it's capable of searching out vulnerable hosts, testing them, cataloging them, running DDoS attacks, and more.

Step 1: Get the Source

Our first step is to get the UFONet source, so open your favorite terminal emulator and clone the repo:

We will also need to ensure that we have all of the dependencies required to run this. We will need Python >2.7.9, python-pycurl, and python-geoip. In order to install these dependencies in a terminal on a Debian-based system such as Kali Linux, simply run:

  • sudo apt-get install python-pycurl python-geoip

Next, we will update UFONet:

  • ./ufonet --update

Step 2: Configure Tor (Optional)

If we were using UFONet to DDoS a target, we would set up Tor and run:

  • ./ufonet --check-tor

Since we are not actually going to be attacking any targets or exploiting any hosts other than those on our local network, we can skip Tor configuration.

Step 3: Find Vulnerable Hosts

Now we'll use the search function to find vulnerable hosts. UFONet uses only Bing by default to locate vulnerable hosts. This can be changed with flags. I will be using all of the available engines built into UFOnet to search for a vulnerable host.

  • ./ufonet -s 'proxy.php?url=' --sa

This command tells UFOnet to search for sites containing "proxy.php?url=", using all built-in search engines. Sites containing "proxy.php?url=" may be vulnerable to open redirects. You can also load search strings from a text file with the command:

  • ./ufonet --sd 'botnet/dorks.txt'

This command uses UFOnet's dorks.txt as a list of strings to search for potential open redirect vulnerabilities.

Since none of these sites have asked me to test whether or not they are vulnerable to open redirects, I did not check the hosts. If we had selected "Yes," UFONet would have checked the remote hosts ensuring that they are vulnerable to open redirects.

Another option for locating targets is downloading the community zombie file from UFONet. I can't verify the validity of this list, but it's worth a shot.

  • ./ufonet --download-zombies

Step 4: Testing

We now have a large list of zombies available to us. Since the hosts provided by the community are not under my control, I cleared the community hosts that I downloaded from my bots list and set up a vulnerable page in a VM (virtual machine). This page is a simple open redirect and belongs in the botnet/zombies.txt file.

UFOnet stores data on vulnerable hosts in text format in the botnet folder. Each text file has a themed name, and represents a different form of open redirect.

  • Zombie: HTTP GET 'Open Redirect' bot
  • Droid: HTTP GET 'Open Redirect' bot with parameters
  • Alien: HTTP POST 'Open Redirect' bot
  • UCAV: These sites check whether the target of the DDoS is up
  • Dorks: A list of potentially vulnerable search strings

Next, I test that my VM is vulnerable to an open redirect.

  • ./ufonet -t botnet/zombies.txt

Looks like it's working.

Step 5: Inspect Our Target

We may want to inspect our target for large files. Luckily, UFONet has the functionality built in:

  • ./ufonet -i http://192.168.1.97

Focusing on larger files is not a necessary step, though it may eat more bandwidth from the target site wreaking a bit more havoc. Since my VM consists of two hosted pages, the default Apache page, and the vulnerable open redirect page, this command isn't going to discover anything major. Though, in some cases, you may discover large files.

I inspected my vulnerable web server. It looks like the largest file on my web server is "ubuntu-logo.png". It appears UFONet has followed an external link off my site though. If I hadn't read through the information presented to me, I could have potentially attacked the wrong target! Tools can report the wrong information, so it's important to pay attention.

Step 6: Launch an Attack

Lastly, I will launch:

  • ./ufonet -a http://192.168.1.97 -r 10 -b "icons/ubuntu-logo.png"

In this command we launch UFONet, and the -a flag specifies the target to attack. The -r flag specifies the number of times each host should attack. The -b option selects where to make requests on the target.

When we execute this command, UFONet will attack the target 10 times for each zombie. If you have a list of 100 zombies, it would launch 100 zombies times 10 rounds for a total of 1,000 requests to the target. Specifically, it's requesting the largest file on the site "ubuntu-logo.png". That number may seem small, but remember with a bit of web scraping and peer-to-peer sharing, it should be easy enough to launch a respectable DDoS attack.

In this case, I'm getting a target down message. Obviously, my target is still up. Since I'm attacking a local VM from within my own home network, sites like isup.me that check whether a website is up, will detect it as down.

Conclusion:

UFONet is just one of many DDoS attack platforms. A search on GitHub or Google for botnets should turn up some interesting results. I would never run a botnet app without thoroughly reading through the source. Without an understanding of the code, it's quite possible that you could face criminal charges. If that weren't enough, running unknown applications from known malicious developers can compromise your system—turning your machine into a zombie or worse. Depending on your location, simply testing for open redirect vulnerabilities in remote machines could be illegal.

Just updated your iPhone? You'll find new emoji, enhanced security, podcast transcripts, Apple Cash virtual numbers, and other useful features. There are even new additions hidden within Safari. Find out what's new and changed on your iPhone with the iOS 17.4 update.

Cover image by UFONet

9 Comments

Hi , i have a question which is not related to this article.

I was pentesting a payload, i have sent it to victim machine which is actually my PC and the attacker is my VMWare virtual machine.

I have generated and encoded the payload (reverse https) using magic unicorn, and then sent it to victim machine.

When payload is executed in the victim, in Victim's Task manager i can see the powershell opened but not the LHOST & LPORT , but when i use the software TCP VIEWER , i can see both.

LHOST is 192.168.67.210
LPORT is 4440 , which i had given during the generation of payload.
Why is the IP address shown in terminal and in internet is different, whats the difference b/w these 2 IP's?
Even if the victim comes to know of my LHOST IP , will he be able to find out about the attacker through the LHOST?

One more thing, when I searched for info using nmap about the LHOST in victim's PC, the nmap results gave me the mac address of VMWare (attacker), and again when i searched on internet about LHOST IP , the search results showed that it is a private IP and no other info was shown.

You may want to re-post this question to the forums.

When I do ./ufonet -s 'proxy.php?url=' --sa
I get some +Victim found and at the end Error - something wrong searching using: bing

When I go ./ufonet -t botnet/zombies.txt I get
Error - something wrong testing!
traceback (most recent call last):
file "/media/root/Kali Linux/UFONet/ufonet/core/main.py", Line 302, in run
test = self.testing(zombies)
file "/media/root/Kali Linux/UFONet/ufonet/code/main.py", Line 2331, in testing
self.connect_zombies(zombie)
file "/media/root/Kali Linux/UFONet/ufonet/core/main.py", Line 450, in connect_zombies
t.start()
file "/usr/lib/python2.7/threading.py", Line 736, in start
startnew_thread(self._bootstrap, ())
error: can't start new thread
Segmentation fault

Are your bot files empty?

No, and I found out what the problem was.
I had too many URLS in the bots file

Can anyone tell me where/how to get more zombies, blackholes and dorks?

Did you try the download zombies option?

Yeah. I'm just wondering how people find these dorks and more zombies. I doubt any blackholes are public though :/

You can search for dorks, it's built into UFOnet. From the UFOnet site:

UFONet has some P2P options to share/keep 'zombies' with other 'motherships'.

  • Setup web server with a folder "ufonet", this folder should be:
  • located in /var/www/ufonet (default debian/ubuntu install)
  • owned by the user running the blackhole
  • accessible with http://your-ip/ufonet/
  • Start the blackhole with: ./ufonet --blackhole (or python2 blackhole.py)
  • Anyone wanting to connect to your server needs to set the --up-to/--down-from

to the ip address of your webserver...

!WARNING : this ADVANCED function is NOT secure, proceed if you really want to.

People share them p2p. Sharing the list isn't illegal, though I would probably consider doing it on a VPS just for privacy reasons.

Share Your Thoughts

  • Hot
  • Latest