"Transport of London" Malicious E-Mail

Published: 2015-09-28
Last Updated: 2015-09-28 10:52:30 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

This morning, I received several e-mails with the subject "Email from Transport of London". The attacker even picked a plausible "From" address with noresponse@cclondon.com. This domain is used by Transport of London for information about London's congestion charge. 

The domain does have an SPF record defined, making it easy to reject the emails as spam:

v=spf1 include:spf.messagelabs.com -all

This SPF record would allow all hosts listed in Messagelab's SPF record to send e-mail on behalf of cclondon.com. Interestingly, the e-mail seems to include a fake "Received" header, listing a "cclondon.com" host as part of the received chain:

Received: from ( [])

    by mail.dshield.org (Postfix) with ESMTP id B11E07FE0C;

    Mon, 28 Sep 2015 09:40:21 +0000 (UTC)

Received: from cclondon.com (tfldxmqmp63-svc [])

    by tfldcpopp21.cclondon.com (Postfix) with ESMTP id 367DFD536

    for ; Mon, 28 Sep 2015 10:39:59 GMT

Since my server (mail.dshield.org) states that it received the e-mail directly from, an apparently home user system, I doubt the second Received header is real.

These emails do not only target Londoners, but appear to also use Subject lines like:

"Toll road bill notice"
"Outstanding toll road payment notice"

The London Transport one was however the only one I saw that played the trick with a valid looking From address.

Sadly, anti-virus coverage for the obviously malicious attachment is dismal with 4 out of 55 on Virustotal (F-Secure being the only "name brand" AV recognizing it as a generic downloader). [1]

A quick screen shot of the entire message:

(click on the image for a full size view)

[1] https://www.virustotal.com/en/file/80237fc10155567a68163bfd5bbf0afc5cb521bfdd1d486e1c3682083b5f61f8/analysis/1443436044/


Johannes B. Ullrich, Ph.D.

4 comment(s)


Should the extranous mail header record not matter in the end since it validates against the latest header only and the EHLO/HELO from the SMTP server ?
Correct. The received header should be ignored (as obviously, it may be forged). I wonder if whoever sent this knows about some implementations that will interpret these headers wrong, or maybe just make abuse reporting more difficult (which should also ignore this header).
Received these this afternoon. Never opened them, just classified them as junk, moved to trash and the dumped upon closing Thunderbird.
Interesting. I'd always imagined they could forge part of the headers, but had never seen it. I guess now I'll need to follow the received chain to make sure it's consistent.

Diary Archives