In late January 2026 the accounting mailbox at a small consumer personal-care services business received the tail end of a conversation it had never had. Three lines of new prose asked for an approved invoice to be paid by ACH, signed with the display name of the company's own principal. Under them sat a two-message quoted invoice thread attributed to a CRM vendor's accounting team. That quoted block arrived carrying the state of the editor it was written in: sixteen paragraphs each holding a unique per-paragraph editing identifier, nine inert custom wrappers no mail client understands, and five grammar flags still open, three of them keeping a second divergent variant of the phrase they wrapped. The new prose above the quote uses ordinary mail-client styling, so the convention changes exactly where the quoting begins. Be precise about what that proves. It proves the quoted block passed through the sender's composition surface in the same session as the text above it. It does not prove the words were invented, because a stolen thread pasted into the same editor would leave identical marks. Fabrication was settled separately, from content: both quoted messages stamped at the same minute, a vendor apparently forwarding its own mail to the person who already had it, a quoted invoice number that disagrees with the one in the live subject, a company named in that subject and nowhere in the body, and an attached invoice claimed twice against zero attachments on the record. Nothing failed an authentication check, because the attacker owned every identity being checked: a sending domain eleven days old, a DKIM signature earned inside a bulk-mail provider, and his own DMARC record at p=none. Triage a quoted region as markup, not as prose. An operator can tidy up his timestamps; he cannot tidy up the document tree he pasted. (Link to full teardown in comments)

This phishing email is 41 words. The AI filter reading it saw 903. Text salting grew 9x in six months, and here's how it works.

Attachment triage runs on a binary: either a file executes something, or it is an empty prop meant to push you toward the link. On September 4 a business voice and unified-communications platform operator received a third kind of file. It was 847 bytes, named with a Voicemail_ prefix, ten digits and a doubled .mp3.mp3 suffix, and declared as audio/mpeg. The declaration came from the MIME header and the filename, not from the bytes: a content-based identifier returns unclassified binary data, because the file opens with an HTML document tag. Inside are two image references, each one pixel by one pixel, both pointing at the same open-tracking endpoint on a mainstream email service provider. That is the entire file. No script, no form, no macro, nothing clickable, and exactly one outbound request when it renders. The load-bearing detail is the token. The message body already carried its own one-pixel beacon on that same tracking host, and the attachment's token is a different one. Two independent open-confirmation channels in a single message, reporting separately, which means an organization that strips remote images in the body has closed one and left the other open. Two genuine MPEG frame headers were appended after the markup, at offsets 671 and 805, and neither had the 417 bytes it declared. The header table around them had been HTML entity escaped in transit, so the file could never play. That is the evidence the audio was never the point, not evidence of careful construction. Every automated layer called the message legitimate: the attachment verdict was Clean, the link verdict was clean, upstream anti-spam scored it at zero, and the automated analyst returned a spam recommendation rather than a phishing one. It reached the inbox. A person at the organization marked it malicious. Two changes worth making: treat a Clean verdict on a very small attachment as unresolved rather than safe, and count outbound requests per artifact. (Link to full teardown in comments)

Almost every Unicode abuse case works by destruction. The attacker takes a string a matcher would recognize, a brand name or a button label, and shatters it with invisible characters so the match fails. This kit did the inverse. Inside a button element carrying the class Recording it assembled a working-looking media player out of printing characters: U+2022 bullets at each end, a run of ASCII vertical lines reading as a waveform, and the Myanmar section signs U+104A and U+104B reading as a scrub handle and a play control. Five zero-width non-joiners sit inside the run, and a sibling element supplied a fake Call Durations: 0:54 Secs readout. The glyphs were not hiding a match, they were manufacturing trust. The incident record shows an empty attachment array, an empty OCR array and an empty QR array, and the only two image elements in the whole body were a first-time-sender banner we inject on the recipient side and an ordinary 1x1 open-tracking pixel. So OCR had nothing to read, perceptual hashing had nothing to hash, logo detection had no template and brand matching had no brand. Those controls were not defeated here. They were inapplicable, and the distinction matters operationally, because an image pipeline can tell you what it found inside a picture but it cannot tell you a picture is missing. Authentication was no help either: one external hop, SPF and DKIM passing and aligned under an enforced DMARC quarantine policy, on a domain about three and a half years old whose ownership status is not determinable from this record. What caught it was link and landing-domain reputation plus sender behavior: a first-time correspondent, a high risk rating, no prior exchange in either direction, and a call to action resolving through a tracker to a free-tier hosting subdomain. All four mailboxes were quarantined and a human analyst resolved it malicious. A message that offers a playable recording while carrying no audio file, no attachment and no image is internally inconsistent, and that inconsistency is computable. Score the affordance, not just the asset. (Link to full teardown in comments)

At 10:24 on a Thursday morning a customer-service representative at a residential trades contractor told a sender in writing that her team could not open attached files, and asked two verification questions. She did exactly what awareness training asks. Two minutes later, at 10:26, she had a reply. The sender had already pre-empted that objection fourteen minutes earlier, unprompted, volunteering that the file had been sent to it in that condition and supplying a device workaround before anyone had questioned the file at all. Across four logged turns in twenty-four minutes it gave three different accounts of why the file would not open, responsibility shifted away from itself, then file size, then no explanation at all, while one lowercase instruction to open the link on a particular kind of PC stayed fixed. Under pressure the story was not improved, it was abandoned. There was no attachment. The incident record shows an empty attachment array, and what looked like a native cloud-storage attachment chip was HTML: an anchor wrapping an 18 by 18 pixel icon hotlinked from a legitimate provider, in the typeface and thin grey border a real widget uses. Clicking it entered a commodity click-tracking redirect that expanded to a host on an attacker-registered apex with no MX, no published DMARC or DKIM, CDN-fronted, valid TLS. Authentication passed cleanly at every layer because nothing was forged, and the inbound gateway prepended its external-sender caution to every hop, so it appears four times in the message. It fired on all four turns and changed nothing. Link analysis closed this one, after every identity signal had pointed the wrong way. The control here is organizational rather than personal. Shared intake mailboxes that answer strangers for a living need a one-click report path and a standing rule that a refusal is escalated and never negotiated, because a correct objection is not a stopping condition while the only place to send it is back to the sender. (Link to full teardown in comments)

One message reached one mailbox at a North American cloud communications and managed-voice provider, and two hops on its delivery path stamped it with Authentication-Results headers that do not agree about who sent it. The provider's upstream inbound MTA wrote dmarc=absent and bound that evaluation to a domain named only inside the From display name. The final Microsoft 365 hop read the identical header and bound DMARC to the real envelope domain instead, recording bestguesspass and compauth=pass. One message, one From header, two values for header.from, and therefore two DMARC evaluations of two different identities. The From header carried exactly one real routable address, a mailbox on a hosted third-party domain, and everything in front of it was shaped like something it was not: a legal-documents brand label, a parenthesised second address at an unrelated domain, the bare word internal on a message the same stack had already tagged external, and a bracketed pseudo do-not-reply token. That divergent domain appears nowhere else in the message, not as an envelope sender, not as a Return-Path, not as a Reply-To, not in the body, and it returns no registration data at all, so nobody can say anything about it beyond the fact that a header string mentioned it. DKIM was none at every single hop, so there was no cryptographic identity anywhere on the path and each parser's own tokenization was the final word. A failure is a result. Absent is not. Alert when a From display name contains an address-shaped string, diff header.from across every Authentication-Results header on the message, and treat absent as unevaluated rather than acceptable. (Link to full teardown in comments)

Earlier this year a mailbox at a commercial facilities and property-services company received a message headed Official: Please Confirm Your Carrier Details, signed by the Federal Motor Carrier Safety Administration's carrier records office. Every check a gateway is built to run came back fine. SPF passed, two DKIM signatures passed with an identical body hash, DMARC passed in alignment, both URLs returned clean verdicts, and the sending domain had no bad history at the tenant, because the attacker registered and configured its own domain properly. The only thing in the message carrying information was the HTML. Thirteen paragraphs still had a browser's computed-style dump on them, orphans, widows, font-variant-caps and a hard-coded rgb colour, sitting under a markdown-renderer class name that belongs to no mail platform, and thirteen declared a first-position font family that is a web application's quotation-mark fix. Wrapped around that pasted block, not interleaved with it, was the attacker's actual send template: component classes, presentation-role layout tables and a framework comment marker left in the output. So two authoring toolchains are legible in one delivered body, and the boundary between them is clean. This is not a kit leaving traces of its own last run. It identifies the window the copy was written in, upstream of the send infrastructure that never touched it. The ask matched: a motor-carrier and DOT number, legal business name and address, and fuel-tax and payment-system details, to be entered at a lookalike registry host on the attacker's own apex. Carrier identity and payment accounts, not mailbox access. The control is cheap and content-side. Retain inbound HTML long enough to search it, then hunt print-layout properties like orphans and widows on body paragraphs, absolute rgb values applied inline at scale, and class-name prefixes that belong to no platform you receive mail from. (Link to full teardown in comments)

A document-invite lure reached a chief executive on September 4, and pasted into the same HTML body, below the lure, was a verbatim copy of the web console of the phishing service that sent it. The panel read like a SaaS billing page: an Enterprise plan marked active with 23 days remaining, a lifetime counter of 138,291 emails, three add-on meters all at zero, a tab strip from Send and Leads through SMTP Config and Proxy, and an empty-state line reading no saved campaigns. Then the working state: 4,043 leads loaded, one relay, 25 sends in parallel at zero delay, and a fifty-line delivery log of 250 response codes. The arithmetic proves it was live, not filler. Twenty-five sends across 26 seconds is 0.96 per second, displayed as 1.0, and the leads still queued at that rate produce the printed estimate of 69 minutes 18 seconds; the next batch recomputes to about 78 minutes and prints 78 minutes 12 seconds. Static text cannot carry estimates that integrate their own timestamps. The log named fifty real mailboxes at forty-nine uninvolved companies and we are publishing none of them. Two corrections worth making. This was not an authentication failure: the message passed SPF at the true inbound edge, DKIM was not evaluated there, the sending domain publishes no DMARC policy, and the failure pair visible downstream was manufactured by the receiving side's own gateway-to-relay topology. And nothing here was attacker-registered: the relay host dates to 2011, the sending domain belongs to a real insurance brand whose provider account was abused, and the landing page sits on a compromised legitimate website owned by a private individual. The receiving gateway fired three rules and totalled 0.50 against a kill threshold of 3.0, and the only one that scored anything was a non-standard-port URI, present solely because the operator pasted his own log. The defensive read is cheap. Kit banners, a lead-loader line, a repeating delivery log and a licence meter are ordinary body strings, easy to match and easy to score heavily, and this leak class is structural because kits invite the operator to paste custom HTML. (Link to full teardown in comments)

A tax-notice lure arrived with a one-page PDF attached, and the attachment scanned clean: 8,692 bytes, no JavaScript, no URI, no submit action, no auto-action. Its properties were emptier still, with an Info dictionary reading anonymous for author, anonymous for creator, and untitled for title. Inside those same bytes, in a compressed stream no text-extraction pass can read, the file carried a readable signed provenance manifest that names its generator: a c2pa.created action, a digital source type of trainedAlgorithmicMedia, a software agent string of gpt-5-5, a claim generator name of ChatGPT, and an X.509 leaf subject reading OpenAI OpCo, LLC. That is not a validated signature. The file was re-saved twenty-five days after signing and nothing re-signed it, so a validator run today would most likely report the manifest as tampered. The naming survived anyway, because whoever handled the file never stripped the manifest, and that is the finding. The body also insisted twice that the PDF was password protected with the password 2026, and one properties call reports encryption as false. The operator submitted through a shared hosting provider's authenticated SMTP as a customer mailbox, so the host signed it as the true sender, the sending domain publishes no SPF record, and DMARC passed on the DKIM leg alone under a policy of p=NONE. Two cheap queries follow. Alert on inbound mail that passes DMARC with spf=none, and add a provenance-manifest check to attachment triage right after the Info dictionary dump. Attachment provenance is two layers deep now, and the layer that is trivial to blank is the one everybody reads. (Link to full teardown in comments)