Convincing look OWA fake leads to PDF exploit

There are getting spammed out at the moment:

From: automailer@blahblah.blah [mailto:automailer@blahblah.blah]
Sent: 13 January 2010 11:08
To: Victim Username
Subject: The settings for the username@blahblah.blah mailbox were changed

Dear user of the blahblah.blah mailing service!

We are informing you that because of the security upgrade of the mailing service your mailbox (username@blahblah.blah) settings were changed. In order to apply the new set of settings click on the following link:

http://blahblah.blah/owa/service_directory/settings.php?email=username@blahblah.blah&from=blahblah.blah&fromname=username

Best regards, blahblah.blah Technical Support.

Letter ID#NGTS7OTY8XPZX8FEUYTTTZ1PF

The displayed link isn't the actual link, underneath it points to something like:
http://blahblah.blah.vcrtp21.eu/owa/service_directory/settings.php?email=username@blahblah.bah&from=blahblah.blah&fromname=username

Clicking through the link takes you to a convincing looking OWA (Outlook Web Access) forgery page, populated with the victim's domain name and email address.

There are two exploits on the page, the first one is a drive-by download of an infected PDF file called pdf.pdf for which VirusTotal detection is only 10/41, detected by McAfee as Exploit-PDF.ac and various others. The executable file you are directed to download is also a bit patchy on detections.

Sender names include:

• operator@
• support@
• notifications@
• no-reply@
• system@
• alert@
• info@

..all on your local domain, obviously.

Subjects include:

• The settings for the blah@blah.blah mailbox were changed
• The settings for the blah@blah.blah were changed
• A new settings file for the blah@blah.blah mailbox
• A new settings file for the blah@blah.blah has just been released
• For the owner of the blah@blah.blah e-mail account
• For the owner of the blah@blah.blah mailbox

Some domains in use on this are:

• vcrtp1.eu
• vcrtp21.eu
• vcrtprsa21.eu
• vcrtpsa21.eu
• vcrtrsa21.eu
• vcrtrsr21.eu
• vcrtrsrp2.eu
• vcrtrsrp21.eu

..there are probably many more of a similar pattern.

WHOIS details are fake:

Name:
Quezada, Ramon
Address:
1800 N. Bayshore Drive
33132 Roma
Roma
Italy
Email:
wawddhaepny@yahoo.com

Domains are on a fast flux botnet, so there's no point listing IPs. However, nameservers are as follows:
ns1.raddoor.com
84.243.201.159 [Netrouting Data Facilities, Amsterdam]
ns2.raddoor.com
71.123.51.158 [Verizon Internet Services Inc, Aston]
ns1.elkins-realty.net
84.243.201.159 [Netrouting Data Facilities, Amsterdam]
ns2.elkins-realty.net
71.123.17.61 [Verizon Internet Services Inc, Whitesboro]

Registrant details for raddoor.com are probably bogus:

edmund pang figarro77@gmail.com
751 kinau st. #30
honolulu
HI
96813
US
Phone: +1.8085362450

Registration details for elkins-realty.net are DEFINITELY bogus:

Name : B O
Organization : B O
Address : 123 elm str.
City : Los Angeles
Province/State : beijing
Country :
Postal Code : 23456
Phone Number : 86--8586104812
Fax : 86--8586104819
Email : BO.la@yahoo.com

Once your machine is infected, it probably gets infected with a Zbot variant as in these two previous examples.

One Invalid Recipient..

In my opinion, one of the great underappreciated Microsoft Knowledgebase articles is KB147093 which explains one of those mysteries you see with Exchange servers from time-to-time.

The symptom is this - a remote sender transmits a message to multiple recipients on your Exchange server, but one or more of the recipients is incorrect. This causes the mail transaction to fail and NO recipients get the message.

Although KB147093 refers to X400, in fact this is the behaviour that you'll see on an Exchange 5.5 Internet Mail Connector, and it works with other SMTP-based mail servers too.

The problem is this - when sending to multiple recipients at one remote domain, the software at the sender's end will make a single connection to the remote mail servers.. and it's an all-or-nothing proposition.

The problem is compounded if you suppress NDRs (nondelivery reports) to the internet, because a remote sender will never receive a bounce message to say that the mail transaction failed. In these circumstances, it can take some time to work out that there's a problem at all.. but in this case you need to carefully check the recipient list for invalid users and remove them.

Now, if you have NDRs enabled, the problem will probably be spotted much sooner. But these days a lot of organisations turn them off, especially if they are the targets of mass spamming or directory harvesting attacks. It's one of those cases where the current levels of spam have unexpected adverse impacts on infrastructure.