After Epsilon lost a bunch of customer lists, I've been keeping an eye open to see if any of the vendors I work with had any of my email addresses stolen — not least because it'll be interesting to see where this data ends up.
Last week I got mail from Marriott, telling me that "unauthorized third party gained access to a number of Epsilon's accounts including Marriott's email list.". Great! Lets start looking for spam to my Marriott tagged address, or for phishing targeted at Marriott customers.
I hit what looks like paydirt. Plausible looking mail with Marriott branding, nothing specific to me other than name and (tagged) email address.
It's time to play Real. Or. Phish?
1. Branding and spelling is all good. It's using decent stock photos, and what looks like a real Marriott logo.
All very easy to fake, but if it's a phish it's pretty well done. Then again, phishes often steal real content and just change out the links.
Conclusion? Real. Maybe.
2. The mail wasn't sent from marriott.com, or any domain related to it. Instead, it came from "Marriott@marriott-email.com".
This is classic phish behaviour — using a lookalike domain such as "paypal-billing.com" or "aolsecurity.com" so as to look as though you're associated with a company, yet to be able to use a domain name you have full control of, so as to be able to host websites, receive email, sign with DKIM, all that sort of thing.
Conclusion? Phish.
3. SPF pass
Given that the mail was sent "from" marriott-email.com, and not from marriott.com, this is pretty meaningless. But it did pass an SPF check.
Conclusion? Neutral.
4. DKIM fail
Authentication-Results: m.wordtothewise.com; dkim=fail (verification failed; insecure key) header.i=@marriott-email.com;
As the mail was sent "from" marriott-email.com it should have been possible for the owner of that domain (presumably the phisher) to sign it with DKIM. That they didn't isn't a good sign at all.
Conclusion? Phish.
5. Badly obfuscated headers
From: =?iso-8859-1?B?TWFycmlvdHQgUmV3YXJkcw==?= <Marriott@marriott-email.com>
Subject: =?iso-8859-1?B?WW91ciBBY2NvdW50IJYgVXAgdG8gJDEwMCBjb3Vwb24=?=
Base 64 encoding of headers is an old spammer trick used to make them more difficult for naive spam filters to handle. That doesn't work well with more modern spam filters, but spammers and phishers still tend to do it so as to make it harder for abuse desks to read the content of phishes forwarded to them with complaints. There's no legitimate reason to encode plain ascii fields in this way. Spamassassin didn't like the message because of this.
Conclusion? Phish.
6. Well-crafted multipart/alternative mail, with valid, well-encoded (quoted-printable) plain text and html parts
Just like the branding and spelling, this is very well done for a phish. But again, it's commonly something that's stolen from legitimate email and modified slightly.
Conclusion? Real, probably.
7. Typical content links in the email
Most of the content links in the email are to things like "http://marriott-email.com/16433acf1layfousiaey2oniaaaaaalfqkc4qmz76deyaaaaa", which is consistent with the from address, at least. This isn't the sort of URL a real company website tends to use, but it's not that unusual for click tracking software to do something like this.
Conclusion? Neutral
8. Atypical content links in the email
We also have other links:
(Those "[Random Number]" bits aren't me hiding things. That's literally what is in the email.)
That's an awful lot of other servers this mail is going to try and contact when you read it. I'm pretty sure that most of those are tracking links (but how many legitimate emails that advertise a single company and which are sent directly by that company, need to use half a dozen independent affiliate tracking links?).
Conclusion? Doesn't look terribly honest. Maybe some sort of affiliate scam rather than a phish, though.
9. Most of the links in the email go to marriott-email.com, but then immediately redirect to marriott.com.
This shows someone is tracking clicks, which is pretty common for mail sent via ESPs, so as to make click tracking information available to the client without the client having to do any work to capture data on their website.
Conclusion? Real.
10. The unsubscription link goes to a terrible page with a set of checkboxes, rather than providing a simple unsubscription button.
Conclusion? Sadly, that's a sign that it's real.
11. Sending network configuration
It was sent from a machine with reverse DNS of dmailer0112.dmx1.bfi0.com, but which claimed to be called dmx1.bfi0.com, not a valid hostname for the IP address it came from.
This is pretty common misconfiguration of the network that happens at larger ESPs with complex outbound smarthost farms. I'd expect a phisher not to have that sort of mistake if they were sending from their own machine or through a botnet. And while "dmx1.bfi0.com" could be an obscure end-user DSL, the reverse DNS of dmailer0112 looks like it's a system intended to send email, not a botnet.
Conclusion? Real.
Final Conclusion
You've probably guessed by now. It's real email, sent on behalf of Marriott Rewards through one of their ESPs. But if it takes me several minutes of groveling through the mail before I convince myself it's real, what chance does a typical consumer have of telling the difference between a well targeted phishing email and a typical piece of commercial email?
By Steve Atkins, Founding partner of anti-spam consultancy & software firm Word to the Wise. Visit the blog maintained by Steve Atkins here.
To post comments, please login or create an account.
SecuritySponsored byVerisign | |
Top-Level DomainsSponsored byMinds + Machines | |
MobileSponsored bydotMobi | |
DNS SecuritySponsored byAfilias | |
IPv6Sponsored byNominum | |
DNSSponsored byNeustar UltraDNS |
If you take a look at most commercial email from larger organizations, it's actually more common to not use the TLD consumers would be used to seeing as the sender and linkback TLD for the email itself.
Why? Because after years of being burned by over-excitable realtime email blacklists that shut down their primary TLD (and stop legitimate email communication and work for an indeterminate period of time) until the "issue" can be resolved, large orgs and their bulk-email service providers have decided sending using a secondary is better than risking their primary. One more kick in the shins for consumers having any hope of knowing whether an email is legitimate or garbage.
I'm not saying blacklists are explicitly bad, but that the process and the inaccurate way that they gather evidence result in bad senders getting missed and real senders getting hit - and professionals like Steve, let alone consumers, being unable to tell a good grift from a marketing message (though there is admittedly a fine line).
Looking at WHOIS for that domain, we see that it's been registered since July 2008. That's not short, but it's not long either. It very much pre-dates the attack, though, so we'd need to call this evidence for "real". Also, the contact email for the domain is an "@marriott.com" address. More evidence for "real".
And if they had signed it correctly, would you call it evidence for "real" or just "neutral"? I'd be calling it "neutral" no matter what: if it were correct, then we have assurance that the sender is associated with the domain name, but our beliefs about the domain would not be strengthened by this signature, so "neutral" it is. The broken signature would decrease my belief in the authenticity of the message if the domain in question were the obvious one to fake, like "marriott.com", but faking the signature for an already-questionable name like "marriott-email.com" seems utterly pointless. On top of that, I have no reason to believe that phishers are less competent at setting up DKIM signatures than ESPs are (in general). DKIM fail is thus also a neutral result for me in this case.
Some of those links are recognisably "real" in the sense of being things that online advertisers use to track their readership. The sheer number of them is daunting, but this reflects how very very keen the typical marketing organisation is on tracking people. Creepy? Yes. Indicative of truly malicious intent? Not so much. The links could be utter smokescreen, though, or the result of copying a real message. The "[Random number]" parts look like breakage (although they might not be), and suggest incompetence somewhere in the chain if they are broken, but that's a neutral result. Are ESPs more competent than phishers? Neutral — see comments under DKIM.
You conclude "real"; I conclude "neutral". This could be an attempt to install a drive-by download, in which case the redirect to marriott.com is a standard diversionary tactic to reduce suspicion. Sure, it indicates that we're not dealing with a phishing attack of the sort where they give you a fake login page, but that's unsophisticated by today's standards, and I don't think we're dealing with the unsophisticated end of the threat scale with the Epsilon breach.
The
(verification failed; insecure key)response looks like a DNSSEC issue (configurable with theInsecureKeyparameter in opendkim.conf.) That is to say, that signature may pass with a different verifier configuration.As for SPF, a good signature by the wrong domain should result in a "neutral" conclusion. If the ESP used subdomains and/or authorized third-party signers, it would get more significant results. In facts, these authentication schemes are DNS-based, thus the DNS should somehow reflect whether an ESP is acting on behalf of someone else or not. Until ESPs keep secret any relationship with their customers, the real-or-phish game stays guesswork, however vast the examiner's skills.