Home > Uncategorized > From pass_file to Script Kiddies

From pass_file to Script Kiddies

September 30, 2009

This is a follow-up to my previous post.  For background on this post, please read that post.

The botnet master behind the attacks described in the last post could be*:

Image © Crystal Project

Image © Crystal Project

  • Romanian
  • trancetears@yahoo.com, cezar179@yahoo.com and/or hotzu@hotzu.us
  • Frequenting IRC (Undernet): Diemen.NL.EU.Undernet.org:6667
  • Controlling a small botnet with IRC nickname fSs in channel #19
  • Talking in these channels: #ls, #Work, #LinuxTeam, #Linux-Team, #Catalin, #112, #juno and #master
  • Using small variations of the word “tears” for his/her handles and the handles of his/her bots
  • (Probably) proxying his/her IRC connection through compromised hosts
  • Using pre-packaged tools

*I don’t have any evidence indicating that this specific individual is the one attacking me (in fact it’s kind of a long shot), but I do have evidence that this individual is using a toolkit very similar to the one being used against me and that this individual is operating a botnet.  You sacrifice privacy when you choose to run a botnet.

script kiddie magic

this is how you know they're legit. they have skulls and knives in their banners.


Gathering the info:

I’ve been running my modified sshd for a few days now, and as previously mentioned, I have a fairly lengthy log going already.

My original purpose for collecting full usernames & passwords tried against my server was to use those captured credentials to determine whether this dictionary attack was the work of a single group or the work of multiple groups.  I set out determine which using the following observations:

  • If there is a single group behind these attacks, it would make sense that they would synchronize this work amongst the attacking IPs, allowing the attack to evade simple IDS rules and avoid duplication of effort.
  • If there are multiple parties behind these attacks, it would make sense that the same username/password combinations would be tried by different hosts, pointing to a lack of synchronization.

Let’s take a look at first two IPs in these logs:

  • For about 8 minutes from 09/27/09 05:05:47 AM until 09/27/09 05:13:38 AM PST, 85.62.95.198 tried a list of 86 username / password combinations.
  • For about 2 minutes from 09/27/09 07:06:10 AM until 09/27/09 07:08:03 AM PST, 190.82.64.149 tried the exact same username / password combinations in the exact same order.
  • 85.62.95.198 made a request every 7 seconds and 190.82.64.149 made a request every 2 seconds, with very small clock drift.
  • Using two hosts was almost certainly a duplication of effort (that is unless they were trying to determine the rate at which my ssh daemon would process logins…in which case they were just sloppy).
  • Given the even spread of the attempts and the identical dictionaries, it’s not unreasonable to conclude that these two hosts are running the same attack software with a wait parameter changed.

So: one group (no synchronization of dictionaries between bots), or multiple groups (both using a common dictionary)?

In order to determine which, I needed more information on the toolkit in use here. 


Warning: the URL below should not be visited without taking precautions. I use NoScript inside of a VM when looking at sites I know to be malicious. Whenever possible, I have notified the providers hosting this malicious software and have reported whatever is applicable to Google Safe Browsing.


I am a fan of full disclosure; I will be listing sites that are hosting malicious toolkits.  Please do not make the mistake that blackhats find toolkits by reading whitehat blogs.  They already know about and use these tools or could easily find them with simple Google searches (as I did).  Exposure to real world attacks and toolkits is an important learning tool for anyone on the defensive.  Not talking about them doesn’t help anyone.


blah

yeah - this is the entire script.

I took the odd-looking username/password combinations and ran some Google searches.  The following is what I found with my first search.  I’ve found much more than this, including more sophisticated attacks and full output (screenshots, keys pressed) from a keylogger, but going into that would be too much material for this post.

search term: mythtv vivafood
initial result: pass_file
host: f0rbidden.home.ro
notes: payload staging server; activity as recently as Sep. 13th
interesting files found on host:

boo.tgz:

  • Linux IRC bot
  • c&c information

boodarwin.tgz:

  • darwin: PPC Mach-O (OS X) IRC bot
  • freebsd: FreeBSD IRC bot
  • sendmail: Unix IRC bot
  • pico (trojaned? are the attackers unfamiliar with vi?)
  • help files and configuration for a popular botnet control program
  • “random” IRC nicks, comments, away messages, insults, etc.

gosh.tgz:

  • a bunch of things we’ve seen already
  • ssh-scan, ss: ssh brute-forcer & tool; based on libssh-0.1
  • pscan2: a port scanner
  • a, go.sh: ssh-scan supporting scripts
  • mfu.txt: a list of IPs serving SSH(?)
  • vuln.txt: a file to hold successfully brute-forced hosts
  • gen-pass.sh: combines a user list & password list into a single list
  • secure.sh: checks if user is root, moves mail to s8 if user is root

psyBNC-2.3.2-7.tar.gz & psyDarwin.tgz:

  • IRC bouncers (BNC). Allows the attackers to proxy their IRC connections through infected hosts.

sniff.tgz:

  • a bunch of things we’ve seen already
  • the bot master’s email address (found inside sniff/install)

liviu.tar (partially corrupted):

  • a bunch of things we’ve seen already
  • a PHP shell
  • ps: trojan horse scanner

gosh.tgz is a Romanian(?) kit made a group identified as “TASE”.
scam, a file inside gosh.tgz, will email the following to hotzu@hotzu.us:

  • output from /sbin/ifpconfig (IP address of bot)
  • output from uptime (reliability of bot)
  • /etc/issue (bot’s Linux distribution)
  • /etc/passwd (valid users on bot)
  • output from id (current user)
  • output from df -h (disk space available on bot)
  • output from pwd (working directory)
  • current list of successfully brute-forced hosts

As previously stated, I’m not going to dissect the other malware staging servers I found as this would take too much time/space.  I will, however, point out a few highlights that resulted from some simple Google searching with the usernames / passwords tried against me (you’re going to have to find these yourself):

  • a complete PayPal phishing package (source code included)
  • output from a keylogger (screenshots, captured credentials)
  • possible source code for the ssh brute-force utility
  • a rather odd place for a pass_file
  • privilege escalation attempts (most likely successful, judging by the timestamps); very similar tools appear to be used post-escalation
  • Conficker uses some of the same passwords that have been used against me
  • valid* logins to SSH servers on compromised hosts
  • the same toolkit (or slight variations thereof) on about a dozen hosts (hosting providers have been notified)

*Obviously I didn’t verify this.

At this point I know a lot about the tools most likely being run against me.  But what about some more info on the attackers?  IRC information was included in some malware kits…

I decided to look up the OP and see what other channels (s)he frequents.  Almost all were Romanian chat channels, but #a1b2c3 looked interesting:

very lonely botnet

a very lonely c&c channel.

…as did #19:

looks like (s)he figured me out.  no more trolling c&c channels for me.

looks like (s)he figured me out. no more trolling c&c channels for me.

The #19 log is particularly interesting because you can clearly see fSs issue commands and expect a response.  After I failed to respond correctly, was he actually asking me something or is all of this part of the “random” request/response/nickname/away message lists mentioned previously?  Is everyone just reading from a script but me?

The command “shit” is an EnergyMech command.   He told all his bots to ban me (shitlist me) for the next 999 days even if one of them tries to unban me.  His reason for doing this is “boo”.

Advertisements
  1. June 15, 2010 at 4:02 pm

    Hey, how can I view a scan file, the ones that when you open it, it looks weird, like this: ELF ‰…°þÿÿƒ½°þÿÿ ; thanks in advance!

    • June 20, 2010 at 7:37 am

      That’s not a text file; that’s a *NIX (probably Linux) binary. If you’re on Linux / OS X / some other *NIX, run “file (insert filename here)” and the file utility will tell you the type of file.

  2. June 20, 2010 at 8:10 am

    Hey again, well I found this in my pc the other day:
    objdump -r scanssh
    scanssh: file format elf32-i386

    Its the scan file i was talking about..looks kinda weird – I’m curios what is it for.. I asked someone and told me that is written in C++ and compiled so I can’t see the algorithm – Any other thoughts or suggestions ?

    • June 29, 2010 at 10:12 pm

      That means ‘scanssh’ is a compiled ELF binary for a 32bit processor. Specifically its compiled for the i386+ family of processors (Intel processors, or what is often referred to as x86). That someone is right in that you cannot open a compiled binary directly. You, may however, disassemble the binary to deduce its purpose. Here’s some things you can try:

      – read: http://en.wikipedia.org/wiki/Disassembler
      – read some of: http://en.wikipedia.org/wiki/X86
      – run ‘strings’ on the binary
      – try IDA Pro free http://www.hex-rays.com/idapro/idadownfreeware.htm
      – run it inside a VM and debug it via gdb
      – run ‘strace’ on the binary inside of a VM

      Have fun :)

  3. John Moore
    October 17, 2010 at 6:43 pm

    You could have used kippo (https://code.google.com/p/kippo/). It’s not a perfect sshd honeypot because there’s not a lot of functionality (wget.py, tar.py, ls.py). I’ve had one bad guy quit because of the lack of an ftp emulation script. Most download their toolkits using wget, then only get wise when they can’t access them. I created the Mercury Live DVD with multiple honeypots. Andrew Waite has a post (http://blog.infosanity.co.uk/2010/09/22/mercury-live-honeypot-dvd/) about it. He also details how to redirect port 22 to port 2222 using iptables.

    It’s interesting to see what you’ve found just by analyzing the username/password combinations, but it doesn’t tell you what their intent is other than breaking into your system. Sure, you get a peek at what’s available to them, but you don’t really know these attackers true aims. I’ve seen them try to install the unixcod ssh scanner/brute force cracker as well as download sipvicious.py to scan and attack Asterisk PBX systems. With your python programming skills, you could probably enhance kippo to your liking and gain further insight into what these guys are doing without worrying about the honeypot becoming a weapon. I’ve thought about chrooting a Linux file system inside of directory like one does to make live CDs, but preventing the system from becoming a malicious jumpbox would require a packet mangling firewall like roo (https://projects.honeynet.org/honeywall/) which is a pain to install and configure. I suppose I could install the packet mangling firewall script directly on the honeypot. Preventing it from being disabled by the attacker would be tricky though.

    • October 17, 2010 at 7:18 pm

      All great tips. Thanks for referring kippo – I hadn’t heard of that one. If I ever find spare time to look more into the honeypot topic, I’ll have to look at that and Mercury.

      The reason why I went the route of modifying sshd by hand was curiosity. I figured I could probably get a pre-modified binary (or emulator, etc) to do what I wanted, but that didn’t seem like as much fun. Part of me wanted to know just how easy it would be to create an sshd that could be used for more nefarious purposes.

      As for the attackers’ intent, this was certainly not a forensic investigation :) From the disclaimer towards the top of this post: I don’t have any evidence indicating that this specific individual is the one attacking me (in fact it’s kind of a long shot), but I do have evidence that this individual is using a toolkit very similar to the one being used against me and that this individual is operating a botnet. I suppose I should have mentioned that I’m also not aware of their specific motives, but I certainly could guess.

      In regards to something like Roo, I did this research in college at a house where five other people lived and didn’t want to risk them getting attacked because I didn’t configure something like Roo correctly. My housemates seemed to get infected often enough on their own without my help :P

  4. John Moore
    October 17, 2010 at 11:41 pm

    If you download the Mercury live DVD, there’s a working copy of mitmssh. Think of it as an ssh proxy that also grabs usernames and passwords. Take a look here: http://www.madirish.net/justin/kanbe-malware-toolkit. You can download the toolkit and compare the dictionary files to your logs. I believe that there’s a copy of unixcod in there as well. The unixcod archive decompresses to the directory scan. You run it like so: ./unix 192.168 or whatever the first two octets of the IPv4 network you want to scan. Unixcod is Romanian in origin and is a very fast ssh scanner/brute forcer with something like 4 or 5 dictionaries. I was surprised that it’s not covered in Chris McNab’s Network Security Assessment book. Your modified sshd would be even more valuable if it logged all keystrokes of a console session to a monitoring system. That would be VERY handy to security researchers! Of course, it would be handy for espionage as well, but the NSA and CIA have likely already beat you to it. :)

  1. October 1, 2009 at 4:56 pm
Comments are closed.
%d bloggers like this: