A friend received a spam email from quickbooks@notification.intuit.com
Intuit is a real company, and intuit.com is their real domain. Looking online, a number of people received this scam email a few months ago, and then again over the last week.
If you came across this post from Google, this is why it reeks of a scam email:
- 12 of other email addresses are listed in the
toandccfields - it says that a subscription is set to renew, “$399.99 will soon be taken out of your account” and that it will happen within the “next 24 hours”. Classic sense of urgency
- It includes an
888phone number that does not come up as any legitimate number, and it includes a PDF which my friend did not download in case it is malicious
Does this mean that Intuit lost control of that subdomain, or is there another way that someone might be spoofing it? I can have my friend check any other metadata if it would be helpful.
If you came here from Google, welcome to the Fediverse :)
E-Mail is old. So old that when it was invented, “hacking” and “security” was not really something anybody thought about.
To send an email you connect to the recipients mail server and type in all the data of the mail. Including recipient, subject, mail body and importantly the address displayed in the “from” and “reply to” fields. They are all defined by the sender. The Email protocol has no way to verify if this information is correct and the sender is actually part of the aledged domain.
Today, when you send a mail, most of the time you will not connect to the recipient mail server directly, but to a “sending” mail server, which then sends the mail to the recipient. For example if you log in to gmail, you write the mail on a google Mailserver which sends it to the recipient. Or you connect to your companies exchange through outlook.
There is a modern extension to the mail protocol, which allows a domain owner to define the sending mail server which is allowed to send mails on behalf of this domain. But it is in the responsibility of the receiver to check. (Its called sender policy framework SPF)
So most likely intuit didn’t do anything and the scamer just send mail without a sending mail server. And your receiving mail server did not verify the SPF correctly. Or intuit did not define an SPF. Or they did but it allows sources that do actually not belong to intuit but might be controllable by the scammers. This can happen if they want to send mails from cloud hostet systems and include them in their SPF, which may include systems by other customers of the cloud hoster.
If you want to verify mail yourself, look in the mail headers (often called: view source) and look at the “received” headers. They deta the full path the mail has taken including which system initially wrote the mail. They are ordered bottom to top, so the (chronologically) first entry is the lowest. Check if the ip adress/hostnames for the first few hops belong to intuit and if they don’t, its most likely spam.
TLDR: what is necessary to send mails from somebody else’s domain? Nothing. You can just do that. Mail is insecure by design and should be abolished.
What this person said… I keep telling my dad over and over that I can literally send him an email and say I am anyone and it will show up in his email box. I feel like the urge to make everything “user friendly” has put us in this situation. The mail headers are so hidden now, it’s almost a chore to find them in most email programs, which is unfortunate.
Even if you do have DKIM, DMARC, and SPF someone can still spoof your domain and the admin will still get an email about it. After that, instructions are unclear since the receiving domain is rejecting it properly.
Ask me how I know
Yeah, it has to be both sides cooperating. You can set a recommendation what to do with mails that failed the checks. Including dropping the mail altogether. But it’s open to the receiver to honor that request, or not do any checks at all.
Very good answer. It’s really complicated since it’s an old protocol and lots of different mechanisms have been added on top. I found one small error: You can’t rely on the “received” headers either. Just the line from your mailserver and the IP and hostname right before. The rest of the path (before) can be fake, too. (And this regularly happens.)