r/EmailSecurity

Wrote up an active case from this week, sharing in case it helps anyone seeing similar voicemail lures.

One of our customers got hit with a quishing email branded as Spectrum Business + RingCentral + Google Voice. The bait is the usual missed-call story, "you have a voicemail about an overdue payment." Nothing remarkable so far.

The clever part is the chain. The malicious link isn't in the email body. It's in a QR code, inside a .docx attachment, inside the email. Three layers deep before anything fires.

Whole thing is designed to push the click off the corporate laptop and onto the user's phone, which is the entire point of quishing as a technique:

Once the user scans, they get a fake "Tap the box to confirm" captcha (kit-style, blocks perimeter sandboxes from following through), then a near-perfect Microsoft login page pre-filled with the victim's email pulled from the URL path. Behind it is an AiTM proxy grabbing the password and the session cookie in real time.

Phishing Email

Attached Docx

Auth Impersonation

Full writeup with the IOCs, the captcha + AiTM screenshots, the docx internals, and some detection ideas is up on the company blog. Not posting the link inline to keep the post technical-first. I'll drop it as a comment for anyone who wants it.

Disclosure: I work at ZeroBEC

Workspace will happily send outbound mail through your gateway, but Gmail does not magically make that relay part of your domain's authentication story. The next hop still has to pass SPF or DKIM in a way that lines up with DMARC.

The common failure is SPF alignment. Workspace hands mail to the relay, the relay rewrites MAIL FROM to its own bounce domain, and now your From: domain has no aligned SPF pass unless DKIM survives.

DKIM is usually the cleaner path. Sign in Workspace before the relay, then make sure the relay does not break the body or headers you signed. If it adds footers, rewrites links, or mangles MIME, expect DMARC failures.

For gateways in front of Workspace, I treat this as a mail flow test, not an admin checkbox. Send to a mailbox you can inspect, read the Authentication-Results header, and verify alignment from the final receiver's point of view.

Sharing a quick heads-up from an active IR case in case it helps anyone else triaging similar emails this week.

A customer received a phishing email that looked like a generic Adobe / DocSend "New Secured Document" lure. Standard stuff on the surface, but the interesting parts:

• Sender: noreply-<random string>@jobote.com ("Adobe-Docsend" as display name)
• "View Document" button links to mailtracking.jobote[.]com/f/a/{token} - which is Jobote's own legitimate tracking/redirect subdomain for their referral product, being abused as a clean-reputation redirector
• Final payload is a ConnectWise ScreenConnect installer - attacker uses it for hands-on-keyboard access after install
• Reply-To is literally noreply at yourdomain[.]com - an unfilled template placeholder, which is a strong pivot IOC for hunting other emails from the same kit/operator

Phishing Email

ScreenConnect Download Redirection

​Not making any claim about how the jobote[.]com SparkPost tenant got abused (compromised account, stolen API key, abused customer subaccount, etc.) - that's for SparkPost to investigate. But the abuse pattern matches what we've been seeing more broadly: attackers riding low-reputation but legitimate ESP/tracking infrastructure to bypass URL reputation filtering before dropping a remote-access tool.

Pivots worth hunting on:

• Reply-To containing yourdomain[.]com (placeholder strings in Reply-To = high signal)
• X-MSFBL header containing customer_id=107475
• Any mailtracking.jobote[.]com URLs in inbound mail
• Apple Mail headers on ESP-injected mail (deliberate misdirection or sloppy operator)
• Reported to SparkPost abuse and notifying Jobote directly so they can rotate keys / audit.
• Firewall logs for access to cherylbirch[.]com

Disclosure: I work at ZeroBEC. Happy to drop the full writeup in a comment if anyone wants the headers / IOCs to feed into their own tooling.

One of our MSP clients had a mail DLP rule that blocked outbound attachments containing customer IDs. I wrote it years ago, tested CSVs and PDFs, got clean blocks, then mentally filed it under handled.

Last week a user copied the same customer IDs out of a spreadsheet, pasted them straight into the email body, BCC'd a personal account, and the message sailed out. No attachment, no match, no alert.

The ugly part is the rule was not broken. It matched the scope I gave it, and my threat model stopped at files leaving by email instead of data leaving by email.

I'm now tightening body inspection and personal-mail recipient checks, but I hate how easy it is to create DLP that only protects the path you happened to test. Curious where other mail admins draw the line before outbound rules become noisy enough that everyone starts bypassing them.

When an email account gets popped, I start with Exchange Online message trace and audit events before I ask the user what looked weird. Their timeline is usually fuzzy, and the inbox has often been cleaned up by the attacker or the user by then.

My first pass is boring: inbound lure, successful sign-ins, MailItemsAccessed, inbox rules, sent mail, deletes, forwarding, OAuth grants, then message trace for who else got hit.

The user interview still matters, but I treat it as a lead source, not the source of truth. Logs first, feelings second.

Interesting paper on a fairly under-discussed issue in DNS: what happens to expired or repurposed domain names that remain embedded in DNS dependencies across systems. The core finding is that these “orphaned” or changed domains can persist in resolution paths and integrations long after their original context is gone, creating real security and reliability implications.

My take: this becomes even more relevant in modern AI systems, where agents, tools, plugins, and third-party APIs are rapidly stitched together. In that environment, domain names and DNS-level dependencies can quietly extend the AI supply chain attack surface in ways that are easy to overlook.

Paper: https://arxiv.org/abs/2605.06880

Found this during a mail-flow cleanup, not during an alert. An old Exchange Online transport rule set SCL -1 for one supplier domain because invoices kept hitting quarantine in 2021.

Last week that supplier got compromised and a threaded invoice reply delivered a malicious ISO into three AP mailboxes. Message trace made the ugly part obvious: the allow rule hit before Defender for Office had done anything useful.

I am done with domain-level allow lists in Exchange transport rules. If a supplier cannot send clean mail, they get scoped remediation or quarantine release, not a permanent bypass stapled to mail flow.

Customer forwarded a phish to abuse@ with all the right headers. SPF, DKIM, and DMARC passed because it came from a still-active Mailchimp account tied to our domain.

The account belonged to someone who left nine months ago. Marketing had killed the obvious access, but the external sender login was still alive.

The annoying part is abuse@ caught it before any internal control did. Our offboarding list had laptops, IdP, GitHub, payroll, all the usual stuff. It did not have bulk email platforms that can still send authenticated mail as us.

If a service can send as your domain, it needs an owner and a shutdown path. Otherwise abuse@ becomes your asset inventory, which is a stupid way to run email security.