The $250 Donation Receipt That Nobody Authorized

The email arrived on a Tuesday afternoon. Subject line: "You're Making a BIG Difference!" It carried the logo of a youth mentoring nonprofit, a cheerful thank-you message, and a receipt for a $250 donation the recipient had never made.

The recipient was a financial professional at a regional accounting firm. The kind of person who would immediately recognize a $250 charge she didn't authorize, and the kind of person who would know exactly how to dispute it. That instinct to act quickly was the entire weapon.

A Receipt With Perfect Credentials

The email came from receipts@qgiv[.]net, the transactional sending address for Qgiv, a nonprofit fundraising platform owned by Bloomerang. The platform has been in operation since 2007. Its sending infrastructure routes through SendGrid (o1[.]em[.]qgiv[.]com, IP 167[.]89[.]23[.]145), and the domain's authentication is textbook-correct.

SPF passed. DKIM passed with a valid rsa-sha256 signature under d=qgiv.net. DMARC passed with compauth=100. Microsoft's own anti-spam headers returned SCL=1, barely above baseline. The X-Forefront-Antispam-Report tagged it SFTY:9.25, a safety tip indicating an external sender, but not a block.

Every authentication check did exactly what it was designed to do: confirm that Qgiv's infrastructure sent this message. The problem is that confirmation says nothing about whether the donation it describes is real.

The Receipt IS the Payload

There were no malicious links in the email body. The only URLs present were Microsoft's own safety-tip support pages, injected by Outlook's external sender banner. No attachments. No QR codes. No embedded phone number. The entire content was a standard donation receipt: date, transaction ID, donor name, amount, payment type.

The tracking pixel (url5833[.]qgiv[.]net/wf/open?upn=...) was a standard open-tracking beacon, common in transactional email. Nothing in the message gave URL scanners or sandbox engines anything to analyze. Content filtering had no keywords to flag. Link reputation engines had no URLs to evaluate.

This is what makes vendor platform abuse effective. The attacker doesn't need to build infrastructure, register domains, or craft HTML that mimics a brand. They use the brand's own tools to generate a real receipt on real infrastructure. The Microsoft Digital Defense Report 2024 documents this pattern as a growing trend: threat actors leveraging legitimate SaaS platforms as delivery vehicles, exploiting their high reputation scores to bypass filtering entirely.

The social engineering happens outside the email. A financial professional who sees a $250 charge she didn't authorize will take action. She might search for the nonprofit's contact information online (where attacker-poisoned results can intercept the query). She might reply to the Reply-To address, which pointed to a contact at the nonprofit's own domain rather than the sending platform. She might call her bank to dispute the charge, creating the exact type of account-verification interaction that enables downstream fraud. The receipt doesn't need to contain a malicious payload because the receipt itself creates the urgency that drives the victim to act.

The FBI IC3 2024 Annual Report recorded over $2.9 billion in BEC and related fraud losses, with an increasing share attributable to attacks that abuse trusted vendor relationships. The Verizon DBIR 2024 found the human element present in 68% of breaches, and social engineering remains one of the most effective initial access vectors precisely because it bypasses technical controls entirely.

See Your Risk: Calculate how many threats your SEG is missing

Infrastructure and Reconnaissance Signals

The attacker demonstrated clear reconnaissance. The donor name on the receipt matched the recipient's identity (same surname, same first initial in the email local-part). This is not a spray-and-pray campaign. Someone obtained or guessed the recipient's name and email address, then used the fundraising platform to generate a receipt that would land in her inbox with her own name on it. That personalization is what transforms a generic scam into a targeted vendor attack.

The sending path was clean: SendGrid relay (recvd-cbc75bd76-jbclg) to Microsoft Exchange Online Protection via TLS 1.3. The Return-Path used Qgiv's VERP-encoded bounce address (bounces+{id}-{hash}-{recipient}@em8579[.]qgiv[.]net), which is standard for transactional email and confirms the message was generated through Qgiv's actual platform, not a spoofed replica.

Three mailboxes at the accounting firm received the same message, suggesting a small, targeted campaign rather than a single test probe. The Reply-To header pointed to a different domain than the From address (the nonprofit's domain versus the fundraising platform's sending domain), a subtle mismatch that most recipients would never notice in a donation receipt.

MITRE ATT&CK maps this to Phishing (T1566) for the delivery vector, Establish Accounts: Email Accounts (T1585.002) for the attacker's use of a legitimate platform account to generate the receipt, and Phishing for Information (T1598) for the off-channel information harvesting the receipt is designed to trigger.

What Caught It

IRONSCALES Adaptive AI flagged this message through behavioral signals that authentication checks are blind to. The sender (receipts@qgiv[.]net) was a first-time contact for this organization. The recipient held a financial role, making her a high-value target for BEC and vendor fraud. The combination of an unexpected financial transaction from an unknown vendor, targeting a VIP mailbox, triggered Themis to classify it as a vendor scam at 87% confidence.

All three affected mailboxes were quarantined. The initial detection and quarantine happened within seconds of delivery. A second mailbox that received the message later was also quarantined automatically.

When the Platform Is the Problem

This attack exposes a structural blind spot in authentication-dependent security. SPF, DKIM, and DMARC answered the question "did Qgiv send this?" correctly. The question they cannot answer is "did the person named on this receipt actually make this donation?"

Vendor platform controls matter. Fundraising platforms, invoicing tools, scheduling systems, and payment processors all generate transactional emails that pass authentication. If those platforms don't verify the relationship between the account creating the transaction and the person named on the receipt, they become open phishing infrastructure.

Behavioral detection fills the gap authentication cannot. First-time sender from a vendor platform, targeting a financial-role mailbox, with a transaction the recipient didn't initiate. None of those signals appear in SPF/DKIM/DMARC results. They require AI analysis that understands recipient context, sender history, and content patterns.

Train for the receipt, not just the link. Most phishing simulations focus on malicious links and attachments. This attack had neither. The danger lives in what the recipient does after reading the email. Security awareness programs need scenarios where the "right" action (disputing a charge, calling support) is itself the trap. Organizations should establish internal escalation paths so employees report unexpected vendor receipts to their security team before engaging with the sender.

The IBM Cost of a Data Breach Report 2024 found that the average cost of a breach reached $4.88 million, with phishing as the most common initial attack vector. Attacks like this one, where the infrastructure is legitimate, the authentication is perfect, and the payload is psychological, represent the frontier that technical controls alone cannot hold.