Yet Another Apple Phish and Some DNS Lessons Learned From It
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|
Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
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/
Anonymous
Apr 18th 2017
7 years ago
Anonymous
Apr 18th 2017
7 years ago
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!
Anonymous
Apr 18th 2017
7 years ago
"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.
Anonymous
Apr 19th 2017
7 years ago
Anonymous
Apr 19th 2017
7 years ago
Anonymous
Apr 20th 2017
7 years ago