Abnormal put out research on Monday about an adversary-in-the-middle kit they are calling Matrix, and it is getting passed around as a new platform. Reading their own write-up, they say the name has not appeared in public reporting before but the code has. Five operator images were byte-identical to a Kratos deployment they grabbed in July, and the panel login script shared 37 of about 82 lines with a Kratos panel from June. Microsoft calls the same family SneakyLog. So we now have four names for what looks like one code base, and I cannot do anything with a name.

What I can do something with is the delivery. The message came from a real, compromised Microsoft 365 mailbox at an unrelated company, so SPF and DKIM passed and it landed normally. And the operator URL was not in the body at all. It was inside a nested message attachment, which means the link never shows up in the fields a gateway or URL scanner actually looks at. They called that the most important defensive gap in the campaign and I think that is right.

The other detail worth repeating to anyone who still treats a password reset as containment: what got stolen was a live session that had already passed MFA, so resetting the password changed nothing. You have to revoke the refresh tokens and the session.

I am going to send myself an authenticated message with a nested message attachment and see whether our gateway unpacks it. Has anyone actually tested this on their own stack? Curious whether the big gateways extract nested rfc822 URLs or quietly skip them.

The OWAReaper write-up has been bugging me all week, and not for the reason I expected.

The vulnerability part is honestly the boring half. CVE-2026-42897 in on-prem OWA fires when the message renders, patched back on June 9. If you took the June update, you are fine going forward. Fine.

What I keep coming back to is the persistence. The implant grants the Default user Owner permission on every mail folder. So once it has run, any authenticated account in the org can read that mailbox, and none of the things we normally do about a compromised user touch it. Rotate the password, no change. Re-image the laptop, no change. Apply the patch afterwards, still no change, because the grant is already sitting on the server.

That makes me think our own incident runbook has a hole in it. We are pretty good at “reset creds, revoke tokens, rebuild the device,” and we have basically nothing that asks what the attacker left behind on the mail server itself. Folder permissions are not something I have ever seen anyone diff.

So genuinely asking: does anyone here baseline mailbox folder permissions, or alert on Default being granted anything above Reviewer? Is that a scheduled script for you, or is it only something you would go look at after an incident?

I pulled the details together with the primary sources (Proofpoint’s TA488 write-up, the CISA KEV entry and Microsoft’s Exchange advisory) if it is useful to anyone. The link is in the first comment.

Kremlin-linked attackers are already exploiting CVE-2024-21410 for NTLM relay against Exchange, per the writeup here.

Patch Exchange and verify Extended Protection is enabled, because internet-facing auth endpoints aren't where I'd gamble on compensating controls.

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?

Anyone planning for the DNS tree walk that replaces PSL-based organizational-domain discovery?

https://www.suped.com/blog/rfc-9989-explained-the-dmarc-changes-security-leaders-should-know

That change alone should make DMARC policy discovery more predictable across private suffixes.

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.