[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ISN] Swen identification and response
Forwarded from: "Rob, grandpa of Ryan, Trevor, Devon & Hannah" <rslade@xxxxxxxxx>
It is time, and past time, for the network community to start taking
serious action to clean up the flood of Swen that has been going on
for over a week. Typical server-based virus scanning tools may
respond to the existence of an infected message, but likely respond to
the FROM line in the header, which is spoofed in the case of Swen (and
many others). However, Swen does seem to provide for identification
of the infected user.
Swen is difficult to identify from the sender or subject information.
Swen can be identified by most virus scanners. The quickest and
easiest way to identify Swen may be by the size of the messages.
Swen has two very distinct forms. One generates a message roughly
143K in size, and the other roughly 156K in size. You will usually
receive one of each form from an infected machine, generally in close
The 156K version always contains a message body that starts out with:
this is the latest version of security update, the "September 2003,
Cumulative Patch" update which fixes all known security
vulnerabilities affecting MS Internet Explorer, MS Outlook and MS
Outlook Express. Install now to protect your computer from these
vulnerabilities, the most serious of which could allow an attacker to
run executable on your computer. This update includes the
functionality = of all previously released patches.
The message contains two gif attachments, and one executable, which uses the
msdownload vulnerability, and so the message body contains the string:
Content-Type: application/x-msdownload; name="[variable].exe"
The subject almost universally ends with "upgrade" "Update" "Upgrade" "Patch"
The sender name field is polymorphically generated frequently using
the words Internet, Microsoft, or MS, and often Security, Corporation,
Customer, Bulletin, Assistance, Division, Program, Department,
Section, or Technical. The sender address uses a randomly generated
username, sometimes a generic domain (ywbclobaqneqbh@xxxxxxxxxxx),
sometimes a random domain (rdarqmllhdedqx_zyyywtd@xxxxxxxxx), but
frequently names that appear to be associated with Microsoft
Except for the fact that it uses the iframe vulnerability, the 143K
version may be more difficult to identify automatically. Many mail
systems do not recognize messages formatted to use the iframe
vulnerability as having an attachment, and so these messages may not
be completely scanned for viruses by some server based scanners. The
subjects used are those normally used for bounced or rejected
messages, as well as some such as "Bug report." The sender names used
are also very common, such as Admin and Administrator. Sender
addresses are polymorphically generated. giving results like
mailengine, mailerform, mailerroutine, mailrobot, webroutine,
imailprogram, postform, amailbot, smtprobot, masterdaemon,
postautomat, or webautomat at various common mail domain names.
Message headers (somewhat edited for brevity) typically contain:
Received: from mail00.svc.cra.dublin.eircom.net ([126.96.36.199])
Received: from p145-175.as1.mvw.galway.eircom.net (HELO lgonmo)
by mail00.svc.cra.dublin.eircom.net (qp 83441) with SMTP; 27 Sep 2003
FROM: "Microsoft Security Assistance" <selkmkyiuq@xxxxxxxxxxxxxxxx>
Received: from smtp.austarmetro.com.au ([188.8.131.52]) by orval.sprint.ca
Received: from tyhsbtop (dialup-184.108.40.206.acc03-dryb-
by smtp.austarmetro.com.au (8.12.6/pre1.0-MySQL/8.12.6) with SMTP id
Sat, 27 Sep 2003 09:58:22 +1000
Date: Sat, 27 Sep 2003 09:58:22 +1000
FROM: "Net Mail Storage Service" <kmailrobot@xxxxxxxxxxx>
Note that the Return-Path line does not agree with the FROM line
(which fact can, itself, be used as a partial identifier), but *does*
generally agree with the Received lines and the Message-Id.
Therefore, it is likely that the Return-Path does identify the
infected user or machine. (When IP addresses are checked, they also
generally agree with the domain found.)
Therefore, when infected messages are detected, a message should be
returned to the user, using the Return-Path identification, alerting
them to the existence of the infected messages. Given that the user
may not be aware of actions to take in regard to a virus infection,
copies of the message should probably be sent to the postmaster,
abuse, and/or support accounts at the same domain. (If the IP address
is checked and returns a slightly different domain, that abuse account
should probably be copied as well.)
If we can start *properly* alerting users to infections, we may be
able to reduce the virus load much more quickly than simply letting
the infection run its course.
(Letting delinquent ISPs know may also help. Charter.net seem to have
cleaned up their act, but BTConnect, BTInternet, and BTOpenWorld, a
number of Italian, and not a few Australian ISPs seem to be well
represented in the samples I've found.)
====================== (quote inserted randomly by Pegasus Mailer)
rslade@xxxxxxxxx slade@xxxxxxxxxxxxxx rslade@xxxxxxxxxxxxxxxx
After attacking the sacred majesty of kings, I shall scarcely
excite surprise by adding my firm persuasion that every
profession, in which great subordination of rank constitutes its
power, is highly injurious to morality.
Mary Wollstoncraft (1759-1797), A Vindication of the Rights of Woman
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
ISN is currently hosted by Attrition.org
To unsubscribe email majordomo@xxxxxxxxxxxxx with 'unsubscribe isn'
in the BODY of the mail.