full-disclosure - Empty emails example

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>] [day] [month] [year] [list]

From: full-disclosure at royds.net (Bill Royds)
Subject: Empty emails example

Here is another one. The last Received line is definitely fake. It uses an
unused IP address range.
I think it actually is Trojan machines being tested by spammer before being
used in spam run. 

-----Original Message-----
From: Martijn Lievaart [mailto:m@...j.nl] 
Sent: February 28, 2004 5:36 PM
To: Bill Royds
Subject: Re: [Full-Disclosure] Empty emails example

Bill Royds wrote:

>I am still getting a lot of empty emails and noticed a peculiar similarity.
>All of them use a compromised or open relay home hispeed network connection
>to bounce the message.
>Here are the headers from one I just received ( others are similar but with
>different relay points).
>
>
>  
>
>>Return-Path: <ZVIFHFGZRZI@...oo.com>
>>Received: from h0010b59bf977.ne.client2.attbi.com ([24.147.39.6])
>>          by fep02-mail.bloor.is.net.cable.rogers.com
>>          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with SMTP
>>          id
>>    
>>
><20040228195530.WTUH244767.fep02-mail.bloor.is.net.cable.rogers.com@...10b5
9
>bf977.ne.client2.attbi.com>;
>  
>
>>          Sat, 28 Feb 2004 14:55:30 -0500
>>Received: from 80.76.205.232 by 24.147.39.6; Sun, 29 Feb 2004 00:46:57
>>    
>>
>+0500
>  
>
>>Message-ID: <Y[20
>>Date: Sat, 28 Feb 2004 14:55:31 -0500
>>
>>    
>>
>
>The return path is an obvious fake
>
>The immediate relay point is a cable modem customer
>
>The seeming original sender is a British company with domain
>tradeelectronically.com which is a hosting service.
>
>Are others seeing this pattern?
>
>  
>

That header is most probably fake. My guess is that 24.147.39.6 is a 
"zombie", a troyaned windows box. I see a lot of those spams. I proved 
those boxes are plain windows clients not running any mailserver. So how 
can they insert a received header if they are not running a MTA?

As Julian Height already noted, spammers get to the point where they can 
actually fake a correct received header... :-)

M4