[TZubiri]

Making a custom rule for a specific sender feels like fighting a fire with a glass of water.

It's better to focus on more systematic solutions. There exist a lot of them, SPF, DKIM, Recipient mail filtering (Your mail provider).

The screenshotted emails don't even do anything tricky like spoofing the sender address, it looks like "Sent from [e-mail]". If it spoofed the domain it would have been caught by SPF/DKIM.

Most of the time the user doesn't need to do much, you can just be weary of sender domains, and report the email as phishing and help blacklist that specific IP address/domain. Similar to how in medicine sometimes the physician tells you to drink water and rest, no medicine needed, just let the immune system do its thing.

[rezonant]

As explained in the article, the scammers are using compromised Sendgrid domains to send the phishing emails. This means the emails are going to pass SPF/DKIM. Those domains are apparently owned by legitimate businesses which are actual Sendgrid customers. The phishers just compromised their account and API credentials

[ZoneZealot]

SendGrid's platform doesn't need to be the sender of these emails at all. It's just classic phishing, the emails can pass SPF, DKIM and DMARC as all of these rely on DNS resource records to be created on the RFC5321.MailFrom and/or RFC5322.From domain. Which is under control of the spammer. It's not pretending to be from sendgrid.com, if it was then these measures would help.

[TZubiri]

Correct, I think the confusion might arise because of the self replicating nature of this attack when the target domain is an MTA.

I can't pinpoint it exactly, but it might be a combination of the replication cycle of the attack being recursive and very short if the target is an MTA. But it may also be because the fact that sendgrid clients are sendgrid clients is public information.

Kind of how like meta companies are overrepresented in their medium, in a stock exchange banks are overrerpresented, lots of websites about building websites, lots of road ads are about placing road ads.

[rezonant]

Yes, as the article says, they seem to be using Sendgrid to phish Sendgrid customers because the UX is "xyz.com delivered by sendgrid.com", hoping that this is seen as legitimacy by the recipient.

[ZoneZealot]

None of the examples in the article exhibit the 'via' UX. They were all sent with an aligned RFC5321.MailFrom and RFC5322.From (i.e. domain name used in both of those values is the same), those not matching is the most common reason to have the 'via' displayed [0]. They do have display names which pretend to be SendGrid.

0: https://support.google.com/mail/answer/1311182#zippy=%2Ci-ca...

[TZubiri]

There's some confusion here, there is a secondary compromise, but it's not very relevant.

The actual origin of the email: theraoffice.com

The fake origin of the email: SendGrid

There is a mismatch there, easy to detect. SendGrid was not compromised, and nothing was sent in the name of sendgrid or whatever.

Now the domain theraoffice might have been registered by an attacker, warmed up with some small fake traffic, and aged. Or it might have been compromised.

The previous email could have used sendgrid or mailchimp or google workspace, that's not very relevant. The SPF and DKIM would always pass, because SPF and DKIM verifies that the owner of theraoffice.com is the one sending the emails.

There might be a connection with SendGrid, but it's not at all accurately explained in the article, it may be as simple as SendGrid being a common phishing target of attackers just because they can get access to more email infrastructure for magnifying their reach, like a self-replicating virus.

[rphillips]

The first rule doesn't match a specific sender. Run it through a re2 regex tester.