Skip to main content

Joined #TOKUGAWA

The first track-back (reversal) I did was on some Japanese hackers who staged out of South America. Here's an excerpt from the log of the server they attacked:

200.165.33.242 - - [18/Jun/2006:19:16:50 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 51
200.165.33.242 - - [18/Jun/2006:20:32:28 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 62
200.165.33.242 - - [18/Jun/2006:20:32:34 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 6568
200.165.33.242 - - [18/Jun/2006:20:33:04 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 34
200.165.33.242 - - [18/Jun/2006:20:33:08 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 6564
200.165.33.242 - - [18/Jun/2006:20:33:14 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 34
200.165.33.242 - - [18/Jun/2006:20:33:19 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 6574
200.165.33.242 - - [18/Jun/2006:20:33:25 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 34
200.165.33.242 - - [18/Jun/2006:20:34:00 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 34
200.165.33.242 - - [18/Jun/2006:20:34:16 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 34
200.165.33.242 - - [18/Jun/2006:20:34:32 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 34
200.165.33.242 - - [18/Jun/2006:20:34:36 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 56
(***) 200.165.33.242 - - [18/Jun/2006:20:34:43 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 34
(***) 200.165.33.242 - - [18/Jun/2006:20:34:59 -0500] "GET /cartaoUOL/ HTTP/1.1" 200 43611

200.165.33.242 - - [18/Jun/2006:20:35:24 -0500] "GET /cartaoUOL/ HTTP/1.1" 200 43611
200.165.33.242 - - [18/Jun/2006:20:35:41 -0500] "GET /cartaoUOL/ HTTP/1.1" 200 43611
200.165.33.242 - - [18/Jun/2006:20:39:47 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 62
200.165.33.242 - - [18/Jun/2006:20:39:55 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 6574
200.165.33.242 - - [18/Jun/2006:20:40:00 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 52
200.165.33.242 - - [18/Jun/2006:20:40:09 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 34
200.165.33.242 - - [18/Jun/2006:21:07:48 -0500] "GET /cgi-bin/ikonboard.cgi HTTP/1.1" 200 62
200.165.33.242 - - [18/Jun/2006:21:08:25 -0500] "GET /cartaoUOL/ HTTP/1.1" 404 133

Note the tell-tale "ikonboard" which in 2006 had all sorts of security problems. What you should immediately see in this listing is the test of "cartaoUOL" with a 404, then some CGI work, then suddenly "cartaUOL" exists. That was the start of the exploit.

They went on to add their IRC bot for the C&C and start exploring the file system. They defaced the web site and caused all sorts of embarrassment. Their target was an athletic association that helped kids. Way to go h4x0r! 1337 skillz with milkshakes.

200.165.33.242 - that's a Brazilian IP, naked just like a brazilian. The IRC bot called back to irc.irchighway.net and connected to the #TOKUGAWA room. There it looked like the bot was trying to upload some 30MB file:

** 2005-11-08-20:38:29: DCC Send Accepted from Named: [animesquest]_imyme01.rm (30622KB)
** 2005-11-08-20:38:29: Upload Connection Established
** 2005-11-08-20:38:32: Upload: Connection closed: Connection Lost

All of this was happening on:

** 2005-11-08-20:37:55: NOTICE: :Named!named@76b3cfb.3d716d1f.telesp.net.br NOTICE TK|Sasuke :DCC Chat (200.158.244.210)

200.158.244.210 was also Brazil. It's Telefonica now.

The ISP hosting the site ran a scan of the virtual host and found some compromised files. 

www/cgi-bin/
bindz : Backdoor.Trojan
php : replacement script for PHP executable
sn : unknown script/executable
sitevars : help script
www/
new.cmd : Infostealer.Bancos

They were able to do this because the web process was running elevated and had permission to write over itself. Something more common in 2005 than in 2016, thankfully.

They left their "snarf.c" and its compiled executable. Mostly these were amateur hackers who were just experimenting with a site that was very unsecured. I remember digging into their irc traffic and finding some irc logs published on the internet. That's where I learned that they were Japanese and had been using another relay "jump" node out of Uruguay. I don't have records on that anymore.

The owners of those IP addresses back in 2006:

inetnum: 201.14/16
aut-num: AS8167
abuse-c: BTA17
owner: Brasil Telecom S/A - Filial Distrito Federal
ownerid: 076.535.764/0326-90
responsible: Brasil Telecom S. A. - CNRS
address: SEPS 702/092 Cj. B - Bl B 3 andar Gen. Alencastro, S/N,
address: 70390-025 - Brasilia - DF

inetnum: 200.165/16
aut-num: AS7738
abuse-c: CGR13
owner: Telemar Norte Leste S.A.
ownerid: 002.558.134/0001-58
responsible: Marlemar Telgon
address: Rua Humberto de Campos, 425, 7ยบ andar
address: 22430-190 - Rio de Janeiro - RJ


Popular posts from this blog

Number of Primes

Anderson's Theorem (a) The number of primes in [1,n] is no more than 2+floor(n/2). The probability of n being prime when n is not prime is 1/2 - see Dasgupta,Papadimitriou,Vazirani "Algorithms" page 26. Therefore, the E(pi(n)) is n/2. (b) There does not exist another set of adjacent primes other than {1,2,3} 5: 2 + floor(5/2) = 2 + 2 = 4:=> {1,2,3,5} : 4 <= 4 7: 2 + floor(7/2) = 2 + 3 = 5 => {1,2,3,5,7} : 5 <= 5 11: 2 + floor(11/2) = 2 + 5 = 7 => {1,2,3,5,7,11} 6 <= 7 26: 2 + floor(26/2) = 15 => {1,2,3,5,7,11,13,17,19,23} : 10 <= 15 Lagrange's Theorem is Inaccurate Lagrange's theorem about primes states that pi(x) is the number of primes <= x. The pi(x) is approximately x/ln(x). He postulated that the lim of pi(x)/(x/lnx) as x-> infinity was 1. This is incorrect. if the number of primes is bounded by n/2 then refactoring and reducing Lagrange's Theorem results in the lim of ln(x) as x approaches infinity. This is alwa...
Read more

How To Cancel ATT Uverse

I was a subscriber to the AT&T Uverse service for a little over 2 years. In that time, we had experienced good service for the first year, and then it sucked. After 12 months, or there in, the service degraded quickly, and would stop working all together at times. At first it would die for a short period of time, usually when we were not home. Then it would get progressively worst, until there was an entire week of no service. We had technicians at the house trying to fix the service, but it would repeat the behavior quite consistently. On January 15th we finally gave up and switched to a lesser service, COX TV and Internet. In the past we had cable service and it was always reliable, but not as good as the AT&T digital service. COX doesn't have nearly as many HD channels, but that's not enough. We needed internet to be reliable, and AT&T couldn't deliver that. Cancelling the AT&T service was a nightmare. Try to find anything about such things on their web s...
Read more

DNS Custom Logs and selinux

If you google "named custom logs selinux" you will find quite a bit of chatter about setting up custom logs outside of /var/log for DNS (named). These posts are interesting, but they tend to be run on posts about learning selinux and becoming an expert on named. What you need to know? If you have setup custom logging locations in your /etc/named.conf file, such as:     channel default_file {         file "/var/log/named/default.log" versions 3 size 5m;         severity dynamic;         print-time yes;     }; Then you will likely see errors like this in /var/log/messages: Oct 26 11:41:13 namedsvr setroubleshoot: SELinux is preventing /usr/sbin/named from write access on the directory /var/named/chroot/var/log/named. For complete SELinux messages. run sealert -l 6eab4aaf-e615-4ade-9e88-4efdc789eaf2 Then you run the sealert command as suggested by the very friendly selinux audit log and yo...
Read more