full-disclosure - Increase probe on UDP port 1026

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Increase probe on UDP port 1026

Paul Dokas <dokas@...umn.edu> replied to Nicob:

> > 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 ...

Sorry -- caught "one" what??  A local machine doing this type of 
scanning, or just similar incoming traffic?

> ... and doing popups
> directing people to www.PopAdStop.com.  The 1026/UDP and related traffic
> is *definitely* popup spam related.  ...

Yep -- if you send Windows Messenger traffic to the "right" port you 
need not have "initiated" anything through the port mapper first and it 
seems that enough more or less default W2K and XP machines will have 
Windows Messenger listening on 1026 to make this a worthwhile 
"spamming" target.

> ...  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.

Huh??

What malware?

If anything it is not at all clear what it is you have "detected".  If 
you have found a local machine doing this type of spamming I'm sure I'm 
not the only one interested in learning more about what has been 
installed on it (and how?)...

> BTW, I did `wget http://www.PopAdStop.com` a little bit ago.  Looks like
> they could win an obfuscated JavaScript contest.

Lessee...

index.htm == 13,082 bytes consisting of a trivial HTML header, a bunch 
of script that assigns long string values to a couple of variables, the 
script commands:

   e=unescape("%25%37%33[...]);
   eval(unescape(e));

and a noscript tag explaining the viewer must have JavaScript enabled 
in their browser to view the page.  Double-unescaping "e" you get a 
rather typical (for these types of thing) Caesar (sp?) cipher routine 
that uses the shorter of the two string variables as the index for 
decrypting the longer string, which turns out to be partially Unicode-
encoded HTML with the important part starting:

   document.write("\u003Ctable\u0020border\u003D\u00220\u0022[...]

In turn that decodes to a fairly straightforward page which links to a 
similarly obfuscated download page.

I'd say about par for the course these days, as far as web page 
obfuscation goes...

Regards,

Nick FitzGerald