[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200312021915.57683.capegeo@opengroup.org>
From: capegeo at opengroup.org (George Capehart)
Subject: Increase probe on UDP port 1026
On Tuesday 02 December 2003 04:21 pm, Paul Dokas wrote:
> On Tue, 02 Dec 2003 10:16:23 +0100 Nicob <nicob@...ob.net> wrote:
> > I captured some packets and it appears to be (only) a Windows
> > Messenger "spam" for a "penis enlargement" product.
>
> I caught one last night scanning 1026/UDP and 1030/UDP and doing
> popups directing people to www.PopAdStop.com. The 1026/UDP and
> related traffic is *definitely* popup spam related. At this point, I
> suspect that the malware is getting onto computers via .HTA mime or
> ADODB.Stream vulnerabilites in IE. However, I have no proof of this
> yet.
>
> BTW, I did `wget http://www.PopAdStop.com` a little bit ago. Looks
> like they could win an obfuscated JavaScript contest.
Heh. Out of curiosity, I tried to get there just now (1845 EST - GMT
-5). Interesting results. Firstly, wget complained about not being
able to resolve www.popadstop.com. Dig(1)ing for *.popadstop.com got
nothing. Whois for popadstop.com shows that it is registered at TUCOWS
by NewestStuff.com LLC and the nameservers for popadstop.com are ns1
and ns2.neweststuff.net. Whois for neweststuff.net just also happens
to be NewestStuff.com LLC.
If one digs for the IP address for www.popadstop.com @ns1.newstuff.com,
it bombs. However, if on digs for the IP address of www.popadstop.com
@IPAddressofns1.newstuff.net (from whois), one gets a reply
(66.225.219.162), it seems that they have been removed from the world.
To make a long story very short, it looks like www.popadstop.com is no
longer on the air and newstuff.net's nameservers are no longer listed
in DNS. They are on the air, but DNS can't resolve their addresses
from their names.
Interesting.
>
>
> Paul
--
George Capehart
capegeo at opengroup dot org
PGP Key ID: 0x63F0F642 available on most public key servers
"It is always possible to agglutenate multiple separate problems into a
single complex interdependent solution. In most cases this is a bad
idea." -- RFC 1925
Powered by blists - more mailing lists