Internet Survival Time Analysis (Long)
Results 1 to 5 of 5

Thread: Internet Survival Time Analysis (Long)

  1. #1
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197

    Internet Survival Time Analysis (Long)

    This is my commented notes from a cursory examination of the logs I created. Ms. M asked about it and I thought it might be fun...

    Not wanting to put up a full blown honeypot at this point, (it's my work connection ) I found WormRadar, (www.wormradar.com). It allows you to emulate a couple of services, (IIS, FTP, Telnet), for a brief period before it cuts the connection with a FIN allowing such things as a login to the FTP server as anonymous or to see what the GET/Head etc. request is on HTTP. It then allows listening on a user defined series of ports both TCP and UDP. On these ports WormRadar seems to accept any data sent. It's an interesting little toy but the docs etc. on it's site are sadly lacking so you need to experiment to find out what it does. It takes captures and dumps them as Ethereal captures but the version is old and the most recent version of Ethereal sees the captures as being cut off in the middle of the packet. I get around this by running Ethereal in non-promiscuous mode in tandem with the WormRadar.

    Bear in mind, in many cases my box accepts the connection, let's it go on the built in configured ports for a short while depending upon interactivity available and then sends a FIN to simply close the connection. It's interesting to note that some connections issue an RST to the FIN while others tear the connection down appropriately.

    [Notes]

    File: 11-17-04
    Size: 37kb before cleanup 9kb after cleanup
    Duration: 11-16-04 16:48 EST - 11-17-04 08:04 (16 hours)
    Machine State: All ports closed


    Connecting machines:-

    2004-11-16 17:48:13 cras75p1.navix.net ICMP Echo Request
    2004-11-16 19:05:34.549532 205.78.56.72 Messenger Spam
    2004-11-16 19:15:53.114948 syr-24-59-222-187.twcny.rr.com Port(s) 4899, (RAdmin Backdoor)
    2004-11-16 21:21:52.571062 AC8358A0.ipt.aol.com Port(s) 3127, (MyDoom/AgoBot)
    2004-11-16 21:33:23.832544 220.112.46.149 Port(s) 4899, (RAdmin Backdoor)
    2004-11-16 21:52:56.353857 value.yam.com http > 48159 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0 (Scan)
    2004-11-16 23:56:42.097349 220-132-134-40.hinet-ip.hinet.net Laptop.jvsdet.org Port(s) 80, (http)
    2004-11-17 01:53:46.046246 dsl-134.sarnia.xcelco.on.ca Port(s) 1025, (MSRPC)
    2004-11-17 02:52:50.887391 211.144.125.207 ICMP Echo Request followed by Port(s) 57, (privterm), 1433, (ms-sql-s) (the port 57 often seems to proceed the 1433)
    2004-11-17 04:28:30.268062 cras75p28.navix.net Port(s) Auth, (returned from 10 hours previously.... Not automated, this is a person?)
    2004-11-17 06:48:51.461069 218.62.8.122 Port(s) 31138, (RST ACK) (unknown port with odd flags... Scan?)
    2004-11-17 07:39:28.285469 221.146.1.9 Port(s) 5554, (Sasser FTP), 1023, (Sasser.e FTP), 9898, (Dabber TFTP), Automated tool?
    2004-11-17 07:42:04.436364 i60-36-31-20.s04.a014.ap.plala.or.jp Port(s) 5554, (Sasser FTP), 1023, (Sasser.e FTP), 9898, (Dabber TFTP), Automated tool?
    2004-11-17 07:42:12.252212 zs146054.ppp.dion.ne.jp Port(s) 5554, (Sasser FTP), 1023, (Sasser.e FTP), 9898, (Dabber TFTP), Automated tool?
    2004-11-17 07:42:32.430278 203.234.166.107 Port(s) 5554, (Sasser FTP), 1023, (Sasser.e FTP), 9898, (Dabber TFTP), Automated tool?
    2004-11-17 07:43:15.566356 220.70.99.116 Port(s) 5554, (Sasser FTP), 1023, (Sasser.e FTP), 9898, (Dabber TFTP), Automated tool?

    At this point all ports on this box were closed so everything was responsed to with RST ACK except the unsolicited RST ACK packets which received no answer per RFC.

    The last 5 entries are regular as clockwork. I see them in my firewall logs every morning at about 07:00-08:00 EST. It has to be some sort of worm but it's morning activity, usually from Japan implies that an event triggers the activity though it isn't scheduled because the times vary by a little each morning, (up to 30 minutes either side of 07:30). Oddly enough it would be around 21:00 local time in Tokyo when they occur, (neither the beginning or the end of a work day).


    File: 11-22-04 (Captured the entire weekend)
    Size: 340kb before cleanup 304kb after cleanup
    Duration: 11-19-04 15:36 EST - 11-22-04 07:48 EST (64.5 hours)
    Machine State: Listening (the fun begins)


    Connecting machines:-

    2004-11-19 19:41:06.083930 211.225.252.58 Port(s) 25 (SMTP) - here come the spammers china9988@21cn.com, (I have seen this address for 2 years trying for open relays)
    2004-11-19 19:43:20.918324 doc-24-206-177-67.kw.tx.cebridge.net Port(s) 1433 (ms-sql-s) Sends SYN then FIN ACK in response to SYN ACK, (reconnaisance)
    2004-11-19 19:50:49.914647 82.52.159.13 Port(s) 3127, (MyDoom/AgoBot) Opens connection and uploads a complete executable. Interestingly is doesn't tear down the connection as normal it just sends an RST.
    2004-11-19 20:14:53.429964 205.122.28.10 Port(s) 21 (FTP) Just sent a SYN and moved on after the SYN ACK, half open or stealth scan for open FTP servers.
    2004-11-20 01:36:20.191575 cras75p28.navix.net ICMP Echo Request - This IP did the same on 11/16 - It may be innocuous network noise
    2004-11-20 03:08:41.245974 cpe0040ca4e898a-cm014500117663.cpe.net.cable.rogers.com Port(s) 5554 (Search for Sasser FTP), 9898 (Search for Dabber TFTP) - Scan only RST sent on receipt of SYN ACK
    2004-11-20 05:47:49.282859 tc222-156-14-212.adsl.dynamic.apol.com.tw Port(s) 25 - Spammer again, this time 84trdyfytf9746505@ms69.hinet.net
    2004-11-20 06:05:36.299941 dwby.k12.mn.us Port(s) 1433 (ms-sql-s) Made a complete connection then tore it down immediately. Different from second packet in this capture.
    2004-11-20 06:48:50.638874 222.101.92.127 port(s) 25 - Spammer again, this time gxs00xy6hhfk3ll@yahoo.com.au
    2004-11-20 07:32:49.527575 210.193.21.164 Port(s) 1433 (ms-sql-s) - Another complete connection then it gets torn down like the last but one connection
    2004-11-20 07:42:03.921251 220.87.38.112 Port(s) 1023 (Sasser.e search), 8967 (Sasser Shell), 9898 (Sasser Backdoor) - Seems to be Dabber itself -Sent data trying to log on to the server on 1023 - USER x PASS x Note the time.... Same approximate time as previous capture.
    2004-11-20 07:42:18.600657 i219-165-186-111.s02.a034.ap.plala.or.jp Port(s) Seems Like Dabber again
    2004-11-20 07:44:18.597202 p2202-ipad02kamokounan.kagoshima.ocn.ne.jp Port(S) Dabber again
    2004-11-20 08:03:42.428450 222.45.45.132 Port(s) 22 (SSH) No data captured... I wasn't listening on this port. But it was a half open scan - no response to SYN ACK
    2004-11-20 08:04:13.740932 220.87.47.41 Port(s) Back to Dabber again
    2004-11-20 08:18:19.791190 221.216.163.162 Port(s) Yawn... Dabber again
    2004-11-20 08:40:50.802160 221.194.50.63 Port(s) 1023 (Sasser.e search) - This was a reconnasance scan - RST sent in responseto the SYN ACK
    2004-11-20 08:42:28.012884 221.200.15.229 Port(s) Dabber yet again.....
    2004-11-20 11:30:33.001655 209.198.162.1 Port(s) 1433 (ms-sql-s) Reconnasance scan - Made complete connection and then tore it down.
    2004-11-20 11:52:19.205861 61.109.245.89 Port(s) 1433 (ms-sql-s) Reconnasance scan - Made complete connection and then tore it down as previous. (Slammer? Interesting article: http://www.cs.berkeley.edu/~nweaver/sapphire/)
    2004-11-20 12:08:23.404726 211.229.26.140 Port(s) 25 Spammer again. q306779@hotmail.com
    2004-11-20 13:10:16.777601 199.0.66.62 Port(s) 6129 (Dameware Remote Administration). Not listening on this port. No data captured
    2004-11-20 13:27:18.368413 211.225.154.205 Port(s) 4899 (RAdmin Backdoor) Not listening, no data captured
    2004-11-20 13:32:03.993344 61-231-175-57.dynamic.hinet.net Port(s) 4899 (RAdmin Backdoor), as above
    2004-11-20 13:42:16.057071 221.164.191.14 Port(s) Can we say "Dabber"
    2004-11-20 13:49:54.916903 doc-24-206-177-67.kw.tx.cebridge.net Port(s) 4000 (Witty Worm) - Not listening - no data captured
    2004-11-20 14:23:39.751707 syr-24-59-222-187.twcny.rr.com Port(s) 4899 (RAdmin) - See above
    2004-11-20 16:01:55.445512 c-66-176-129-85.se.client2.attbi.com Port(s) 1433 (ms-sql-s) Reconnaisance - responded with RST immediately after ACK - not the same as the slammer guess above
    2004-11-20 16:19:26.348042 200.60.125.126 Port(s) 113 (Auth) Not listening, no data captured
    2004-11-20 20:51:35.271815 co-colspgs-1-u2-b3-239.clspco.adelphia.net Port(s) 1433 (ms-sql-s) Slammer again? Complete build and tear down of connection.
    2004-11-20 22:17:09.922488 221.165.115.42 Port(s) 17300 (Kuang) - Not listening, no data captured
    2004-11-20 22:44:21.722237 lcmnys03.local.louiscapital.com Port(s) 3306 (MySQL) - Not listening, no data captured.
    2004-11-20 23:44:59.976735 host-66-81-128-123.rev.o1.com Port(s) 901 (SWAT - HTTP interface to Samba?) - not listening, no data captured
    2004-11-20 23:57:58.265570 61.109.27.23 901(SWAT - HTTP interface to Samba?) - not listening, no data captured
    2004-11-21 00:54:04.992899 66-215-12-127.gln-mres.charterpipeline.net Port(s) 17300 (Kuang) - Not listening, no data captured
    2004-11-21 01:36:24.091969 212.68.213.147 Port(s) 443 (SSL), 80 (HTTP). Complete connection followed by complete tear down on SSL - Reconnaisance. On HTTP GET /sumthin HTTP/1.0 - Reconnaisance
    2004-11-21 01:43:50.132125 pD958AA0A.dip.t-dialin.net Port(s) 6129 (MockBot?) Not listening, no data captured
    2004-11-21 02:27:23.214502 207.157.133.3 Port(s) 1257 (ShockWave) - Not Listening, no data captured
    2004-11-21 03:06:36.364882 205.137.171.196 Port(s) UDP 1026 (Messenger) - Messenger Spam
    2004-11-21 04:08:03.562430 210.22.194.14 Port(s) 111 (sunrpc) - Not Listening, no data captured
    2004-11-21 05:54:43.988087 205.227.63.58 UDP 1026 (Messenger) - Messenger Spam
    2004-11-21 05:54:44.482644 205.212.84.198 UDP 1026 (Messenger) - Messenger Spam
    2004-11-21 07:41:49.434479 220.77.151.40 Port(s) (Sasser.e Search) - Logon Attempt USER x PASS x
    2004-11-21 07:41:52.509311 222.101.126.107 Port(s) (Sasser.e Search) - Logon Attempt USER x PASS x
    The above two then did the entire Dabber thing across every port numerous times for a whole minute followed by
    2004-11-21 07:42:20.821019 218.155.242.16 doing the same thing
    2004-11-21 07:42:34.281791 220.85.254.238 doing the same thing
    2004-11-21 07:42:52.170097 220.77.151.40 doing the same thing It then all stops until
    2004-11-21 09:21:45.535966 cable-67-97-55-122.dct.al.charter.com Port(s) 4899 (RAdmin Backdoor) Not listening, no data captured
    2004-11-21 11:06:44.515771 209-77-36-46.ded.pacbell.net See Previous
    2004-11-21 15:51:06.736049 205.229.81.20 UDP 1026 (Messenger) - Messenger Spam
    2004-11-21 15:53:16.393767 211.53.122.69 Port(s) 4899 (RAdmin Backdoor) Not listening, no data
    2004-11-21 16:02:14.774334 61.84.118.28 Port(s) 25 (SMTP) Spammer uls33333rq3333cutub@yahoo.com.au
    2004-11-21 16:15:10.962715 203.230.172.23 Port(s) 4899 (RAdmin Backdoor) Not listening, no data
    2004-11-21 16:29:58.358751 211.186.23.237 Port(s) 4899 (RAdmin Backdoor) Not listening, no data
    004-11-21 16:53:18.076962 modemcable200.112-70-69.mc.videotron.ca Port(s) 4899 (RAdmin Backdoor) Not listening, no data
    2004-11-21 19:04:13.561505 210.82.34.169 Port(s) UDP 27015 (Half Life/Counterstrike) ooops....
    2004-11-21 22:54:57.572770 ACAD6F96.ipt.aol.com Port(s) 901 (SWAT - HTTP interface to Samba?) - not listening, no data captured
    2004-11-22 00:11:50.982698 206.170.79.121 Port(s) 1433 (ms-sql-s) Slammer again? Complete build and tear down of connection.
    2004-11-22 01:24:29.502773 61.109.245.89 Port(s) 1433 (ms-sql-s) This had a PSH ACK packet that referenced the SA of the server, (that doesn't exist), and it then properly tore down the connection.
    2004-11-22 01:35:31.515419 cras75p34.navix.net Port(s) 113 (Auth) - I'm beginning to think there's a reason for this... I just can't fathom it....
    2004-11-22 02:55:04.856885 218.38.56.40 Port(s) 22 (SSH) - Not listening, no data captured
    2004-11-22 03:06:17.763108 205.41.32.99 Port(s) UDP 1026 (Messenger) - Messenger Spam
    2004-11-22 03:08:35.407078 200.37.92.138 Port(s) 1433 (ms-sql-s) Slammer again? Complete build and tear down of connection.
    2004-11-22 03:13:24.134913 ba.slovakalarms.sk Port(s) 1433 (ms-sql-s) Slammer again? Complete build and tear down of connection.
    2004-11-22 03:15:40.286051 h209-139-218-162.gtcust.grouptelecom.net Slammer again? Complete build and tear down of connection.
    2004-11-22 05:29:37.421715 160.79.166.210 Port(s) 443 (SSL) Connection torn down properly
    2004-11-22 07:15:20.943653 208.154.199.8 ICMP Echo Request
    2004-11-22 07:23:40.701505 209.12.6.242 Port(s) 1433 (ms-sql-s) Slammer again? Complete build and tear down of connection.
    2004-11-22 07:41:44.313392 222.111.35.27 Can we say Dabber yet again????? NOTE THE TIME AGAIN
    2004-11-22 07:41:55.698996 60-56-73-254.eonet.ne.jp Dabber.....
    2004-11-22 07:42:13.689244 221.150.171.112 My early morning Dabber continues......
    2004-11-22 07:42:15.725346 220.72.204.155 And it goes on.....
    2004-11-22 07:42:42.203430 220.79.120.51 And on.......
    1512 2004-11-22 07:46:55.549290 222.118.94.46 And on....

    [/Notes]

    At this point I killed the capture.... 'cos I got to work and got to the box more than anything, (curiosity).

    I find it interesting that this stuff seems to come in batches.... If something starts it seems to kick off some other of the same thing too... It's like something out there kicks things off by doing something. Matbe when one Dabber starts and hits an already infected machine the machine that is hit kicks off too... I dunno, speculation....

    Interestingly enough there doesn't seem to have been anything that might have compromised this box automatically at any time, (unless I can't see something obvious) in the entire period, (some 80 hours of capture). I think the "survival time" figure is a little misleading... Misleading in that there are thousands of boxes worldwide monitoring and the overall time to compromise is read across all those boxes. Yet, in reality there are millions of boxes on the net and they aren't all scanned/hit by the same sample as the thousands of monitors.

    That being said, I still like the "survival time" for it's FUD value with regular users. I think it's a useful statistic in that arena. Eventually though, a separate hardware device such as a Linksys is invaluable.

    I'm going to "hone my skills" with the packet capture filters and the WormRadar so that I can more accurately capture some more intersting stuff and see what I get.... I'll report back anything interesting if anyone is interested.
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  2. #2
    Just a Virtualized Geek MrLinus's Avatar
    Join Date
    Sep 2001
    Location
    Redondo Beach, CA
    Posts
    7,324
    I'd certainly be interested in more live results.
    Goodbye, Mittens (1992-2008). My pillow will be cold without your purring beside my head
    Extra! Extra! Get your FREE copy of Insight Newsletter||MsMittens' HomePage

  3. #3

  4. #4
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    I'm running a capture over the weekend, (it's Thanksgiving holiday here for those not "up" on US culture), and I probably won't go in on friday.

    I have altered the ports that are "listening" to get rid of the sasser/dabber dross and the ms-sql-s stuff which is rife and really comes up with little of interest. I added in SSH and a few other things that look like they are frequent from the previous captures and may offer more interesting stuff....

    Interestingly, the wormradar emulates 135, 139 and 445 and I have yet to have a connect on them.

    What does peeve me about wormradar is that it updates a central system on port 82 every time you have an "incident" and regularly to show you the "world view". You can't stop this. Furthermore it sends an email to the author for every incident that you can't stop either. OK you all say just filter the capture for the IP addresses.... This is where I get _really_ bothered.... The author has it set up to report and mail to his home dsl connection.... Which rotates it's frigging IP address every few hours and he fixes that by using DynDNS or something... hence creating a filter works for the first few hours of the capture and then the log gets filled up with gallons of extraneous crap that has to be filtered, then refiltered ad nauseam just to get to the "meat" of the capture which can take some time... especially if you keep screwing up the saves....

    We'll see if I get some fun on monday.... It seems that the longer the thing is out there the more attention it seems to get.....

    Maybe on monday I'll throw up an FTP server with some "misconfiguration" and see if we can play with some skiddies....
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  5. #5
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    I've been a tad busy recently but I didn't want to let this go because it's quite fun.....

    The results from the Thanksgiving weekend have been siiting on my drive waiting to be looked at since monday and it bothers me. The base log, (single line per connection text file is about 366k), is attached. What I will do is take a "scoot" through it and annotate "interesting things " with the word "Tiger". What you can do is look at these notes and open the file in a text editor and do a find for "Tiger" then keep doing "Find Next" to keep jumping to the next point of interest....

    It's sort of a cursory exam but it is a little enlightening....

    I turned off the ms-sql-s listener because once some of them find it open they keep hammering away for hours even though the port has been closed.... I didn't want the extraneous rubbish so i ditched it.

    Notes:-

    1. This navix.net scanner for what appears to be various exploits is a little broken, (the checksum is bad.... ooops, bad programming...)

    2. This Navix.net box really like port 113, I have noticed it a lot in this log and subsequent logs... I'm not sure what it's trying to acheive, anyone have any thoughts. Notice also something that I said in my previous post regarding somethin happens and it seems to "kick off" other things.... Look at the other navix.net boxes that start trying right after this.... There has to be a "trigger" here....

    3. This is probably one of the SSH brute forcers but because it doesn't get the appropriate SSH response it throws another SYN and then quits on the original connection....

    4. Some worms just don't give up.... Even though the response to a SYN is RST ACK they keep sending SYN's.... like it's going to change... Kinda like some of my users that try to get to yahoo mail and get the "access denied" page and keep trying every hour to see if they can sneak by.... LOL

    5. Now this SSH brute forcer seems to have the right idea... It doesn't get what it wants so it RST's me and moved on.... There's more than one SSH brute forcer out there or was this a human? The timing indicates it could have been.... maybe....

    6. OMG.... Someone is looking for eDonkey..... Is there an exploit.... Won't find it here...

    7. In case you don't know these messenger things are spam looking for boxes with the Messenger service open and the message tells them they are owned and need to "click here" to fix their box.... Yes, if the messenger service is open the chances are high that there are more exploitable ports open too so the spam is right.... However, I wouldn't trust the solution....

    8. Got me a nice little executable here.... Used Ethereal to follow the conversation, saved it and scanned it thinking that if it is a known piece of malware the signature will be there and be recognized, it isn't.... I don't know if the sigs also have offsets etc. as part of them - I didn't think they would because it would make evasion too easy.... but maybe they do... any comments anyone?

    9. Here's a classic spammer.... Note the response from WormRadar... It does this a lot.... Accepts a bit of a conversation, suckering them in and then everything after results in a "command not supported" response.... gotta be frustrating if a human were sat on the other end.... Bummer....

    10. IIRC this was a different executable than the one in 8. I did the same and got no alarm from the AV.... I need to know if they employ offsets otherwise there are things being moved around that are unrecognized....

    11. Another unrecognized executable.....

    12. I don't recall exactly but this was a small exe that I didn't get a chance to look at.

    13. This was a biggie... Wormradar is emulating the Kuang2 trojan... Again... whole executable.... no recognition from AV.... I gotta think they use offsets in the sigs and the ethereal "follow conversation" messes them up.

    14. More stuff.... No time to AV it....

    15. More Kuang2.... Different from the first I seem to recall.... Not AV tested

    16. More Kuang... maybe same as the first seems different to the second.

    17. I guess I didn't do what 653217hfc38.tampabay.rr.com wanted the first time.... He came back..... LOL

    18. I'm skimming this so this may have happened before but this box sent a broadcast, (255.255.255.255), and then came right back on the same port to have a go at me.... then he tested almost everything even though my box doesn't seem to have replied to the broadcast.... I'll have to chack the filter on this though...

    19. It does look like my box might be responding to the broadcast and the filter is not showing it.... Gotta check that filter.....

    20. Odd... No outgoing packets.... but getting SYN ACK's... Spoof or mistake? Not enough to be some form of a DDoS...

    21. Here's an IMAP attempt, first I've seen and coincides with the two new IMAP exploits... early in the period... maybe it was just a 'spec" attempt and not related to the exploits.

    All in all, having been capturing the traffic for 10 days or more now and scanning the results this is all pretty "vanilla" stuff.... You will also notice that there are _no_, (I scanned... remember), connections that would exploit a new box on the net automatically.... They are all looking for previously exploited boxes.... Frankly I find that a little surprising.... I have no filters on the border router and this box is outside the firewall.... It is locked down... but the connection attempts would still show.....

    I'll try to keep this going and maybe keep making the box more vulnerable to see what happens..... But it's a comfort level issue.....
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

Posting Permissions

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