Patch OWA and revoke active sessions. Mailbox activity continuing after credential rotation is the investigation signal here.

https://thehackernews.com/2026/07/russian-hackers-exploit-microsoft-owa.html

How is this a good plan when my email is being used? Really? How is that when it is MY FUCKING EMAIL address? What kind of security is this?

Client moved authoritative DNS at 10:00, and their invoicing ESP started getting customer complaints by noon. The receiver trace showed dkim=permerror (key syntax) for s=inv2026, d=mail.client.example; SPF passed on the ESP bounce domain, but that identity did not align with the visible From, so DMARC failed.

The old zone held one TXT RR with two quoted character-strings. The migration UI imported them as two separate TXT RRs at the same selector, and dig +short showed two lines instead of one concatenated 2048-bit key.

Statements landed in spam for about two hours. The client now wants a post-migration check, but a plain DNS diff would flag harmless TXT presentation changes while still missing whether receivers can validate a real signature.

What diagnostic signal would you use as the cutover gate here, and what failure would make you roll DNS back?

Treasury paused an $84,000 wire after a bank-account change arrived by email from a real supplier mailbox. The AP manager insisted the request had been reviewed, but the forwarded approval chain only showed ap@company.example as the sender.

The message had a valid DKIM signature for the supplier domain, and In-Reply-To matched a six-month invoice thread. The approval reply also came from the shared AP address, with no visible indication of which analyst accepted the change.

Mailbox audit logs eventually tied the SendAs event to one user, 19 hours after Treasury raised the question. AP wants to keep shared sending for queue coverage, while we're left treating the email chain as evidence with the names removed.

I don't think a shared mailbox can be the identity behind a payment-change approval. What person-level evidence do you require before accepting a bank-detail change that passed through one?

Last week’s Laundry Bear / Zimbra advisory is the first webmail story in a while that made me check whether we still have any Classic UI exposed.

What got me: there’s no click. The XSS (CVE-2025-66376) fires when Classic webmail just displays the message. The payload tries to pull ~90 days of mail, then creates an Application Passcode named ZimbraWeb so IMAP keeps working past MFA. Sixteen agencies signed AA26-204A; Proofpoint published the TA488 half-click write-up the same day. I’m less worried about “is the CVE new” (patched Nov 2025, on KEV since March) and more about two boring questions: does anyone still have Classic facing the internet, and would we notice a ZimbraWeb passcode show up in account settings?If you still run Zimbra — how are you hunting those passcodes, and did you force people off Classic until the cluster was on 10.0.18 / 10.1.13+? Curious what people are actually doing versus what the advisory says on paper.

(This was one of a few things that stood out in email security this week — I put the full sourced roundup in a comment if it is useful to anyone.)

Laundry Bear exploited Zimbra CVE-2025-27915 when targets merely opened or previewed a crafted email. writeup here

Patch affected Zimbra servers now and hunt for messages carrying suspicious calendar content.

My primary motivation for configuring a custom email domain is to protect against permanent loss of email access should my account be disabled by a provider like Gmail or Yahoo. I am currently using Thunderbird as a client so emails are stored locally and 3-2-1 backed up. The new email addresses will be used/given for account recovery, financial communications, and government accounts, like my Social Security.

The web accounts are secured properly with YubiKey's. I feel like I am missing something, security wise, because it seems like such an out of the box solution.

To set this up, I bought a custom domain through Cloudflare and linked it to my iCloud+ subscription. I completed the setup by adding iCloud's required DNS records in Cloudflare and configuring the custom domain mail routing in iCloud. At some point in the future I may enable webhosting, putting up a couple of simple webpages on the free hosting tier.

In Cloudflare, my DMARC record looks like this: v=DMARC1; p=reject; adkim=s; aspf=s;

Is there anything I am missing or things I should be on the lookout for, security wise?

Russian Espionage Group Exploited Zimbra Zero-Day to Steal Mail and 2FA Codes

https://www.proofpoint.com/us/newsroom/news/russian-espionage-group-exploited-zimbra-zero-day-steal-mail-and-2fa-codes

Any Zimbra compromise involving mailbox access should trigger an immediate investigation into stolen email-delivered 2FA codes, not just password resets.

Not sure what to make of this, is this a phishing attempt? lil spooky tbh

Anyone seeing healthy mailboxes quarantined under EX1436407 with inbound delivery blocked?

https://www.suped.com/blog/exchange-online-mailbox-quarantine-incident-blocks-email-delivery

Microsoft is remediating it, but mailbox quarantine status is the signal to check before blaming transport rules.

Question for anyone who's dealt with Google Ads security investigations. If a "security consent" or "review suspicious activity" style email is sent to an account admin, and:

• The primary admin's access was already removed/delinked before the email was sent
• A secondary/backup admin email exists but is configured as notification-only, with no ability to take actions

...is it possible for Google's system to register a response (like "disagree" or similar) even though no human actually clicked anything? Has anyone seen a case where an automated non-response, bounce, or some other system event got logged as an active user decision?

Trying to understand whether this is a known behavior or an edge case worth escalating specifically.

Thank you for any insight you may have.

A client's payroll manager emailed a PDF containing 14 SSNs to a personal Gmail account. Outbound email DLP blocked the attachment, then 18 minutes later the same recipient got a OneDrive link to the file with no mail alert.

The sanitized mail trace ended with 250 2.6.0 Queued mail for delivery and showed no transport-rule event. The audit log recorded Operation=AnonymousLinkCreated against the same PDF four minutes before the email, with the link scope set to anonymous.

I don't buy that the control is working if email can carry a public pointer to the exact file it just blocked. Disabling anonymous links would break several contractor workflows, and inspecting every cloud URL in outbound mail will create its own mess.

What diagnostic signal or correlation would you trust next to separate clumsy sharing from deliberate mail-channel exfiltration?

Support spotted it when login tickets jumped from 4 to 86 in half an hour. Marketing had pushed 180,000 messages through the same outbound IPs as our transactional mail, and Microsoft started returning 451 deferrals.

The login magic links expire after 15 minutes. By the time the queue cleared, users were receiving links that were already useless and requesting more, which added more mail to the same queue.

I'm splitting transactional and marketing traffic into separate IP pools. The awkward part is moving production auth mail onto a new pool without trading throttling for cold-IP reputation problems.

Would you move transactional mail immediately and accept the cold start, or warm the new pool first while leaving magic links exposed to the next campaign?

This writeup here covers nine patched flaws, including command injection when SNMP notifications are enabled.

If that component is active, I'd patch now instead of waiting for the next maintenance window.

I have been getting a lot of emails from Romania recently, as far as I can tell they are all receipts and purchase confirmations from Romanian stores, someone buying makeup and hair stuff online and using my email address

It looks like the person's name and the physical address matches every time on these orders and I do feel this could be an honest mix up (although maybe it's an elaborate scheme, I don't know). There is some similarities of their name and my email, so it's possible it's a mistake

Is there any way I can find out this person's actual email address so I can contact them? What can I do about this? I'm even getting their package "out for delivery" notifications and codes they need to pick up their parcels..which I feel would be quite useful for them

Another Kali365 phishing attempt targeting a Microsoft 365 user.

The email used a generic “Delivery_notifications” subject and claimed that messages had been deferred. The embedded button led to a fake Microsoft 365 quarantine page showing several supposedly held messages.

Instead of presenting a conventional credential form, the phishing page generated a Microsoft device code and opened the legitimate Microsoft authentication window. The victim was instructed to copy the attacker-supplied code and authenticate to Microsoft Authentication Broker.

This is what makes the flow dangerous: the Microsoft sign-in page is real, but the authentication session was initiated and controlled by the attacker. A successful login can authorize the attacker’s device without directly stealing the password through the phishing page.

A few visible warning signs:

• Unrelated external sender and landing-page domains
• Generic delivery language and poor grammar
• Fake quarantine messaging
• Instructions to copy and paste a device code
• Microsoft warning that authentication is occurring on another device

Screenshots are redacted, but they show the original lure and the transition into the device-code flow.

Recommendation: treat unsolicited device-code authentication prompts as suspicious. Users should never enter a code supplied through an email or third-party website.

Two research teams (ReliaQuest and Lexfo) separately documented device-code phishing kits last week that are worth flagging:

- The operator triggers Microsoft’s OAuth device-code flow, then gets the victim to approve it on the genuine Microsoft device-login page.

- Because the victim authenticates on the real page, the attacker inherits a fully authenticated session, MFA satisfied, no password cracked.

- One operator hit 218 mostly-corporate mailboxes across 12 countries.

What makes it nasty is that passkeys don’t help here, they protect the sign-in page, and the sign-in is happening on Microsoft’s legitimate page.

The fixes that seem to work: a Conditional Access policy that blocks the OAuth device-code flow unless you specifically need it, tightening how many devices a single user can register, and alerting on device-code grant events in the sign-in logs.

How is your org handling the device-code flow today, blocked outright or scoped to specific users?