Analysis of an e-mail from Badsender... Uh... Or not!

If there's one hot topic right now, it's anything related to phishing. When I look at my LinkedIn news feed, there is not a day when I don't see posts on the subject... It can range froma post decrypting the use of a fake site à phishing attacks in mass! So, you have to be very careful about the e-mails you send so that they are not considered as spam and/or phishing but also about the e-mails you receive to avoid having your professional or personal data stolen... A few long weeks ago, I received an e-mail sent by Badsender... Well... Not really! Anyway, I suggest you to decrypt it in order to know how I knew that it didn't really come from our mail servers!

The sender... The trompe l'oeil par excellence!

My first instinct when I receive an e-mail is always to look at the trio sender's wording, sender's address, object. And I must say that with this e-mail, everything here is made to deceive! Let's look at each element:

The sender's wording

The sender label used is rather reassuring since it includes the company name: badsender.com

If you are a subscriber to our newsletter, the sender label always remains the same Badsender (with a capital B). However, I looked at everything that was sent via our domain name (whether it was proofs, internal emails or other notifications sent by our host), I couldn't find any other sender wording.

We will not hide it but the fact of putting badsender.com makes one already have suspicions about the legitimacy of this e-mail even if the error remains human!

Sending address

At first glance, it is enough to deceive anyone! The address used belongs to our domain name : mailer-daemon@badsender.com... It may seem legitimate! You should know that the alias mailer-daemon is generally used when an e-mail could not be delivered, in this case a non-delivery message is sent to the sender. On the other hand, the mailer-daemon will not intervene to report an incoming mail problem...

I did two checks that led to a certainty... This email is really not from us, here's why!

- I sent an email from my work account to an address that does not exist: fsfkfergkjdfklsdjferlkjfekjf@gmail.com and I got the following feedback:

If we look at the sender of the e-mail (the full address used is MAILER-DAEMON@infomaniak.com), this is none other than our host Infomaniak. This means that if there is a problem with our email, it is their address mailer-daemon that is used and not ours.

- I also checked to see if the sending address existed with us and got the following response: 550 5.1.1 mailer-daemon@badsender.com: Recipient address rejected: User unknown in virtual mailbox table

So there is no doubt about it! A sender address that does not exist to send e-mails... This is clearly not our style! Moreover, when we changed our IT infrastructurewe did not migrate or configure this address and the only address provided free of charge by Infomaniak was POSTMASTER).

The object

Finally, the object used Incoming mail error may seem legitimate... Since I've never had any problems or notifications with Infomaniak, I had fun simulating shipments to an address that doesn't exist to see how our dear French ISPs (Free, La Poste, Orange and SFR) react. Here are the results:

• Free ' Sender address: mailer-daemon@smtp.free.fr ' Sender label: Mail Delivery System ' Subject: Undelivered Mail Returned to Sender
• La Poste ' Sender address: mailer-daemon@laposte.net ' Sender label: Mail Delivery System ' Subject: Undelivered Mail Returned to Sender
• Orange ' Sender address: mailer-daemon@orange.fr ' Sender label: Mail Delivery System ' Subject: Undelivered Mail Returned to Sender
• SFR ' Sender address: mailer-daemon@sfr.fr ' Sender label: Mail Delivery System ' Subject: Undelivered Mail Returned to Sender

What is sure... Neither Free, nor La Poste, nor Orange, nor SFR uses a French object! Is it a lack of knowledge of the malicious person on the subject?

The SMTP header... The fortune teller!

After not being really convinced by the sender of the e-mail, I wanted to know where this e-mail came from. And there is only one thing to do, go and check the SMTP header of the e-mail, it will tell you everything... or almost! By the way, I advise you to read an article I wrote on the subject: How to read an SMTP header?

Even though not all the information in an SMTP header will be useful, some of it gives valuable clues about the sender. So, for the purpose of my analysis, I have focused exclusively on the important elements (and their output) of the header. However, one element is missing, namely the DKIM signature. This makes sense, otherwise it would mean that the hacker has managed to get into one of our routing tools to send emails on our behalf or that he has managed to decrypt our DKIM signature!

The return-path address

The first element to look at is the address return-pathit contains the MailFrom domainwhere the SPF authentication is located:

• Address return-path ' return-path:

Here, no bad surprises, the malicious person has chosen our domain name on the domains linked to the sender (FROM) and the e-mail envelope (MAILFROM).

THE IP

The second item on my list is the IP that was used. You just have to search where it comes from thanks to its WHOIS registration (see his identity card).

• IP received: from [185.157.77.30] (185.157.77.30 [185.157.77.30]) by ns.oshu.co.jp (deepsmtpd.so)

I always check this information via the site Domain Tools. I find two key pieces of information:

- IP Location : Ukraine Kremenchuk Zemlyaniy Dmitro Leonidovich

- ASN AS42159 DELTAHOST-AS, UA (registered Aug 17, 2009)

And then bingo! The information I find on the WHOIS record of the IP clearly tells me that it does not come from one of our routing platforms, nor from our host (which is Switzerland) but from a Ukrainian host called Deltahost!

SPF authentication

Third item on my list, check the result of the SPF authentication:

• SPF authentication authentication-results: mx.infomaniak.com; spf=permerror smtp.mailfrom=badsender.com

Since the IP is completely unknown to us, the result of the SPF check is a permanent error, which is logical because we never allowed the IP belonging to Deltahost to send emails with our domain name. Another important point is that we have not declared a SPF qualifier -all but only ~allThe fraudulent e-mail was accepted by Infomaniak.

DMARC authentication

Last item on my list, check the output of DMARC authentication:

• DMARC authentication authentication-results: mx.infomaniak.com; dmarc=fail (p=none dis=none) header.from=badsender.com

The result is clear: FAIL ! This is logical since SPF is failing and DKIM is not present, we have here 0% of compliance. Unfortunately for us, our DMARC security policy is to NONE, the email was not refused, nor placed in spam 🙁

The message... The deceiver deceived!

The last point to analyze is the content of the e-mail. And here, I had an air of déjà vu ! I mean, the content is not unknown to me, I've seen it somewhere before... So I decided to go through my old emails before finding what I was looking for...

Before moving to Infomaniak, we were using the Office 365 suite and I'd had this email several times when I sent an email to a recipient whose email address didn't exist or no longer existed! Anyway, I came across a copy-cat or a Microsoft lover (I let you choose the right answer :p). He only changed two or three information to make it credible!

Last but not least, the CTA URL makes no sense and typically looks like what you would see in phishing emails:

Not so good! He could have done better...

Solutions to protect yourself... A minimum!

To each problem... its solution! I was not the only one at Badsender to receive this e-mail. It was the occasion for us to reinforce our defenses by hardening the security rules on our domains and in particular badsender.com.

• The SPF record is changed from SOFTFAIL (~all) à STRICT (-all) The objective here is to tell the fai/webmails that if the IP is not on the list of authorized IPs, they must reject the e-mail!
• The DMARC record goes from NONE à QUARANTINE then REJECT (early 2023): the goal here is to tell DMARC-enforcing fai/webmails that any failed or non DMARC-compliant email should be put into spam (QUARANTINE) and then rejected (REJECT).
• Continue to monitor DMARC to know the activity of our domains: as we are tightening our security policy, it is important for us to know if legitimate flows would not be compliant with DMARC (and therefore make them compliant) and if malicious people (like our fake friend) are trying to use our domains to send spam!
• Reduce the number of routing tools we use, always keep the same configuration (sender address vs. IP) to easily recognize our emails.
• Do prevention internally (everyone reports the potentially dangerous e-mails they receive!) but also with our customers via coaching / audits! And finally report these phishing e-mails to specialized organizations, in particular Signal-Spam.

There will be more actions coming soon, I will be sure to update this article 🙂

To conclude...

Even though it was very disappointing / frustrating that this phishing email arrived in our inbox, this article shows you that no one is safe from being tricked. In fact, as I write this article, two of our clients have alerted us to acts of piracy... In short, it doesn't just happen to others!

Do not hesitate to check your different configurations (or passwords) to make sure that your domains or accounts are well protected. If you have any doubts or if you need advice on how to optimize their protection, contact us 🙂