Security Incidents mailing list archives

RE: A new hack tool - tcp port 3139 ?


From: <METE.EMINAGAOGLU () DIGITALPLATFORM com>
Date: Sat, 16 Mar 2002 00:49:42 +0200

What about this one? A fresh news ... http://www.securiteam.com/tools/5WP08206KU.html

<quote> The Reverse-WWW-Tunnel-Backdoor is proof-of-concept Perl program for the paper "Placing Backdoors through 
Firewalls". It allows communicating with a shell through firewalls and proxy servers by imitating web traffic. The 
master/slave relation is reversed; therefore no listening ports are used on the target machine. ........

In that info, the source code is given. Perhaps the chosen random proxy port (in the code at that link it' s sampled as 
PROXY_PORT="3128"; ) was 3139, and the outsiders were the ones infected with this tool and was trying to get through 
our FW via port 3139... 


-----Original Message-----
From: Kelly Martin [mailto:kmartin () pyrzqxgl org]
Sent: Friday, March 15, 2002 11:42 PM
To: METE EMINAGAOGLU (IT)
Subject: Re: A new hack tool - tcp port 3139 ?


My guess, based on my parsing of your rather fractured description of the
traffic, is that these are probably return packets coming back to servers on
your network that are sending stuff out FROM port 80 TO port 3139.  I
checked my firewall log here, and the only port 3139 traffic is incoming
Nimda traffic being blocked by the firewall FROM infected machines outside
the network TO targeted hosts on my network.  If the packets you are seeing
are from port 3139 on an external host to PAT ports on your firewall
external address, and the PAT translates to port 80 on an internal host,
what you have is an external host sending a return packet (TCP ACK, TCP RST,
TCP FIN, or return channel traffic) to a packet originating from hosts on
your network going outbound.  I'd suggest capturing the traffic and closely
examining the hosts on your network that are the recipients of this traffic
to find out what they're sending out, as the odds are that they have been
compromised in some way.

Kelly

----- Original Message -----
From: <METE.EMINAGAOGLU () DIGITALPLATFORM com>
To: <kmartin () pyrzqxgl org>
Sent: Friday, March 15, 2002 3:22 PM
Subject: RE: A new hack tool - tcp port 3139 ?


Exactly not.

Nimda and such other worms, viruses are scanned both  in the LAN, and DMZ'
s, etc.

Also, these requests are coming from outside, and dropped by my FW.

And also, no Nimda variant (as far as i know) uses port 3139...

I' ve posted this because I' m curious about it, (reminds of some Trinoo,
and some trojans from the past :):)


-----Original Message-----
From: Kelly Martin [mailto:kmartin () pyrzqxgl org]
Sent: Friday, March 15, 2002 11:18 PM
To: METE EMINAGAOGLU (IT)
Subject: Re: A new hack tool - tcp port 3139 ?


If I had to guess, I'd say you probably have a machine on your network with
a Nimda infection.

Kelly

----- Original Message -----
From: <METE.EMINAGAOGLU () DIGITALPLATFORM com>
To: <incidents () securityfocus com>
Sent: Friday, March 15, 2002 1:24 PM
Subject: A new hack tool - tcp port 3139 ?


Hi to all,

Beginning from 6th of March until today, I' ve been continously observing a
very strange and presumably dangerous probe (possibly caused by a new trojan
or trojan-like tool) in my Firewall logs.

The source IP is different real-world IP' s, the destination IP is always my
FW' s outer interface IP, and the service port is tcp 3139.

However, it' s s.thing like a "masked" action. Because, when I analyse the
logs in detail, Xlate Dest IP' s are any of our DMZ IP' s (random), and the
Xlate Destin Port is,

tcp 80 - http !!!

Has anyone faced this similar oddity? I' ve searched all the sec. sites,
news, but nope!!!

Thanks in advance...

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com


----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com


Current thread: