[Dshield] anti-mydoom worm

Andy Streule andy.streule at lythamhigh.lancs.sch.uk
Thu Feb 12 14:24:38 GMT 2004

Just noticed it on the register site. 


"A new variant of the Nachi worm which attempts to cleanse computers
infected by MyDoom and download Microsoft security patches to unprotected
computers has careened onto the Net this morning. "

sophos http://www.sophos.com/virusinfo/analyses/w32nachib.html

it's all going mad I tell you.


Technical Support
Lytham St. Annes High Technology College

-----Original Message-----
From: Jon R. Kibler [mailto:Jon.Kibler at aset.com]
Sent: 12 February 2004 14:00
To: General DShield Discussion List
Subject: Re: [Dshield] Scans occurring in large bursts

Stephane Grobety wrote:
> JRK> I thought about a decoy nmap scan, but it left me without an
> JRK> explanation for the ICMP 3/31 traffic that seems related. Also,
> JRK> it appears to be scans more oriented towards finding open proxy
> JRK> servers (except for the 53/tcp and 111/tcp probes).
> Well, without knowing your configuration, I would hazard that it could
> simply be the machine scanned sending back a SYN-ACK packet back to
> the decoy IP. The ICMP traffic you're seeing is simply the target
> network telling your machine that it doesn't want your packets.

The router simply drops all packets -- no feedback to the connecting system.
Also, the ICMP traffic is usually 10/8 source IPs.

> That being said, the decoy technique is not specific to namp: it's
> rather trivial to implement it on another scanner.
> JRK> I was hoping that someone else would say, "yes, I've seen that
> JRK> and snort says it is...". Unfortunately, we run snort behind the
> JRK> router so it does us no good in this case.
> Unfortunately, I can't help you there. The only thing in my logs that
> could be remotely related to your situation is the strange SMTP
> connections I see on my mail server: several completely unrelated
> machines connecting in a very short time frame (10-20 seconds),
> grabbing the banner and disconnecting. These machine are from
> different networks all over the planet (well, the networks that aren't
> automatically denied SMTP connection, that is) and they do complete
> the 3 way handshake so they are not spoofed.

This is one that I can easily explain! First, the apparently unrelated
machines are not unrelated. They are all under the central control of
a spammer somewhere. (This is one of the techniques we use to backtrack
and find spammers.) Why grab the banner? Several reasons: To determine
that a mail server is running on that IP; to determine the mail server
software and version; and, most importantly, to find out the domain you
claim to be serving on that IP. The spammer builds a database of such
information to use to later exploit the mail server. For example, using
the domain name the mail server claims to be serving, the spamware
collects all the email addresses in their database associated with that
domain, connects directly to that mail server, and attempts to send spam.
Why that approach? To exploit secondary mail servers that may not include
spam and virus filtering, thus resulting in the successful delivery of
junk that may otherwise be blocked if the spammer tried to use the mail
server indicated by the domain's MX records.

A few other points:
 -- You will always find that the systems connecting in the manner you
    describe are either running proxy servers or spamware of some sort.
 -- You should always configure your firewall to limit SMTP MTA port
    connections to only your real incoming mail server; you should block
    all SMTP MSA port connections that do not originate from your local
 -- If your incoming mail server is not the mail server listed in your
    MX records, then you should limit connections to that mail server
    to the authoritative server that first receives your mail.
 -- You should configure all your MTAs to NOT disclose the version of
    your MTA and you should disable your MTA's SMTP help file as well.
 -- Finally, if you haven't already done so, disable your MTA's ability
    to respond to the SMTP VRFY, EXPN, and ETRN commands, and to refuse
    server return-receipt delivery requests.

Hope this helps!


Jon R. Kibler
Chief Technical Officer
A.S.E.T., Inc.
Charleston, SC  USA
(843) 849-8214

Filtered by: TRUSTEM.COM's Email Filtering Service
No Spam. No Viruses. Just Good Clean Email.

This e-mail is confidential and privileged.  If you are not the intended
recipient do not disclose, copy or distribute information in this e-mail
or take any action in reliance on its content.

This email has been checked for known viruses. 

More information about the list mailing list