My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Yet Another Apple Phish and Some DNS Lessons Learned From It

Published: 2017-04-18. Last Updated: 2017-04-18 16:14:32 UTC
by Johannes Ullrich (Version: 1)
6 comment(s)

Our reader Charlie forwarded us a somewhat interesting Apple phish. Apple is a big phishing target, and the phish itself wasn't all that special. It does a reasonable good job emulating real Apple e-mails, but what is more interesting are the "From" address and the URL of the link:

The "From" address was set to apple.ssl.com . For the uninitiated, this may look like a valid Apple domain. But instead, it is a subdomain of "ssl.com". SSL.com is of course not the valid source of the e-mail. But why did this e-mail make it past SPF filters? ssl.com does define an SPF record:

v=spf1 ip4:144.76.245.218 ip4:199.102.137.146 include:amazonses.com include:mailanyone.net include:fusemail.net ~all

The record contains a common error: In the end, the "~" ahead of "all" indicates a "soft fail". In essence, this may short-out the SPF definition. There is also no DMARC record for this domain. The "~" is often added to prevent false positives, for example, if companies are afraid that they didn't capture all the mail servers sending e-mail on their behalf. While this may be a good idea initially, it should be removed later.

Next, the link leads to apple1-id.com. The domain is not associated with Apple. The web page is still up (but blocklisted), and provides a good copy of the genuine Apple login page. 

Interesting about this domain: It was registered back in January. So the bad guy put some work into this to avoid some "recently registered domain" filters.

So lessons learned:

  • Make sure your SPF record ends with -all not ~all (subtle but important)
  • When hunting for bad domains, details matter and the registration date may not be enough to find malicious domains.

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
STI|Twitter|

Keywords: apple phishing
6 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

Checked my environment and I've been getting these emails as far back as 1/5/2016. They come in no more than 2 at a time and the early emails show that ssl.com never had an SPF record:

Authentication-Results: spf=none (sender IP is 74.208.121.252)
smtp.mailfrom=apple.ssl.com; dkim=none (message not signed)
header.d=none; dmarc=none action=none header.from=apple.ssl.com;
Received-SPF: None (protection.outlook.com: apple.ssl.com does not designate
permitted sender hosts)

Also, the embedded links mostly go directly to a .com like Charlie noted but over time the URLs have been modified. My earliest one has a link to hxxp://webs-gb0.com/

All identified domains:
hxxp://webs-gb0.com/
hxxp://conservadoradompedro.com.br/xml/online-login/online-login/
hxxp://host-app0.com/
hxxp://host-app1.com/
hxxp://ll-host2.net/
hxxp://ll-host2.com/
hxxp://host-ll1.net/
hxxp://ie-app1.net/
hxxp://gb-en01.com/
hxxp://myid-gb1.net/
hxxp://mycloud-3.com/
hxxp://aws-cloud1.com/
hxxp://ahpi1.com/
hxxp://apid-1.com/
hxxp://cr2-02.com/
hxxp://verid01.com/
hxxp://verid02.com/
hxxp://sys-v2.com/
hxxp://sys-v1.com/
hxxp://i-msg1.com/
hxxp://appleid1-cgi.com/
hxxp://reactivate-appleid.com/
hxxp://appleid-customersignin.com/
hxxp://icloud-billing1.com/
We moved from the soft fail ~ to the hard fail - a while ago. I'm glad we did, but it wasn't fun. It was unreal how many services (parts of the organization have subscribed to, usually w/o telling IT) there are that send email with our address as the from address. We still have some spammers/phishers that manage to evade our SPF list and phish us with our from address. Next stop DKIM, I guess. I remember reading a blog that said SPF wasn't that great, but can't find it at the moment.
SPF will _NOT_ prevent phishing because receiving mail servers (_if_ they check for SPF) only check Envelope-From (AKA Return-Path), not Message-From. For example, in 2015 customers of UK ISP TalkTalk were massively spammed with emails seemingly origination from cisco.com after the spammers figured out that TalkTalk would whitelist incoming mail with valid SPF information (_not_ from Cisco). See, for example,
https://community.talktalk.co.uk/t5/Email-Webmail/Inundated-with-Spam-Emails-from-cisco-com/m-p/1764154#M42985

SPF _DOES_ prevent backscatter though - in case spammers specify your domain (including valid email addresses in your domain) in Envelope-From (regardless of what they put in Message-From) and the spam cannot be delivered for whatever reason. But only provided that receiving mail servers honor your SPF record...

DKIM doesn't prevent phishing because the information where in DNS to look for the DKIM certificate, is included in the DKIM header _itself_ (inserted by the sending server). In other words, phishers can add their own DKIM header signed by a server under their control. You can find an example (in Dutch) here:
https://www.security.nl/posting/463813/Waarom+DMARC+(%2BSPF+%2BDKIM)
In that example, Message-From shows a gmail.com address, while the message was sent from a mailserver in Romania. So if you see a DKIM signature: ask yourself _who_ signed it and whether the signer is authoritative for the apparent sender domain!

DMARC, when correctly used in combination with SPF, prevents spammers from phishing using your _exact_ domainname in Message-From. One problem with DMARC is that a receiving (and validating) mail server will be happy if ONE of the other measures SPF or DKIM are present, even if _your_ mail servers provide both. Also DMARC has problems with manipulated (or duplicate) Message-From entries.

However, NO combination of SPF, DKIM and/or DMARC prevents spammers from phishing using domainnames that _LOOK_ like yours (as is the case with apple.ssl.com - there's nothing apple.com can do about this), while these measures can cause _you_ a lot of headaches (for example, SPF breaks forwarding, and if you make mistakes, you may prevent your own servers from sending legitimate mail). Also the success depends on receiving mail servers actually checking and complying with what you ask them to do, which is not always the case.

Your mileage may vary!
Whilst the domain "ssl.com" has the softfail record you show, this is not directly relevant to the subdomain "apple.ssl.com".

"apple.ssl.com" is valid, with an A record but no MX or SPF records. So it is viewed as a valid mail domain (due to the A record being an allowed fallback of last resort if no MX, something that should really be deprecated), however it has no SPF record, and this isn't recursed to its parent by SPF parsers (this was rejected in the standard after long discussions).

Ideally DNS administrators should put a TXT record of "v=spf1 -all" in any non email subdomain that contains an A record to reduce spoofing.
the real question, and i know this should be obvious, but to me it is always a scratching your head moment. why are the domain companies allowing creation of these domains unchecked? i shouldnt be able to type gooogle.com and not get anything but google.com (yes i think google bought that url). I know domain creation and dns is probably something that does not have very good oversight, but isnt part of the reason these malware coders like to use domain addresses vs ip address so they can move around their servers. there should be some sort of watch dog just deleting these domains out of the dns lists
Thanks Erik!

Diary Archives