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 no-reply@theraoffice.com". 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.
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
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.
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.
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.
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.
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.
There are inputs and outputs to life. Many, many, many things try to consume our ability to consume inputs. By consuming these inputs there is less time to create an output. These outputs are super important and can be anything: sports, 3d printing, art, woodworking, musical instrument, gardening, other hobbies or projects, etc.
The phone is an easy input to pickup. Make it easy to pickup something else to occupy that time to create something tangible (an output). Other comments mention "real world" and it is so true. Do something that rewards yourself in the real world. It'll be great for your kid too.
That would have been a great way to go about it. "This part infringes our copyright, here's a patch to fix that". But we all know they don't want to fix anything, they want only to destroy and prop up the corpse as a big bad wolf so the actual content creators get scared and keep paying them.
+1, Sweeney took the low road by violating his contract with Apple, removing Apple IAP from the existing Fortnight on people's iOS devices, and generally making a point by doing it the wrong way. Two wrongs do not make a right.
Epic didn't remove IAP... they advertised a lower price elsewhere, which is against guidelines (which is not a contract), and did so via an unreviewed update.
Note that updates via webview or JS code are explicitly allowed by contracts, and what Fortnite did is very likely to have used that mechanism.
+1 to KEXP and KCRW (and KCRW's Eclectic 24). KEXP plays a ton of great music of different varieties of music, some of which, I wouldn't normally listen to.
I do something very similar. I save files into a watched folder with Hazel (Google Drive, Dropbox and my Downloads folder). Hazel has a rule to rename the file with the YYYYMMDD_Filename.ext, and then depending on the extension filters it to a different folder, or with a PDF runs an OCR on it and stores it in Devonthink Pro.
1. Add expressions to: If ALL of the following match the message.
2. Expression 1: Type: Advanced content match Location: Full headers Match type: Matches regex (?im)^from:\sSendGrid(?:\s+\w+)\s*<[^>\r\n]+>+$
3. Expression 2: Type: Advanced content match Location: Sender header Match type: Not matches regex (?i)^[A-Za-z0-9._%+-]+@(sendgrid\.com|twilio\.com)$
Set the rule to reject or quarantine. Users will not see the messages unless the attackers change the From header.