[walrus01]

Can you please clarify how exactly the decision making process occurred to give a 3rd party email provider a copy of your private DKIM signing key for the domain "namecheap.com" ?

The emails could not have gone out with DKIM-signature and successfully validated by openDKIM at my receiving MX/SMTPD against the public half of the key in your DNS TXT record for your DKIM key, unless you had given them access to the private key.

Did the persons who are responsible for creating and maintaining your DKIM public/private key pair and its selectors directly give the key to some third party (sendgrid, mailchimp, whatever) type email newsletter services, or were they ordered to do so by somebody else in Namecheap management?

Or, did the persons responsible for your authoritative DNS zone for namecheap.com insert an additional DNS TXT record for the DKIM key used by a 3rd party service?

[oneplane]

While I don't know the details of the third party at name cheap, it's pretty common to have a bunch of third parties with their own DKIM keys and just trusting and including their public keys on your DNS zone. Nobody sends all their own mail, your service desk, support software, ticketing system, alerting system, collaboration provider all have DKIM keys and SPF records you're adding to your zone and they just control the keys for their own input.

This means that if they get pwned, it's their ability to send mail on your behalf that gets abused, not some key stealing and DKIM impersonation (and why would they bother if a perfectly fine emailing system is already open and ready to spam the crap out of everyone).

[28mm]

I received one of the phishing messages as well as the follow up / apology. An interesting wrinkle is that both were handled by sendgrid and used the same dkim selector. I would guess that a set of sendgrid api credentials shared with some 3rd party service was compromised.

[oneplane]

I've seen it even worse:

  - One of our domains had a DKIM trust with Mailgun (3rd party)
  - Mailgun was integrated with a planning service (4th party?)
  - Planning service was integrated with a CRM (5th party?)
  - CRM was integrated with a website (6th party?)

Website got pwned, spam ensues using the entire chain all the way back to our domain. This was a while ago but I think the website was pwned, leaked API credentials for the CRM, those were locked to only read the address book for sources (not even destinations! but '*' was allowed...) but because the software was crap the planning/calendaring service was registered as a 'source', which included API creds. The planning service itself was pretty good, no further grab-keys-via-API, but using what was already allowed you could send raw MIME messages and it would just use the Mailgun API it had access to.

Luckily for me, I was on a prometheus spree and had an exporter grab the Mailgun metrics every few minutes (Ironically to support the CRM team because they didn't have any good metrics of their own and did like to blame everyone else), so while it was configured to look for dips, it also triggered on spikes because those tend to end with dips too.

I think in the end nobody learned from it because every team/vendor covered their ass with "well we only run it in datacenters with firewalls so this is the cloud at fault" and I don't think anyone got flak for it (but some definitely deserved a fair bit).