[Dshield] anti-mydoom worm

Doug White doug at clickdoug.com
Thu Feb 12 17:47:30 GMT 2004

Old news,  Article dated December 2.

Stop spam on your domain, Anti-spam solutions
For hosting solutions http://www.clickdoug.com
Aspire to Inspire before you Retire or Expire!

----- Original Message ----- 
From: "Andy Streule" <andy.streule at lythamhigh.lancs.sch.uk>
To: "'General DShield Discussion List'" <list at dshield.org>
Sent: Thursday, February 12, 2004 8:24 AM
Subject: [Dshield] anti-mydoom worm

: Just noticed it on the register site.
: http://www.theregister.co.uk/content/56/35524.html
: "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.
: ~Andy
: ============================================
: Technical Support
: Lytham St. Annes High Technology College
: http://www.lythamhigh.lancs.sch.uk
: -----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
:     network.
:  -- 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
: -- 
: 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
: http://www.trustem.com/
: 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.
: ***************************************************************************
: _______________________________________________
: list mailing list
: list at dshield.org
: To change your subscription options (or unsubscribe), see:

More information about the list mailing list