Help Identify Trojan

[John Coutts]

When I noticed a lot of similar Spam (particulary penus enhancing patch) coming
from a lot of different sources, I started looking for similarities. What I
found was a common set of open ports (17878, 17879, 17880). 17880 will not
respond if it is currently in use.

This looks very much like a Backdoor Trojan similar to Backdoor.Jeem, but it
does not respond to a telnet and I am having trouble identifying it. Any help
would be much appreciated.

J.A. Coutts
Systems Engineer
MantaNet/TravPro

 

[wsb1234null]

This looks very much like a Backdoor Trojan similar to Backdoor.Jeem, but it
does not respond to a telnet and I am having trouble identifying it. Any help
would be much appreciated.

Would it not make just a whole lot more sense to just send a copy to
an AV company for analysis rather than depend upon the guesswork of
others?

 

[John Coutts]

Would it not make just a whole lot more sense to just send a copy to
an AV company for analysis rather than depend upon the guesswork of
others?

************* REPLY SEPARATER **************
That's the whole point. I do not have a copy of the Spam Engine because it is
being used on a large number of machines around the world (mostly North
America) to spam our domain. I tracked it down by doing a port scan on the
offending machines. I need to know what protocol to use on these ports to
verify that it is a Backdoor Trojan.

 

[Nomen Nescio]

Trojan. Download and run a copy of The Cleaner from moosoft.com

 

[Nick FitzGerald]

That's the whole point. I do not have a copy of the Spam Engine because it is
being used on a large number of machines around the world (mostly North
America) to spam our domain. I tracked it down by doing a port scan on the
offending machines. I need to know what protocol to use on these ports to
verify that it is a Backdoor Trojan.

And you have what authority to port-scan these machines?

I note in your first post you signed off:

J.A. Coutts
Systems Engineer
MantaNet/TravPro

You should know that port-scanning alone is considered by many to be a
"hostile act", so therefore it is at best a dubious "tool" for a
professional sysadmin to use.

Regardless though, even if port-scanning machines over which you admit
you have no administrative authority is not problematic (some argue
quite strongly for this position, so I'll allow it even though it is
fundamentally bogus for other, non-ethical reasons) even red-neck
sysadmins from Edson, Alberta would have to admit that actually
connecting to and remotely poking around on a machine over which s/he
had no administrative authority was liable to get them in trouble with
the RCMP cybercrime division if they were ever reported by sites they
"attacked" thus...

I'll put it simply for you John -- it's none of your firking buisiness
what s/w is running on those machines. If they are "attacking" you
with spam then report them to their sysadmins (probably the abuse@...
address for their ISP, right?). If you get no result then black-hole
them or their whole IP block or adjust to the fact that, for better or
worse, that is the way the Internet is. I mean fercrissakes -- what
do you expect when you connect to a network with no built in traffic
authentication mechanisms, no minimum technical, ethical or any other
requirements of the folks ahop are allowed to connect machines, and so
on??? (Oh, and before answering, note that a cowboy like you is not
only allowed on this network but is apparently sufficiently qualified
to get the exalted job title of "Systems Engineer" -- Hmmmmm...)

 

[John Galt]

And you have what authority to port-scan these machines?

What authoritiy is needed?

I note in your first post you signed off:


You should know that port-scanning alone is considered by many to be a
"hostile act", so therefore it is at best a dubious "tool" for a
professional sysadmin to use.

Hypothetically, let's say I configured my mail server as follows:

------------------
look up connecting
IP in local
blacklist
------------------
|
V
____---^---____ --------------------------------------
< Is IP listed? >--- Yes --->| Refuse connection w/553 - Rejected |
---___ ___--- | Shut down TCP connection. |
\ / --------------------------------------
| No
V
------------------
Look up connecting
IP in local
whitelist
------------------
|
V
____---^---____ --------------------------------------
< Is IP listed? >--- Yes --->| Accept message for delivery. |
---___ ___--- --------------------------------------
\ /
| No
V
-----------------------
Refuse connection with
451 Service temporarily
unavailable.
-----------------------
|
V
---------------------
Port scan originating
IP address. (Look for
trojans, worms, open
RPC ports, open SOCKS,
open proxies, etc.)
Probe and identify
any open ports if
possible.
---------------------
|
V
_____----^----______ -----------------------------
< Is IP compromised? >--- Yes --->| Add IP to local blacklist |
----____ ____----- -----------------------------
\ /
| No
V
-------------------------
Add IP to local whitelist
-------------------------

My apologies for the ASCII graphics, I hope I got the point across.

Note that my port scan is purely a defensive measure. I want to know
if a host is already compromised, and if it is, I will refuse inbound
(email) connections from that host. I have no interest in exploiting
any weaknesses I find or accessing any data on the target of the scan.
I am using the information from the port scan as a method of
determining if I will allow that host access to my network.

Can I set a policy that I will not allow compromised hosts access to
my network? How else can I implement that policy?

Regardless though, even if port-scanning machines over which you admit
you have no administrative authority is not problematic (some argue
quite strongly for this position, so I'll allow it even though it is
fundamentally bogus for other, non-ethical reasons)

What is bogus about the example I gave?

even red-neck
sysadmins from Edson, Alberta would have to admit that actually
connecting to and remotely poking around on a machine over which s/he
had no administrative authority was liable to get them in trouble with
the RCMP cybercrime division if they were ever reported by sites they
"attacked" thus...

I'll put it simply for you John -- it's none of your firking buisiness
what s/w is running on those machines.

Really? In my example, I should just accept or reject the connection
on incomplete data and either assume that the machine is not
compromised and the connection is legitimate or waste my valuable
bandwidth discovering that the machine is sending me malicious code
(probably without the knowledge of the machine's owner) or unsolicited
advertising for penis enlargments, online casinos and online porn.

 

[David W. Hodgins]

What authoritiy is needed?
Hypothetically, let's say I configured my mail server as follows:

In my opinion, when they connect to your mail server, to try and send
you mail, that is all the authority you need, to scan their system,
for obvious relay, or proxy ports.

Regards, Dave Hodgins

Change nospam.invalid to rogers.com to reply by email.

 

[Gabriele Neukam]

On that special day, John Galt, ([email protected]) said...

Note that my port scan is purely a defensive measure. I want to know
if a host is already compromised, and if it is, I will refuse inbound
(email) connections from that host. I have no interest in exploiting
any weaknesses I find or accessing any data on the target of the scan.
I am using the information from the port scan as a method of
determining if I will allow that host access to my network.

The problem is, not all scans are done directly. There exists an
indirect method to check whether a service is running, by using another
idle machine and a nearly forgotten thing called IP-ID.

www.research.att.com/~smb/papers/fnat.pdf
http://www.sysattack.com/english/ipid.php
http://www.security-express.com/archives/bugtraq/1999-q4/0205.html


Gabriele Neukam

(e-mail address removed)

 

[David W. Hodgins]

The problem is, not all scans are done directly. There exists an
indirect method to check whether a service is running, by using another
idle machine and a nearly forgotten thing called IP-ID.

But he isn't responding to port scan attempts. He's running limited
port scans, on systems that have connected to send mail (very hard
to spoof). I see no problem with this.

Regards, Dave Hodgins

 

[John Galt]

Flowchart clipped, recapping for NANAE readers new to this thread, the
logic went like this:

Mail connection is requested by some remote host.
Look up remote host IP in local blacklist, if found in blacklist,
terminate connection with 550-Rejected.
Look up remote host IP in local whitelist, if found, accept connection
and deliver mail.
If remote host IP is in neither blacklist nor whitelist, do the
following:
{ Temporarily block connection with 450-Service temporarily
unavailable.
Portscan remote host IP to check for Trojans, open proxies,
vulnerable RPC services that are open, etc.
If remote host appears compromised, add to blacklist
(with a fairly short [3 days or so] expiry time).
If remote host appears reasonably secured, add to whitelist
(with a longer [2 to 3 weeks] expiry time).
}

In my opinion, when they connect to your mail server, to try and send
you mail, that is all the authority you need, to scan their system,
for obvious relay, or proxy ports.

So, you would not object to me scanning port 80 or port 1080 on any
system that connects to my mail server.

What about ports like 12345 (NetBus) and 16959 (SubSeven)? Can I look
at those ports. I can tell you absolutely that any system that has
sent mail to me that had either of those ports open, the email was
unwanted (and often dangerous). Can I set a policy that I don't accept
mail from hosts with those ports open? If that is my policy, I would
have to scan those ports in order to decide whether to accept mail
from any host trying to send mail to me. Am I evil for scanning those
ports to decide whether to accept e-mail from an unknown host?

What about ports like 593 and 135 and 445 on Windows machines? Can I
scan those? Can I probe them for version information or somehow
determine if they are the completely unsecured, unpatched versions or
the slightly more secure patched versions?

In short, if it's reasonable for me to have a policy that I don't
accept mail from compromised systems, and I think that is a reasonable
policy, how do I implement that and what is unacceptable in gathering
information to make the determination that a host is uncompromised?

 

[David W. Hodgins]

In short, if it's reasonable for me to have a policy that I don't
accept mail from compromised systems, and I think that is a reasonable

Of course. Your server, your rules.

policy, how do I implement that and what is unacceptable in gathering
information to make the determination that a host is uncompromised?

As long as you're only scanning systems, that have initiated contact
with you, and you're only checking for open ports (not trying anything
like testing for rpc vulnerability, which could crash a server), I
don't see any problem here.

If they want you to accept email from them (which could contain
malware), checking their system for obvious signs of trojan
infection, seems to me, to be something all mailservers should do.

Your procedure limits the scanning to the first attempt to send
mail to you. I'd increase the scanning to something like the
first attempt each day, or each week, or whatever you're comfortable
with. If the system owner doesn't want you scanning their system,
they don't have to send mail to you.

Regards, Dave Hodgins